Maximum X coordinate. Size of float

[AncientGrief]

Hi everyone,

I just wondered how far away from the origin I can draw a sprite. I guess the maximum is FLT_MAX (1E+37)?

//The maximum I can enter without getting warnings and display errors
float x = 99999999999999999999999999999999999999.f;
sprite.setPosition(x ,-25.f);
 

So on my computer, this should be the highest X-Coord possible I guess?! Or am I missing something (I sure am missing something! Sounds too enormous to me...I could let my character walk to the right for a long time without worrying about an overflow.)?

Thanks in advance 

[Grimshaw]

When using the float type in C++, the precision decreases as the number grows bigger..

To cut the story short, it is usually recommended in game engines that you keep your coordinates within -30.000 and 30.000, which is usually a relatively "safe" area to work with. Also, don't make things too small or that can also give you trouble.

Once you start going with numbers way far from these limits, you may experience big errors in your math and jittering..

[AncientGrief]

Hi Grimshaw,

thanks for your answer . I guessed so. So I will try to keep a defined MAX size, if the player goes beyond that point, everything will be reset to "zero" except the map tiles.

[Nexus]

Big numbers are not a problem on their own, but as mentioned by Grimshaw, they become less precise. If you take "floating point" literally, the decimal point is floating (it can move its position between the digits), meaning that higher numbers have fewer bits to store the decimal part.

I wouldn't say +/-30 is the area where you should keep your coordinates, it totally depends on the application. The rounding error from adding velocities to positions usually doesn't accumulate so fast; there are other issues like Euler integration (instead of more precise RK4, for example) which impact calculation to a much higher degree, independent of the precision.

Furthermore, keeping numbers small doesn't really solve the problem, it literally shifts it (by some decimal points). You will automatically have smaller values for velocities and other attributes, so you're essentially scaling everything. It is usually reasonable to let coordinates represent a meaningful metric in your game, for example meters, pixels or tile lengths. Use numbers that make sense and are easy to debug, it's very unlikely that you reach the smallest or greatest possible number in normal scenarios. And don't forget that if there are actual problems with respect to precision, C++ also offers double and long double; but don't use those types prematurely, as they will only require casts (SFML is working with float anyway).

And a max size is definitely one of the most unintutive things the player will encounter when playing your game. Don't introduce bugs where there are none.

[Grimshaw]

What are you trying to achieve?

Let's say 1 unit = 1 meter, and you can run at 2 m/s, that gives you a immensely huge map already. You probably DON'T need to handle anything at all, if you are a bit careful building up the maps to be within certain constraints.

In case you want really huge worlds or even a pseudo-infinity, what is usually done is to forget about absolute coordinates, and subdivide the infinite map in cells, in which one the objects have local coordinates. But don't go that way unless you have a really good reason

EDIT: I second Nexus there. The seemingly random numbers I thrown were in relation to graphics coordinates. You will usually want to scale down all values in a physics simulation for example. That's a common practice. When I said 30.000, it was just an estimation for an average case, take it with a pinch of salt and see what works for you. That number is merely a suggestion made even in big engines like unity.

[AncientGrief]

What are you trying to achieve?

This :

In case you want really huge worlds or even a pseudo-infinity, what is usually done is to forget about absolute coordinates, and subdivide the infinite map in cells, in which one the objects have local coordinates. But don't go that way unless you have a really good reason

I thought about it a couple of days and came up with a "local coordinates" solution too. It doesn't even make sense if my entities have positions like 2425634x23136572 ... this seems just weird hehe.

I am planning to have a streamed world. Like Gothic, but in 2D.

With a tile size of 64x64 I sure have a lot of space to all directions, but before I even start to code, I want to make sure I won't get stuck because of shifting problems etc...

Thanks for your long answer, Nexus
What exactly do you mean with:

And a max size is definitely one of the most unintutive things the player will encounter when playing your game. Don't introduce bugs where there are none.

Extra:
I thought about this scenario:
(E.g. map sizes are 3000x756)

-3000       0            +3000
| PREV MAP  |  ACTIVE MAP | NEXT MAP |
 

ACTIVE MAP starts at (0,0). if the user leaves the map to the right and enters NEXT MAP. All Coords get reset.
NEXT MAP is now (0,0) and the entities get all set to position entity.posX-MAP.WIDTH.
PREV MAP will be delete from memory, and a new one will be loaded to the right.

Thanks for your great answers so far, I will have to read something about Euler integration. Train my brain a bit

[Nexus]

Ah, I thought you simply want to set everything to zero that exceeds a certain number, without a smooth transition to the next tile.

Still, I wouldn't use the approach of resetting coordinates unless you really need to. Because it makes everything more complicated: You cannot simply compare two positions with relational operators, and operations near the border (such as collisions) require special treatment. You can still provide a conversion function to relative coordinate, based on std::fmod().

For Euler and RK4 integration, this article is a good start. I'm not saying Euler should generally be avoided, I just wanted to show that there are more important factors to keep in mind than pure floating point precision. Note that the article author explicitly talks about physics simulations, which are expected to be very precise and run for a long time; not every game needs RK4. Some don't even need acceleration.

[AncientGrief]

Still, I wouldn't use the approach of resetting coordinates unless you really need to. Because it makes everything more complicated: You cannot simply compare two positions with relational operators, and operations near the border (such as collisions) require special treatment. You can still provide a conversion function to relative coordinate, based on std::fmod().

A small example depending on my previous post:

- Player is @ Position X=2999(ACTIVE MAP) and an enemy at x=3100 (100 pixels inside NEXT MAP).
- Player runs toward the enemy and crosses the map border. All loaded maps are "shifting to the left".
- Player is now @ X=0 and the enemy @ x=100

Maybe I am missing something, but collision detection should work as normal, since the active map is always located at (0,0).

Another thought:
A cutscene is playing and scrolling to the next Map. Since it's prleloaded in memory the View can move beyond the active map's border and show the player what's coming toward him.

This approach just makes sure, that if the viewport "leaves" the map, the next map is already visible.

[Nexus]

Is there a continuous transition between maps?

If yes, then you make things complicated with player.x = 2900 and enemy.x = 100 (absolute 3100). Because enemy.x < player.x, it looks like the enemy is to the left of the player. You have to write additional code for all such cases.

If there is no continuous transition (the player can only be in one map at a time and there are clear borders), then I don't see why more than 1 map must be loaded at any time.

[AncientGrief]

Is there a continuous transition between maps?

Yes, there should be continuous transitions, like it's a huge single map.

I don't see the problem :/

PREV,ACTIVE and NEXT Map are active.
So, if I have 3 maps (width=3000px each) I have a span from -3000 to +6000
If the player moves outside the center/active map (pos=3000) into the NEXT map, all entities and tiles shift to the left. Like bit shifting

A small illustration:
Green = Player
Red = Enemy
(Player runs into the next map)


The only coordinates I have to take an extra eye on are the coordinates of all entities on the neighbour maps.
I have to Add (-/+)3000px to their initial position.

I just want to keep the coordinates in a normal range. If I wouldn't reset the coordinates and shift the maps I would end up at position 30,000 after 10 maps and so on.