Why Sprite floats are evil

[Ben]

I don't think sprites should use floats to position themselves. I understand that motions seem more fluid if the position doesn't have to be an integer but floats have several problems (and don't even always solve the original reason why using them!)

• Floats are a lot slower than plain integers. There are a lot of Sprites which don't move (think of controls, background,...) and I don't like the idea of paying for something that I don't use.
• Floats don't have a fixed precision. In fact the precision depends on the size of the value. In 2D this means that the precision depends on the distance to the origin (the 0,0 point). If you are very far away from it you will even have a precision that is smaller than those of plain ints (which means a+1 == a).

Think of an object that flies out of the screen makes a long turn and comes back into the screen (rocket, planet,...). It could actually get stuck somewhere outside of the screen because it's velocity is smaller than the float precision. (improbable but possible)

The very mean thing is that if you follow the object you will most likely move the origin and therefore the bug wont occur. A bit like quantum physics. The bug doesn't occur when you look at it.

I have debugged such a problem in the past and it was really a pain to figure out the reason.

Look at the following code:

Code: [Select]

float a = numeric_limits<float>::max()/1000;
float b = a-100000000;
float c = a - b;
cout<<c<<endl;
c will actually be 0. That's an error as big as 10^8 that's more than any screen is width.
[/list]
I see to possible solutions:

• Use plain old integers.
• Use fixed point numbers. These share many of the arithmetic instructions with the plain old integers (especially addition, subtraction and comparison) so should in most situations perform just as fast as plain old integer. Furthermore there precision is independent of the distance to the origin. The rocket wont get stuck outside of the screen. Furthermore the goal of smooth motions is also met.

[Laurent]

Floats are a lot slower than plain integers. There are a lot of Sprites which don't move (think of controls, background,...) and I don't like the idea of paying for something that I don't use.

Come on man... We're not in the 80s, today's processors have efficient FPUs. Do you know any 2D or 3D engine using integers ? Do you think your GPU is using integers for 3D calculations ?
In fact, you would pay for that if I used integers, as the graphics API (and then the GPU) is taking floats as input.

I see to possible solutions

I see another one : instead of bothering 99.9% people with integers and make them use their own float variables, I suggest keeping floats to make 99.9% of users happy and bother the 0.1% of users who will actually need such high precision.

I think people needing high precision will be much more aware, and be much more efficient to handle the possible issues, than the average beginner who will just wonder how to make a sprite move smoothly with integer coordinates.

Anyway thanks for the feedback, it's still important to know that no solution is perfect and can lead to different issues

[Ben]

I think you missed the main point. Efficiency is one point in favor of integers but only a small one. The major issue I have with floating points is that this way Sprites will behave differently depending on their position. In most situations this effect can be ignored but if you run into one of the situations where it does bit you will run into a brick wall. Also I didn't suggest using integers but using fixed point numbers.

PS: In the documentation for Image::SetPixel the reference to Image::Update seems outdated. (I'm using the current stable version.)

[Laurent]

As I said, if you really have precision issues then use fixed-point or whatever you want on your side. I'm not forcing people to use floats for all their calculations.

I agree with what you say, but I still believe that a lot more people will benefit from keeping float coordinates than using other stuff.

PS: In the documentation for Image::SetPixel the reference to Image::Update seems outdated. (I'm using the current stable version.)

You're right, thanks

[zarka]

hmm since sfml offers a verry hand class called Drawble which you can inherit from it would be such a pain to write your own intSprite and make sure to call OpenGls integer functions insteed of the float functions

[Lord Delvin]

I see to possible solutions:

Uhm?
double is your friend;)
cast it to float for screen coordinates and you wont have ANY problems;)
btw. double is not slower on 64bit systems and you dont need to worry of memory or precission in your project...you need a really big project to waste a normal systems total memory with a 2D game. (unless you didnt notice delete:P)

[Laurent]

Calling OpenGL integer functions would be useless, as the driver internally uses floats and will do the conversion. OpenGL functions taking integers or doubles are for convenience only.