So, basically... I have some real problems I've experienced, repeatedly, with GMS's rather flexible concept of "now".
There appears to be <some mechanism> in GMS that, if a game-frame takes "too long", forces it to increment a frame. I've been fighting with this mechanism for months; it causes a lot of weird problems with my procedural world generator that I've had to work around via Global states, internal states within Instances, and a host of other things. Most of the time, it all "works" but occasionally, I see issues, even now that I've gotten used to it.
For example, if you create Instances and tell them their XY is now <something different> right after creating them, they won't move until the next frame. This is a standard (and annoying) rule. However, I've caught them taking many multiples of a frame to move, because <something else that takes time> is happening in the same game-frame.
I get why it's in GMS; it prevents hard-locks under certain circumstances that newbies might trigger, like creating infinite loops, etc.
Is there any possible way to turn this "feature" off, or govern it, so that during <some operations that take massive amounts of computational time> it is not allowed to move a frame forward until <some condition> has been reached?
This isn't a true show-stopper, but I've been fighting with it for a year now, and it keeps causing problems, because certain things should happen before anything else aren't always operating completely reliably.
Here's an example of what I'm talking about, in practice:
There appears to be <some mechanism> in GMS that, if a game-frame takes "too long", forces it to increment a frame. I've been fighting with this mechanism for months; it causes a lot of weird problems with my procedural world generator that I've had to work around via Global states, internal states within Instances, and a host of other things. Most of the time, it all "works" but occasionally, I see issues, even now that I've gotten used to it.
For example, if you create Instances and tell them their XY is now <something different> right after creating them, they won't move until the next frame. This is a standard (and annoying) rule. However, I've caught them taking many multiples of a frame to move, because <something else that takes time> is happening in the same game-frame.
I get why it's in GMS; it prevents hard-locks under certain circumstances that newbies might trigger, like creating infinite loops, etc.
Is there any possible way to turn this "feature" off, or govern it, so that during <some operations that take massive amounts of computational time> it is not allowed to move a frame forward until <some condition> has been reached?
This isn't a true show-stopper, but I've been fighting with it for a year now, and it keeps causing problems, because certain things should happen before anything else aren't always operating completely reliably.
Here's an example of what I'm talking about, in practice:
GML:
//someObjects create Instances, which in turn get a bunch of variables set, and, when the Global "blockingVar" is set, can proceed to do many, many complex operations.
with(someObject){
<run an operation that creates a bunch of Instances>
<Instances need to perform a bunch of operations upon Create>
<instances created may include a new someObject>
//Gets rid of this particular someObject, since it has done its work now.
instance_destroy();
}
//If we've just created any someObjects, don't allow CrunchyMath
if(instance_exists(someObject)){
Global.blockingVar = true;
}
//If we've run out of someObjects in the world, now we can start doing CrunchyMath.
if(Global.blockingVar = false){
CrunchyMath();
}