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

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

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

Postby dugan » 2017-1-06 @ 18:07

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 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.
dugan
Newbie
 
Posts: 28
Joined: 2015-4-04 @ 03:17

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

Postby dugan » 2017-1-10 @ 00:20

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
Newbie
 
Posts: 28
Joined: 2015-4-04 @ 03:17

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

Postby Dominus » 2017-1-10 @ 00:48

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

Previous

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 3 guests