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-3-21 @ 14:54

wnaspi32.h
cdrom_ioctl_win32.cpp


Yeah someone else will need to fix that. I'm not set up to do Windows builds right now.
dugan
Newbie
 
Posts: 46
Joined: 2015-4-04 @ 03:17

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

Postby emendelson » 2017-3-21 @ 15:00

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...
emendelson
Oldbie
 
Posts: 737
Joined: 2010-2-14 @ 02:00

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

Postby dugan » 2017-3-21 @ 15:02

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

viewtopic.php?f=32&t=34770&start=60#p537272
dugan
Newbie
 
Posts: 46
Joined: 2015-4-04 @ 03:17

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

Postby emendelson » 2017-3-21 @ 15:05

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

viewtopic.php?f=32&t=34770&start=60#p537272


I'll try it and report back. Thanks!
emendelson
Oldbie
 
Posts: 737
Joined: 2010-2-14 @ 02:00

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

Postby emendelson » 2017-3-21 @ 16:30

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

viewtopic.php?f=32&t=34770&start=60#p537272


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-3-22 @ 12:19, edited 1 time in total.
emendelson
Oldbie
 
Posts: 737
Joined: 2010-2-14 @ 02:00

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

Postby Dominus » 2017-3-22 @ 00:23

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

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

Postby emendelson » 2017-3-22 @ 01:03

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...
emendelson
Oldbie
 
Posts: 737
Joined: 2010-2-14 @ 02:00

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

Postby Dominus » 2017-3-23 @ 11:05

The project file dosbox.vcproj references it...
User avatar
Dominus
DOSBox Moderator
 
Posts: 7538
Joined: 2002-10-03 @ 09:54
Location: Vienna or Ludwigsburg

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

Postby emendelson » 2017-3-24 @ 01:53

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.
emendelson
Oldbie
 
Posts: 737
Joined: 2010-2-14 @ 02:00

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

Postby NY00123 » 2017-4-01 @ 07:28

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 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!
NY00123
Member
 
Posts: 219
Joined: 2010-2-13 @ 19:42

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

Postby emendelson » 2017-4-03 @ 18:39

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...
emendelson
Oldbie
 
Posts: 737
Joined: 2010-2-14 @ 02:00

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

Postby dugan » 2017-4-07 @ 02:02

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

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

Postby Dominus » 2017-4-07 @ 06:22

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

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

Postby dugan » 2017-4-07 @ 18:41

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:

Code: Select all
sh autogen.sh
./configure
make


And I never build against SDL_sound.

Not sure what else could be different.
dugan
Newbie
 
Posts: 46
Joined: 2015-4-04 @ 03:17

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

Postby NY00123 » 2017-4-11 @ 10:56

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.)
NY00123
Member
 
Posts: 219
Joined: 2010-2-13 @ 19:42

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

Postby emendelson » 2017-4-11 @ 12:35

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.
emendelson
Oldbie
 
Posts: 737
Joined: 2010-2-14 @ 02:00

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

Postby vanfanel » 2017-11-02 @ 16:42

@dugan: Could you please update your patch so it works against current Dosbox SVN? I have tried patching but it fails...

[EDIT] I now build from your branch in git, so no problem :)
vanfanel
Newbie
 
Posts: 12
Joined: 2011-9-05 @ 21:32

Previous

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 3 guests