An adaptation to SDL 2.0 (Alpha-level Android build attached)

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby NY00123 » 2013-2-24 @ 11:20

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.


Hey all,

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!
Attachments
dosbox_sdl2_sample_icons_for_android.tar.bz2
A few sample icons, originally coming from an SDL2 Android project template, although the original source probably differs.
(9 KiB) Downloaded 235 times
dosbox_sdl2_20130224.diff
Patch against r3818 for SDL2 support
(131.37 KiB) Downloaded 296 times
Last edited by NY00123 on 2013-6-26 @ 15:05, edited 5 times in total.
NY00123
Member
 
Posts: 206
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Currently tested on Linux)

Postby NY00123 » 2013-2-25 @ 10:41

Here is a little update. It basically combines the above patch with a variant of this (flicker glitch fix): viewtopic.php?t=34777

As described in that thread, after toggling triple buffering in the driver and VSync (all for OpenGL rendering), I have experienced a few flickering related glitches, mainly when SDL2 is used. These occur with output=texture (using the OpenGL renderer driver) and output=opengl, as a change from text mode with aspect=false to graphics mode with aspect=true occurs. Older textual contents can be seen flashing, basically staying in one of a few buffers.

One may conclude that after swapping buffers, you may *never* assume anything about the contents of the back buffer (or rather *any* back buffer, since triple-buffering is a possibility), as mentioned here: http://gamedev.stackexchange.com/questi ... wapbuffers

Yes, a specific assumption may work on a great deal of setups. But it has clearly failed for me when triple buffering is toggled.
Attachments
dosbox_sdl2_with_bufferswap_20130225.diff
SDL2 patch, combined with a patch fixing a flickering glitch in OpenGL (using output=opengl,texture)
(132.04 KiB) Downloaded 186 times
NY00123
Member
 
Posts: 206
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Currently tested on Linux)

Postby NY00123 » 2013-2-25 @ 16:32

Oh yeah, now I've realized that a typo of mine HAS actually slipped into the patches!

Basically, to the ones who want to check their tough luck with this on Android, please edit AndroidManifest.xml so it says "@string/app_name" rather than "@string/dosbox".
... Or simply use one of the attached patches. [The one fixing the flicker is suggested by me, although for consistency I have attached both.]

EDIT: Well, maybe it's also good to suggest these:
- As mentioned in android-project/compilation.txt, DOSBox is expected to create a configuration file on a location like /path/to/sdcard/Android/data/com.dosbox.emu/files/dosbox-SVN.conf.
- In case of problems you may wish to play with the graphical settings. fullscreen=true, fullresolution=0x0 and output=surface are good examples of settings to try.
- As I've realized just now, it may also worth to play with sound settings. In particular you may like to change the "rate" value to something like 48000, if not disable the sound by setting nosound=true.
Attachments
dosbox_sdl2_with_bufferswap_20130225_2.diff
SDL2 patch with flicker fix and corrected AndroidManifest.xml
(132.05 KiB) Downloaded 170 times
dosbox_sdl2_20130225.diff
SDL2 patch with corrected AndroidManifest.xml
(131.37 KiB) Downloaded 171 times
Last edited by NY00123 on 2013-2-25 @ 17:17, edited 1 time in total.
NY00123
Member
 
Posts: 206
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Currently tested on Linux)

Postby Dominus » 2013-2-25 @ 17:03

Hmm, when I muster the courage to build SDL2, I want to to try this on OSX. I'm annoyed at the CDRom thing though, didn't know that SDL2 killed it (even though it's mostly useless on OSX anyway).
User avatar
Dominus
DOSBox Moderator
 
Posts: 7129
Joined: 2002-10-03 @ 09:54
Location: Vienna

Re: An adaptation to SDL 2.0 (Currently tested on Linux)

Postby NY00123 » 2013-2-27 @ 14:58

An update is now up, against r3819 this time. I'd say it doesn't add a lot. Apart from updating a few in-code comments, there are mainly *basic* adaptations for the Android platform. These consist of:
- A new set of icons, which are simply the original DOSBox icon with proper scalings applied. While technically not a part of the code-wise update, an actual DOSBox icon is now shown.
- A few different defaults for DOSBox settings that can help with making this modified DOSBox somewhat stable out of the box. One such example is fullscreen=true.
- Proper relative mouse MOTION support using the touchscreen. [Sorry, but mouse buttons emulation is not there now.]
- The system Back button is now mapped to the Esc key in the emulated DOS machine. Note that on some Android setups there is practically no difference between Esc and Back.
- android-project/compilation.txt has renamed to android-project/instructions.txt. As before, please check it out if you want to try building this for Android, or even just run it.

I should also mention that the aforementioned "buffer swap" fix is now integrated, and it won't be separated from now on.

Finally, with a big warning of potential troubles, an APK file that ones may test is attached. Note that you do need a physical keyboard. If it's a problem then WiFi Keyboard may come to the rescue: https://play.google.com/store/apps/deta ... losyukivan

Note that there are very great chances I won't do much more than that. You still have the diff, though.

Dominus wrote:Hmm, when I muster the courage to build SDL2, I want to to try this on OSX. I'm annoyed at the CDRom thing though, didn't know that SDL2 killed it (even though it's mostly useless on OSX anyway).


If you do get to try this, I wish you a good luck! :)
Attachments
DOSBox-debug-unaligned.zip
**Rename to DOSBox-debug-unaligned.apk before installation (ZIP to APK)**
**Installation from unknown sources should be permitted**
**Physical keyboard required**
**instructions.txt from the diff may help**
(1.12 MiB) Downloaded 206 times
dosbox_android_icons.tar.bz2
The DOSBox icon with adapted variations for Android package construction
(43.51 KiB) Downloaded 164 times
dosbox_sdl2_20130227_all.diff
Updated SDL2 patch for February 27th (2013); Includes the "buffer swap" fix.
(136.49 KiB) Downloaded 171 times
NY00123
Member
 
Posts: 206
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby NY00123 » 2013-3-04 @ 15:27

Another update is up. Most of the changes are again Android-specific, although there's a little more.

- To begin with, the kind of value to set for the "renderer" setting within the DOSBox configuration file has changed. It now accepts a string as a value. renderer=auto is the default. More values are platform-specific. A few examples are: direct3d (Windows only), opengl (every non-Android platform), software (all platforms). You can let DOSBox generate its own copy of a configuration file (like dosbox-SVN.conf) to see the list of possible values in a comment.
- Fixed a graphical glitch occurring with output=surface and aspect=true (SDL2 only).
- Android: The DOSBox "Activity" class has been renamed to DOSBoxActivity (and so has the Java file). Truly, I could just keep it named DOSBox as before. Oh well...
- Android: config.h has been touched so the recompiling core (for ARMV4LE) is now supported. I wonder why have I used something like ARMV7 and made this fail beforehand...
- Android: The on-screen keyboard can now be displayed/hidden, using the Menu button or three-dots Action Bar. Please note that the keyboard's actual purpose is text input, and the SDL Activity lets you display the keyboard just for that. The inherited DOSBox Activity has been modified to catch Menu/Action button presses/releases before SDL itself. In particular, the DOSBox app itself (including the mapper) never catches a Menu/Action button press/release. Further note that many on-screen keyboards will not work as expected for all time, again due to the different purpose of them. Nevertheless, some of you may be interested in Hacker's Keyboard: https://play.google.com/store/apps/details?id=org.pocketworkstation.pckeyboard.
- In case of problems, you may still use physical keyboards on Android, WiFi Keyboard included: https://play.google.com/store/apps/details?id=com.volosyukivan
- Android: The device's volume keys should now control the application's volume, as done in other apps. As with the Menu/Action button, the Java file has been modified so it catches the volume key events before the SDL Activity does. Sorry if someone has used these for in-game actions...
- Android: When DOSBox is just loaded, it checks for the current screen orientation and starts according to that. Note that auto-rotation is DISABLED while DOSBox is running. It's only on the very beginning that the orientation can be chosen. Further note that I can't exactly test this with the portrait orientation here, probably since the display's width of the device I've got is 480 pixels (in portrait orientation), which is too low for the DOSBox command prompt.
- Android: The visual contents are now vertically aligned to the top of the screen (on Android only), so the onscreen keyboard hides less of them. I can't seem to test this with the portrait orientation, though, getting a crash. It may again be the result of the low screen width in pixels (in such a case).
- Android: Full mouse emulation (well, a prototype) is now built-in. Use the left third of the screen for left mouse button clicks, the middle third for mouse motion and the right third for middle and right button clicks. To be more specific, the rightmost sixth of the screen is used for right button clicks.
- A few more minor fixes.

Note that it is still a prototype, especially on the Android platform. Maybe it'll be further improved, possibly not by me. I can't promise anything in regards to that.
Nevertheless, hope someone enjoys while trying this out!
Attachments
DOSBox-debug-unaligned.zip
**Rename to DOSBox-debug-unaligned.apk before installation (ZIP to APK)**
**Installation from unknown sources should be permitted**
**instructions.txt from the diff may help**
(1.15 MiB) Downloaded 192 times
dosbox_sdl2_20130304_all.diff
SDL2 diff against r3820
**instructions.txt from the diff may help for building an Android package**
**A set of icons for the Android package is required. See dosbox_android_icons.tar.bz2 from previous post and instructions.txt.**
(140.89 KiB) Downloaded 175 times
NY00123
Member
 
Posts: 206
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby NY00123 » 2013-3-19 @ 19:38

After a little while, an update to the patch is now up.

* Known bug discovered just recently (using SDL2 only): Sometimes, after loading the mapper with the default key binding of Ctrl-F1 and then exiting from the mapper back to the emulator, it would act like one of the Ctrl keys is still pressed. As a workaround, press-and-release the EXACT SAME key to fix. That is, if the left control key has been used for loading the mapper, press-and-release left control, not right.

List of changes:
- Patch updated to be compatible with r3824 (where NV_PixelDataRange is replaced with ARB_PixelBufferObject). What it has shown me is that while it may seem useful to separate SDL 2.0 specific code from SDL 1.2 one, code duplication is still the source of troubles... I guess SDL 2.0 only (or 1.2 only) is simply...simpler...
- SDLActivity.java has been updated (from the SDL repository).
- I think that, at least on a specific GNU/Linux desktop, window focus issues are finally fixed! In particular, "priority=higher,pause" should work as expected.
- Preparation for (very) theoretical support for output=opengl,openglnb on Android (actually OpenGL ES 1.0) has been done. It's not really working, though.
- There are also preparations for output=texture on Android, again not working at the moment... oh, and even if it doesn't crash for any of you, it should be no more than a fallback to output=surface. Note that aspect correction is NOT set in that case even if you want it, or so it seems to me.
- A few Android-specific (technical) hacks are removed now, thanks to a few modifications.
- The 24-bit bpp warning is now gone if a 32-bit color depth is set for the desktop.
- (Should have done this before) The following DOSBox settings are now absent on Android: fullscreen, windowresolution. fullresolution can still be set, though.
- fullscreen=true is basically forced on Android now. The mapper fullscreen toggle functionality can still be activated in theory, though.
- Fixed a possible glitch in the splash screen when SDL2 is used.
- The mapper colors should be correct now with SDL 1.2 and 2.0 altogether! In general, a 32-bit RGBA software surface is used for drawing with this update.
- A few more fixes and other kinds of changes.
Attachments
DOSBox-debug.zip
Android package for testing
**Rename to DOSBox-debug.apk before installation (ZIP to APK)**
**Installation from unknown sources should be permitted**
**instructions.txt from the diff may help**
(1.16 MiB) Downloaded 194 times
dosbox_sdl2_20130319.diff
SDL2 diff against r3824
**instructions.txt from the diff may help for building an Android package**
**A set of icons for the Android package is required. See dosbox_android_icons.tar.bz2 from an earlier post and instructions.txt.**
(150.22 KiB) Downloaded 183 times
NY00123
Member
 
Posts: 206
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby NY00123 » 2013-6-26 @ 15:02

Been a bit long, but there is another update as of this moment. Among the changes:
- Some code duplication has been removed.
- Fullscreen window handling has improved on X11 and hopefully more.
- output=texture is now the default when targeting SDL 2.0. In case SDL 1.2 is the target, the default is still output=surface.
- The mapper UI is drawn using a 8-bit surface again, only that it gets converted to the desktop's pixel format before updating the on-screen contents.
- This has been tested on Android using an update to the ARM backend attached to this post and stolen from here: viewtopic.php?t=31787
- To adapt for more recent devices, the Android "target" API level has been raised to the maximum available as of today (17). Furthermore, the "menu" button is *not* used for showing the on-screen keyboard anymore. Use the "back" button for that.
- As for the older default behavior of the "back" button emulating the Escape key, this is now the role of a specific portion of the touchscreen.
- Note that the bundled SDLActivity.java has a few patches applied in order to make the app work better.

Only recently I have spotted a few problems regarding screen rotation and possibly more. So, for now, as before a fixed screen orientation is determined on application startup.

**************

Roles of different touchscreen portions (for mouse actions and simulated *host* Escape key, the latter being theoretically mappable to other client-side things)):

Code: Select all
/-----------------------------------------------------------------------\
|    Left   | (H)Escape |   Motion  |  Motion   |   Middle  |   Right   |
\-----------------------------------------------------------------------/
Attachments
armv7.diff
ARMv7 recompiling core patch stolen from http://www.vogons.org/viewtopic.php?t=31787
(160.77 KiB) Downloaded 92 times
dosbox_sdl2_win32_20130626.zip
Win32 executable (cross-compiled with MinGW)
(1.33 MiB) Downloaded 163 times
dosbox_sdl2_20130626.diff
SDL2 diff compatible with r3833
**instructions.txt from the diff may help for building an Android package**
**A set of icons for the Android package is required. See dosbox_android_icons.tar.bz2 from an earlier post and instructions.txt.**
(167.48 KiB) Downloaded 105 times
DOSBox-debug.zip
Android package for testing
**Rename to DOSBox-debug.apk before installation (ZIP to APK)**
**Installation from unknown sources should be permitted**
**instructions.txt from the diff may help**
(2.43 MiB) Downloaded 126 times
Last edited by NY00123 on 2013-6-26 @ 20:04, edited 2 times in total.
NY00123
Member
 
Posts: 206
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby NY00123 » 2013-6-26 @ 16:13

Guess what? Somehow I have found out that I have missed something. Naively raising the target API level for the Android platform is one thing, but not replacing android:configChanges="orientation" with android:configChanges="orientation|screenSize" in the AndroidManifest.xml file...

Well, that has broken screen rotation capabilities. To fix that, I have updated the manifest as required and also applied minor updates to sdlmain.cpp which should have an effect on Android only. Fixed patch is attached, along with an updated Android package.

Since there are no actual changes on any platform other than Android, I have not re-built a Windows executable. See the previous post for one.

P.S. Before I forget, the attached Android package has executables built for ARMv7 and x86. It takes advantage of the aforementioned ARMv7 recompiling core patch, which can be downloaded in the earlier post of mine or via the original forum thread where this was posted on.
Attachments
DOSBox-debug.zip
Fixed Android package (as usual rename to APK)
(2.43 MiB) Downloaded 133 times
dosbox_sdl2_20130626_2.diff
Fixed patch (Ignoring the minor modifications, anything applying to Android before should still apply here.)
(167.3 KiB) Downloaded 159 times
NY00123
Member
 
Posts: 206
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby rcblanke » 2013-8-12 @ 16:40

Apparently, the SDL 2.0 final release is very near, now - http://www.phoronix.com/scan.php?page=n ... px=MTQzNDI
User avatar
rcblanke
Oldbie
 
Posts: 1290
Joined: 2005-4-01 @ 09:44
Location: Round 42

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby NY00123 » 2013-8-13 @ 12:16

rcblanke wrote:Apparently, the SDL 2.0 final release is very near, now - http://www.phoronix.com/scan.php?page=n ... px=MTQzNDI


Looks like it's even nearer than expected: http://forums.libsdl.org/viewtopic.php?t=9374
An archived copy: http://sdl.5483.n7.nabble.com/Announcin ... 36145.html
NY00123
Member
 
Posts: 206
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby DosFreak » 2013-8-13 @ 17:20

Does the change in license in SDL 2.0 affect using it with DOSBox?
Game Acronym List
DosBox CVS Builds
DosBox Feature Request Thread
DosBox FAQ
PC Game Compatibility List
"People like coldplay and voted for the nazis, you can't trust people."
User avatar
DosFreak
l33t++
 
Posts: 9233
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby P4R4D0X » 2013-8-13 @ 17:50

DosFreak wrote:Does the change in license in SDL 2.0 affect using it with DOSBox?
As far as I know the zlib license should be compatible with the GPL. SDL was relicensed and it's freely available for static linking in commercial closed-source projects. Too bad that the CD API is now removed, but it's really a great update by looking at the changelog. Hopefully one day we will have full SDL 2.0 support in DOSBox.
User avatar
P4R4D0X
Newbie
 
Posts: 99
Joined: 2012-10-06 @ 14:46

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby DosFreak » 2013-8-13 @ 20:27

Has there been a solution provided yet for physical CDROM support for SDL 2.0? Seems ridiculous to drop support when almost every OS still supports CD-ROM.....
http://wiki.libsdl.org/moin.fcg/MigrationGuide

Worst case would be to provide links to CD imaging utilities for each supported OS.

I also hate how SDL still mentions the operating systems they support.....but they don't list each one. So they support "Windows". Which one? Well with SDL 2.0 it's XP+ but you're not going to find that anywhere.
EDIT Well it's about damn time http://hg.libsdl.org/SDL/file/default/R ... tforms.txt
Game Acronym List
DosBox CVS Builds
DosBox Feature Request Thread
DosBox FAQ
PC Game Compatibility List
"People like coldplay and voted for the nazis, you can't trust people."
User avatar
DosFreak
l33t++
 
Posts: 9233
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby NY00123 » 2013-8-13 @ 22:02

About CD-ROM support: This is what happens when the main targets of SDL 2.0 are new/modern games and platforms, it seems. In fact, the SDL 1.2 CD-ROM API is practically a CD Audio API, referring to one of the oldest features of optical discs for PCs and similar platforms in general. (Discs can also be used for general data storage and there are still DVD videos and (relatively) a few Blu-Ray discs.)

Personally, though, while I do have a DVD-RW drive installed in the desktop I'm using right now, I rarely get to use it...
In case I do want to load some game from a physical CD/DVD, I prefer to make a proper image and mount that instead. Daemon tools letting ones create images and mount them, like "Alcohol 52%" for Windows, as well as "CDRDAO" and "CDEmu" for Linux, can be quite useful here.
NY00123
Member
 
Posts: 206
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby gulikoza » 2013-8-14 @ 07:37

If I understand correctly, CD-ROM API is also needed when mounting from Daemon tools as that is just another CD/DVD to DOSBox. The only way not needing it, would be imgmount, but that is somewhat hard to use because of lack of gui (and unlike disk images, one tends to change cd-rom images more frequently so you can't put that in [autoexec]).
One solution would be to put SDL1.2 CDROM code directly into DOSBox. Supporting 3 major platforms (WIN, LIN, OSX, ...) would probably cover 99.99% of the cases where physical cd-rom can actually be used.
User avatar
gulikoza
Oldbie
 
Posts: 1694
Joined: 2004-6-25 @ 14:53

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby NY00123 » 2013-8-14 @ 07:52

Actually, while typing about daemon tools, I haven't thought of using these with DOSBox at all :o
But yeah, when it comes to DOSBox itself, imgmount is the preferred way. Problem is that certain image file formats are unsupported.

And yeah, I did think about the basic idea of moving the CD-ROM API to somewhere else; Either embed it within DOSBox, or create a small shared library to be used with more programs. For a long(er)-term working solution, though, imgmount is still the better way. (Of course it doesn't handle non-DOS games that well...)
NY00123
Member
 
Posts: 206
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby truth_deleted » 2013-8-14 @ 08:37

The SDL 2.0 adaptation will be well received by tablet users, especially if an iOS port becomes available; they are currently using an old version and it runs slow. However, the desktop systems will lose other features than CD-ROM, including the OpenGL-HQ driver and cross-platform applicability (outside the tablets). "wd" also previously mentioned the new set of bugs which will crop up with 2.0 (then 1.3). It's too bad there isn't a way to use both 1.2 and 2.0 libraries alongside one another; perhaps a developer will allow them to co-exist, given this is possible.

Your current direction seems perfect by targeting the Android platform along with the ability to experiment with basic 2.0 functions in the desktop.
truth_deleted
 

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby NY00123 » 2013-8-14 @ 21:06

It's interesting that it has taken a bit before a few reports about the release have come to the web. Or maybe that's just me.

truth5678 wrote:However, the desktop systems will lose other features than CD-ROM, including the OpenGL-HQ driver and cross-platform applicability (outside the tablets).

I guess you are talking about less commonly used platforms (even when compared to Linux) like FreeBSD (having new releases) and MacOS Classic (which has been considered outdated for quite long)? Then yeah, that is a point. But:

It's too bad there isn't a way to use both 1.2 and 2.0 libraries alongside one another; perhaps a developer will allow them to co-exist, given this is possible.

I think that I made the patch in such a way that you can optionally build a separate EXE targetting SDL 1.2. Chances are I haven't really tested this last time, but that should be possible. A different executable is required, though. (Of course someone may try to go the way of dynamically loading everything, obtaining function pointers...)

"wd" also previously mentioned the new set of bugs which will crop up with 2.0 (then 1.3).

I did see some complaints from him before, but I'm not entirely sure about the details. Now that SDL 2.0.0 has been released, maybe the situation has changed since then? I really have no idea, so I'm guessing: The complaints may refer to changes like these:
- The removal of CDDA support.
- Some modifications to keyboard input handling.
To be more specific about keyboard support, SDL 1.2 report what you may call numeric key codes for pressed/released keys, and there is an upper bound of SDLK_LAST on them. Usually, DOSBox uses hardware scan codes values (at least partially), which can easily be platform-specific, yet these were surely tested by at least one DOSBox developer for a few specific platforms. As for SDL 2.0, SDLK_LAST is gone, but there are more portable representations of scancodes, along with the upper bound of SDL_NUM_SCANCODES.

The SDL 2.0 adaptation will be well received by tablet users, especially if an iOS port becomes available

Not sure if you're aware of this, but I have a feeling that, while chances are it simply won't happen, if DOSBox ever arrives to iOS then it won't appear in Apple's App Store (for iOS powered devices).

Your current direction seems perfect by targeting the Android platform along with the ability to experiment with basic 2.0 functions in the desktop.

Well, I know this is something that some users will not like to hear (or read), probably. While I did get some kind of a port of DOSBox to SDL 2.0, there is surely some more (and a different kind of) work to do for proper support on touchscreen-centric platforms (especially with no much physical buttons). Yeah, it's probably not that hard to (very partially) go by Pelya's way with his earlier SDL 1.2/1.3 port for Android (or so I understand), adding a few on-screen controls that basically emulate specific *host* keys (i.e. result in SDL *keyboard* events). These can then be optionally mapped using the built-in DOSBox mapper.
However, for truly proper support, I believe any of the following features can't really be ignored:
- Handle on-screen controls in the mapper directly, for the purpose of mapping emulated input events (as currently done for physical buttons).
- Let one move/resize/(add/remove) on-screen controls.
- Handle host/client mouse in the mapper. (Right now it's only about emulated keyboards and joysticks, and the host (physical mouse) of a desktop computer is always mapped to an emulated mouse.)
- Make it easier to save custom on-screen controls arrangements for multiple games.
- In fact, eventually write something that does not really differ from what is known today as a "DOSBox frontend".

One minor question that comes to mind (far from a promise to do such a thing on my own!) is a choice of a UI toolkit for such a frontend. Yeah, a native Android UI is a way on the Android platform, and same on others. Alternatively, though, it may actually be simpler to have a single uniform (probably SDL-based) UI across all supported platforms.
NY00123
Member
 
Posts: 206
Joined: 2010-2-13 @ 19:42

Re: An adaptation to SDL 2.0 (Alpha-level Android build attached)

Postby truth_deleted » 2013-8-15 @ 00:36

Retroarch has encountered some of these questions. On iOS distribution, they chose "Cydia" to replace the Apple App Store. Retroarch also contended with a portable GUI system and previously chose the QT toolkit. However, this GUI was not favored by users so they now utilize the RGUI menu system; it should be open source: https://github.com/libretro/RetroArch/wiki/RGUI. From other postings, the other possibility is coding directly to the Android API; I have yet to find a reference to SDL 2.0 providing a simple menuing system for Android.

I've wondered if a dosbox port to retroarch would support sufficient functionality. They provide the universal frontend and even the on-screen controls. However, your project would support the full feature set of dosbox along with the SDL 2.0 additions.
truth_deleted
 

Next

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 1 guest