VOGONS

Common searches


Reply 101 of 183, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

OK - I'll keep hoping! Meanwhile, thank you for all the work you've done so far.

I'm also going to try building under macOS, but I hope someone knowledgeable might provide some pointers...

Reply 103 of 183, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
dugan wrote:

For Windows, can you you use NY00123's last patch instead? I'd imagine it should work.

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

I'll try it and report back. Thanks!

Reply 104 of 183, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
emendelson wrote:
dugan wrote:

For Windows, can you you use NY00123's last patch instead? I'd imagine it should work.

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

I'll try it and report back. Thanks!

EDIT (replacing bad information). See two messages below this one for the results.

Last edited by emendelson on 2017-03-22, 12:19. Edited 1 time in total.

Reply 105 of 183, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

ok, *finally* had time to look into this.
I patched latest SVN with the latest patch by NY.
Three things bombed compilation for me:
- carbon needed to be added to the frameworks in configure.ac (or midi would be problematic)
- I needed to undefine C_COMPAT_SDL_CDROM_PLATFORM and
- define C_PHYSICAL_CDROM_MOUNT 0 (both in config.h)
After this it compiled *and* it switched easily to fullscreen and back on my retina iMac.
Next up is Dugan's patch.

@NY: there is something odd going on with the CDRom part of your patch (on OS X at least). First it should honor the #define C_PHYSICAL_CDROM_MOUNT - if that is 0 it shouldn't try to add the CDRom support, IMO.
Second, I think the OS X part of the patch need the Cdrom compatibility header included but I need to investigate another time 😀

Edit: @Dugan - I cloned your github and that compiled out of the box 😀 (thanks for that 😀)
I had no problem switching fullscreen with your fork on my retina iMac. When I enabled your retina fix in configure, I ran into the issue that a second display would go black when you go fullscreen (I mentioned this before, this is an issue with your fix).
This was with a clean preference file (I had to make sure as my preferences would crash your fork - another thing to figure out)

Edit2:@dugan: I found the crash reason. For some reason your fork crashes on the dynamic core (easy test, in DOSBox enter "core dynamic"). That's odd, I've made sure to build in 32bit to avoid all the problems of a 64bit on OS X.

Edit3: apparently the autotools stuff needs some work to recognize that SDL_sound can also be in the --with_sdl_prefix...

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 106 of 183, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

Ignore what I said two messages back. The error messages were the result of using the wrong additional library directories. I'm still stuck with one error when building NY00123's patch:

1>LINK : fatal error LNK1181: cannot open input file 'sdl_net.lib'

That should of course be sdl2_net.lib, but I can't find the reference to sdl_net.lib that I should presumably fix...

Reply 107 of 183, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

The project file dosbox.vcproj references it...

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 108 of 183, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

I just deleted two stupid posts by me. I finally realized that I had already built NY00123's patch (and built it again), and that it worked well, except that it was blank in full-screen mode. Apologies for wasting bandwidth on repeating this.

Reply 109 of 183, by NY00123

User metadata
Rank Member
Rank
Member

Hey there,

Dominus wrote:
ok, *finally* had time to look into this. I patched latest SVN with the latest patch by NY. Three things bombed compilation for […]
Show full quote

ok, *finally* had time to look into this.
I patched latest SVN with the latest patch by NY.
Three things bombed compilation for me:
- carbon needed to be added to the frameworks in configure.ac (or midi would be problematic)
- I needed to undefine C_COMPAT_SDL_CDROM_PLATFORM and
- define C_PHYSICAL_CDROM_MOUNT 0 (both in config.h)
After this it compiled *and* it switched easily to fullscreen and back on my retina iMac.
Next up is Dugan's patch.

Great to see you've finally gotten this to work on your Mac!

@NY: there is something odd going on with the CDRom part of your patch (on OS X at least). First it should honor the #define C_PHYSICAL_CDROM_MOUNT - if that is 0 it shouldn't try to add the CDRom support, IMO.

That's interesting, I'm wondering what's the prob. There are already various tests in the patched codebase, checking if C_PHYSICAL_CDROM_MOUNT is defined to a nonzero value.

While the imported SDL_cdrom code does not look at this macro, the macro C_COMPAT_SDL_CDROM_PLATFORM is checked instead, albeit in a hackish manner.

For instance, in sdl_cdrom/macosx/SDL_syscdrom.c, COMPAT_SDL_CDROM_PLATFORM_MACOSX is defined to 1 and then there's a test checking if (C_COMPAT_SDL_CDROM_PLATFORM == COMPAT_SDL_CDROM_PLATFORM_MACOSX). On OS X, if real CD Audio playback support is enabled, then C_COMPAT_SDL_CDROM_PLATFORM is defined to COMPAT_SDL_CDROM_PLATFORM_MACOSX, and since the latter is defined to 1, the test passes. Otherwise, C_COMPAT_SDL_CDROM_PLATFORM is not defined, so it's essentially evaluated to 0 in the test. The same occurs if C_COMPAT_SDL_CDROM_PLATFORM is defined to a different macro (on a different platform).

Second, I think the OS X part of the patch need the Cdrom compatibility header included but I need to investigate another time 😀

Heh, I guess I can't do much here (well, maybe I can, but it's just more difficult).

Thanks for checking this out! The same also applies to other testers, like Dugan and emendelson, of course!

Reply 110 of 183, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

Meanwhile, this is a terrific project. In my selfish way, I hope someone can fix the one thing that's getting in the way of using it for my own project - the blank screen when I press Alt-Enter in Windows to switch from windowed to full-screen mode. It's the only barrier to using it in the real Windows world...

Reply 111 of 183, by dugan

User metadata
Rank Newbie
Rank
Newbie
Dominus wrote:

Edit2:@dugan: I found the crash reason. For some reason your fork crashes on the dynamic core (easy test, in DOSBox enter "core dynamic"). That's odd, I've made sure to build in 32bit to avoid all the problems of a 64bit on OS X.

I need more. I just tried launching Gabriel Knight ("core dynamic; sierra") with the dynamic core, and it works fine.

And I can confirm that the SDL compatibility patch has issues on OS X. The fact that it doesn't build on OS X is a big reason why I don't use it. I've also heard from the maintainer of the DosBox ECE fork that he can't incorporate the patches I released because he considers the lack of physical CDROM support to be a dealbreaker.

Reply 112 of 183, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Hmm, odd, just switching to dynamic core crashes it for me. Are you building with an extra config option?

I think CD-Rom support can go IMO, at least on Linux/OS X it never worked with CD-Roms that have audio tracks.

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 113 of 183, by dugan

User metadata
Rank Newbie
Rank
Newbie
Dominus wrote:

Hmm, odd, just switching to dynamic core crashes it for me. Are you building with an extra config option?

All I do is:

sh autogen.sh
./configure
make

And I never build against SDL_sound.

Not sure what else could be different.

Reply 114 of 183, by NY00123

User metadata
Rank Member
Rank
Member
emendelson wrote:

Meanwhile, this is a terrific project. In my selfish way, I hope someone can fix the one thing that's getting in the way of using it for my own project - the blank screen when I press Alt-Enter in Windows to switch from windowed to full-screen mode. It's the only barrier to using it in the real Windows world...

Thanks for your comment about the patch!

Now, I'm not sure this'll help, but let's see if any of the following assists:
- Just to verify, do you get the problem with a *mostly clean* EXE build, using only the stock DOSBox sources from SVN with my SDL2 patch applied?
- Did you already try to remove (or at least relocate) dosbox-SVN.conf and then let the SDL2 build generate a new configuration file?
- Tried to play with the output, renderer and fullresolution settings? (fullresolution=desktop, or equivalently 0x0, is preferred, and in fact, the SDL2 patch currently modifies the default setting value to 0x0.)

Reply 115 of 183, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
NY00123 wrote:

Now, I'm not sure this'll help, but let's see if any of the following assists:
- Just to verify, do you get the problem with a *mostly clean* EXE build, using only the stock DOSBox sources from SVN with my SDL2 patch applied?
- Did you already try to remove (or at least relocate) dosbox-SVN.conf and then let the SDL2 build generate a new configuration file?

Amazing! I deleted dosbox-SVN.conf - and now full-screen works! Thank you! As soon as I can, I'll experiment with specific full-screen settings and will report back! Thank you! I should have thought of this before, but simply didn't consider it.

And, yes, this build is clean revision 4000 with your patch added; everything else is the same.

Thank you again - and I hope this helps other people who may find the same situation.

Reply 117 of 183, by NY00123

User metadata
Rank Member
Rank
Member

It's been long by now, but I've recently realized that the patch as I posted last time isn't compatible with the current SVN revision. Thus, I've updated it.

Note that it is *only* a simple modification of dosbox_sdl2_20161028.diff which is compatible with r4112.
There is no additional change, not even any macOS-specific fix possibly mentioned beforehand.

This was tested with 32-bit Linux builds only (SDL 1.2 and SDL 2.0). It was quite basic, but hopefully it should be OK. The Android-specific code pieces are *untested* by me, and many of the files are quite outdated, anyway. (I'm also reminding this does *not* including the application icons' files, posted by me separately, somewhere in this thread.)

There are also at least a couple of other SDL2-based DOSBox forks by now. What I originally tried to do (and is probably still imperfect) was a "pure" SDL 2 adaptation, with just a few extras (e.g., the hackish Android "support", as well as minor coloring changes to the mapper UI).

As a side-note, two checks for GFX_RGBONLY were removed from sdlmain.cpp in-between these 2016 and 2018 revisions. This has interestingly leaded to a couple of *less* diffs in the updated .diff file.

Attachments

  • Filename
    dosbox_sdl2_20180604.diff
    File size
    480.35 KiB
    Downloads
    79 downloads
    File license
    Fair use/fair dealing exception
Last edited by NY00123 on 2018-06-04, 21:42. Edited 1 time in total.

Reply 118 of 183, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

I'll be giving this a try when I work on the unofficial DOSBox builds for the guide soon. Thanks for updating it.

For Windows builds there's no point in using Mingw (what the DOSBox devs are using) for compiling a SDL2 build until/if SDL2 is modified for < XP support and assuming so you'd only need to use Mingw for < i686 support.

I'm going to look at SDL2 support for <XP. There is a patch out there for raw input for SDL2 for 2000 without having to use unofficial updates and the person who did that patch may look into 9x support so that would be nice.

So currently:
Mingw w/gcc <XP w/SDL1 for <=i586 (You can of course use Mingw for >=XP and SDL 2 but Mingw is ancient on linux unless you compile it from scratch and difficult to get a working environment on Windows.)
Mingw-W64 win32 or posix w/gcc >=XP w/SDL2 for >=i686 (You can also use Mingw-W64 win32 for <XP w/SDL1 but only for i686+)

How To Ask Questions The Smart Way
Make your games work offline

Reply 119 of 183, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Thanks! AND QBIX & CO! it is time to update to SDL2!!! 😀
Seriously, Apple being Apple is allowing 32bit in MacOS 10.14 for the last time and is also deprecating OpenGL in MacOS 10.14 (so it might be still available in 10.15 and one ore more later) in favor of Metal. While SDL1 .x still works in 64bit, it doesn't support Metal, etc...

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