VOGONS

Common searches


Reply 40 of 183, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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!

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 42 of 183, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

The thing is that the SDL2 devs cut out CD Rom support on purpose, so they are not really interested in this patch...

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 43 of 183, by NY00123

User metadata
Rank Member
Rank
Member

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.

Reply 44 of 183, by dreamlayers

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 45 of 183, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Thanks, I'll need to give it a try once I'm back at my devel machine

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 49 of 183, by NY00123

User metadata
Rank Member
Rank
Member

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.

Attachments

  • Filename
    DOSBox-debug.zip
    File size
    3.81 MiB
    Downloads
    149 downloads
    File comment
    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**
    File license
    Fair use/fair dealing exception
  • Filename
    dosbox_sdl2_20150704.diff
    File size
    188.02 KiB
    Downloads
    125 downloads
    File comment
    SDL2 diff compatible with r3921
    **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.**
    File license
    Fair use/fair dealing exception

Reply 50 of 183, by NY00123

User metadata
Rank Member
Rank
Member

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/e217ed463f25/i … /SDL_platform.h):

--- 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.

Attachments

  • Filename
    dosbox_sdl2_win32_20150709.zip
    File size
    1.51 MiB
    Downloads
    127 downloads
    File comment
    Win32 executable (Cross-compiled with MinGW; Some features may be missing)
    File license
    Fair use/fair dealing exception
  • Filename
    dosbox_sdl2_20150709.diff
    File size
    480.72 KiB
    Downloads
    115 downloads
    File comment
    SDL2 diff compatible with r3921
    **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.**
    File license
    Fair use/fair dealing exception

Reply 51 of 183, by NY00123

User metadata
Rank Member
Rank
Member

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.

Attachments

  • Filename
    dosbox_sdl2_20150713.diff
    File size
    480.73 KiB
    Downloads
    224 downloads
    File comment
    SDL2 diff compatible with r3924
    **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.**
    File license
    Fair use/fair dealing exception

Reply 52 of 183, by NY00123

User metadata
Rank Member
Rank
Member

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.

Reply 56 of 183, by vanfanel

User metadata
Rank Newbie
Rank
Newbie

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

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:

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:

patch -p0 < ../dosbox_sdl2_20150713.diff

DOSBOX with SDL2 at last!! Let's get ready to rumble!!

Reply 58 of 183, by vanfanel

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 59 of 183, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
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.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper