# how do you store positions?

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

## Recommended Posts

hi, how do you guys store your positions in a networked game? positions of objects, that is. im doing 2D w / OpenGL, so i store positions as floats. however, i dont think that an X/Y position will ever get near 65,536.... that would be a HUGE map, and i can live with limited my map sizes to smaller then 2048x2048... anyway, the point is, i can probably store my positions as unsigned short int's. this would cut the size in half of positions. however, im concerned this will make me lose precision. this might be more of an OpenGL question, but, will i lose precision if i store my coordinates as unsigned short's ? what do you store positions as? thanks for any help.

##### Share on other sites
Define a type for positions, eg typedef unsigned short POSITION;

That way if you ever get an overflow or something you can easily upgrade your type.

##### Share on other sites
Quote:
 Original post by graveyard fillahi,how do you guys store your positions in a networked game? positions of objects, that is. im doing 2D w / OpenGL, so i store positions as floats. however, i dont think that an X/Y position will ever get near 65,536.... that would be a HUGE map, and i can live with limited my map sizes to smaller then 2048x2048... anyway, the point is, i can probably store my positions as unsigned short int's. this would cut the size in half of positions.however, im concerned this will make me lose precision. this might be more of an OpenGL question, but, will i lose precision if i store my coordinates as unsigned short's ? what do you store positions as?thanks for any help.

You could also use whole numbers as fractions -- 1/8 of a position increment -- so you could send a bit more precise than by whole increments.

How much accuracy you need is dependant on how critical your coords on the client side have to be. (you could even goto 1/16 if you want to handle the sign by using UINT16)

You may have to investigate if mult/divides are faster than using Shifts F = I >> 4; when you need to do conversions.

##### Share on other sites
We use a 13:3 fixed point format for coordinate storage and 20:6 for calculations (through a custom fixed point template class)

This works well for a networked 2d game and I suspect that you'd get away with sending 16-bit coordinates in most (indoors) 3d games too.

However I wouldn't recommend storing them as 16 bit integers internally. The only reason that we use fixed point is to guarantee deterministic behaviour (due to a slightly unorthodox networking model).

##### Share on other sites
I feel that 13:3 really isn't enough on the decimal point side. I find that millimeter precision is barely enough for things that use actual physics. That would mean 13:10 fixed point for about 5x5 km levels, or about 24 bits to round it to bytes.

For velocities and forces, you probably want to be even more precise than that, because otherwise quantization effects will be very evident when standing "almost" still.

##### Share on other sites
Quote:
 Original post by hplus0603I feel that 13:3 really isn't enough on the decimal point side. I find that millimeter precision is barely enough for things that use actual physics. That would mean 13:10 fixed point for about 5x5 km levels, or about 24 bits to round it to bytes.

Agreed. To get away with 3 bits you'll pretty much need a fixed time step for physics (16 Hz in my case) and avoid any complex procedural calculations (i.e. just not worth it in most cases).
It's not as bad as you'd think though, for instance I was almost chocked to discover that it's enough to for a prodecural ninja-rope.

Use 32-bits or even 64-bits internally. Fixed point can still be useful (you won't loose any precision when dealing with large worlds, which can be a serious problem).
But don't choose your coordinate system for storage or speed reasons.

However for most games there's no reason the serialisation format has to match the internal format. So why not use variable length integers with a few bits of decimal precision for sending over the network? That way you don't have to worry about limiting the world's size and still get the benefits of 16-bit integers in most cases and maybe even 8-bit integers for velocities.

[Edited by - doynax on October 7, 2004 5:44:06 PM]

##### Share on other sites
Quote:
 To get away with 3 bits you'll pretty much need a fixed time step for physics.

What is your basic unit? If your basic unit is meters (and thus 13 bits give you +/- 4 kilometer levels) then 3 bits means you can't place things more accurately than about five inches. If your unit is feet, it's still worse than inch accuracy. If you're trying to accumulate velocity into that, quantization will kill you.

Quote:
 for most games there's no reason the serialisation format has to match the internal format

If you run everything in sync, and usually send user input between server and client (rather than full state), then you have to round your internal variables to the serialized precision, or the server and clients will diverge.

If you blat out positions every so often, and don't have too many entities, and use floats internally for your interpolation, and hide lag/jitter from the network input using sliding interpolation, then something coarser is probably going to work a little bit better.

##### Share on other sites
Quote:
 Original post by hplus0603What is your basic unit? If your basic unit is meters (and thus 13 bits give you +/- 4 kilometer levels) then 3 bits means you can't place things more accurately than about five inches. If your unit is feet, it's still worse than inch accuracy. If you're trying to accumulate velocity into that, quantization will kill you.

Heh, we're european so it's not in feet ;)
It's a fixed resolution 2d game so the natural unit is pixels. 8 subixels of accuracy has been enough so far and the remaining 13 bits gives us 8x10 screens to work with (in 512x384. loosing one bit as sign).

Quote:
 Original post by hplus0603If you run everything in sync, and usually send user input between server and client (rather than full state), then you have to round your internal variables to the serialized precision, or the server and clients will diverge.

The formats must match since our game uses input reflection and p2p. This reduces the lag a lot but introduces many new problems.

In retrospect I can say that it probably wasn't worth it though. A system with "dumb" clients (something like q3's networking model) seems like a much better choice for just about everything except a RTS or MMORPG.

##### Share on other sites
hi guys,

thanks for your replies. i actually didnt even know what a fixed point variable was untill this thread. after some googling, i think i get what they are...

so the general consensus is that i should make my own fixed point type and use it? why not just send a float over the wire?? just to save a few bytes??

thanks again everyone.

##### Share on other sites
"Saving a few bytes" per packet, per player, per second, is quite important in networked games over the Internet.

If your game doesn't send a lot of traffic, or doesn't have a lot of players, or is LAN only, then sending full floats is going to work fine, be less trouble, and easier to implement.

• 13
• 18
• 29
• 11
• 28