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 DosFreak » 2018-6-05 @ 13:48

I didn't think SDL supported Metal yet? I see a fork on github and posts about implementing metal and vulkan support awhile back though.
User avatar
DosFreak
l33t++
 
Posts: 9783
Joined: 2002-6-30 @ 16:35
Location: Your Head

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

Postby Dominus » 2018-6-05 @ 14:07

With SDL 2.0.8 a 2D Metal function was added https://discourse.libsdl.org/t/sdl-2-0-8-released/23957 for MacOS, iOS and tvOS (edit, still proud of these release notes, as there are two changes that I instigated and partly added patches for it :) (SDL_HINT_IOS_HIDE_HOME_INDICATOR & SDL_HINT_RETURN_KEY_HIDES_IME))
User avatar
Dominus
DOSBox Moderator
 
Posts: 7618
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

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

Postby DosFreak » 2018-6-05 @ 14:20

Nice! That's what I get for expecting their site to get updated. Gotta dig through those release notes. heh
User avatar
DosFreak
l33t++
 
Posts: 9783
Joined: 2002-6-30 @ 16:35
Location: Your Head

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

Postby NY00123 » 2018-6-06 @ 16:38

Yeah, there's now a Metal implementation of SDL_Renderer. MoltenVK can be used for Vulkan, and ANGLE for OpenGL ES.

As for MinGW, well, it shall be possible to build DOSBox with Mingw-w64, as of the last SVN revision. If not, it's probably a matter of not more than a few simple fixes (this was done beforehand).
NY00123
Member
 
Posts: 232
Joined: 2010-2-13 @ 19:42

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

Postby NY00123 » 2018-6-12 @ 20:36

OK, so the recent update has made me go over the patch and make just a few simple clean-ups. Nothing major.

However, I've kinda reproduced an old problem with the mouse, at least on Ubuntu 14.04 with the Unity shell. While it's not the first time I observe it, I now have a way to reproduce this.
Since it wasn't the only issue I had, I'll give out a list. The issue I've referred to above is about pressing on an "Alt" key after moving an imaginary "captured" cursor to any of the screen's edge. (It isn't exactly captured by the way of warping the cursor, but hopefully the idea is clear.)

*** All of the behaviors listed below have been observed with Ubuntu 14.04, using the Unity shell. ***

SDL 1.2 and 2.0:
- I had to disable the ability to show the HUD upon pressing on an Alt key. This seemed to cause some problems. It was probably an issue with SDL 1.2 apps, and I'm quite sure it's also the case with SDL 2.0 apps.

SDL 1.2:
- Keyboard input is fully locked in full-screens: You can't leave the window with shortcuts like Alt+Tab, but almost all shortcuts shall be usable in the games.
- As of Ubuntu 14.04 with Unity, you simply *can't* use any of the Alt keys in a non-fullscreen SDL 1.2 window, unless the mouse cursor is captured. (This used to be OK with older versions of Ubuntu.)

SDL 2.0:
- Keyboard input isn't entirely locked anymore: Keyboard shortcuts like Alt+Tab are usable. However, it's possible a few more might be used, even when not desired or even expected...
- Can't use Ctrl+Alt+<Arrow_Keys>, which are reserved for workspace switching, *even if there's only one workspace*. You basically need to disable these shortcuts keys (might be important for Keen 4-6).
- Can't use Alt+Space, since it's reserved for showing the window menu, and seemingly also has an effect on games. You may have to disable this as well (say for Jazz Jackrabbit).
- A complicated case DETERMINISTICALLY REPRODUCED ONLY RECENTLY: If you enter fullscreen with the mouse "captured" using SDL_SetRelativeMouseMode (actually hidden and in a "relative mouse motion" mode of sorts), then move the (inivisible) mouse cursor to any of the screen's edges and FINALLY toggle full-screen off, there are chances there'll be a VISIBLE mouse cursor which ***cannot leave the window's boundaries***.

Regarding the last case (with some details figured out just yesterday), this is possibly related to an unexpected window focus change. Basically, when you press on "Alt", an unexpected X11 event of type "LeaveNotify" may be received, effectively leading to the mouse cursor *mistakenly* being *unlocked*.
When fullscreen is finally toggled off, a call to SDL_SetRelativeMouseMode shall unlock the mouse and show the cursor. However, apparently, it's assumed the cursor is already unlocked, and so...it remains locked (albeit visible) in the non-fullscreen window.

Note that unfortunately, I couldn't easily reproduce this in a separate, smaller test app. Well, I technically could, it just wasn't reproduced as often.



As hinted above, I've added an updated patch. Following is a summary of changes, at least of what I haven't missed:

Code: Select all
- Removed useless '#include "SDL_version.h"' statements from cdrom-related
sources, originally added by me before the introduction of C_PHYSICAL_CDROM_MOUNT.
- cdrom.h: Added a comment about the inclusion of compat_SDL_cdrom.h, even
if C_PHYSICAL_CDROM_MOUNT is not defined at all, due
to MSF_TO_FRAMES and FRAMES_TO_MSF (and CD_FPS).
- dos_programs.cpp: Moved a relocated "int error = 0;" defintiion to at
a location closer to the original.
- dosbox.cpp: "cycles" is now *not* set to "max" by default on Android
(and also not on other platforms, as usual).
- sdl_mapper.cpp: Removed commented out MAXBUTTON definition.
- Made sure comments related to SDL 1.2 specific code pieces are either
inside the relevant #if...#endif blocks, or right after any
of the #if and #endif statement.
- sdl_mapper.cpp: Now comparing a joystick event's "event->jbutton.which"
field to a given stick for all SDL versions, instead of "event->button.which".
- Misc. E_Exit additions/changes.
- sdlmain.cpp, sdl struct: Changed sdl.update_window to sdl.resizing_window
(now storing the exact opposite values); Removed unused window_desired_width
and window_desired_height fields; Removed commented out sdl.desktop.bpp
field for good (also unused in DOSBox from SVN).
- Removed misc. comments for SDL_SetWindowTitle calls.
- sdlmain.cpp:GFX_GetBestMode: Misc. comments removal.
- sdlmain.cpp:GFX_GetBestMode: Shared code for SCREEN_OPENGL and SCREEN_TEXTURE.
- sdlmain.cpp:GFX_SetSDLWindowMode: Removed a few commented out lines,
made sure sdl.window is *not* dereferenced if SDL_CreateWindow failed.
- sdlmain.cpp:GFX_SetSize: Removed commented out "opengles" renderer driver checks.
- sdlmain.cpp:GFX_UpdateSDLCaptureState: Now unmodified from the original and
not compiled at all if SDL 2.0 is used. GFX_RestoreMode is also not compiled
in a similar manner.
- sdlmain.cpp:GFX_EndUpdate: Removed commented out checked call
to SDL_UpdateWindowSurfaceRects.
- sdlmain.cpp:GUI_StartUp: sdl.desktop.sdl2pixelFormat now gets the pixel
format from the window surface, rather than the window itself.
- sdlmain.cpp:GFX_Events: Reverted a useless rename of HandleVideoResize to
GFX_HandleVideoResize; It's a commented out line in an SDL 1.2 specific block.
- sdlmain.cpp:Config_Add_SDL: Removed a few useless words from description
of "vsync" setting (renamed from "fulldouble" in the case of SDL 1.2);
Added "metal" SDL renderer driver for OS X.
You do not have the required permissions to view the files attached to this post.
NY00123
Member
 
Posts: 232
Joined: 2010-2-13 @ 19:42

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

Postby gm_matthew » 2018-7-01 @ 19:11

With SDL 2.0.6 onwards, the audio doesn't work when running on Windows. This is because newer versions of SDL use WASAPI by default.

DOSBox uses signed 16-bit samples for mixing, which DirectSound and XAudio2 were fine with, but WASAPI insists on using 32-bit floating point samples. DOSBox does not notice the demand for a different format and continues to use signed 16-bit samples, which don't work.

I managed to get the audio working again by forcing SDL to transparently convert the samples. Here's the diff:

Code: Select all
diff -ur dosbox/src/hardware/mixer.cpp dosbox2/src/hardware/mixer.cpp
--- dosbox/src/hardware/mixer.cpp   2018-05-29 13:58:58 +0100
+++ dosbox2/src/hardware/mixer.cpp   2018-07-01 18:29:27 +0100
@@ -682,7 +685,6 @@
 
    /* Start the Mixer using SDL Sound at 22 khz */
    SDL_AudioSpec spec;
-   SDL_AudioSpec obtained;
 
    spec.freq=mixer.freq;
    spec.format=AUDIO_S16SYS;
@@ -696,16 +698,16 @@
       LOG_MSG("MIXER: No Sound Mode Selected.");
       mixer.tick_add=calc_tickadd(mixer.freq);
       TIMER_AddTickHandler(MIXER_Mix_NoSound);
-   } else if (SDL_OpenAudio(&spec, &obtained) <0 ) {
+   } else if (SDL_OpenAudio(&spec, NULL) <0 ) {
       mixer.nosound = true;
       LOG_MSG("MIXER: Can't open audio: %s , running in nosound mode.",SDL_GetError());
       mixer.tick_add=calc_tickadd(mixer.freq);
       TIMER_AddTickHandler(MIXER_Mix_NoSound);
    } else {
-      if((mixer.freq != obtained.freq) || (mixer.blocksize != obtained.samples))
-         LOG_MSG("MIXER: Got different values from SDL: freq %d, blocksize %d",obtained.freq,obtained.samples);
-      mixer.freq=obtained.freq;
-      mixer.blocksize=obtained.samples;
+      if((mixer.freq != spec.freq) || (mixer.blocksize != spec.samples))
+         LOG_MSG("MIXER: Got different values from SDL: freq %d, blocksize %d",spec.freq,spec.samples);
+      mixer.freq=spec.freq;
+      mixer.blocksize=spec.samples;
       mixer.tick_add=calc_tickadd(mixer.freq);
       TIMER_AddTickHandler(MIXER_Mix);
       SDL_PauseAudio(0);
You do not have the required permissions to view the files attached to this post.
gm_matthew
Newbie
 
Posts: 13
Joined: 2010-3-11 @ 21:23

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

Postby NY00123 » 2018-7-06 @ 14:01

This is interesting, thanks for the report.

Personally, I think that it's better to call SDL2's SDL_OpenAudioDevice function instead, with the SDL_AUDIO_ALLOW_FREQUENCY_CHANGE flag passed as the value of allowed_changes (we don't want SDL_AUDIO_ALLOW_FORMAT_CHANGE, and probably also not SDL_AUDIO_ALLOW_CHANNELS_CHANGE).

We should not forget that sdlmain.cpp has a call to SDL_CloseAudio that similarly has to be replaced with SDL_CloseAudioDevice, though. I'm guessing a separate mixer.cpp wrapper shall be added for this.


On another note, this may come as more bad news, but it shouldn't be a surprise.
Basically, while checking DOSBox on a different setup with Ubuntu MATE 16.04, I had the usual issue of certain keyboard combos (like Ctrl+Alt+Left_Arrow) being handled by the desktop environment, and not handled by DOSBox, as expected for certain games.
While these *are* the correct behaviors, it probably means different keyboard mappings will be required (if not just disabling OS-related functionalities altogether).
NY00123
Member
 
Posts: 232
Joined: 2010-2-13 @ 19:42

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

Postby NY00123 » 2018-7-13 @ 09:14

LATE POST EDIT: If you fail to apply the following patch under the last SVN revision, please downgrade to r4131.
The patch itself should already include the change introduced in r4132, either way.

I've updated the SDL 2 patch with two changes.

- First, to continue from my preceding post, SDL_OpenAudioDevice is now used with the SDL_AUDIO_ALLOW_FREQUENCY_CHANGE flag in SDL 2 builds, along with SDL_PauseAudioDevice and SDL_CloseAudioDevice. A new MIXER_CloseAudioDevice wrapper function is used instead of a direct call to SDL_CloseAudio from sdlmain.cpp::restart_program.
I know a comment in mixer.cpp mentions that the SDL-specific bits shall probably move from mixer.cpp to sdlmain.cpp, rather than doing the exact opposite, but this leads to much less changes.

- Secondly, I've fixed a minor bug in the mapper window for SDL 1.2 builds, with another color (somewhat brownish) being shown instead of dark gray. Basically, as in the SDL 2 case, a separate 8-bit SDL surface is used for drawing, while the window surface shall have the current display bit-depth. (This does *not* apply to a clean DOSBox tree from SVN.)
In practice, though, SDL_SetVideoMode_Wrap was still called with a bpp of 8...changed to 0 in the last patch.
You do not have the required permissions to view the files attached to this post.
NY00123
Member
 
Posts: 232
Joined: 2010-2-13 @ 19:42

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

Postby Dominus » 2018-7-20 @ 18:29

I don't remember whether we talked here in this thread or elswhere, but SDL_sound is seeing some love by Ryan Gordon
User avatar
Dominus
DOSBox Moderator
 
Posts: 7618
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

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

Postby NY00123 » 2018-7-20 @ 18:53

Dominus wrote:I don't remember whether we talked here in this thread or elswhere, but SDL_sound is seeing some love by Ryan Gordon


Nice! Just checked it now.

What's not clear for me atm is the status of MP3 decoding, if there's any cuesheet which is using this: https://twitter.com/icculus/status/1020189416512466944

LATE POST EDIT: MP3 and OGG should be supported: https://hg.icculus.org/icculus/SDL_soun ... README.txt

On the other hand, support for SDL 1.2 has been removed during this week; More important, is that I think that the library file itself can finally have the name (or at least a name's sub-string) of "SDL2_sound" on various platforms. :)

https://hg.icculus.org/icculus/SDL_soun ... eLists.txt
NY00123
Member
 
Posts: 232
Joined: 2010-2-13 @ 19:42

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

Postby NY00123 » 2018-7-21 @ 20:09

An update with two fixes:

- dos_programs.cpp: Fixed an issue with language files. All translation entries shall now be present, regardless of the availability of physical CD-ROM support with CD-Audio playback. (Thanks Qbix!)
- sdlmain.cpp: DOSBox could crash on Linux (X11) after alt-tabbing from a fullscreen window with output=surface. Reason is this currently leads to an automatic window minimize by SDL2, which in turn changes its dimensions to, I think, its preceding dimensions; In my case, these were 640x400, as used for the splash screen. However, due to technical reasons (windowresolution=original and other config values, text mode), a rendering output rectangle with the dimensions of 640x480 was expected. Such a rectangle simply cannot fit in the (minimized) window. Thus, screen updates are now *disabled* while this is the case.
You do not have the required permissions to view the files attached to this post.
NY00123
Member
 
Posts: 232
Joined: 2010-2-13 @ 19:42

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

Postby krcroft » 2018-8-02 @ 14:31

NY00123, thanks for the in-depth SDL2 work - and maintaining it across these years!

I was curious how you suggest applying the SDL2 patch? It doesn't appear to be a unified diff created with the typical diff command:

Code: Select all
Create:
    diff -Naur original-source-dir new-source-dir > my-unified.patch

Patch:
    cd original-source-dir
    patch -p1 < /path/to/my-unified.patch


Attempting to apply it to the current 4132 source:

Code: Select all
curl http://source.dosbox.com/dosboxsvn.tgz | tar zx -C /tmp
cd /tmp/dosbox
patch < /path/to/dosbox_sdl2_20180721.diff


Produces:
patching file acinclude.m4
patching file AndroidManifest.xml
patching file ant.properties
patching file build.properties
patching file build.xml
patching file default.properties
patching file instructions.txt
patching file Android.mk
patching file Application.mk
patching file Android.mk
patching file config.h
patching file proguard-project.txt
patching file project.properties
patching file main.xml
patching file strings.xml
patching file DOSBoxActivity.java
patching file SDLActivity.java
patching file note.txt
patching file configure.ac
patching file Makefile.am
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 14.
2 out of 2 hunks FAILED -- saving rejects to file Makefile.am.rej

<snip>
...


Thanks for the help. I'm looking forward to giving it a whirl!
Last edited by krcroft on 2018-8-02 @ 19:12, edited 1 time in total.
krcroft
Newbie
 
Posts: 58
Joined: 2017-4-29 @ 15:07
Location: Tsawwassen

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

Postby NY00123 » 2018-8-02 @ 18:29

krcroft wrote:NY00123, thanks for the in-depth SDL2 work - and maintaining it across these years!


You're welcome!

Attempting to apply it to the current 4132 source:

Code: Select all
curl http://source.dosbox.com/dosboxsvn.tgz | tar zx -C /tmp
cd /tmp/dosbox
patch < /path/to/dosbox_sdl2_20180721.diff


I think that you've forgotten this bit? :)
Code: Select all
-p0
NY00123
Member
 
Posts: 232
Joined: 2010-2-13 @ 19:42

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

Postby krcroft » 2018-8-02 @ 19:15

PEBKAC :-)..

That did the trick, thank you NY00123!

.. In all these years I've only ever used -p1. I noticed this patch didn't have parent directories prefixed; so figured patch < ... would be equivalent to not stripping any directories.. but looks like -pX it changes the behavior as well.

Cheers!
krcroft
Newbie
 
Posts: 58
Joined: 2017-4-29 @ 15:07
Location: Tsawwassen

Previous

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest