• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Questions about the uses and equivalent of Cs const volatile variable declarations in gml

In the language of C you can declare variables as const volatile ....

const volatile int x;

The application of such a declaration is for embedded hardware systems as I learned from a post on stack overflow's website :
const volatile in c or c++

The question is, in gml, is there any use for this invention in game designing in GMS?
And if there is a use for this, then what is the equivalent of a const volatile declaration of a variable in gml?

Thanks.
 

kburkhart84

Firehammer Games
In the language of C you can declare variables as const volatile ....

const volatile int x;

The application of such a declaration is for embedded hardware systems as I learned from a post on stack overflow's website :
const volatile in c or c++

The question is, in gml, is there any use for this invention in game designing in GMS?
And if there is a use for this, then what is the equivalent of a const volatile declaration of a variable in gml?

Thanks.
As one of the answers mentions, even in C++ it is something you would likely see ZERO times in your life. That means it would be even less likely to be useful here in GML.

I don't see any use at all for that in GML. The const part is basically what a #macro can do(though not literally the same rather close enough). The volatile part I only see making any sense if you were to use extensions to start up new threads that have direct access to the RAM that the GML variables is stored in(that was a thing back in like GM8 times IIRC). This is generally not going to be viable though, as GM's loops generally don't last more than a percentage of a frame, meaning the variable would not likely have changed within that time. You are basically starting to get into things that GML just wasn't meant for. Worse, I have no idea but I seriously doubt even the C++ that the YYC is being used to convert GML to has any usage of the volatile declaration.

So yeah, there is certainly plenty of use for the idea of a const(in MACRO form in GML). But the volatile declaration has no use here unless you do something outside the general purpose of the software. And the idea of combining both is basically irrelevant at that point to be honest, especially since macros aren't exactly the same thing as const variables anyway.
 

Juju

Member
For the uninitiated, a const volatile can be thought of as a read-only global variable. There's a lot more going on than that, but that's the jist of it if we're to port the idea from C++ to GML.

Easiest way to emulate this in GM is to use a macro to wrap a getter function that reads a "private" global variable.

GML:
#macro variable __getVariable()
global.__variable = 42: //Starting value, other values also allowed

function __getVariable()
{
    return global.__variable;
}
If we only ever use the macro then the underlying variable can be read from but not written to. If you do want to change the value of the variable, you need to go out of your way to write to it.

Is this useful? Eh, if you care loads about what your syntax looks like then this has some appeal I suppose. It might also prevent unintended writing of a global variable, but I've not found that to be a particularly common situation in GML. I think in general this pattern has limited use.
 
Last edited:

GMWolf

aka fel666
For the uninitiated, a const volatile can be thought of as a read-only global variable. There's a lot more going on than that, but that's the jist of it if we're to port the idea from C++ to GML.

Easiest way to emulate this in GM is to use a macro to wrap a getter function that reads a "private" global variable.

GML:
#macro variable __getVariable()
global.__variable = 42: //Starting value, other values also allowed

function __getVariable()
{
    return global.__variable;
}
If we only ever use the macro then the underlying variable can be read from but not written to. If you do want to change the value of the variable, you need to go out of your way to write to it.

Is this useful? Eh, if you care loads about what your syntax looks like then this has some appeal I suppose. It might also prevent unintended writing of a global variable, but I've not found that to be a particularly common situation in GML. I think in general this pattern has limited use.
this covers the const bit, but not the volatile bit.

volatile means the variable may be modified by something else, like another thread etc.
more precisely, it tells the compiler not to re-order read and writes to that variable, and not to cache the variable in a register.
The main places you would see a volatile is when two threads need to share information. (although usually it would be wrapped as an atomic type in c++).

So what about const volatile? A const cant be changed, so why would it make sense for it to be volatile, since it cant change?
Well const really just means that the program is not allowed to change it, but something external might be allowed to.
Usually you would see this being used with hardware registers: the value might change so re-ordering would cause issues, but it doesnt make sense for you to write to it.


In GML volatile *could* exist, but it wouldn't be useful:
There are not threads, and variables can only be GM runtime variables.
So even though you could tell GM not to optimize your variable access, there would be absolutely no point in doing so.

The const bit also doesnt exist in GM. Const is most useful when you have a compile time type system. without it, its really not all that useful. As juju pointed out you could fake it with an accessor function though.
 

Juju

Member
You write to global.__variable via some complex, un-exposed system and that's your volatile. There's no point treating GML like it has fixed memory addresses so we have to use some imagination. As kburkhart pointed out, this behaviour is useful for extensions (or 3rd party code in general) where you don't want the end-user to write to a variable but another process (that the end-user doesn't control) does.
 

GMWolf

aka fel666
You write to global.__variable via some complex, un-exposed system and that's your volatile. There's no point treating GML like it has fixed memory addresses so we have to use some imagination. As kburkhart pointed out, this behaviour is useful for extensions (or 3rd party code in general) where you don't want the end-user to write to a variable but another process (that the end-user doesn't control) does.
I still don't quite see how that's volatile.
That's just seems like c style const. (Different from say, rust const where const actually means const. In C, you can expose a const pointer to a non const object. Which is essentially what you describe above, if I'm not misunderstanding.).

Volatile doesn't say anything about who is and isn't allowed to write to a variable. Const does.
Volatile just tells the compiler not to re-order read/writes to that variable.
It's used when dealing with other processes (as in OS processes, not a different system within the same process) or threads.

But in GML we don't have threads, and there is no exposed way of modifying variables from another process, or even a DLL. Hence volatile doesn't apply to GM land.


Actually, there is one place it could actually make some sense:
Buffers.


You can get the address of a buffer and hand it to a DLL, which would then be free to modify the data from another thread, while a GML acript could be trying to access it.
In that case, it would be handy for that entire buffer to be considered volatile memory.
It would be sensible for GM to already mark that memory volatile internally.

So, I suppose, the nearest thing to a volatile we get in GML would be buffers, assuming GM made them volatile.
 
@GMWolf In the stack overflow post , const volatile is used for software embedded systems for a special hardware use , where you do not want to change the value, that the hardware is changing. I was thinking about using this idea to see of GM works with game controllers that are more sensitive.

This might not be the right application for const volatile, in my example, but off the top of my head....

For instance, a friend of mine told me that if you really want play a racing game, like GTA or Need For Speed : Carbon ( or any racing game like that ) you should invest in a joystick for flight simulators. The reason is, that the flight simulator joystick is more sensitive and therefore more responsive than what a common game controller can do. So in the game programming you need to have something that recognizes that sensitivity so that the game responds correctly. For the flight simulator joystick , there are intermediate sensors that detect minute changes that a normal game controller would not be able to detect. So the question is if its possible to have in GM a means of detecting that sensitivity. Well since its hardware, that's always changing the value of what is being read - it falls under the use of const volatile where you want read those sensitive variables. Which means, that GM would have to have a provision in its game controller functions to read those sensitive values.

I dont think there is a provision in GM in its game controller functions, that allows you to create a variable for reading those values that are intermediate between left and right, or up and down, to interpret that sensitivity for a game to respond to. It would be similar to how , in Mojang's Minecraft, when your in Minecraft's creative mode, how it distinguishes the difference between when you press space on the keyboard, when you want to jump OR when you want to be flight. That same condition exists with the flight simulator joystick being used in a racing game, so you can control how tight of a turn you can make, or how slightly, you can steer the car with little movement using the joystick, but that depends on if the game ( which depends on the programming language ) has the means to respond that kind of hardware.
 

kburkhart84

Firehammer Games
I don't think that this "specialty" hardware does anything different as far as the programming goes though. I think all it does is have higher sensitivity to the axes. So instead of 0.01 being a minimum value, these might be able to notice an 0.005 difference. If I'm right, I'm not sure as it is currently if GML can use those. I think it rounds to the nearest 0.01 when checking axis values. I don't know if that is something happening with Gamemaker or something that SDL does, or if the driver itself simply doesn't have any better sensitivity.

All that said, the best bet is likely to just try it. 0.01 is a hundredth, meaning an axis has basically 100 position in each direction(+ and -). I guess in the case of a racing wheel that has a massive range of motion you could need more precision, but I'm not familiar enough with them to know.

In any case, the whole "const volatile" idea is basically useless in GM unless you are coding some extension. In that case, if you found or coded drivers for some such device you might need it, but you would need to be getting somewhat low level and have multiple threads running for that specific declaration to be useful.
 
Top