EasyRPG
Game Settings - Using the 2k3 OpenVideoOptions command
Now that we have the async framework, it is possible to implement the 2k3 OpenVideoOptions command if we think it makes sense on some platforms.
This could async suspend the current game, draw up a scene with video options, then resume the game back from where it started.
Thinking about it further, we could extend this to a general settings menu
- Remap controls
- Video options
- Audio options
I would make it available from:
- TitleScreen
- MainMenu
- KeyBinding
- OpenVideoOptions event command
Many people have asked for button remapping, and this could be the way to do it.
Open Question: How do we save user settings?
That this cmd should call a settings scene was discussed multiple times but I can't find it.
Why was the async framework a requirement for this? Normal scene calling via the interpreter is supported much longer.
Related #666 and #713
The OpenVideoOptions command behaves async. It suspends the game, pops up the dialog, and then resumes the game. If we want strict frame compatibility we would need to mirror it.
We might be able to get away with calling it like a normal scene though. But then games which use the command won't execute the same way and could break.
ah I guess Cherrys code simply creates a modal window and blocks until it is closed.
We could get away with not using async for this.
Another approach could be to just set a flag when the video options menu is requested by an event, and then instead of an async call, call the scene at the end of the frame like other scenes. This would need to not have the side effects on interpreter execution that other pending requested scenes have. We could not use Scene::SetRequestedScene() for this.
Then the menu wouldn't spawn at exactly the same time as in RPG_RT, but since none of the results of the menu affect game logic, it shouldn't matter.
Well, events can check if the window is in fullscreen (and can toggle fullscreen). This is very obscure, but I could see a difference in behavior if another parallel even would run after the one that called OpenVideoOptions and would check for the fullscreen state, and the user changed the fullscreen state in the menu. Then that event would read the old state in EasyRPG once more but the new state in RPG_RT.
Though, I don't see in what way this could mess up anything, unless it's some sort of 4th-wall-breaking game that actually wants to user to change the fullscreen in the video options dialog... (and even then, you'd assume that the dev then checks the state in the same event directly after the options call)
Btw, yes, Ghabry, it's just a modal dialog that's opened synchronously in the event command handler.
EDIT: Hm I wonder what would happen if then something like a battle and the video options were called in the same frame, with your method...
I'd have to call the video menu and then the battle immediately after. In order to preserve the frame timing. That also adds edge cases we would need to handle. Calling 2 scenes at end of map frame.
wouldn't it be total nonsense to call the video options before any other scene?
Also don't know any game which uses the fullscreen state for any game logic. This check would break on any platform that lacks a window manager (so everything except, Windows/Linux/macOS), because there is nothing else than fullscreen.
The fullscreen example is nonsensical, yet it's possible. I'm just saying. (And the video options and the battle may not intentionally be called on the same frame in my example.)
It's up to you to decide how close you want to get - I guess it's fine to do it as a separate scene. I'm just pointing out the issues I can see, even they are tiny :)
Cherry's example is a good one to consider. Not just battle, but also any other scene call.
If we have to add hacks to handle 2 scene calls without advancing the map frame, we may just want to consider going all in and doing async scene calls as originally planned. I already have working async scene call code that works with the Inn sequence.
Will decide what to do whenever I get to making this feature.
In RPG_RT v1.11 the F5 key is used to open video options. We can emulate that here.
Also interesting but faaar out-of-scope for an initial revision: The settings could be queried by native settings dialogs to make them more user friendly tp configure.
E.g. on Android opening the Settings launches a Settings Intent (native Ui) that lists all the settings, on Desktops some libui stuff, etc.