• 13
• 16
• 27
• 9
• 9
• ### Similar Content

• While looking out for that pesky Terrator, our little alien is doing a bit of relaxed mining down on the new gas planet "Lelantos" this weekend....

• I have a native iOS game (objective c, XCode build) which I am considering to port to other platforms.
Core gameplay is based on solely on geographical maps, and custom drawing over maps. It also has Core Data. This part is complete in development.
What is not done yet is: monetization, gamification (leaderboards, challenges) and multiplayer functionality.
As I think more about it, I am tempted to think if this is the right time to move to a cross platform tool such as Unity. But before dedicating time to port my 5 years side-project effort in Objective C, I really want to know if its worth it.
- Does Unity support such plugins / assets that will fulfill all my above requirements?
- Unity Personal seems to have only 20 concurrent users - is it too costly scaling if I decide for extending to web and android platforms?
- What is the general workflow involved in publishing to iOS, Android, PC, and web platforms while using Unity? I mean to ask about various points of signing stuff, paying fees and getting certified.
- How long will it really take to port my entire Objective C project into Unity? I am somewhat familiar with C# but I am finding it hard fidgeting with Unity IDE as lot of things are focused around FPS and 3D while my game is still 2d - not much action involved. I seem bit overwhelmed by the list of features I see there. All in all, I do not want to lose my momentum while still making sure its portable to everywhere.
- Any assets I could use (for free to try basis in debug) that are relevant for my game?
- Last but not the least, are there any costs that I need to be paying upfront to Unity, for using it (apart from their monthly subscription model)? I don't understand their costing for multiplayer in conjunction with their subscription fees - if someone could kindly elaborate.
• By GytisDev
Hello,
me and few friends are developing simple city building game with unity for a school project, think something like Banished but much simpler. I was tasked to create the path-finding for the game so I mostly followed this tutorial series up to episode 5. Then we created simple working system for cutting trees. The problem is that the path-finding is working like 90% of the time, then it get stuck randomly then there's clearly a way to the objective (tree). I tried looking for some pattern when it happens but can't find anything. So basically I need any tips for how I should approach this problem.
Use this image to visualize the problem.
• By aymen
please any know how can i' calculate the centroid from any number vertices

• Good day sir/maam. I am developing a game for my thesis and im done with multiplayer and plan to start the implementation of AI but i dont know how/where to start. Please give an advice. I am developing it in C# using UNITY.
Im am now collected all pieces that has possible moves but i am stuck on which best move to select. I hope you will help me. This is link explained the game https://en.wikipedia.org/wiki/Game_of_the_Generals

# Unity Divide by zero - not an error?

This topic is 3715 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I asked this as part of another post (here), but for this particular problem, I think I'm more likely to get answers here. I wrote some code that might occasionally divide by zero, but I only realized it after I wrote it. I then stepped through it with a debugger, and whenever a float was divided by zero, the result was something like 1.INF. In that particular code it doesn't seem to be a problem because those numbers are apparently not used (the numbers represent clip-space (and then screen-space) coordinates which are later clipped), but is it safe to do any calculations with these numbers? Am I just getting lucky?

##### Share on other sites
It's safe in the sense that your program will not die as a result of this. However, using these values will eliminate any hope of numerical stability in your program, so you should either make sure they don't appear, or design your program so that these values are correctly handled when they appear.

##### Share on other sites
I've also seen some pretty severe performance problems from using those "special" floating point values.

##### Share on other sites
Quote:
 Original post by ToohrVykusing these values will eliminate any hope of numerical stability in your program

I don't know if that part of the code needs numerical stability, but hopefully that will be answered in my other post.

Quote:
 Original post by Evil SteveI've also seen some pretty severe performance problems from using those "special" floating point values.

Could you please give some examples or point me to a resource that discusses this?

Thanks for the help so far.

##### Share on other sites
Quote:
 Original post by Gage64I wrote some code that might occasionally divide by zero, but I only realized it after I wrote it.

Might we see the code in question?

##### Share on other sites
Here is one such article, though it's rather old.

Unless you have floating point exceptions enabled (off by default) for division by zero, you will not get a fault as you would with integer division. You just get infinities, as you've observed.

##### Share on other sites
Quote:
Original post by Gage64
Quote:
 Original post by Evil SteveI've also seen some pretty severe performance problems from using those "special" floating point values.

Could you please give some examples or point me to a resource that discusses this?
I don't have any resources really, I had some raytracing code that wasn't working correctly and causing divisions by zero. That code took 4 times longer to run than the code that was correct and didn't cause division by zero (Although the code complexity was pretty much identical). This is probably an extreme case though, since I was doing thousands and thousands of floating point calculations.
I assume it's throwing floating point exceptions, and I know you can turn them off, but I never got around to testing that.

##### Share on other sites
Quote:
 Original post by ZahlmanMight we see the code in question?

Here it is:

Vector2 project(const Vector3 &p) {	// Perspective projection	float x = p.x * distanceToCamera / (p.z * aspectRatio);	float y = p.y * distanceToCamera / p.z;	// Viewport mapping	int w2 = width / 2;	int h2 = height / 2;	return Vector2(x * w2 + w2, -y * h2 + h2);}

This function takes a vertex in view space and projects it to screen space (it's part of a software renderer I'm working on).

Initially I didn't do any clipping to the near clipping plane (but I did do clipping in screen space). When an object moved behind the camera, I sometimes got inverted projections (because of the division by negative Z), and sometimes the program crashed, but I thought the crashes were normal because they were caused by a division by zero. When I added clipping to the near clipping plane, everything worked normally.

However, in my renderer, I calculate the view-space and screen-space positions before doing any clipping (I am basing the architecture of my renderer on this article), so I realized that I can still get a division by zero, but the crashes stopped. Now that I think about it, I don't know what was causing them (I don't have the old version of the code so I can't check).

So I'm basically wondering if this will cause a problem, either with performance or with program correctness in general. If you need to see more code, let me know.

##### Share on other sites
Be careful with this, though.

On a technical c++ note, the result of divide by zero is undefined behavior. Specifically:
Quote:
 If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined, unless such an expression is a constant expression (5.19), in which case the program is ill-formed.[Note: most existing implementations of C++ ignore integer overflows. Treatment of division by zero, forming a remainder using a zero divisor, and all floating point exceptions vary among machines, and is usually adjustable by a library function. ]

In other words:

Your implementation *may* give you an INF.
Your implementation *may* give you an NAN.
Your implementation *may* throw an exception.
Your implementation *may* yield "3" (or any other number) and carry on like nothing happened.
Your implementation *may* have different results every time you run it.
Your implementation *may* have different results in different builds.
Your implementation *may* call abort() or terminate().
Your implementation *may* crash the machine.

Any code you write that depends on the behavior of your particular compiler and/or chipset, and is non-portable.

In this case, you can let the floating point exception happen, and take the appropriate performance penalty of 1.INF computations. But it is NOT a portable behavior, it isn't guaranteed to work in the future or on other compilers, and it is NOT a "correct" program (as you mentioned in the post above.)

##### Share on other sites
Quote:
 Original post by frob...

Well that's exactly what I was afraid of. I could check for a divide by zero, but that will cause a severe performance penalty and some of the benefits mentioned in that article (like the division by Z occurring simultaneously with the transformation) will probably disappear.

What bothers me the most is that the article doesn't say anything about this. I can certainly believe the author might rely on non-portable behavior, but in that case I think he should at least give a warning.