• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

 GMS2 64bit Future Thinking: Higher precision math

Kaliam

Member
This is something I have been pondering as of late as it has been a constant difficulty I have been having with the scale of my current project. Specifically I am creating a large Open world real time strategy which is based in space and as such requires lots of room space.

This brings me to my problem which is looking onward to the future of GMS2. This is far off at least as we know it, but proper 64 bit support is eventually going to be coming to GMS2. And with this comes the possibility of much more precise calculations using the precision of double values. Currently how gamemaker and most game engines work is by using floating point math to calculate "world space" or in GMS2's case, calculate the coordinates of your instances in a gamemaker "room". Unfortunately due to the limits of floating point math,
(8 digits 99999.99) once an object reaches a point past 99,999.99 x,y,z(depth) it will encounter precision errors. What this does it cause awful render "jittering" caused by the computer's inability to calculate the exact coordinates of the object due to the limit of floats.

Example of precision loss as coordinates get larger:
99.00000
990.0000
9900.000
99000.00
990000.0

I know that gamemaker is more designed towards smaller projects which really don't need precise math or very large rooms, but I call on YoYoGames to go against the grain and give their engine full 64bit support when 64bit is released in the future. I think that not only will this future proof GMS2 as an engine, but it will also make GMS2 a sought after resource for creating amazing large scale projects which not many engines are currently capable of doing.

When it comes to performance demands of double precision, there are minimal losses when executed on a 64bit system. This means that there would be little to no effect on the actual performance of the engine itself. This is due to how 64bit processors actually calculate math. I don't know how Gamemaker works on the backend, but I have enough experience in several other programming languages to know that this is no small task.

One modern game that uses this feature is StarCitizen. This allows that game to have a nearly infinite world with precise collision no matter how far from the origin(0x 0y 0z) you are. What I am asking is that YoYoGames consider something like this when the future 64bit update eventually comes into the works. This will most likely become the standard in the coming decade as there are less and less 32 bit devices. Why not go all the way when GMS2 gets updated to 64bit and future proof the engine? Imagine being able to create rooms with usable space up to 999,999,999,999.0000xyz to -999,999,999,999.0000xyz (nearly two trillion pixels squared!) without losing any kind precision. The possibilities for massive games are endless! =P. This combined with 64bit memory integration could make GMS2 an even greater engine/tool than it already is!

Anyway thanks if you read all the way to the bottom of my ramble, I know it was a little tech heavy, I just felt that this needed to be said. Computers are continuing to evolve and the tools that use them should evolve with them to allow greater possibilities for us all!
 

Mike

nobody important
GMC Elder
GameMake has always used 64bit doubles for it's variables..... Only recently have we started to add integers, and even then only in certain cases.

Graphics cards however don't - and can't, use doubles. So you have to make sure you subtract camera/location values first so that are in float range before rendering. You also can't make vertex buffers in universe coordinates. They should all have local origins so that verts never need to be very large. This is how you deal with massive worlds. In my last job, I mapped the UK down to a sub-cm resolution, this is how it's done.
 
S

Storyteller

Guest
just because something looks like its far from the origin does not mean it is. you might look into 'chunking', which is a common method used in 'voxel landscape sandbox games'.

https://forum.yoyogames.com/index.php?threads/best-method-for-infinite-terrain-generation.5845/

https://gamedev.stackexchange.com/questions/45148/demystifying-chunked-level-of-detail

https://spin.atomicobject.com/2015/05/03/infinite-procedurally-generated-world/

in short, keep your guy and stuff you interact with near the origin, and swap out what you are looking at on the fly. Much more efficient than trying to have everything in giant scale, all the time.
 

Kaliam

Member
Thanks Mike and Storyteller for the info,

For @Storyteller
I have actually thought about doing some world chunking, but the nature of my project doesn't really work with that solution. The main problem being that the game requires all areas of the gameworld to be actively loaded in a physical way. For example, you might have a fleet of starships doing combat on one side of the map, while a planet is being colonized on the other side of the map. This doesn't mean that all objects and events are loaded when there is no "player presence" present in an area, the game just needs the ability to have area's that are far away from each other to be actually physically far away. I have a dynamic "chunking system" I call sectors that keep records of local objects (if there are any) for script efficiency, but they use real world space too. I think I have found my answer though which you mentioned about the game origin which I will talk about below.

For @Mike
Thanks for the quick reply mike, sorry I haven't been able to respond due to my life being crazy atm. So if I understand what you're saying, gamemaker is already using double values in all calculations? So the errors in drawing sprites at large coordinates are purely GPU based? If this is the case, am I safe to assume that something like a precise collision would still function properly even if the object was far from the origin, say 999,999,999x and 999,999,999y? If this is the case, I can easily implement a "Floating Origin" design to the project. Basically, just moving the whole world around 0x, 0y and keeping the camera stationary, thus having everything on screen being drawn at low world coords while still allowing the game world to be extremely large. I'll probably do some tests myself, but I just don't have the time at the moment. This will hit performance because i've got to add an extra calculation every step to make sure objects are in their proper location, but it should work theoretically. Thanks again!

Also:
I had another odd/bad idea, and that was to just convert the world coords to the GUI or a Surface and draw everything there, but somehow that solution just feels wrong.
 
Top