Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Refactor scene calling #1658
If you're around. I've noticed some very strange behavior with event code delaying by frames in ways that don't make sense..
When an event calls a menu scene, does this have any affect on how events execute that frame? Or does it just let them all execute like normal and then calls the menu at the end?
It does have an effect. A quite complex effect actually, I believe.
It sets the scene value to menu immediately. This then has a couple of effects:
Now to that last point: It's not as simple as just stopping all event execution. Remember that in general, there are two kinds of workers, the "parallel process workers" (where one exists for each such event) and the "global autostart event worker" (where only one exists) which handles autostart events and events otherwise triggered (e.g. by action button) and has more complexity in its main loop than the parallel process workers.
Also remember that the overall order is this (from my other post):
Now, both kinds of workers will check at the end of their loop whether the scene is no longer the map and would exit the loop in that case. However, since this happens after command execution, that means that even if the scene is changed, each worker may execute one command before reaching that check and exiting.
Therefore, if a parallel process changes the scene, you will see other events still executing one single command - those events who are parallel process events coming after the scene-changing one (and all map events come after all common events) and the first autostart/otherwise-triggered event, if any. (You should not see anything weird if an autostart/triggered event calls the menu, since the global autostart worker is the last one to be run.)
Note: I did not empirically test this, this is just the result of logical deduction based on what the code in the binary appears to be doing.
*: To help understanding what this means: The main loop normally does things in this order: Increase frame counter -> Update key input -> Update current scene -> Draw current scene -> Wait for next frame. The drawing can be skipped in case the updating used too much CPU time recently, or when the scene was changed during the updating of the old scene. (And there are occasions, like transitions and some things in battle, where a "mini-version" of this loop is run inside of the scene updating itself, without updating the frame counter!)
Thanks for confirming this Cherry, this matches exactly what I've seen empirically. And checking at the end of the loop makes more sense as to why this would be the case.
Given the amount of testing I've done against this + Cherry's confirmations, this is ready for review and merge.
There is one more small piece of this where we don't load new events in the interpreter after the 1 command executes, but that's implemented in #1628. It can't be done here without that PR's refactors first.
Even without that, this is an improvement and good to merge.