I noticed you were having precision errors at large x/z values, suggesting there are smaller errors at smaller numbers as well. I had the exact same problem with a solar system simulation game I wrote a while back in C# with the requirements of scaled spheres to very large numbers (planets, moons, star) coexisting with smooth movement on very small scales (spaceships, people, small asteroids). I got jerky movement quickly when I tried this with the sun centered at 0,0 and the player starting near earth, which was like 09825702387,0,38205346987 on my coordinates system, I was using meters as the units (eventually) and I observed online that all the planets are arranged in a plane (except uranus and pluto) mostly for no known reason, so with y being my arbitrary vertical axis.... anyways, the trick was to internally store all the numbers as a high-bitcount precison type, a string would work although I was using the C# "decimal" high precision arraylist type variable with a variable bitcount to store internal high precision/high value coordinates. Naturally the vidcard/3d (I was using D3D, I assume ogl is similar?) would only take 32-bit floats and not decimals, so my trick was to take the player's location (on the render target system, not other players in multiplayer...also my game was called 'spaceflight' and 'near earth space', and I included the source, it might be online somewhere?), and subtract the player's decimals from the object's decimals, then convert into a 32 bit float to pass to the 3d function calls. The net effect was to programmatically use accurate numbers as normal, but in rendering to always center the player at 0,0,0 (+orientation), then position all the objects around the player. Since the internal numbers are accurate to meters or inches on that scale, and floats are very accurate when centered around zero, this allowed smooth movement on a small scale. Very large objects that were distant got rounded, and I had a formula to not render objects that had a high combination of smallness and far away from the player, along with a constantly sorted distance tracking arraylist so as to only update the closest things relative to the current player. Distant objects had jerky movement or inaccurate representation due to float rounding at large values, however since the sun is large and distant a small shift to a direction is not visible or noticable, and the true values are tracked via decimal internally to ensure actual accuracy in code.
notch has talked about it before.
a long time ago.
maybe a year and a half ago or so.
In the statement he made about it, he stated that he did know how to fix it, but he was going to keep it the way it was because (paraphrasing) "It is unlikely anyone will get to those locations without using a cheat of some sort, and the idea of a strange, faraway land is intriguing to me."
I have to emphasize this part. Your post is awful to read like this. If you want people to pay attention to your message then please take some effort to make reading it a pleasure.
The precision problems of floating point and how to work around them are well known. I doubt Notch and his team are so uneducated that they don't know about this.
Rollback Post to RevisionRollBack
Support the Allocator! Find my inventions such as my pressure plate removal detector on the About Me page of my profile.
I'm still looking for more feedback on my configurable Redstone Gate mod. All gates and common circuits (such as e.g. clocks, edge detectors, latches and Flip-Flops) in a single block.
Actually in 64 bit a decimal is 2 registers, a 'double double' type. Note that you are optimizing the wrong spot...in a 'big' map potential like minecraft you do need precision in some places, and the biggest delay here is the render call on the cube models, it calls render a lot and it's doing it in java3d and not a more native call like directx xna etc, if you swap the internal storage from doubles or floats to a longer type you probably won't affect the render loop speed much, although yeah all ops on bigger variables are slower, yet 'optimization' is not a simple thing and programming is an art , the real way to optimize might be something like not drawing cubes that are blocked by other cubes, or by drawing distant clumps of cubes as one larger cube, or other forms of optimization that are 'high level' typically grant the biggest boost, as well as the fast 'highly indented' loops where you can optimize those more carefully, and simply calling the directx functions from java right there might be a huge speed boost, not sure what the java syntax for calling a c++, managed c++, or c#/xna function is but i bet it exists, and probably 95% of the code is outside the render loop and the speed is almost irrelevant
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
a long time ago.
maybe a year and a half ago or so.
In the statement he made about it, he stated that he did know how to fix it, but he was going to keep it the way it was because (paraphrasing) "It is unlikely anyone will get to those locations without using a cheat of some sort, and the idea of a strange, faraway land is intriguing to me."
I have to emphasize this part. Your post is awful to read like this. If you want people to pay attention to your message then please take some effort to make reading it a pleasure.
The precision problems of floating point and how to work around them are well known. I doubt Notch and his team are so uneducated that they don't know about this.
I'm still looking for more feedback on my configurable Redstone Gate mod. All gates and common circuits (such as e.g. clocks, edge detectors, latches and Flip-Flops) in a single block.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDecimal types are processed entirely by software.