UPDATE: Please check my most recent updates in a later post within this topic.
In particular, note that the "renderer" setting accepts a string now, renderer=auto being the default.
Attached here is a patch against r3818, which is basically a prototype of an adaptation to make DOSBox work with SDL 2.0. Problems ARE expected, but at least the SDL 2.0 API is mostly stabilized now, it seems.
As mentioned in the topic, so far I have tested this on Linux. To be more specific:
- The modified DOSBox works, more or less, in a GNU/Linux desktop enviroment.
- With several clear limitations (and a crash at some point!) it can also be made to run for a short while on Android. Note that this is far from being usable at the moment. The need to use a physical keyboard (e.g. via USB-OTG) is one such. DOSBox also crashes for me on Android when I try to load the mapper.
Anyway, here is a list of changes in regards to compilation on GNU/Linux
- If you're use to compiling with the "configure" script, you may now optionally tell it to compile DOSBox using the SDL 2.0 API. Simply add --with-sdl2 as an argument. Note that the way I've done it may not be the best, but at least it seems to work.
- Basically, with --with-sdl2 in usage, the script looks for "sdl2-config", rather than "sdl-config".
- Furthermore, if you pick SDL2 in "configure", SDL2_net will be used (if found).
- However, SDL_sound (not "SDL2_sound") will still be used, at least if found and not disabled in some way. You can think of it as a library compatible with SDL 1.2 and 2.0 altogether.
Be warned that this is considered far from being usable, but if you still want to try the Android path (at least from a GNU/Linux desktop):
- Well, you'd want to install the ADT Bundle, as well as the Android NDK.
- If you wish, you may try and play with the android-project/jni/src/config.h file. It is based on one originally generated by "configure" for the desktop.
- Extract the contents of dosbox_sdl2_sample_icons_for_android.tar.bz2, so the icons reside in subdirectories within android-project/res. For instance, you should have android-project/res/drawable-mdpi/icon.png.
- Follow the instructions in android-project/compilation.txt.
Alright, now to a detailed list of changes, possibly missing things I've forgotten:
- Let's begin with the video output. I've had a few issues which appear to be related to the following: With SDL 1.2, you may use SDL_SetVideoMode to quickly change from one kind of a window to another one. You may toggle fullscreen with this, change from "surface" to "opengl" and vice-versa, etc. When it comes to SDL 2.0, though, you need to manually doing some things, like clearing an existing SDL_Window and then recreating one. I think the main advantages are that you have more control in a few ways, and you can also have more than one window (if supported). For now, though, only a single window should appear at a time.
- The "fulldouble" setting has been renamed to "vsync". Reason is that while on SDL 1.2 you have the SDL_DOUBLEBUF flag, the closest match on SDL 2.0 I've found so far is SDL_RENDERER_PRESENTVSYNC.
- To be consistent, "vsync" also applies when DOSBox is built to use SDL 1.2 (in this modification).
- Due to potential problems with some window managers, the default value set for "fullresolution" is now 0x0, implying the current display's resolution.
- Some code has been added so this also works on platforms other than Windows. Basically, SDL 1.2.10 has added a way of doing so via an SDL_VideoInfo structure, and SDL 2.0 has its own way.
- The choices of "ddraw" and "overlay" for the output settings are gone when compiled against SDL 2.0.
- output=surface is still there, although it seems to me it acts more like a compatibility layer. That is, behind the scenes SDL 2.0 may do stuff like with output=texture (to be mentioned soon), with a software renderer driver. Furthermore, "vsync" cannot be toggled here by the user.
- "opengl" and "openglnb" are still there working as before, although with a few modifications. Technically, a GL context is created separately from the window, when SDL 2.0 is used.
- Again for the sake of consistency, the "vsync" settings applies now to "opengl" and "openglnb" outputs (with SDL 1.2 and 2.0).
- New "texture" and "texturenb" values have been added as choices for the "output". With these, a renderer is created for the window, and then a texture is formed so the graphical data can be stored. As with the opengl choices (and ddraw,overlay for SDL 1.2), scaling is applied.
- Note that in general, RGB color format (or RGBA) is assumed. The exception is output=opengl (openglnb), which uses BGRA as before.
- As a consequence, scalers other than normal*x and advmame*x are expected to work with surface, texture and texturenb outputs directly. As is the case with SDL 1.2, though, DOSBox will fallback to output=surface if opengl/openglnb is used.
- A new "renderer" setting has been added. Basically, when output=texture or texturenb is used, there can be a few choices of an implementation for the renderer. A few examples are OpenGL, Direct3D and Software. For simplicity, the setting currently accepts a numerical value. -1 stands for an automatic choice, while a nonnegative number is used to select a specific rendering driver. While I could use actual names, the availability of specific renders vary from one platform to another. So, for now this is the way to choose one.
- For SDL 2.0, a "display" setting has been added, letting one pick a display in a multi-monitor setup. I haven't tested this with such a setup, though.
Next comes a list of changes for keyboard input handling and the mapper UI:
- In general, vanilla DOSBox currently uses SDL keycodes. It can also use scancodes, although they are quite platform-specific, at least on SDL 1.2. When these are used, DOSBox takes advantage of a few mapping tables. It seems to be mostly based around keycodes, though.
- Now, with SDL 2.0, the SDLK_LAST constant is gone and several keycodes have quite large associated numeric constants (as defined in SDL_keycode.h). This poses a problem in at least one place in the DOSBox code.
- However, SDL 2.0 now has a list of constants that can be used for scancodes. They appear to be somewhat more platform-independent, in comparison to SDL 1.2. Furthermore, an occurrence of SDL_NUM_SCANCODES (a potential substitute for SDLK_LAST) can be found in SDL_scancode.h. In general, one reason to use scancodes rather than keycodes is to provide layout-independent IDs based on the LOCATIONS of the keys. For instance, if you're using W,S,A,D to move in some game, it shouldn't matter if the letter W,S,A,D are actually printed on them, right?
- As a result, I've decided that on the SDL 2.0 case, SDL scancodes will be *exclusively* used as a replacement for the SDL keycodes. So, unless you compile for SDL 1.2, "usescancodes" is now gone.
- Oh, one more little thing about the mapper UI: As a preparation for devices with touch-input (although I couldn't test that so far...), the following change has been done. While holding a mouse button and pointing at some button on the UI, it gets marked with a unique color. Let's hope there are no great bugs. Note that this change applies for SDL 1.2 and 2.0 altogether.
- To finish, you'd better want to keep fullresolution=0x0. If you try to use anything other than the desktop resolution, problems are possible. SDL 2.0 tries to solve this in a way, although a cooperation of window managers is required as well. You may also set SDL_VIDEO_X11_LEGACY_FULLSCREEN=1 to have a behavior somewhat similar to SDL 1.2.
A list of problems to mention:
- With SDL 2.0, the window focus stuff isn't working for me as expected and I couldn't fix that after trying for a little while. Yeah, you may unlock and lock the mouse cursor as usual. But, suppose that you set priority=highest,pause in the configuration file. Then, chances are that DOSBox will be paused immediately, with no clear way to unpause it.
- In SDL 1.2 you may find the notion of bits-per-pixel commonly used. The thing is, it isn't that common these days to change this within games, and more often than not the relevant value is always 32-bpp, at least on currently common desktop environment. Furthermore, probably as a way to be compatible with more platforms, SDL deals now with pixel formats more than just bits-per-pixel. You can have RGBA8888, ARGB2101010 and more.
- So now, with the possible exception of OpenGL, I assume the pixel format of RGBA of RGBA.
- Note that may see a warning in regards to the usage of a 24-bit color depth on the desktop. While it may really be 32-bit, this is what I get in some kind of a way for now...
- For simplicity, I also don't tell the difference between 24-bit and 32-bit (on the host side) in a few places (with SDL 2.0 only).
- In a few places, like the DOSBox splash screen and the mapper GUI, an SDL 1.2 style surface is still used, even when compiled with SDL 2.0 in mind. This approach seems to have a few issues. For instance, the red and blue channels get swapped here in the mapper.
- Furthermore, the mapper isn't drawn efficiently with SDL 2.0. This is the case since it's still based on a 8-bit paletted surface, even with SDL 2.0. A manual pixel-by-pixel conversion has worked for me, ignoring the red and blue channels swap.
- Furthermore, with SDL 2.0 you may see in the mapper that the extra "less than" or "backslash" key found in these keyboards with the 102-key layout are unnamed. I refer here to the host key, not the one in the UI for the emulated machine. Basically, SDL_GetScancodeName appears to return an empty string for the scancode of this key. One may think it's better to use SDL_GetKeyFromScancode and then obtain the keycode's name, especially if we want the host key *labels* to be layout dependent. However, at least based on this page (is it up-to-date?), no keycode is associated with that specific scancode: http://wiki.libsdl.org/moin.cgi/SDL_Scancode
EDIT 1: Guess what? I have omitted a few things, indeed!
- One feature removed with SDL 2.0 is (physical) CD-ROM support. As a consequence, I have decided to omit that altogether, whenever SDL 2.0 is used. I know that on a few platforms DOSBox may not actually use SDL for that, and the "mount" command can also be used to mount plain directories as CD-ROMs (with limited support). For simplicity, though, the CD related features of "mount" are gone now if SDL 2.0 is used. You can still use "imgmount", and it's true that it may be better for us to have image backups of original CDs. I prefer these over the discs, even though I do have an optical drive right here. Furthermore, maybe the CD-ROM code of SDL 1.2 can be formed into a separated library or a similar thing.
- Ones may see the patch file has a few "hacks" involved in the source. Some of these are Android-specific, mostly done to make the code compile (at all). Not sure if these are good, but this is the situation for now. Other "hacks" may be related to the way functions are organized. I suppose that, at least in theory, it shouldn't be too hard to fix a few of these.
Hope somebody has fun with this!