Thanks for the report and for getting the backtrace, testerson. Can you check out the updated patch?

Summary of changes for the attached patch:
- Compatible with r4178.
- Should actually use SDL_LockAudioDevice/SDL_UnlockAudioDevice in SDL 2.0 builds, instead of SDL_LockAudio/SDL_UnlockAudio. Seems to fix the reported segmentation faults (reproduced by testerson with Pinball Fantasies). This one has been somewhat tricky to figure out, for obvious reasons.
- Swapped the order of inclusions of <winioctl.h> and <ntddcdrm.h> in cdrom_ioctl_win32.cpp, so Mingw-w64 builds should be possible with the packages from Ubuntu 18.10. Applies to SDL 1.2 and 2.0 builds altogether, although *not* required for the stock DOSBox sources (probably since "cdrom.h" is included earlier, after applying the patch).

@NY00123
Thx for your SDL2 patch! Have you ever considered to melt your changes into this build https://blog.yesterplay80.net/dosbox-ece-en or adopt these into yours? Right now I'm using this build https://github.com/duganchen/dosbox but it's somewhat outdated. There are several DOSbox builds out there but none of them is either "feature complete", supports SDL2 or is based on a recent version. Also would it be possible to create a DOSbox repo on git or something similar to keep track of your changes?

best regards & a happy new year 😀

Thanks @NY00123.
Have you tried to push your patches upstream?

To keep track of what I needed on OS X to make this work:
- in src/sdl_cdrom/macosx/CDPlayer.h needed to add #include "../compat_SDL_cdrom.h"
- in src/sdl_cdrom/macosx/CDPlayer.c:562 threads need to be named so changed SDL_CreateThread(RunCallBackThread, NULL); to SDL_CreateThread(RunCallBackThread, CheckInit, NULL);
- in configure.ac:645 needed to add -framework CoreFoundation -framework Cocoa to the darwin LIBS= line

SVN broke the patch in some small instances since last year, too.

Thanks to Dominus for testing the patch. I've updated it after applying required fixes for OS X and updating to r4293.

Notes that I should add first:
- Whatever I previously said about SDL_sound still applies. Additionally, as I'd been informed by Dominus, SDL_sound had been updated (during 2018) so it now requires SDL2. There were also other various changes, partially done in order to relicense SDL_sound under zlib. However, I've found out that with this version, Sound_Decode may incorrectly return half the expected value, leading to very clearly audible issues with playback under DOSBox. I suspect that it's related to an internal conversion between differing sample formats.
- Dominus has reported that a 32-bit SDL2 build may crash on OS X, reason being that there's no Metal support for 32-bit EXEs, yet it doesn't seem to lead to a failure, and the SDL_renderer code doesn't try another renderer driver.

In case you observe the above crash:
- If you have a ready conf file for the SDL2 build, edit it so "output" differs from texture/texturenb. Alternatively, change "renderer" to "opengl" (or "software", although that's probably less recommended).
- Otherwise, set the environment variable SDL_RENDER_DRIVER to opengl (or software) before starting DOSBox. After it creates a .conf file, you may edit it as described above
- Alternatively, if you can, make and run a 64-bit SDL2 build, at least for temporarily creating the .conf file.

This time, I've further decided to attach a smaller patch, which removes most of the Android-related code, but still keeps the adapted SDL_cdrom 1.2 code. In particular:
- This removes the whole android_project dir. It's probably incompatible with newer Android development setups, anyway (the move from Ant to Gradle is just one reason).
- This also removes code which is clearly specific to Android and touch input (like the alternative mouse input), and also a few bits which might actually be related to STLport (unsure about this).
- Eventually, though, I still kept a great deal of the code originally added for Android in, albeit it's untested. This includes OpenGL ES 1.1 functionality and the always-fullscreen changes, but also minor changes related to running in portrait orientation while an on-screen keyboard is displayed (moving the viewable area to the top of the screen).

Hello, NY00123 - let me start by thanking you for your work on bringing SDL2 to DOSBox - this is high-quality implementation and it solves so many DOSBox bugs, that I can't just list them all.

Just today we merged your patch (with extensive code cleanups before and fixing warnings and some small issues after) to master of dosbox-staging repo.

Our implementation is based on your patch version from December 2018 (your latest version appeared when had a lot of work finished already, and we couldn't easily pivot).

In the process we made following changes / solved some issues:

- Build is SDL2-only, making the code a lot cleaner and easier to maintain long-term
- SDL_sound (which was never officially released for SDL2 btw) is no longer an issue - we have it integrated with dosbox code (via krcroft's audio patch) - this works much better than relying on unmaintained SDL_sound 1.2 / unrealeased SDL_sound 2.0
- All code in sdl_mapper, that was unusable with SDL2 was removed - this way it should be easier to improve going forward
- We removed support for CD audio playback from physical CDs - similar to the way your original patch did it. Maybe in 2013 it was relevant feature, but in 2019 much less so. In the process we cleaned up all the code, that is totally unusable with SDL2 (which allows us to implement further improvements to CD-related code). Perhaps we'll bring this support back in the future, but ATM we're not convinced using SDL_cdrom is the way to go.
- We skipped code implementing output=opengles (OpenGL ES is already supported via texture). Perhaps it'll make sense to introduce this code, but rather after Android support will be in.
- We skipped Android support for now - we very much want to support it, but it needs more work (especially to make it build on our CI, co we can easily assure we're not breaking it in future changes)
- Lots and lots of compiler warnings were fixed, allowing for cleaner builds
- We query SDL for available renderers for output=texture instead of hardcoding it

During implementation, we also found some regressions (I mentioned them here).

Would you be interested in co-operating with me and krcroft on developing dosbox-staging? We would love to offer Android support as first-tier OS. For you, it will be easier than regularly rebasing the whole patch against new SVN trunk (we are merging-in new SVN revisions usually the same day they appear in trunk).

Hey dreamer, many thanks for your interest and feedback about this patch! I suppose the former of which is being demonstrated by the integration into dosbox-staging.

In case there's any concern, I've just compared dosbox_sdl2_20181222.diff to dosbox_sdl2_20191120.diff, and the actual changes are really minor. These are more-or-less the important differences that I've seemed to spot:
- The few fixes for OS X: Added dependency in configure.ac, and minor fixes in compat_sdl_cdrom code.
- Minor GL-related changes in sdlmain.cpp, mostly with calls to glClear/glClearColor; The latter changes were done in order to be in sync with the upstream revision that I checked by the time.
- A couple of diffs from the 20181222 revision are now gone, since they're technically in upstream.
- Mouse sensitivity being split into separate x and y fields.

Replacing SDL_sound with the other libraries might be the way to go, if this works better. Another alternative, if there are problems with SDL2_sound as it currently is, is including and maintaining a modified copy of it (like compat_sdl_cdrom), I guess.
Originally, I also didn't think that physical CD-ROM mounting support was a big deal when it came to a migration to SDL2, but then I heard more than once that it was considered quite important. Thus, I initially added limited CD folder mounting support, and later, I brought a modified copy of the SDL_cdrom code into the patch for greater SDL 1.2-like support. It's indeed been ~4.5 years since then, though.

Querying SDL2 for available renderer drivers is a good thing; Originally I hardcoded them since it was close to the way it's done in this piece of DOSBox code.

For the ones not aware, my patch was intended to be not far from a "clean" SDL 2.0 patch, in the sense that it shouldn't add much more than the SDL2 support. I did make a few exceptions; Say, minor changes to configuration settings (partially making sense, say the SDL2 renderer driver); But also the Android bits, without too much work on touch input support, and minor changes in mapper UI drawing.

I thought that keeping the option to make SDL 1.2 builds made sense, since the code was still there, so why not keep the support (especially for environments where you can't easily use SDL2). It also made the patch files smaller, I guess. Many apps do eventually go for a total replacement, though.

While it's great to see there's an offer to join forces with you, I'm afraid that I don't have a lot to contribute. Usually, if I update the patch these years, it doesn't occur that often, it's mostly for compatibility with newer DOSBox SVN revisions, and it's occasionally having just the few changes (e.g., OS X fixes).

Is that patch tested with the OpenGL output too? Aren't there issues with speed drop when used OpenGL output in DOSBox with that path applied? It seems as opengl in dosbox it just a blitter it mean that texutres updated everyframe, which mean in turn that there will be speed drop in compare with pure "surface" output.. At least how it looks like this.

kas1e wrote on 2020-01-20, 11:07:

Is that patch tested with the OpenGL output too?

Yes.

kas1e wrote on 2020-01-20, 11:07:

Aren't there issues with speed drop when used OpenGL output in DOSBox with that path applied?

When using with vsync=false (default), there are no performance drops (tested on several Linuxes and Windows 10). When used with vsync=true on Linux, we've seen real problems: #104.

Edit a bit previous post. Strange that on my setup (some ppc box) with vsync=false i have 50% speed drop. But i not sure if it because of SDL2 at all, probabaly just because of dosbox use opengl as blitter and update textures each frame.

Also, I noticed that in comparison with SDL1 build, with both core:normal, or core:dynamic, speed is better. With SDL2 build I see loosing of few fps.

kas1e wrote on 2020-01-20, 11:35:

Edit a bit previous post. Strange that on my setup (some ppc box) with vsync=false i have 50% speed drop. But i not sure if it because of SDL2 at all, probabaly just because of dosbox use opengl as blitter and update textures each frame.

What does it mean "some ppc box"? 😀

Anyways, here's my test results using v0.75.0-pre-396-g518c1428 on Linux x86_64 (Fedora), AMD RX590. Benchmark: Quake 1 (Steam), timedemo demo1, 3 runs, windowed:

texture 118.6 118.8 118.9
surface 117.6 117.9 118.0
opengl 118.6 119.0 117.4

What does it mean "some ppc box"?

I just test it on amigaos4 which is powerpc (big-endian) cpu, if you in interest see: https://en.wikipedia.org/wiki/AmigaOS_4

By speed yeah, it seems that for you with opengl mode there of no big issues.

Btw, i also noticed now, that swithing to/from window/fullscreen mode via alt+enter somehow not works all the time. Its like "Sticking". I.e. if i run in fullscreen mode, then hit alt+enter so to switch to window mode, then, i need to made a dosbox window be inactive firstly , and then make it active , so all input will be back. And the same when swith to fullscreen. Didn't notice something of that sort ? It can be easy some issue on my side , or with my sdl2, but maybe worth of note.

Many thanks @NY00123 and @dreamer_ for your great work, i was able to port dosbox on my Vu Solo4K STB device and works with SDL2 and DirectFB .
It has some sound issues for now and works only with a keyboard which i do not want to attach, i am trying to figure out how to add my remote codes to the dosbox instead, i already patched my SDL2 to add all my remote control keys.
Any help and/or directions to change the PC keyboard with my remote control will be helpful.

Attached a patch to change sdl2-config with pkg-config

serdeliuk wrote on 2020-02-07, 16:25:

Many thanks @NY00123 and @dreamer_ for your great work, i was able to port dosbox on my Vu Solo4K STB device and works with S […]
Show full quote

Many thanks @NY00123 and @dreamer_ for your great work, i was able to port dosbox on my Vu Solo4K STB device and works with SDL2 and DirectFB .
It has some sound issues for now and works only with a keyboard which i do not want to attach, i am trying to figure out how to add my remote codes to the dosbox instead, i already patched my SDL2 to add all my remote control keys.
Any help and/or directions to change the PC keyboard with my remote control will be helpful.

Attached a patch to change sdl2-config with pkg-config

@sardeliuk Looking at the path, I see it's specific to dosbox-staging. If you want for me to include it (maybe it's ok, maybe not), then you'll need to create a pull request on GitHub; this will allow me to do the review and easily run your patch through CI to test if it works correctly on a number of OSes and build configurations. But I suspect you might want to look at `./config --help` instead - there are some options in there to help development with locally-build SDL2 (e.g. `./config --with-sdl-exec-prefix=<path>`).

@dreamer__ thanks, i used your dosbox-staging github source indeed, i attached the patch to help others which wants to build their dosbox, directly on/or for , their embedded systems, in my case i build the dosbox directly on the vusolo4k 😀 it is a powerful enough machine with 2x-core 1.5Ghz ARM EABI (broadcom) maybe at the end i can create a patch to detect at runtime if there is an usable sdl2-config or not.

If you have few minutes or so maybe you can guide me how to replace the keyboard with my remote-control 😀 i wonder how i can add a new button let say SDLK_RED to replace left control, which files i need to modify? What do you think, it is something i can do? It is hard? Please note that i am not a programmer, just an experienced linux sysadmin 😀 but i was able to add all missing buttons to SDL2 (which has only PC keyboard buttons by default)

serdeliuk, I'm assuming your remote control generates evdev events? Here's a tutorial on how to map your remote control buttons to keyboard events. http://atterer.org/mythtv-xmbc-remote-control-without-lirc. Doing this will let you define things like "Red button" as "space bar" at the OS-level, in which case no modifications will be needed in SDL or DOSBox (they will simply see an inbound space-bar event).

However, if you're using your Vu Solo4K for stuff other than DOSBox, then you might not want your remote-control-DOSBox mapping to be active all the time. In which case, you could load your configuration just before launching DOSBox, and then revert back to the default mapping for KODI (or whatever else you're running on it). Just some ideas. I have done similar things, but not for DOSBox (for DOS gaming I need a full-size keyboard and D-pad 😀 )

@serdeliuk I think for quick and dirty proof of concept, you can try this: in src/gui/sdl_mapper.cpp find all uses of SDL_SCANCODE_LCTRL and replace with a scancode you probably added for a RED button. After that, you'll want to re-generate or manually edit mapper file (path to the file is printed on stderr during DOSBox startup).

Regarding your patch… hmm, maybe I should modify buildsystem a little to use `pkg-config sdl2` as a fallback in case `sdl2-config` is not found? Feel free to ping me via GitHub issue or email (you can find the address in git log).

[edit] krcroft's solution seems more long-term, and maybe it's also easier to maintain 😀

@krcroft thanks for suggestion, but i need to modify dosbox to use SDL2 keys, i am preparing a dosbox package installer for users which do not know more than "opkg install"
@dreamer__ the sdl2-config exists but exit with following error and EXIT CODE 1

root@vusolo4k:~# sdl2-config ; echo $?
ERROR: /usr/bin/sdl2-config should not be used, use an alternative such as pkg-config
--should-not-have-used-/usr/bin/sdl2-config
1

How i can create that mapper file by hand? Do you have one around to attach here?

During dosbox startup it say only about config file
CONFIG: Loading primary settings from config file /home/root/.dosbox/dosbox-staging-git.conf
Which contain a reference to missing mapper file
mapperfile = mapper-sdl2-git.map
Which probably should be in the same folder as config but is not, and there is no mapper file in source code as well

serdeliuk wrote on 2020-02-07, 19:34:

How i can create that mapper file by hand? Do you have one around to attach here?

Build dosbox-staging on Linux, run it, press Ctrl-F1, click "Save" - it will generate a new mapper file for you (it's a text file - you will have no problems with editing it manually), and it will be automatically loaded on next run.

In dosbox-staging (but not in SVN) you can also reload mapper files dynamically during runtime if you want to juggle through several different ones:

Z:\>config -set "sdl mapperfile=~/path/to/file.map"

(It's documented in manual/README file)