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 Dominus » 2015-1-13 @ 23:13

NY00123: as I wrote on irc, I started adapting your autoconf changes to Exult and was about to commit when wjp chimed in and told me:
it's not so good to have a custom version of the standard AM_PATH_SDL without giving it a different name
and actually I'm also not a big fan of the standard AM_PATH_SDL, since it behaves very poorly for cross-compilation
we rewrote it for pentagram years ago

so he wrote a better acinclude.m4 file and a very unobtrusive configure.ac line :) see http://sourceforge.net/p/exult/code/7506 (ignore the opengl change in configure.ac - it's only relevant to Exult but not to DOSBox (we implemented OpenGL rendering as a scaler and this will probably never work with SDL2 in this way)).
Even though we rather adapted the acinclude.m4 of Pentagram, still many thanks for your patch!
User avatar
Dominus
DOSBox Moderator
 
Posts: 7968
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

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

Postby Darklord42 » 2015-1-16 @ 06:12

Wouldn't the cd patch for SDL2.0 be better off being sent to the SDL forums? That way everyone can make use of it and not have it eventually disappear in the internet void.
Darklord42
Newbie
 
Posts: 50
Joined: 2007-9-18 @ 00:26

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

Postby Dominus » 2015-1-16 @ 06:39

The thing is that the SDL2 devs cut out CD Rom support on purpose, so they are not really interested in this patch...
User avatar
Dominus
DOSBox Moderator
 
Posts: 7968
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

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

Postby NY00123 » 2015-1-17 @ 19:55

Alright, another medium-sized reply of mine follows up.

First, to Dominus, nice to see you taking advantage of the autoconf modifications. As said on irc, I just tried getting something to work back then, not knowing much about the autoconf stuff. Also thanks for the other DOSBox-related works of yours.

Next, thanks paolo-sz for your CD-ROM related updates, someone may find these useful. Unfortunately, while DOSBox v0.74 for Windows may used a version of SDL 1.2 with a minor custom modification (something to do with windib and ddraw), the addition of CD-ROM support to SDL 2.0 is much more significant and may be harder to add back in the future. Furthermore, it may be less useful on a few non-Windows platforms, at the least (e.g., because a shared SDL2 library is more commonly used). Hence, it may be better to accept here that CD-Audio shouldn't be in the scope of a library like SDL2, possibly even since about 2001, and handle CD-Audio separately (possibly even with a modified copy of the SDL 1.2 code separate from SDL 2.0).

Further thanks to truth for packaging the binaries, as well as the patches and instructions for building an EXE. Thanks for your other contributions, too.

To finish: As expected, I cannot promise I'll make an update whenever compatibility of the last patch with the most recent DOSBox revision from SVN is broken. But you can see post updates if you wish. Either way, as usual these patches should be considered unofficial.
NY00123
Member
 
Posts: 235
Joined: 2010-2-13 @ 19:42

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

Postby dreamlayers » 2015-1-29 @ 17:02

I'm using dosbox_sdl2_20140712.diff in Em-DOSBox, my port of DOSBox to Emscripten for running in web browsers. The Emscripten port of SDL 2 is better at some things than the SDL 1 that is built into Emscripten. I removed the Android-specific code with unifdef to simplify git merges.

The patch works great! Thanks a lot!

Here are some minor issues I found:
[*] Mac OS compile fix
[*] OpenGL to surface fallback fix
[*] The changes from surface pitch to w in the mapper seem wrong. SDL 2 SDL_Surface also has pitch, and I think pitch should be used for correctness when pitch != w.
dreamlayers
Newbie
 
Posts: 6
Joined: 2014-1-22 @ 18:57

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

Postby Dominus » 2015-1-29 @ 18:24

Thanks, I'll need to give it a try once I'm back at my devel machine
User avatar
Dominus
DOSBox Moderator
 
Posts: 7968
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

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

Postby kekko » 2015-1-30 @ 19:13

I'd be curious to try an android build with 3dfx-opengl patch.. :P
Do android devices support opengl right?
If anyone did this experiment, please share the apk :P
User avatar
kekko
Member
 
Posts: 480
Joined: 2004-3-24 @ 18:56

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

Postby dreamlayers » 2015-1-30 @ 22:33

Android only supports OpenGL ES, which is different from plain OpenGL. Any OpenGL code will need changes.
dreamlayers
Newbie
 
Posts: 6
Joined: 2014-1-22 @ 18:57

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

Postby ovvldc » 2015-2-09 @ 11:24

Not necessarily. OpenGL ES is a subset of OpenGL (depending on the version), so it all depends on what parts of OpenGL got used..
ovvldc
Newbie
 
Posts: 45
Joined: 2008-8-17 @ 12:48
Location: NL

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

Postby NY00123 » 2015-7-04 @ 21:32

Hey there,

I'm attaching a small "maintenance update" to the patch. While there aren't exactly new additions, you should be aware of these changes:
- The mapper filename is now mapper-sdl2-SVN.map if SDL 2.0 is used (otherwise it's still mapper-SVN.map). Given that vastly different SDL2 scancodes are used, this should make it possible to use the SDL2 build along with one or more SDL 1.2 based builds in parallel, even if there are custom mappings (although the SDL2 mappings have to be configured separately). This can have an impact if you e.g., downloaded the sample game controller mappings for Android posted by me earlier.
- The --with-sdl2 parameter of the configure script is gone. Instead, you can pass --with-sdl=sdl12 or --with-sdl=sdl2, with sdl12 being the default. This is done following the inclusion of EXULT_CHECK_SDL.

A few more modifications:
- Except for the change to configure.ac, the OS X and OpenGL fixes from dreamlayers are now integrated.
- SDL_EventType is the type of sdl.laltstate and sdl.raltstate from sdlmain.cpp now (applies to SDL 1.2 and 2.0 altogether).
- Following a recent update to sdl_mapper.cpp, a few code changes have been applied, including the addition of the CClickableTextButton class and a few modifications of existing functions.
- The minor Android-specific workarounds for misc/programs.cpp are gone, since upstream has just been updated to take care of these. The edits in src/dos/drive_local.cpp are still in-place and will probably remain, though.

Thanks to Dominus for his comments and wjp for writing the alternative acinclude.m4 for Exult, currently used as-is (along with other m4 code).
Further thanks to dreamlayers for the fixes, although I haven't been sure if I should include the configure.ac fix in this patch or not. Regarding the pitch, well, I can tell that draw_surface is used because you can't have an SDL2 window with the color depth of 8-bit anymore. Conversion to an RGB surface is done in DrawButtons, along with a following (software) scaling to the window's surface. More often than not, no actual scaling is done here, but this should cover the Android case with a fullscreen window at the least. Back to draw_surface, given that this surface is manually created from scratch with 8-bit color depth, the pitch (measured in bytes) as exactly the same as the width in pixels. Maybe I thought that the term "width" is clearer, not sure now.
You do not have the required permissions to view the files attached to this post.
NY00123
Member
 
Posts: 235
Joined: 2010-2-13 @ 19:42

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

Postby NY00123 » 2015-7-09 @ 19:18

I've attached an updated patch. While not the most significant modification included in the patch, it has the following few fixes:
- A few occurrences of an Android-specific bug in dos/drive_local.cpp regarding a workaround I added to make things compiler for Android, reported by Qbix.
- Fixed EXULT_CHECK_SDL so it's possible to build EXEs with MinGW.
- Fixed sdl.laltstate,raltstate integer overflows with SDL 2.0: These are defined as SDL_EventType now, instead of Bit8u.

All right, it's time for what I think at least a few of you have wanted. Once this revision of the patch is applied, you should find a "src/sdl_cdrom" directory with the SDL_cdrom code from SDL 1.2, after a few modifications. In other words, physical CD-ROM mounting, including CD-Audio playback, is theoretically supported in the environments where this is supported while using SDL 1.2.

Note that this does not include support for certain platforms, like Android, although you can still mount folders with limited CD-ROM functionality. In addition, the imported SDL_cdrom code has different sources for multiple platforms, not all of them being tested, and at least a few may have been deprecated in SDL 1.2. I've also had some problems while getting CD Audio to work under Ubuntu 14.04, even with DOSBox v0.74. Although a bit off-topic, an explanation is given a bit later in this post.

It is good again to see paolo-sz adding the support back into SDL 2.0. As you can see, a different approach has been chosen for the last patch of mine. Here, SDL 2.0 doesn't have to be modified at all, the imported SDL_cdrom can optionally be modified as desired, and it is not mandatory (e.g., it's disabled for Android).

I haven't attached an Android build this time, since there aren't really interesting changes for that platform. On the other hand, I've attached a Windows SDL2 build, cross-compiled from Linux using MinGW (the original one, not MinGW-w64). Interestingly I've gotten working CD Audio playback with these while running DOSBox under Wine, also mention later in this post. The EXE has been built using SDL 2.0.3, along with a patch to SDL_platform.h fixing compilation using MinGW (https://hg.libsdl.org/SDL/diff/e217ed46 ... platform.h):

Code: Select all
--- a/include/SDL_platform.h   Mon Mar 17 19:11:18 2014 -0400
+++ b/include/SDL_platform.h   Tue Mar 18 12:08:49 2014 -0400
@@ -114,10 +114,10 @@
#define __SOLARIS__ 1
#endif

-#if defined(WIN32) || defined(_WIN32) || defined(__CYGWIN__)
+#if defined(WIN32) || defined(_WIN32) || defined(__CYGWIN__) || defined(__MINGW32__)
/* Try to find out if we're compiling for WinRT or non-WinRT */
/* If _USING_V110_SDK71_ is defined it means we are using the v110_xp or v120_xp toolset. */
-#if defined(__MINGW32__) || (defined(_MSC_VER) && (_MSC_VER >= 1700) && !_USING_V110_SDK71_)   /* _MSC_VER==1700 for MSVC 2012 */
+#if (defined(_MSC_VER) && (_MSC_VER >= 1700) && !_USING_V110_SDK71_)   /* _MSC_VER==1700 for MSVC 2012 */
#include <winapifamily.h>
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
#undef __WINDOWS__


It may now be good to add another good hint for the CD Audio functionality being deprecated for long. There have been two methods of CD Playback commonly in use for PCs over the times:
- Analog (more like bypassing the CPU): Here, the CD/DVD drive has the functionalities of a CD Audio player. Some of you may recall that early CD-ROM drives have headphone jacks, and possibly also volume knobs. At least a few of these even have buttons letting you play music directly. In all cases, it was common to use a cable connecting the drive to a sound card or motherboard, transferring the audio in analog or digital form, depending on the specific setup. On DOS, earlier versions of Windows and certain other environments, commands can be sent to such drives, like "Play a track", "Stop playback" and "Eject". It is really the drive, being a CD player, processing the data, though. At least in theory, no CPU cycles are really involved in that.
- Digital: Practically the only feasible way with the modern setups of today, the raw CD Audio data can be transferred for later processing (originally known as transfers over the IDE bus). This makes it possible not to just play CD Audio tracks, but also rip them and do much more. Obviously some CPU cycles have to be processed. Windows 98 and later, along with many other environments, make this possible given compatible hardware.

Next, about SDL_cdrom: Given that there were already games commercially available in 2001 (and earlier) requiring at least one CD, but not taking advantage of CD Audio, it shouldn't be a surprise that a lot of the SDL_cdrom code is very old. Here's the way I understand things to be about Windows and Linux support:
- On Windows 95 and later, as mentioned above, it may be possible to make CD Audio playback work in any of the two ways, but my understanding is that the same APIs can be used. Some versions of Windows have a global setting letting you enable "Digital Audio". Looks like Wine works the digital way as well now, explaining why I can hear anything while running DOSBox under Wine.
- On Linux, though, this depends on the functions in use. There are players like Rhythmbox and VLC that can properly play CD Audio back. Ripping is also a possibility. However, I can't hear any CD Audio sound in DOSBox (Linux exe), not even in version 0.74. More precisely, a game can properly list all tracks and show the current track being "played". With a real CD, I can even see and hear the drive working (also used cdemu for mounting a bin+cue pair while testing). I can't hear the thing, though. SDL_cdrom appears to use ioctl on Linux, probably in a way that works the analog way only. The command-line cdcd player (similarly others) is also known to not work on modern setups, apparently for the same reason (see comment about closing the report): https://bugs.archlinux.org/task/17888

To finish, as expected, this patch does *not* aim to fix this limitation. It just adds the code from SDL 1.2. Hopefully it can still useful for anybody already taking advantage of CD Audio playback in SDL 1.2 based builds of DOSBox.

One thing is sure, though: If you can, you're really better off mounting an image file (BIN+CUE pair) using DOSBox' built-it IMGMOUNT command.
You do not have the required permissions to view the files attached to this post.
NY00123
Member
 
Posts: 235
Joined: 2010-2-13 @ 19:42

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

Postby NY00123 » 2015-7-13 @ 18:07

It turns out there have been a few commits added to the official SVN repository before posting the 20150709 patch. These include a commit from the exact same day, modifying mixer.cpp in a minor way, yet leading to the rejection of a hunk from the SDL2 patch. And so, I've just attached an updated patch compatible with r3924.

It's also a good chance to mention the following summary, as an alternative to yet another wall of text. As in the 20150709 patch, the last one includes the SDL_cdrom code from SDL 1.2 backported, which means (at least in theory) that physical CD-ROM support can be the same in SDL 1.2 and 2.0 builds.
You do not have the required permissions to view the files attached to this post.
NY00123
Member
 
Posts: 235
Joined: 2010-2-13 @ 19:42

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

Postby NY00123 » 2015-12-12 @ 15:31

Hey there,

I'm updating this in case anybody has problems with IMGMOUNT, while using a cuesheet with external files (OGG, MP3 or any other supported format).

To summarize: You should make sure that not only DOSBox takes advantage of SDL_sound, but that the given build of SDL_sound expects SDL 2.0, rather than 1.2 (unless the given DOSBox build depends on SDL 1.2 as usual).

It's also a good chance to add that there may be some problems with joystick support, since SDL2 added joystick hot-plugging capabilities. The main concern here is differences with enumeration of joysticks, although there can be more.

============================================

A bit of a background about the SDL_sound point:

You see, when you want some networking features, you can pair SDL with SDL_net, or SDL2 with SDL2_net. The same applies to other SDL satellite libraries like SDL_mixer.

SDL_sound is different though. For one, I don't think it's even an official SDL satellite library, given that it's hosted on icculus.org, rather than libsdl.org. It doesn't change the fact that Ryan C. Gordon i.e., icculus, has a very major part in the development of SDL itself (along with related libraries).
On the technical side, the last revision of SDL_sound can be built to depend on either SDL 1.2 or SDL 2.0. Problem is, it's very easy to make an SDL 2.0 app use a build of SDL_sound that depends on SDL 1.2, and vice-versa. Chances are, you won't even notice any problem for quite long (which has occurred to me). Only once you try to use SDL_sound for real (say for loading an OGG file), problems may arise. It can be a silent failure, a clear error with a message, a crash or anything else.

From what I can observe, at least the builds of SDL_sound for Ubuntu 14.04 target SDL 1.2. Thus, even if you think you successfully built an (unofficial) SDL2 build of DOSBox with full cuesheet support, there's really no guarantee this is going to work. It simply depends on the way SDL_sound was built.
NY00123
Member
 
Posts: 235
Joined: 2010-2-13 @ 19:42

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

Postby shankao » 2016-1-25 @ 12:06

Is there any possibility of this work getting merged into dosbox svn soon? What would be missing for that to happen? SDL 2.0 support would be a great milestone
shankao
Newbie
 
Posts: 3
Joined: 2016-1-25 @ 09:59

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

Postby Lucario » 2016-1-28 @ 22:23

I want Sdl2 Dosbox
No more Outdated Sdl!!!
Image
User avatar
Lucario
Newbie
 
Posts: 2
Joined: 2016-1-28 @ 22:18

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

Postby lightmaster » 2016-1-29 @ 17:48

No possibility.
Interest is missing.
What would be the Purpose?
Of course a lot of ppl want this and desire this, but this is not enough.
Image
User avatar
lightmaster
Oldbie
 
Posts: 645
Joined: 2005-10-01 @ 12:09
Location: Sol III

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

Postby vanfanel » 2016-2-16 @ 14:25

@NY00123: I have tried to apply the latest patch to R3924 as intended, and I get errors:

Code: Select all
manuel@vader:~/src/dosbox_BUILD$ patch < dosbox_sdl2_20150713.diff
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 13.
2 out of 2 hunks FAILED -- saving rejects to file Makefile.am.rej
can't find file to patch at input line 2602
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: src/dos/cdrom.cpp
|===================================================================
|--- src/dos/cdrom.cpp   (revision 3924)
|+++ src/dos/cdrom.cpp   (working copy)
--------------------------
File to patch:


Any indea on what's wrong or what am I doing wrong here?

EDIT: Foun the problem, thanks to ny0023 on the IRC. Simply download unmodified sources for r3924:

Code: Select all
svn checkout --revision 3924 svn://svn.code.sf.net/p/dosbox/code-0/dosbox/trunk dosbox-code-0


Now, if the diff is for example in the preceedingdirectory, just do:

Code: Select all
patch -p0 < ../dosbox_sdl2_20150713.diff


DOSBOX with SDL2 at last!! Let's get ready to rumble!!
vanfanel
Newbie
 
Posts: 19
Joined: 2011-9-05 @ 21:32

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

Postby shankao » 2016-3-01 @ 08:56

That's great. Does it work properly? Can it be commited to the master branch, so more people can test it?
shankao
Newbie
 
Posts: 3
Joined: 2016-1-25 @ 09:59

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

Postby vanfanel » 2016-3-20 @ 13:46

shankao wrote:That's great. Does it work properly? Can it be commited to the master branch, so more people can test it?


Yes, it works great, but for some reason I can't imagine, DOSBOX devs seem to be staying in SDL 1.x, even if SDL 1.x is bit-rotten in many OSes already and is obvioulsy a dead end now.
vanfanel
Newbie
 
Posts: 19
Joined: 2011-9-05 @ 21:32

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

Postby Dominus » 2016-3-20 @ 14:48

vanfanel wrote:
shankao wrote:That's great. Does it work properly? Can it be commited to the master branch, so more people can test it?


Yes, it works great, but for some reason I can't imagine, DOSBOX devs seem to be staying in SDL 1.x, even if SDL 1.x is bit-rotten in many OSes already and is obvioulsy a dead end now.

I can't speak for the developers of Dosbox but for two other projects I'm part of:
- SDL2 can only now with the fourth version considered stable while SDL 1.x still runs mostly ok on modern systems, as long as you use the latest source of SDL 1.x
- switching to SDL2 means much more testing than a couple of users saying it works. Changing a running system that works to something else may put users into much more trouble than one can say now.
- add to that the few active developers of Dosbox

That said, IMO it's time for the Dosbox devs to take a closer look at this patch and consider adding SDL2 support along with SDL1.x so more people can test it right from the source.
User avatar
Dominus
DOSBox Moderator
 
Posts: 7968
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 0 guests