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

Here you can discuss the development of patches.

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

Postby NY00123 » 2018-12-22 @ 18:14

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).
You do not have the required permissions to view the files attached to this post.
NY00123
Member
 
Posts: 237
Joined: 2010-2-13 @ 19:42

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

Postby 5schatten » 2019-1-02 @ 16:52

@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 :-)
5schatten
Newbie
 
Posts: 1
Joined: 2019-1-02 @ 14:08

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

Postby bam » 2019-1-03 @ 18:37

Thanks @NY00123.
Have you tried to push your patches upstream?
bam
Newbie
 
Posts: 11
Joined: 2019-1-03 @ 02:50

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

Postby Dominus » 2019-10-19 @ 20:28

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.
User avatar
Dominus
DOSBox Moderator
 
Posts: 8024
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

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

Postby NY00123 » 2019-11-20 @ 08:38

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).
You do not have the required permissions to view the files attached to this post.
NY00123
Member
 
Posts: 237
Joined: 2010-2-13 @ 19:42

Previous

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 2 guests