Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Mybowlcut

Member Since 30 Nov 2006
Offline Last Active Nov 06 2014 12:39 PM

Posts I've Made

In Topic: Behavior / AI middleware MASA LIFE

16 April 2014 - 02:58 PM

So is the code cross platform? Is it just the Unity editor that only runs on Windows?

 

 

 

Important: This product runs only on Microsoft Windows operating systems. Furthermore it contains a pre-integration interface for the game engine Unity3d and it does not contain an SDK.

 

I would love to have something like this for my game, but at 500 euro, it's too much for me.


In Topic: Forging Life - An indie RPG game

17 November 2011 - 02:10 PM

Very cool. I have had a similar idea for a while now - except in mine you could build traps to capture animals, use basic tools to hunt etc. Also, mine wasn't planned to be 3d. :P Which technologies are you using for this? Also, I notice that your names are Scandinavian? Where are you guys from?

In Topic: Expecting calculation to be 0

07 November 2011 - 04:20 PM



In other words, your expectation of not losing precision in that process is unreasonable. Now, if the rest of your code is robust enough, whether you get 0 of -1.5308086E-15 shouldn't make much of a difference.

How would I ensure that it is? I'm assuming it's something to do with what haegarr said:

Notice that small errors may become a problem when being accumulated. E.g. concatenating many rotations will yield in a non-uniform scaling deformation because the small errors summed up will leave you with a non-pure rotation. If you have a situation like that you need to be up against it. Another situation is where precision plays a role, e.g. at marginal cases in point in polygon tests. In such cases you need to use precise data types and functions.


In the case of a rotation matrix that ends up not being orthogonal, you can re-orthogonalize it every few frames. If you use a quaternion it's actually easier to do.

Point-in-polygon tests are tricky. Ideally it should be the case that for a point on the border of the polygon it doesn't matter much whether you classify it as inside or outside.

Anyway, you didn't say what you will do with the result, so it's hard to tell if you'll run into trouble. You should educate yourself about how floating-point numbers work. There's just no way around it.

The function in question will be used for entity movement throughout a level.

The 'What Every Computer Scientist Should Know About Floating-Point Arithmetic' is beyond my knowledge of math. I'm satisfied with the result of this thread anyway - it seems that it's inescapable so I'll let it be until it actually affects the game.

In Topic: Expecting calculation to be 0

07 November 2011 - 03:03 PM

Values directly along the x axis do return 0 if you measure along the y axis. The problem is that you cannot represent pi/4 exactly as a floating-point value, and you don't get something that is directly along an axis if you take another axis and rotate it by an amount that is close to pi/4 but not quite pi/4.

Oh, ok. Probably had a lot to do with the fact that I thought the value I was getting was larger than it was, as well. :s

In other words, your expectation of not losing precision in that process is unreasonable. Now, if the rest of your code is robust enough, whether you get 0 of -1.5308086E-15 shouldn't make much of a difference.

How would I ensure that it is? I'm assuming it's something to do with what haegarr said:

Notice that small errors may become a problem when being accumulated. E.g. concatenating many rotations will yield in a non-uniform scaling deformation because the small errors summed up will leave you with a non-pure rotation. If you have a situation like that you need to be up against it. Another situation is where precision plays a role, e.g. at marginal cases in point in polygon tests. In such cases you need to use precise data types and functions.


In Topic: Expecting calculation to be 0

07 November 2011 - 02:38 PM

Looking at the bit pattern makes sense if you are checking something like a relative error. If you want to compare to zero, checking if the absolute value is less than epsilon is actually much more reasonable.

What is it you are trying to do that requires checking if the number is 0?

If you look at the original post, I want to make sure that the method returns 0 and not -1.5308086E-15 for the y axis when an angle of 90 degrees is passed in. Everyone is saying it involves floating point comparison, so that's why we're discussing how to go about it.

Edit: A similar value results from an angle of 270 degrees (4.5924254E-15). What I want is for values directly along the x axis to return 0 during a calculation only involving movement along the y axis, as seen in my original post.

PARTNERS