SDL 1x vs SDL 2

Hi all,

I was looking over SDL code in 3DGE and was wondering whether it would be worth it to upgrade from SDL 1.2 to SDL 2. Apparently it has better input management, but is the effort worth the conversion?

Mainly, I was planning on a cleanup of the menu code and heard people were having some input issues. Seeing as how a lot of ports are SDL 2, I felt it best to ask here.

So, maybe some Pros and Cons? I started the migration last nigbt but held off, as I would need to read the SDL 2 manual to excise the old stuff. So, before I do that... :-)

Thanks!

Yes, yes, absolutely yes.

Over on Chocolate Doom we're halfway through converting to SDL2 ourselves. It's a significant amount of work but it's worth it.

I keep encountering new issues which press the case for SDL2 migration, to the extent that I've even said "All roads lead to SDL2". Things to encourage you:

• Support for high-res displays on OS X (ie. retina display)
  
• Support for on-screen keyboards as used on tablet devices etc.
  
• I have it from the SDL developers themselves that there will be no more SDL1 releases. The 1.2.15 is already starting to bitrot - it doesn't compile OOB on current OS X releases for example.
  
• Built-in support for hardware rendering, which on Chocolate Doom we've used to greatly improve the screen scaling performance
  
• SDL2 supports a bunch of modern platforms that SDL1 doesn't (or at least does them much better): Android, iOS, and there's even an emscripten port now.
  
• High resolution icons (not limited to 32x32 any more).
  
• Better game controller support (includes haptic feedback)
  
• A bunch of other useful little things which have been added into the API: ability to open multiple windows, pop-up GUI windows, power management.
  

These are really all small incremental improvements but for me, they've collectively added up to a compelling case for switching.

Awesome stuff. It will be a bit of work, but since most of the engine is OpenGL there is little to do on the rendering side. I drafted what needs to be converted, but I am still learning what has been phased out since SDL 1.2. (3DGE was using 1.2.4).

Mostly input stuff relating to Unicode support. Seems it is done differently now (?) and I am having a bit of a blunder wrapping my head around it.

Definitely excited about the joystick stuff - I really need the improvements :-)

The input stuff was tricky for me to figure out since it doesn't fit with how Chocolate Doom previously did input, and it was difficult to square with Doom's "responder" based system (which can "eat" events to block other responders from receiving them). This is the solution I eventually came up with - it works by peeking forward into the SDL event queue. It's a hacky approach but I couldn't find a nicer way of doing it.

Does SDL2 mix the sound volume mixing with the music volume bug?

AFAIK, that's only an issue with newer versions of windows (I think everything from 8 on, but I could be wrong). I'm not sure whether the bug is connected to the windows midi api or whatever (partially because I can't code...)

Yes, I would like that bug fixed, but I'm not completely sure if its possible (or maybe I'm being an idiot for thinking that way about something I don't really understand)

Haha, there we go again... :D

After Vista the native midi support sucks. Use another midi driver, like Coolsoft Virtualsynth.

While you couldn't change the MIDI synth in Vista and 7 on a stock system, it was still possible through third-party tools. 8 was the release that truly crippled midi support in Windows by making it almost impossible to change the MIDI synth. The tools that worked in Vista and 7 made no difference after 8, due to the ladder hardcoding certain things.

Based on ZDoom/ECWolf I can say that for OS X SDL2 is a clear winner. If we didn't go to a native Cocoa backend SDL2 would have brought about the same 2x+ frame rate improvement. For Windows it brought back hardware accelerated surfaces which allows some desktop capture software to actually work with it. (SDL 1.2's DirectX backend had issues on many machines.) On Linux there isn't as much of a difference (and a select few are claiming a significant performance loss), but I've noticed a vast improvement in frame pacing and a performance improvement there as well (mostly thanks to OpenGL I'm sure).

All of that is really only relevant to software rendered games, but thought I would mention it anyway.

As for porting, ZDoom's SDL1.2 -> SDL2 port was pretty trivial. It was done in a branch which lasted about a week. Most of the trouble I recall came from changing up the fullscreen mode to a fullscreen window (which has a slew of benefits particularly for multi-head users on Linux). This changed the semantics of anamorphic aspect ratios since it could no longer be assumed the monitor would letterbox.

Vulture said:

Does SDL2 mix the sound volume mixing with the music volume bug?

SDL2_mixer is virtually unchanged from SDL1.2 mixer. I'm not even sure why they maintain a branch since it's trivially possible to compile SDL2_mixer against SDL1.2.

Danfun64 said:

While you couldn't change the MIDI synth in Vista and 7 on a stock system, it was still possible through third-party tools. 8 was the release that truly crippled midi support in Windows by making it almost impossible to change the MIDI synth. The tools that worked in Vista and 7 made no difference after 8, due to the ladder hardcoding certain things.

I'm sure that's perfectly correct but ranting doesn't help solve the problem. "Use an old version of Windows" just isn't a useful solution here.

Blzut3 said:

Based on ZDoom/ECWolf I can say that for OS X SDL2 is a clear winner. If we didn't go to a native Cocoa backend SDL2 would have brought about the same 2x+ frame rate improvement. For Windows it brought back hardware accelerated surfaces which allows some desktop capture software to actually work with it. (SDL 1.2's DirectX backend had issues on many machines.)

Oh, I forgot to include this on my list. Yeah, SDL1 with a retina display on OSX is awful in terms of frame rate - you have to enable the legacy/backwards compatible mode to make it playable. SDL2 on OSX is an improvement in so many ways.

fraggle said:

I'm sure that's perfectly correct but ranting doesn't help solve the problem. "Use an old version of Windows" just isn't a useful solution here.

Sorry if it came off as ranting. Since my main computer is running Windows 10, I'm suffering through the same issue as well.

Danfun64 said:

Sorry if it came off as ranting. Since my main computer is running Windows 10, I'm suffering through the same issue as well.

I think that the "Use an old Windows version" thing was directed at the people who actually considered this a valid strategy. Believe it or not, when the issue first came up there actually were some people who flat out suggested to "stick with XP if the newer versions are broken", instead of working towards a solution.

There is a way to change the default midi synth on Windows 8, if Virtualsynth's installer doesn't do it. I did it through googling and regediting. That's what I'm using on my desktop. (win8.1 x64)

I do not care much for the mixer stuff as 3DGE has Timidity, and soon OPL, for MIDI. I thought about packing the VirtualSynth installer, but I dont like the idea of my end users having to additionally install anything.

@fraggle: so the SDL2 input event handler completely replaces the Unicode handling? I am not in front of my PC at the moment, but I remember that being a pretty big compile issue.

Is it considered "safe" to keep the old SDL stuff snd wrap 'em around defines? KallistiOS only supports the existing SDL and I would rather not maintain another branch if I could help it. For other stuff it is not a problem. . . just curious. .

Last time I tried I could not make 3DGE work with Virtualsoftsynth. I had "native midi" selected but it didn't work. Whereas it worked on all other ports I tried it on, even doom95 and that obscure beta of doom95, heh.

Have you got it working that way? Having it set to Native MIDI and having an alternative midi device driver installed in the place of the windows one?

I have not paid much attention to it. I have an old Win98 machine around if I want to listen to good MIDI (SB AWE32), otherwise, Doom (etc) and clones are the only things I play MIDI through on my modern machine.

I know that I could restore the pre-1.28 EDGE midi code (and it works with Windows 10, save for volume adjustment) but I am not sure if it's worth the effort.

I would just rather get built-in stuff working and limit users to either Timidity or OPL (or OGG/CD for custom stuff).

I will further confirm that SDL2 has no solution to MIDI volume. Using midiOutSetVolume on Windows 7 or later changes the process's digital mixer volume level, because of how the audio stack works.

You have several possible solutions:
1. Marshall MIDI to the native device at the event level and alter the volume of events in real time (super pain in the ass)
2. Use a separate synthesizer (usually either sound awful, like TiMiDity, or are an extreme pain in the ass, because shit like FluidSynth has grotesque unnecessary dependencies on GTK crap and is almost impossible to compile)
3. Don't use MIDI at all (OPL emulation, hidef soundtrack, etc).
4. Be like Eternity and play music from a different process via RPC.

Quasar said:

4. Be like Eternity and play music from a different process via RPC.

I have looked into this before, and it intrigued me. I think that will be a fine solution, as soon as I'm finished with the SDL2 conversion.

And yes, Timidity does sound pretty bad (but this can vary depending on what patchset you have), but it was the only thing that was available for the port at the time.

So, I got most of the input sorted out through SDL2 (really just converting to scan codes), but setting up the video is sort of a headache. Lots of graphic setup stuff needs to be changed. Also, I know SDL_surface* has changed too - should I go with SDL_Window or SDL_Texture? Unclear if I should even change that or not.

Looks like SDL2 manages a lot of the resolution handling...but since there isnt SDL_VideoInfo *info, I am not sure how to call the equivalent (also, no vfmt-> anymore...hmmm). And, do I need to wrap the raw GL calls to clear the screen?

Thanks for the help, I wish there was even a smidge of a compatibility layer. . .

No idea if it's helpful or not given software vs opengl, but ECWolf supports both SDL1.2 and 2.0 so it can give you an idea of what that looks like: https://bitbucket.org/Blzut3/ecwolf/src/a5c613175153d8a80ad5d2a9a5b2fc45d1476b4e/src/sdlvideo.cpp?at=default&fileviewer=file-view-default

I think the SDL_Renderer and SDL_Texture stuff really only applies to software rendering (or if you're interested in using SDL2's 2D rendering functions). For GL you get the GL context from the SDL_Window.

Resolutions you would get from SDL_GetDesktopDisplayMode. For ZDoom/ECWolf we just use a static list of resolutions since we use the fullscreen desktop feature so having the exact resolution list isn't really important.

Awesome, thanks for that! I can see how it is used in that context.

Anyone know if SDL2 still supports CD playback?

It doesn't. This is a very minor problem for Chocolate Hexen which is supposed to offer CD playback as an option, but since we have digital music packs as a feature it's not a huge issue.

fraggle said:

digital music packs

Off-topic, but like the entire chocolate-doom.org domain that link gets blocked by Avast antivirus, and from what I heard some other antivirus tools seem to have it on their blacklist as well. Anything that can be done about it?

Graf Zahl said:

Off-topic, but like the entire chocolate-doom.org domain that link gets blocked by Avast antivirus, and from what I heard some other antivirus tools seem to have it on their blacklist as well. Anything that can be done about it?

What a pain in the ass. I'll take a look, thanks. Edit: this can be reproduced by installing the avast online security Chrome plugin (even on a Mac). The plugin offers no further explanation as to what the problem is. I've contacted Avast to see if we can get it removed.

Edit 2: my report appears to have been acted on and it is resolved. I don't get a block with the web plugin anymore. Anyone running the full desktop tool it would be good to know if that still causes problems.

Graf Zahl said:

Off-topic, but like the entire chocolate-doom.org domain that link gets blocked by Avast antivirus, and from what I heard some other antivirus tools seem to have it on their blacklist as well. Anything that can be done about it?

I'm aware of the problem and have tried to resolve it. The conclusion I've reached is that Avast is broken software written by incompetent people and I'm recommending people stop using it. As far as I know, Avast is the only antivirus that does this but if there are others then I'm interested to know.

fraggle said:

I'm aware of the problem and have tried to resolve it. The conclusion I've reached is that Avast is broken software written by incompetent people and I'm recommending people stop using it. As far as I know, Avast is the only antivirus that does this but if there are others then I'm interested to know.

You can upload to Virustotal and get a general idea.

Of course I think many AVs go overboard with the heuristics, so running it on a system might trigger false positives still.

fraggle said:

I'm aware of the problem and have tried to resolve it. The conclusion I've reached is that Avast is broken software written by incompetent people and I'm recommending people stop using it. As far as I know, Avast is the only antivirus that does this but if there are others then I'm interested to know.

What? Because yours is the only site I ever encountered that gets blocked by it?

I think you should at least report the false positive to them, if they don't know it exists, there's nothing they can do about it.

Avast rocks, really important in protecting the user from spy software:

EDIT: someone didn't like my very topical joke, tsk tsk.

VGA said:

Avast rocks, really important in protecting the user from spy software:

Aside from breaking the layout, what was the point of that?

I did report the problem, and they did fix it. At least this time.