Settings window

Open-source port of PoP that runs natively on Windows, Linux, etc.

Moderator: English Moderator Team

Falcury
Wise Scribe
Wise Scribe
Posts: 341
Joined: June 25th, 2009, 10:01 pm

Re: Settings window

Post by Falcury » December 6th, 2017, 2:21 pm

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)
David wrote:
December 3rd, 2017, 11:43 pm
Actually, any key exits the menu, except the arrows and enter.
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.
David wrote:
December 3rd, 2017, 11:43 pm
By the way, the selection rectangle is somewhat hard to see.
Or maybe just my screen is not adjusted correctly.
OK, I made it brighter, and added a white bar to the left of the rectangle to make it extra visible.

David
The Prince of Persia
The Prince of Persia
Posts: 1523
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: Settings window

Post by David » December 8th, 2017, 6:54 pm

Falcury wrote:
December 6th, 2017, 2:21 pm
David wrote:
December 3rd, 2017, 11:43 pm
Actually, any key exits the menu, except the arrows and enter.
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.)
Falcury wrote:
December 6th, 2017, 2:21 pm
David wrote:
December 3rd, 2017, 11:43 pm
By the way, the selection rectangle is somewhat hard to see.
Or maybe just my screen is not adjusted correctly.
OK, I made it brighter, and added a white bar to the left of the rectangle to make it extra visible.
Thanks!
Norbert wrote:
December 4th, 2017, 8:12 pm
David wrote:
December 3rd, 2017, 11:43 pm
However, my code probably won't work if either
If either what? :)
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.

David
The Prince of Persia
The Prince of Persia
Posts: 1523
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: Settings window

Post by David » December 15th, 2017, 10:52 am

Norbert wrote:
November 30th, 2017, 10:12 pm
(I commented out the SDL_RenderSetIntegerScale() calls because my system has SDL 2.0.4, and I didn't want to manually install SDL 2.0.5.)
I added version checks for that: https://github.com/NagyD/SDLPoP/issues/ ... -351948623
(Although this is not yet on the settings window branch.)

Falcury
Wise Scribe
Wise Scribe
Posts: 341
Joined: June 25th, 2009, 10:01 pm

Re: Settings window

Post by Falcury » January 13th, 2018, 1:58 am

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...)

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 3204
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: Settings window

Post by Norbert » January 13th, 2018, 4:48 am

Here's a direct link to the relevant branch of Falcury's fork:
https://github.com/Falcury/SDLPoP/tree/menu2

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 3204
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: Settings window

Post by Norbert » January 13th, 2018, 6:57 am

Falcury wrote:
January 13th, 2018, 1:58 am
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.

Post Reply