float type q, relating to seamless mmog
Author
Hi all,
I've asked this question on a different forum but I didn't get the answer I'm looking for, so I'm trying again. I'm designing a space MMOG. It's 2D, and the universe is seamless, there are no load-zones. The universe is separated into "zones" which contain all the objects within that area of space. All objects have X and Y float-type variables to store their positions. My question is how large these zones should be. I need to know what their MAXIMUM size could be. I guess I don't understand how the float type works... I know integer has a value of something like -32000 to 30000, but what is float's range? Does it depend on the number of decimal places used?
Thanks for the help
-Andrew
First, get this document, "What Every Computer Scientist Should Know About Floating-Point Arithmetic":
http://www.physics.ohio-state.edu/~dws/grouplinks/floating_point_math.pdf
Probably a _lot_ more than you want right now, but a good document to have on hand.
Second, decent information here: http://en.wikipedia.org/wiki/IEEE_754
It's hard to summarize floating-points... I'd suggest looking at the wikipedia page for a brief overview of how values are represented. Super-briefly, you could have values up to approximately 2^127. Freaking huge. And values down to 2^-126, freakin' small.
But there's a price; not every value can be exactly represented. Most values are going to get rounded to the nearest value that can be exactly represented.
Additionally, the density of values that can be represented using floating-point is not constant. As an example, the number of integers between 0 and 100 (using an int) is exactly the same as the number of integers between 1,000,000 and 1,000,100. That is not true of floating-point. IIRC, as the magnitude of your f.p. exponent increases, the numbers spread out. Which means if you try to use the full range of a float for your zone, as things move further out from the center of the zone, they'd start jumping.
Depending on exactly what you want to do, it may be better to represent certain values with fixed-point rather than floating-point. (In case you're not familiar, fixed-point uses integers and integer arithmetic.) You'll have a well-known range and even distribution.
http://www.physics.ohio-state.edu/~dws/grouplinks/floating_point_math.pdf
Probably a _lot_ more than you want right now, but a good document to have on hand.
Second, decent information here: http://en.wikipedia.org/wiki/IEEE_754
It's hard to summarize floating-points... I'd suggest looking at the wikipedia page for a brief overview of how values are represented. Super-briefly, you could have values up to approximately 2^127. Freaking huge. And values down to 2^-126, freakin' small.
But there's a price; not every value can be exactly represented. Most values are going to get rounded to the nearest value that can be exactly represented.
Additionally, the density of values that can be represented using floating-point is not constant. As an example, the number of integers between 0 and 100 (using an int) is exactly the same as the number of integers between 1,000,000 and 1,000,100. That is not true of floating-point. IIRC, as the magnitude of your f.p. exponent increases, the numbers spread out. Which means if you try to use the full range of a float for your zone, as things move further out from the center of the zone, they'd start jumping.
Depending on exactly what you want to do, it may be better to represent certain values with fixed-point rather than floating-point. (In case you're not familiar, fixed-point uses integers and integer arithmetic.) You'll have a well-known range and even distribution.
Fixed point is perfectly acceptable in this case.
The zones will be limited in size (after all, how far can a player walk/drive).
So if designing a real world, you'll likely base everything around 1m precision. Let's say you want to allow more precise placing, you'll need 1 cm at most. That can be quickly covered in a 32-bit int, leaving you with some 2^24 bits for your zone size (16,000 kilometers).
Each zone can (and probably should ) be its own coordinate system, and some form of indexing is the used to label individual zones.
Float or 32-bit int should really work in both of these cases.
But simply put - numeric ranges aren't as much of a problem (32 or 64-bit integers will cover more than enough), just make sure you look into the limits.
I also haven't tested this, but 64-bit ints might be even faster than floats, and more accurate for most cases, if you find yourself with really big zones.
But better yet - you cannot have large zones, or the purpose of zoning disapears. If you define a very large zone you'll also need to manage absurd numbers of objects. So each zone will likely be small (several kilometers on the side).
The only exception would be if you're planning on non-rectangular zones or dynamically adapted boundaries. There, accuracy is important, just so that an object doesn't end up in no-man's land, where neither of the cluster nodes will want to update it.
The zones will be limited in size (after all, how far can a player walk/drive).
So if designing a real world, you'll likely base everything around 1m precision. Let's say you want to allow more precise placing, you'll need 1 cm at most. That can be quickly covered in a 32-bit int, leaving you with some 2^24 bits for your zone size (16,000 kilometers).
Each zone can (and probably should ) be its own coordinate system, and some form of indexing is the used to label individual zones.
Float or 32-bit int should really work in both of these cases.
But simply put - numeric ranges aren't as much of a problem (32 or 64-bit integers will cover more than enough), just make sure you look into the limits.
I also haven't tested this, but 64-bit ints might be even faster than floats, and more accurate for most cases, if you find yourself with really big zones.
But better yet - you cannot have large zones, or the purpose of zoning disapears. If you define a very large zone you'll also need to manage absurd numbers of objects. So each zone will likely be small (several kilometers on the side).
The only exception would be if you're planning on non-rectangular zones or dynamically adapted boundaries. There, accuracy is important, just so that an object doesn't end up in no-man's land, where neither of the cluster nodes will want to update it.
Consider that you will have more than one zone visible at a time (4 at a corner) and you may want a 'window' of adjacent zones loaded in memory at once.
You want to finish loading zones before you ever need to display them so
you probably would need something like 5x5 so that you will always have a full zone to traverse and a zone beyond that already in memory while you wait out the delay to load the next row of adjacent zones way ahead of your ship. As you cross into the next zone from the current center, it is time to unload the zones behind you and load the ones ahead.
The size of the zone should be as large as the distance your ship can move at max speed for a period equal to the longest disk load delay (for a row of zones).
If there are alot of contents in the zones you can use a larger window of smaller zones (ie 7x7 or 10x10 ) so you load less data more frequently.
If you want a huge map (or tiny details requiring small fractions simultaneously on a medium map) you want as much precision in the mantissa of the float. 14 digits of accuracy can do something like the distance to Pluto in millimeters which might be too small for interstellar distances if you want millimeter details. Even if you did feet (300x larger) its still way too small for even a lightyear.
Of course you may not need to use real distances and could use selective compression to get number ranges that will all easily fit in the double float's range.
You want to finish loading zones before you ever need to display them so
you probably would need something like 5x5 so that you will always have a full zone to traverse and a zone beyond that already in memory while you wait out the delay to load the next row of adjacent zones way ahead of your ship. As you cross into the next zone from the current center, it is time to unload the zones behind you and load the ones ahead.
The size of the zone should be as large as the distance your ship can move at max speed for a period equal to the longest disk load delay (for a row of zones).
If there are alot of contents in the zones you can use a larger window of smaller zones (ie 7x7 or 10x10 ) so you load less data more frequently.
If you want a huge map (or tiny details requiring small fractions simultaneously on a medium map) you want as much precision in the mantissa of the float. 14 digits of accuracy can do something like the distance to Pluto in millimeters which might be too small for interstellar distances if you want millimeter details. Even if you did feet (300x larger) its still way too small for even a lightyear.
Of course you may not need to use real distances and could use selective compression to get number ranges that will all easily fit in the double float's range.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
