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

Here you can discuss the development of patches.

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: 744
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: 744
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: 744
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: 7614
Joined: 2002-10-03 @ 09:54
Location: 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: 744
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: 7614
Joined: 2002-10-03 @ 09:54
Location: 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: 744
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: 231
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: 744
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: 7614
Joined: 2002-10-03 @ 09:54
Location: 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: 231
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: 744
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: 16
Joined: 2011-9-05 @ 21:32

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

Postby NY00123 » 2018-6-04 @ 21:27

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.
You do not have the required permissions to view the files attached to this post.
Last edited by NY00123 on 2018-6-04 @ 21:42, edited 1 time in total.
NY00123
Member
 
Posts: 231
Joined: 2010-2-13 @ 19:42

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

Postby DosFreak » 2018-6-04 @ 21:39

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+)
User avatar
DosFreak
l33t++
 
Posts: 9782
Joined: 2002-6-30 @ 16:35
Location: Your Head

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

Postby Dominus » 2018-6-05 @ 13:04

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

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: knowledge [bot] and 1 guest