Thanks for your interest in this patch!
I should begin by stating the following. It is true that there are more general concerns not related to SDL 2.0, which (may) lead to the lack of a new "proper" release of DOSBox, and/or certain DOSBox modifications even without a release:
- The fact that DOSBox v0.74 is in such a state that it doesn't need a lot of updates by DOSBox devs, especially with regards to compatibility with games.
- Before a proper release is done, the DOSBox devs want to make sure that, at least in general, compatibility with games isn't broken in comparison to an earlier DOSBox release (unless there's a good reason).
- It may feel like it's difficult to make certain changes without writing a whole new emulator, as briefly stated in this interview from 2013: https://sourceforge.net/blog/potm-201301.
- There is less motivation to update DOSBox itself nowadays, following the availability of paid mobile ports of DOSBox (e.g., for Android), as well as taking advantage of DOSBox for offering games in digital stores. There may be other, similar reasons.
- Tech support (for users of DOSBox, say in these VOGONS forums) isn't necessarily fun.
As for SDL 2.0 itself, there are also great chances that the DOSBox devs (maybe not all of them, I have no idea) aren't exactly thrilled with the way SDL 1.2 was abandoned before SDL 2.0.0 was released, so they may be a bit careful with the idea of moving to SDL 2.0.
I can surely see enough reasons for having an interest in using SDL 2.0. Some examples I have at the moment:
- On Linux (more precisely X11), SDL 2.0 doesn't fully grab the keyboard and mouse anymore (say in fullscreen windows). This means, for instance, that window manager hotkeys like Alt-Tab can be used as expected.
- SDL 2.0 supplies SDL_Renderer, which can be used for 2D accelerated rendering. By default, behind the scenes, Direct3D is used on Windows, and OpenGL (ES (2.0)) on other platforms, but SDL 2.0 lets you a different renderer driver if any is available. A software renderer driver is also available.
- Note that SDL 2.0 still lets you do hardware acceleration with OpenGL as before (without SDL_Renderer). Multiple profiles of OpenGL 3.0 can further be used, as well as OpenGL ES.
- While I don't think it's really useful for DOSBox, SDL 2.0 supports multiple audio output devices. One feature that was planned for SDL 2.0 but is probably on-hold at the moment, is audio capture support. While it may be useful for a small selection of DOS games, I don't believe that many games take advantage of it.
- With SDL 1.2, DOSBox uses SDL keycodes for all keys, unless the usescancodes setting is toggled on (which is the default). In the latter case, some platform-specific SDL scancodes are used. With the SDL 2.0 patch, SDL scancodes are used anywhere in sdl_mapper.cpp and are (hopefully) portable. In theory, scancodes represent key locations and not labels, so you should - again in theory - always get the US keyboard layout by default, with the option to internally map it differently for some other language.
It isn't the case there won't be problems at all, though:
- The lack of keyboard grab can be a disadvantage, depending on the situation. By default, the Ctrl+Alt+Arrow key combinations are used for changing workspaces in Ubuntu (or at least certain versions of that). This may lead to problems if these are used in-game. While Ubuntu 14.04 has just one workspace, these key combinations are still defined for workspace switching, which again leads to some unexpected behaviors in-game.
- Despite what I've stated above regarding SDL2 scancodes, there may still be some different behaviors depending on the keyboard layout. With some layouts on the Windows platform, Alt Gr may behave like Ctrl + LAlt, even if SDL2 scancodes are used. Forcing US English layout for the given process (using some Windows API function) may solve this as a workaround.
- It is better to assume that joystick / game controller support is incomplete. Not only I don't really use such an input device these days, but SDL 2.0 adds support for joystick hot-plugging, which DOSBox doesn't take in account at the moment, even with the SDL2 patch.
- As stated beforehand, SDL_cdrom was removed from SDL 2.0. It is true that the last revision of the SDL2 patch should include a usable copy of SDL_cdrom with a few changes, so it's less of a problem now, but this may still be a concern.
There may be more points which I haven't had in my mind as of typing this, but the above is already more than enough for a post.