Here is a demo of the experimental in-game menu system I've been working on for SDLPoP.
My goal is to create an in-game menu that works within the constraints of a 320 by 200 resolution, and is intuitively used with mouse, keyboard and controller.
In terms of functionality, the idea is that it becomes similar to what Norbert originally had in mind for a settings window, but directly overlayed on the main window, instead of a separate window.

Note that it's still rough around the edges.

To bring up the menu, pause the game.
Escape also exits the pause menu (the original behaviour to advance the game by only one frame is disabled for now).

To navigate the menu, use either the mouse (point and click), the arrow keys and enter, or a controller (D-pad for navigation, A to select).
For controllers, I've remapped 'back' to 'escape', so you can use that button to pause the game and bring up the menu.
Use the left/right arrow keys to turn settings on or off.

Added:
* Scrolling
* Enabling/disabling bug fixes (for now, you can enable them all at once, then turn off all the ones you don't like)
* Added some of the customization options (just numbers that can be increased/decreased, sliders don't really seem to be appropriate there)

Yeah... this is probably not good behaviour, because it may be unexpected to suddenly have the menu close because you hit a random key.
For now, I changed it so that only keys with the Ctrl modifier (e.g., Ctrl+R) get through.
And I added backspace as an alternative way to leave the menu, and the spacebar as an alternative way to select a menu item.

Yeah... this is probably not good behaviour, because it may be unexpected to suddenly have the menu close because you hit a random key.
For now, I changed it so that only keys with the Ctrl modifier (e.g., Ctrl+R) get through.
And I added backspace as an alternative way to leave the menu, and the spacebar as an alternative way to select a menu item.

Thanks.
It's funny you chose backspace, since that is the key that I sometimes accidentally tried to use for this purpose...
Probably because I recently tried RetroArch, where backspace is for going back a menu. (And Esc quits the whole thing without warning.)

Oops, it seems I forgot to finish that sentence...
What I wanted to say: If either integer scaling or 4:3 aspect ratio is enabled, then my mouse-coordinate-remapping code probably won't work correctly.

Made some more progress.
It's not perfect yet. But I think I could address issues and get it into a state where it is 'production-ready' in a foreseeable amount of time.
Question is, do we think it would be feasible for the pause menu / settings menu to eventually make it to the main branch? (And, do we even want this feature to exist?)
Personally, I think it might be extremely useful to have. But I might be biased in favor of my own work.

Changes:
* Added a setting that allows you to revert to the original pausing behavior (i.e., pressing escape only pauses the game). Added an alternative way to bring up the menu: press Ctrl+M.
* Can now switch all bug fixes on/off while still remembering what the previous setting was for individual fixes. (Note: I created a new struct type 'fixes_options_type', for keeping the code simple.)
* Added settings for Shift+L behavior in non-cheat mode.
* Added settings for drawn_tile_top_level_edge, drawn_tile_left_level_edge and level_edge_hit_tile.
* Fixed some mouse/keyboard interaction problems (still some bugs remain...).
* Fixed image blending for the arrowhead images not working with the 32-bit RGBA surface (added draw_image_with_blending()).
* Minor fixes for text descriptions.
* Prevent recursion of draw_overlays() (when update_screen() is being called from within draw_overlays()).
* Removed the fixes/enhancement prompt option at startup, because it is no longer necessary. (Instead, the option for disabling/enabling fixes is provided in the pause menu)
* Removed old unused menubar-related code. (Random thought: maybe, the menubar thing could be revived for ecalot's editor. I remember being 'annoyed' that the editor had so many keybindings that I would have to learn before I was able to use it.)

New TODO items:
* Add a way to reset all settings to their defaults.
* Maybe add a way to disable all customizations in the "Mods" section at once (i.e. revert back to the original values).
* How should changing level-specific values in the "Mods" section work?
* Maybe generate a configuration file SDLPoP.cfg (or similar) for saved settings, and use SDLPoP.ini only for changing the defaults? (Would be easier to manage than writing back changed settings to the ini file; and, reverting to the defaults after messing up some settings would also be easy (basically, just reload from the ini file))
* I (temporarily?) added a crude interactive drawing mode for easier debugging of drawing bugs. See the variable debug_drawing_mode in seg009.c. All it does is manually updating the screen after each drawing operation (similar actually to how the screen used to be updated in the past). This is useful for debugging because you can see the final image appearing part by part. (need to decide to either remove this again, or keep/improve...)

Personally, I think it might be extremely useful to have. But I might be biased in favor of my own work.

This paragraph is just me being playful, all in the spirit of good fun, challenging your reasoning and actions a bit. I would like to differentiate between a) the usefulness of allowing easy access to settings, and b) the effort you've put into providing this access. One could say that the intrinsic usefulness does not depend on how much of the functionality has been coded. In a situation where you had coded nothing, it would not be less or more "extremely useful to have". You are (thus) not biased in favor of your own work. You like my idea of allowing easy access to settings, that I demonstrated in my fork, that I linked to in the first post of this thread. As far as I can tell, summoning settings through a pause menu instead of a separate window adds nothing; instead prevents users from observing certain real-time changes.

More seriously though, what you've put together is quite nice. Keep up the good work. The aesthetics of your menu are nice, although I personally prefer dark text on light backgrounds, which is also easier on the eyes (sources). Some small suggestions:
- When pressing up at the very top of a menu (and down at the bottom), maybe not play the sound effect.
- Maybe mouse-clicking the game could also bring up the menu.
- Maybe add a menu option to turn on cheats. And if cheats are enabled, either via the menu or via the command-line, maybe add a "CHEATS" menu that itself, among other options, contains a "LOAD LEVEL" sub-menu. I'd personally suggest adding the "ENABLE CHEATS" option in the main (top) menu - for easy access/findability - and replacing it with the "CHEATS" menu when chosen.
- For me, on Linux Mint, "LOAD GAME" has no effect, possibly because "SAVE GAME" isn't working. Saving and loading with F6 and F9 respectively still works.

Thank you for your feedback, Norbert!
Just to reassure you (perhaps unnecessarily), I'm completely OK with sharp/negative feedback, so please don't hold back for my sake! I try my best to follow Elon Musk's advice on this:https://www.youtube.com/watch?v=TsoUr62ehdE

More seriously though, what you've put together is quite nice. Keep up the good work.

Thanks!

I agree with your point about dark text on light backgrounds being easier on the eyes (I also prefer this, especially for code editing). There are several reasons why I still went with the dark color scheme. Most importantly, Prince of Persia itself already includes white text on a dark background for its UI (e.g., the dialog box on the potions level, and the texts at the bottom of the screen) so I wanted something that sticks as closely as possible to the original look and feel. My second reason is that most other games I know seem to do it this way too. In particular I was inspired by The Witcher 3, and I thought I'd try something similar to that.

I removed the sound effect when pressing up at the very top of a menu (and down at the bottom).

Good idea to add a cheats menu. Then we can use cheats while using a controller. Still working on how that should look, but I already added a pause menu item 'CHEATS' that only appears when cheats are enabled. I also added a toggle for cheats in the settings menu. (Hm, maybe that option should also only appear if you first used the command-line option?)

Yeah, the "LOAD GAME" and "SAVE GAME" menu items seem to be broken. Will have to fix that. I can also add mouse-clicking bringing up the menu.

Don't play sound effect when pressing up at the very top of a menu (and down at the bottom).

Enabling cheats from the Gameplay settings.

Settings are now saved to a file SDLPoP.cfg. Basically, your changed settings will be remembered from that file, as long as you don't touch SDLPoP.ini (If you edit SDLPoP.ini, the ini settings will again override the previously used settings). Not sure if this is the best long term solution, but I quite like not having to forcefully rewrite the ini file every time you change a setting... And this way there is no need for a "save settings" prompt, because settings jsut get saved automatically when you close the menu, with not really any risk of the file being locked for editing, etc.

MODS menu: Added a setting for toggling whether or not to use modified 'custom gameplay' options. So you can quickly revert back to the default if you accidentally changed a customization setting.

MODS menu: Display ticks as seconds instead of ticks.

The 'Start fullscreen' setting now toggles fullscreen immediately, as well as setting fullscreen at startup.

The joystick threshold setting now increments/decrements with steps of 1000.

Refactor: accessing 'custom' and 'fixes' options through a pointer, so that we can switch to another configuration by simply changing that pointer.

Refactor: pulled out process_rw_write() and process_rw_read() from replay.c, so that they could be used in menu.c as well for (un)serializing to/from a configuration file 'SDLPoP.cfg'.

New TODO items:

Add the fuzzy pixels option as a menu setting as well.

Maybe add a "CAPTURE" menu item to the pause menu? Then, there should probably be options to make a screenshot, level screenshot, or record a replay. Maybe allow starting a replay either from the current position, or only as soon as the room changes.

Should the menu be accessible while watching a replay? And if yes, should certain items be disabled?

Same for the title screen/opening cutscene/demo level?

Should there be a setting to enable the debug timer, without needing debug cheats enabled? May be useful for speedrunning.

There should probably be a controller button mapped to bringing up the menu?

When using a controller, support holding down a direction for navigating the menu faster (similar to keyboard keys being repeated if held down).

Bit much for now, but something to think about for later: maybe display a list of mods, and allow switching to another levelset on the fly.

I also added a toggle for cheats in the settings menu. (Hm, maybe that option should also only appear if you first used the command-line option?)

I think it's useful to always include the toggle to enable cheats, for instance for players who don't know cheats exist.
Maybe change "Enable cheats" to "Enable cheats and CHEATS menu", to make it as exact and informative as possible.
In menu.c, the #if SDL_VERSION_ATLEAST(2,0,5) ... #endif could be added to SDL_RenderSetIntegerScale(renderer_, SDL_FALSE);.

I think I found a bug in the menu:
Click on the screen when the menu is not visible. Then maybe move the mouse. Then press Esc.
If now there is a menu item under the cursor, it will be activated immediately.