By using integers, I was meaning that the 'scale' of a DBPro unit would be more like 1 unit = 1 inch, then positioning would snap into this 1 inch grid because the data would be stored as integers.
If your world was 100x100 DBPro units then integers wouldn't give a lot of scope, you'd be better off using floats, and at those ranges accuracy should not be a problem.
I never store positional data as floats, always integers, but I prefer big ranges, typically 100x100 DBPro units per terrain tile, so if a terrain was using a heightmap of 256x256, the game world would be 25600x25600. In that sort of scale, integers are fine and more robust.
There's another thing - rotation angles, why not take your angles and wrap them and divide by 1.5 - then you have a range of 0 - 240. 240 is a very very divisible number, and can be stored as a byte, and gives you 15 extra control values that you just don't get with other methods without an extra variable. Maybe an angle of 241 is a slow spin, 255 is a random angle, 250 to 252 could be the hands on a clock that show the system time!.
I'm using this for a 2D collision system that has to be super fast, so the angle and distance of a point can be stored as a stream of bytes - the distance is 0-255, and is a multiplier depending on the size of the sprite. I'm using those 15 control values to specify points, box, circle, line etc.
It's a good way to show your data who's boss! - 360 degrees is too much freedom anyway, I mean we are talking about loosing half a degree of resolution accuracy, but gaining the option of storing it as a byte, meaning 1/4 the memory usage.
