# Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

### Dark GDK / Variable storage.....

Message
Posted: 23rd Aug 2012 09:01
I have looked up storage units for variables and the largest one I have found is "double". It has up to 15 digits, but I discovered that it has no more accuracy than a float..... Why? I read somewhere (can't remember) that you can turn on double precision preservation (or something like that)..... How?

Is there a storage class that has greater precision with the ability to have a fraction component?

I am currently working on a game that is HUGE in scope. It's a space game (yes another). The distances are going to be accurate, where 1 unit==1meter. This means that in a solar system that has distances of 6Bkm at its max would need something more than what a double can give. I started out using floats and discovered the problem when I reached the edges of the system-- everything moved wierd. So I started using doubles. I finished converting my code to utilize doubles and found the same problem! So now I'm creating a storage class that combines vectors into sectors-- this is a daunting task to say the least.

I hope some one has an answer to this problem.....

The fastest code is the code never written.
Posted: 23rd Aug 2012 09:39
so you want how many digits accuracy? at least 9 whole number digits but how many fraction ones?
Posted: 23rd Aug 2012 10:14
you can try a combination of __int64 and a float, something like this:

Posted: 23rd Aug 2012 12:38
@Hassan:
That's what I'm doing. It seems to work so far, but I just finished the calculations portion of it (operators) and haven't been able to test it yet. I'll let everyone know how it works if it works well.....

The fastest code is the code never written.
Posted: 23rd Aug 2012 13:20
Doubles will be easily enough to store the values you need, the problem is that graphics cards and DarkGDK only use floats for rendering. If you just convert all the doubles to floats then obviously you will lose the precision you need when you are far from the origin. To solve this you need to render the scene so that the player is at the origin at all times. If the player is actually at (10, 5, 2) and there is a planet at (30, 30, 30) you would actually draw the player at (0, 0, 0) and the planet at (20, 25, 28). (ie. you subtract the player position from all of your coordinates when drawing)

As long as you do this subtraction before converting to a float everything will be accurate because everything close to the camera will be close to the origin, and so will be accurate. Stuff that's very far away will be less accurate, but it's very far away so the difference can't be seen.

[b]
Posted: 23rd Aug 2012 17:32
Quote: "To solve this you need to render the scene so that the player is at the origin at all times"

Yes. That's exactly what I'm doing. The problem with doubles is that they loose accuracy around 10000 or so... Don't know why. I think its "precision" is in the places right of the decimal. I came up with a vector convention to handle the problem. I was hoping some one knew of a variable type I didn't.....
Here is the code I promissed:

I guess most people don't use DirectX math, but I do. So some of the functions have D3DXVECTOR3 stuff in them. If you don't like using them, you can make your own or, for DGDK2.0 users, use the new vector structures.

It's messy, but it's mine!

BTW, I have stopped using GDK all together because of the numerous problems. Once DGDK2.0 is a complete package with all that was promissed when I bought it, I may take another look. Until then, I'll keep plugging away with DX.

The fastest code is the code never written.
Posted: 23rd Aug 2012 18:58
PROBLEM!
I am trying to use "__int64" or "long long" and they both "roll-over" at the same point as "int" and "int32".... Is there something in VS I need to turn on/off to make them work properly? Or is this just the way it is?

The fastest code is the code never written.
Posted: 24th Aug 2012 04:18 Edited at: 24th Aug 2012 04:19
Quote: "The problem with doubles is that they loose accuracy around 10000 or so..."

No they don't... Doubles can store 15-17 significant digits accurately. That means for a value as large as 10000 it's accurate to 0.000000000001 (0.001 nanometers) - I seriously doubt you need more accuracy than that.

[b]
Posted: 24th Aug 2012 10:22
I discovered that it was in the way I was looking at the numbers-- I was seeing significant variations with my math around 10000 or so. You are right, the accuracy to the right of the decimal is very good, but I needed numbers in the 1,000,000,000,000 range. When I took doubles to extremes, I got wild math results and objects started to jump from one spot to another-- kinda like being in a universe without known math and physics .

The fastest code is the code never written.
Posted: 24th Aug 2012 12:43
I had a similar problem to this years ago on the Atari ST when playing around with larger numbers. I localised my math to bring all the calcs down closer to zero as Diggsey is mentioning. Caused a bit more overhead but when the results were added back on they closer than what they were...

I set up a struct that held the original numbers and any calcs, usually just the main ones went through functions. The original value would be checked for boundaries, ie if over 1,000,000,000, and so on. Then that value would be subtracted to start with and added to the final result after the calcs were done. It wasn't a perfect solution but it got round the problem with better results.

Mental arithmetic? Me? (That's for computers) I can't subtract a fart from a plate of beans!
Warning! May contain Nuts!
Posted: 24th Aug 2012 16:07
I suppose that if you really need the extreme accuracy at larger numbers, you could use a bignum library like MPIR or GMP. They're not as fast as regular floats/doubles and takes up more memory, so I'm not sure if using them would be worth the performance hits.

Posted: 24th Aug 2012 21:40
My HUGEVECTOR3 system works very well. The only problem I'm having is with objects like planets and moons being rendered correctly. The issue is that when they are VERY far away they go beyond my far clip plane. I have it set at 1,300,000 and I don't want to set it higher. I already get z-fighting/swapping with the planets. I remedied this by making them render in order of farthest to closest. This works well. The next issue was that my scale is 1 unit==1meter. Well, as you can guess, I had to fake the distances of the planets and sun when they are beyond the far clip plane by scaling them down according to distance and rendering them at just before the FCP.

BTW I'm doing all of this without DGDK..... I hope the TGC gods don't mind me posting stuff here.

The fastest code is the code never written.
Posted: 25th Aug 2012 18:07
Hmmm, perhaps you could do a fancy scaling system where you have a mode where all the planets are .1 units = 1 meter but the rest of the game is in 1 unit = 1 meter? You may want to ask Morcilla about how he handles his space simulation, its scope seems similar to yours.

Posted: 25th Aug 2012 22:43
I already e-mailed Morcilla, but haven't heard back. The system I'm using is working great. I would post a demo, but I don't want to make TGC upset with me.

The fastest code is the code never written.
Posted: 28th Aug 2012 15:42
Updated code:

Works better than the other one..... Gotta say, my project is comming along nicely. The only bugs I have encountered is the ones I accidentally put in. But those I have been able to track down and fix.

I wonder when 2.0 will be complete and bug-free.....

The fastest code is the code never written.