Legacy GM Questions about "axis scale"

[XirmiX]

How far does "axis scale" in GMS go? Is it possible to make your own axis on top of it?

Everything that happens within a game needs an area, a sandbox space of coordinates, if you will that will allow things to move around. Well, for one reason, I got curious as for how far a scale can really go in GMS' rooms? a 64-bit floating point for all axis both positive and negative? Higher than that?

To add to that, how SMALL can it get? 3 digits below zero? Smaller than that? 10 digits may be before it rounds up or whatever?

And is it possible to make your own axis on top of that, so-to-speak in some form? Perhaps the axis could be an object?

P.S. Why do I never ever see anyone ask these kinds of questions? It's quite important to know how and what you're working with, no?

The reason I'm asking these questions is because I want to try out something... interesting, and see whether it could actually work. Probably not, but I think it's still worth trying...

 

[Wraithious]

Never heard of it, I had to look it up in the gms manual, the manual has never heard of it either, what do you mean by 'axis scale'?

 

[XirmiX]

Open GMS and create a room. When you create a room, you have your axis shtuff, things, "axis scale"; i.e. the room itself. How big can a room be in terms of x and y and whatever the hell else? I guess that would have made more sense, but I didn't think to say that... "how big can a room be"... huh...

 

[Wraithious]

ahh ok, Well I believe the maximum room size is somewhat flexible, but ultimately determined by the operating system, by the texture page limitations, for example (as far as gamemaker is concerned) android has a range of 256x256 to 2048x2048, ios has a range of 256x256 to 4096x4096, whereas windows and most all other os's have a range of 256x256 to 8192x8192, if you go bigger than these limits you will get compile warnings and errors, not sure about if you go under the low limits, but you can have any size ratio between those ranges but should pick the setting that is equal to or bigger than the largest dimension of your intended background. the settings are available in the last entry of the file tree - global game settings > graphics

 

[Simon Gust]

I believe axi go from 2147483647 to -2147483648.
The

ahh ok, Well I believe the maximum room size is somewhat flexible, but ultimately determined by the operating system, by the texture page limitations, for example (as far as gamemaker is concerned) android has a range of 256x256 to 2048x2048, ios has a range of 256x256 to 4096x4096, whereas windows and most all other os's have a range of 256x256 to 8192x8192, if you go bigger than these limits you will get compile warnings and errors, not sure about if you go under the low limits, but you can have any size ratio between those ranges but should pick the setting that is equal to or bigger than the largest dimension of your intended background. the settings are available in the last entry of the file tree - global game settings > graphics

Why should a tex page size care about room size? Sure backgrounds can only be that large but room size? Room size is one of the most useless things anyway. You can do views yourself, place objects outside the room works too.

 

[Nocturne]

I believe axi go from 2147483647 to -2147483648.

You can go bigger than that actually, but you'll start to get some pretty weird and trippy effects as the rounding errors from the floating point maths gets more and more obvious.

 

[Wraithious]

I believe axi go from 2147483647 to -2147483648.
The

Why should a tex page size care about room size? Sure backgrounds can only be that large but room size? Room size is one of the most useless things anyway. You can do views yourself, place objects outside the room works too.

I get errors if I try to make a background for a room bigger than 2048x2048 on android, I mean sure you can make a big room and scale up your background, but texture pages absolutely do have their limit

 

[XirmiX]

Huh, so it's not actually 2^64 but more like 2^32 divided by 2 (from minus to positive, that is), but you can go higher though if you do it starts to glitch out? Gotcha. So, what about the lower limit? How small can a unit of movement, even on one axis, can be before the program goes "nope, this is as small as you can go, we need to round up now"?

And I think it would probably be good for me to tell you what I'd like to try out knowing this. It's related to No Man's Sky and its "open universe" idea. Currently, the glitch thing happens when you go too far away from the cluster of planets, say, towards the star, which isn't an actual star to begin with. So, to have a free universe, or even a free galaxy to roam in might be challenging to get through. However, someone previously proposed the idea of creating an axis within the room axis, so that coordinates could be mapped farther down or farther out in some form...

If it is indeed possible, I'm not entirely sure how you would set this up. Say you have your 2D space ship object or whatever, and you want it in the center of your created axis, which would move around the room axis' smallest possible coordinates based on its own coordinates. Probably better if I make a visual demonstration. The Red scale is the custom-created scale and the black scale is the room scale; each block being the smallest possible unit for the room scale (0.0001 or whatever it would be).

Before moving to the left:

Spoiler

After moving to the left:

Spoiler

You could put the two images one next to another to see the comparison. Question is whether this would even be possible and how would one even approach this if it indeed is possible? The custom-axis doesn't need to be visible, of course, though for seeing whether this works visual aid would be great.

 

[Wraithious]

I think that this post here has alot of helpfull ideas and different ways you might go about achieving that

 

[flyingsaucerinvasion]

as far as I'm aware, in gms1.4, built in variables like x and y are only 32-bit, meaning you will run into floating point problems more quickly than if you were using your own 64-bit variables.

The size of the movements that will have the precision you want, also depends on the position.

For example you can do fine movements when close to zero and still have a lot of precision, but if you are at some really big number already, then there might not be enough precision to do a small movement from there.

 

[XirmiX]

I think that this post here has alot of helpfull ideas and different ways you might go about achieving that

I can see that the general idea is somewhere along the lines of what I was trying to go for, but in specific terms, I have no idea what most of the stuff that is being discussed actually means.

as far as I'm aware, in gms1.4, built in variables like x and y are only 32-bit, meaning you will run into floating point problems more quickly than if you were using your own 64-bit variables.

The size of the movements that will have the precision you want, also depends on the position.

For example you can do fine movements when close to zero and still have a lot of precision, but if you are at some really big number already, then there might not be enough precision to do a small movement from there.

Oh, that's a good thought; creating your own x and y variables for a customised scale. I would guess a good way to do this would be to use a ds_grid, though how could this grid scale then be "mapped" so-to-speak within the room to have an object in the center of it and so that the scale itself could move around by x and y axis of the room by using its own created axis, as demonstrated before?

 

[IndianaBones]

The precision loss as numbers get larger is an issue.

If I was having to deal with an open world with truly large spaces, a common way to avoid the precision issue is to always have the player located at 0,0 in the room/world, and simply move the world around the player.

Then you will see, actually, there is no spoon.