NY00123 wrote:

To summarize: You should make sure that not only DOSBox takes advantage of SDL_sound, but that the given build of SDL_sound expe […]
Show full quote

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

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

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.

This has an obvious solution: add SDL_sound to the DosBox source tree.

Well, this may be why I was having fullscreen issues on my Mac. Apparently, SDL2 needs an Info.plist file with NSHighResolutionCapable set to true to work properly on retina displays. While I've yet to test of this, the followings guide to building DosBox and packaging it with an updated Info.plist file looks very helpful:

Building a x64 DOSBox binary for macOS Sierra

I can also see that dosbox-x is already set up to build packages with an Info.plist file. Borrowing what they did would probably be a good idea.

dugan wrote:

Well, this may be why I was having fullscreen issues on my Mac. Apparently, SDL2 needs an Info.plist file with NSHighResolutionCapable set to true to work properly on retina displays. While I've yet to test of this, the followings guide to building DosBox and packaging it with an updated Info.plist file looks very helpful:

Building a x64 DOSBox binary for macOS Sierra

This is all wrong!
- SDL2 does not require that plist change. That is only required if you are using a Retina display *and* want to make use of it's higher pixel density and that is for the windowed display only (AFAIK) and needs the flag SDL_WINDOW_ALLOW_HIGHDPI in the display code of DOSBox.
The fullscreen problem lies somewhere else. Places to look for help is the Exult and Nuvie sourcecode which have been ported to SDL2 and have working fullscreen modes.
- a 64bit build of DOSBox is useless. It's way slower than the 32bit build.

Hi guys, i should report a bug over here. So to make it short -> https://github.com/duganchen/dosbox/issues/7#event-979134932

Glog78 wrote:

Hi guys, i should report a bug over here. So to make it short -> https://github.com/duganchen/dosbox/issues/7#event-979134932

Could you please describe to us the steps to "compile against openglide", as you put it?

Does it involve applying another patch?

The files I see in your compile error aren't part of DosBox SVN, this patch, or my fork.

If you're applying an OpenGlide patch that has a separate Vogons thread, then you need to petitition that thread for SDL 2 support. This is not a "bug".

Got the fullscreen issues on OS X fixed. I'm going to fix it in my fork before I contribute the fix back to this thread, but essentially there were two places were SDL_FULLSCREEN_DESKTOP was being used, and the fix was to change them both to use SDL_FULLSCREEN instead.

This is what it looks like now:

https://github.com/duganchen/dosbox/commit/b6 … 3d07b63d93a2ee7

Since that wasn't done in the first place, and I'm admittedly not an SDL expert, I hope the thread has some feedback on how safe that would be to generalize to other platforms.

Glog78 wrote:

Hi guys, i should report a bug over here. So to make it short -> https://github.com/duganchen/dosbox/issues/7#event-979134932

As told by dugan, openglide is a separate project, which is quite unrelated to the SDL 2.0 patch, so incompatibilities are a possibility.
While I don't know much about openglide, it clearly seems to depend on features of SDL 1.2 (not 2.0). Since SDL 2.0 is not backwards-compatible with 1.2, errors as reported by you expected.

dugan wrote:

Got the fullscreen issues on OS X fixed. I'm going to fix it in my fork before I contribute the fix back to this thread, but essentially there were two places were SDL_FULLSCREEN_DESKTOP was being used, and the fix was to change them both to use SDL_FULLSCREEN instead.

Great to see you've figured this out! It's a bit of a surprise to me, though, since it's really SDL_WINDOW_FULLSCREEN_DESKTOP that should be more suitable for current platforms. Using SDL_WINDOW_FULLSCREEN with different resolutions may even lead to unexpected side-effects on certain desktop environments (on X11).

Another Mac user should probably know better, but info like OS versions and contents of Info.plist may assist. As for me, I can tell for sure that I've never tested the SDL2 patch with High DPI in use.

As I wrote the fullscreen problem should have nothing to do with High DPI,

It *should* be SDL_FULLSCREEN -> SDL_WINDOW_FULLSCREEN_DESKTOP on OS X as SDL_FULLSCREEN -> SDL_WINDOW_FULLSCREEN will lead to dark screens on the secondary desktops/monitors if you use more than one. Found that out when Exult got ported.

So my guess is that SDL_WINDOW_FULLSCREEN solved the symptom but not the reason for the fullscreen problem.

NY00123 wrote:

Glog78 wrote:

Another Mac user should probably know better, but info like OS versions and contents of Info.plist may assist. As for me, I can tell for sure that I've never tested the SDL2 patch with High DPI in use.

Sierra. No Info.plist (ran it with ./configure; make; run directly from dosbox/src)

Maybe I'll have finally time to test this evening 😉

A cleaned-up version of the SDL2-only (no support for Android, SDL1 or audio CDs) patch is attached.

Thank you for this patch - I got a lot of errors when applying it to r4006 under Windows. Probably my fault, but if someone else ran it successfully, I'll be grateful to hear about it, and will try again.

emendelson wrote:

Thank you for this patch - I got a lot of errors when applying it to r4006 under Windows. Probably my fault, but if someone else ran it successfully, I'll be grateful to hear about it, and will try again.

Hmm... that's weird. I'll check the patch later tonight (on Linux and Mac), but in the meantime:

Were you able to successfully apply my previous patch? And if not, is it at all possible that you'd checked out the codebase with Windows line-endings? That's the only explanation I can think of.

Also, I recently released a set of patches that built on this, including one to update the OpenGL "output" to OpenGL 3. And one to support loadable shaders. You can find them here:

posting.php?mode=edit&f=41&p=568163

dugan wrote:

Were you able to successfully apply my previous patch? And if not, is it at all possible that you'd checked out the codebase with Windows line-endings? That's the only explanation I can think of.

I think I skipped the previous patch, and I'm not sure about the Windows line endings, but will look into it as soon as I get back to my testing machine. Thanks for the suggestion!

I'm not sure if I can help, unfortunately. I just tested that patch (the newest SDL2-only one) on my Mac and it applied fine. I checked out DosBox with "svn co -r4006 ..." and then applied it.

Thanks for checking this. I'll apply the patch on a Mac and copy it back to my Windows machine, and that will almost certainly work. I'm trying to apply the patches using TortoiseSVN in Windows, and probably I simply don't know what I'm doing...

If it helps, my patching process is:

1cd /path/to/dosbox
2path -p1 /path/to/patch.diff

I'll do that exactly. Thank you!

Well, your patch works perfectly under OS X, so obviously I don't know what I'm doing under Windows (and should probably have just used the command line. Apologies for wasting your time!

The command that worked was this - I added the redirect symbol before the filename

1cd /path/to/dosbox
2patch -p1 < /path/to/patch.diff

Now to copy that and try to build under Windows. Meanwhile, if Dominus is reading these posts, have you tried building a standalone DOSBox using this patch??

OK - I've made progress. An attempt to build under Windows produces fatal errors in two files that I think haven't been patched, presumably because you're not developing for Win32, and no one should expect you to patch for a platform you don't use:

wnaspi32.h
cdrom_ioctl_win32.cpp

Is it possible to make a usable DOSBox that doesn't have ASPI/CD-ROM support? Or is there any hope that someone who is expert in these matters might extend the patch to cover those files?