Future of SDL frontend

[xKiv]

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

[Geti]

nice, i like the rewinds and saves especially.

[xKiv]

Noticed an ommision ...

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

[bgK]

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.

[mudlord]

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

[xKiv]

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, ...?

[spacy51]

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.

[xKiv]

I should probably announce it here, right?

The changes are committed.

Please checkout it, check it out, report problems, post requests for enhancements, ...