Is the SDL "GUI" slated for obsoletion any time soon?
Because in the past few months I have been hacking on it to make it more useful to me and if it could help anybody else, I am willing to clean up the changes for upstreaming.

List of changes follows:
Added cheat capability to commandline
- up to 100 cheats as parameters
- CTRL-E to toggle (Enable) cheats

Rewinds
- toss away the "stack" approach
- make a ring of (8) rewind-states
- allow free navigation among them: back, forward, repeat (home to) last rewind-state, jump to the newest rewind-state
- make messages (rewind stored, ...) go only to terminal

save/load
- configurable keymap
. F# saves/ SHIFT+F# loads
. F# loads/ SHIFT+F# saves
. F5/F6 changes slot, F7 saves, F8 loads
- this means that I no longer need to fear that SDL will eat my SHIFTs
- backups
. make backup of a on-disk savestate we are overwriting (when saving) - last such backup loadable with
. make backup of a in-memory savestate we are tossing (when loading) - last such backup loadable with

IPS patches
- up to 100 IPS files specifiable on commandline
- make it actually work (there was a bug - but it might have been *my* bug, in an intermediate version)

Sound pseudo-muting
- CTRL-S toggles this
- muting implemented by muting all channels when something is on
- unmuting implemented by restoring "muted channels" to whatever they were before last muting
- in the "rare" case that unmuting would leave everything muted (after loading a state that was saved with muted channels), unmute all channels instead

General code cleanup
- use DEFINES for some literal constant (FIXME: should use const variables instead)
- fix configuration bug for the 4th pad
- factor out some bigger code chunks from sdlPollEvents (save/load, rewinds, ...)
- wrote a simple file with all keyboard shortucts found

OpenGL scaling default
- configurable default scaling factor for OpenGL stretching
- only applicable for the "1x" filter (ie. no filter) and when not fullscreen
- changes dimension of the window on startup and when the "1x" filter is chosen (with CTRL-G)

Autofire
- added per-gamepad autofire for A and B (extensible to L and R, ...)
- the previous "solution" (still present) actually toggles autofire for all pads at the same time and you can't suppres it without disabling it altogether
- my solution configures a button that, when pressed, causes rapid changes of the A/B button for the given pad
- and pressing A/B while auto-A/auto-B is on just makes the A/B be persistent (as if it was pressed without autofire) [or maybe not, but this seems to be what I inteded]

Messages
- messages going to the main display are now echoed to terminal
- more messages added (some of them just to the terminal) - for savestates, pausing, cheats, ...
- most terminal messages have timestamp added


I am pretty sure some of the functionality belongs to common code, but so far I have only built the SDL port ...

nice, i like the rewinds and saves especially.

Noticed an ommision ...

Quote:- backups
. make backup of a on-disk savestate we are overwriting (when saving) - last such backup loadable with
. make backup of a in-memory savestate we are tossing (when loading) - last such backup loadable with

should be

- backups
. make backup of a on-disk savestate we are overwriting (when saving) - last such backup loadable with F10
. make backup of a in-memory savestate we are tossing (when loading) - last such backup loadable with F9
. this means that slots 9 and 10 are no longer available for direct saving/loading (they are used for backups)

xKiv Wrote:Is the SDL "GUI" slated for obsoletion any time soon?
Because in the past few months I have been hacking on it to make it more useful to me and if it could help anybody else, I am willing to clean up the changes for upstreaming.

Please do. The SDL port is great because it can compile almost everywhere. I've worked on improving it a few months ago, and it's nice to see some progress again. Great work.

Plus, Nach uses this, so it will still be maintained.

OK, so what should I do with the changes (once I clean them up) to push them to the repository?
Do you prefer broken-up diffs, complete changed files, giving out the write bit, ...?

You did a great job. IMO it would not make sense to just drop something people worked on hard. I also don't want to drop MFC until Qt reaches a state where no one is interested in MFC anymore.

In order to upload your changes, I think it would be best to grant you SVN access. I don't think you can break down all of your changes and upload them sequentally, since you already got a bunch of changes in your files. However, it would be great if you could do so for files, that you only changed a little and which do not depend on others.

For SVN acces, ask Mud.

I should probably announce it here, right?
The changes are committed.
Please checkout it, check it out, report problems, post requests for enhancements, ...