Topics

1

Graphics / Why Sprite floats are evil

« on: March 23, 2008, 11:01:32 am »

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.

2

Graphics / Tileset/Sprite - Design question

« on: March 22, 2008, 11:19:33 pm »

Hello,

I'm pretty new to SFML. Previously I've been working with SDL and Allegro and they handle bliting differently than SFML with it's Sprites.

Suppose I have one tileset in form of one image. Now I want to draw a game map onto the screen (SimCity style). Now I don't know how this is supposed to be done with the Sprite class. Here are the possible ways the come to my mind:

1. Create a new Sprite for each blit. Meaning for each drawing operation in a frame create a Sprite use SetPosition, SetSubRect & Draw and then destroy it again.

2. Create each frame a new sprite then use SetPosition, SetSubRect & Draw for each tile and destroy the sprite once the job is done.

3. Same as 2. but with a sprite that has the same lifetime as the image.

4. For each tile in the set create one Sprite and then each frame use SetPosition & Draw to do the job.

5. For each map square on the screen create a Sprite and then use SetSubRect & Draw each frame.

Which of these 4 ways was intended to be used?

Should I think of a Sprite as a leight-weight throw away object (such as IntRect for example) or as a more resource intensive object?