Update to SDL 2.x

[DavidLudwig]

I've been doing some work to get Basilisk II working with SDL 2.x, primarily to get updated fullscreen support on OSX hosts (SDL2 supports OSX's Spaces/multi-desktops feature, for example), but also with some interest in helping future-proof Basilisk II and/or SheepShaver (SDL 1.x development is pretty much dead, at this point), possibly porting it to other platforms.

This work is still a bit far from complete, but is working. Work is ongoing at https://github.com/DavidLudwig/macemu

Assuming that I also got SheepShaver working with SDL 2, might there be any interest in a pull request for such here, (ubject to code review, of course)?

[asvitkine]

Yes, I think that would be great. Though, as a build option since I think SDL doesn't support some older OSes the current release works on.

…

On Aug 11, 2017 9:12 PM, "David Ludwig" ***@***.***> wrote: I've been doing some work to get Basilisk II working with SDL 2.x, primarily to get updated fullscreen support on OSX hosts (SDL2 supports OSX's Spaces/multi-desktops feature, for example). This work is still a bit far from complete, but is working. Work is ongoing at https://github.com/DavidLudwig/macemu Assuming that I also got SheepShaver working with SDL 2, might there be any interest in a pull request for such here, (ubject to code review, of course)? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#118>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABE8DPuGHXckOvGkyd6kEnGhyCIeOxPks5sXPvjgaJpZM4O1REl> .

[kencu]

On that note, I have libsdl2 building under MacPorts and working very nicely on 10.4 and 10.5 PPC, and of course it has worked for a long time on 10.6+ Intel. So that pretty much covers all the relevant MacOS systems.

If you would like to see / use the 10.4 and 10.5 libsdl2 Portfiles, you can get them at http://github.com/kencu/TigerPorts and http://github.com/kencu/LeopardPorts

[DavidLudwig]

Supporting building against both SDL 1.x and SDL 2.x is possible, but I imagine that it could get a bit messy. Either it’d add a fair amount of #ifdef’ed code, or duplicated code (depending on implementation path), which could make the code a bit harder to maintain Basilisk II and SheepShaver going forward.

Is there a maintained means of building, or testing, either Basilisk II or SheepShaver on OS X PPC? My understanding is that building apps for OS X on PPC has been unsupported by Apple for several years now, although I could be mistaken on this.

[kencu]

One thing I note -- your code is building with SDL2 2.0.5 -- the last version of SDL2 that is working on PPC 10.4 and 10.5 is 2.0.3, and it's not certain that subsequent versions can be modified to work on PPC. (Well they can be, it just depends how much effort one would like to expend).

So that might be important.

[rickyzhang82]

@DavidLudwig I agree that support too board make the code hard to maintain. But my iBook G4 is begging you not to discontinue support. If PPC does support SDL2, we can do a test for you. We can have an experimental branch first which get rid of SDL v1.

[Frizlab]

@rickyzhang82 Out of curiosity, don’t you have Rosetta on a PPC computer? 🤔 Is it not enough?

[DavidLudwig]

@kencu, the version I am linking against is, indeed, SDL 2.0.5 (soon-ish to be 2.0.6, hopefully), one with a few years of bug-fixes over 2.0.3.

I think that adapting the code to be compile-able against SDL 2.0.3 would not be all that difficult, and is something that I am happy to look into. There's at least one function that I've used, which I vaguely recall being added some time after SDL 2.0.0, but it'd be pretty easy to replace. I'll make a note to see if it was in SDL 2.0.3, and if not, replacing them with older calls.

In terms of building for OS X PPC, if that is something that is to continue being done, I could see it making some amount of sense to do so via a different building mechanism than what is used for 'modern' OSX. OS X PPC building hasn't been supported by Apple for many years now, and not since Xcode 3.x (IIRC). I've been creating my Mac builds using the latest, released version of Apple's OS X build chain (Xcode 8, for now), partly out of convenience, but also, in a way, to help try future-proofing them for as long as possible.

[rickyzhang82]

@DavidLudwig Sorry, my bad. I thought you go through GNU automake build. I just checked out your repo and found that you have completely fix the XCode build. Nice work!

I used BII GNU automake build for my PPC and Intel Mac OS X. The preference UI is gtk.

Sorry, I have misunderstood you.

XCode build is beyond broken even under Mac OS X PPC. I have no problem at all for you fix. But I'd like to test for you under PPC using GNU automake build.

@Frizlab I don't know why but It is slow compared to BII in my iBook G4.

[kencu]

Certainly, IMHO building BasiliskII & Sheepshaver on PPC is not by any stretch a significant priority, as AFAIK every one of those machines can boot into 10.4 and use Classic if needed (all mine do). Many of mine can boot directly into MacOS 9.

The focus for BII and SheepShaver is 100% on Intel machines, and all of those (10.6 and up) can run the latest version of SDL2 at this time.

I was essentially only mentioning that a working version of SDL2 does exist for PPC machines, should it be of interest.

[DavidLudwig]

@rickyzhang82 , thank you for the clarification.

I've yet to work on autotools compatibility, but have made a note to look into this (via DavidLudwig#12 ). If and when I have that working on at least one platform (I plan on testing on Linux, at least, probably on at least x86 and ARM), via autotools, I'll note such there.

[DavidLudwig]

FYI, autotools support is now in-place, in my branch (at https://github.com/davidludwig/macemu). I have only tested against x86 Linux, as of yet. I'll try to get to testing ARM Linux, soon.

[rickyzhang82]

@kencu I tried to build SDL2 in Power PC 10.4 Tiger today. It turned out that SDL2 upstream requires 10.6 and above. Mac ports port files also reflect this requirement as well.

[kencu]

Hi @rickyzhang82 . To build SDL2 on Tiger, you need to my customized Tiger repository https://github.com/kencu/TigerPorts, and specifically this Tiger-customized portfile folder https://github.com/kencu/TigerPorts/tree/master/devel/libsdl2.

Likewise, there is a separate build for Leopard PPC.

[DavidLudwig]

Regarding supporting SDL 1.x, in addition to SDL 2.x: is this a make or break feature?

I've been continuing work on a port, via a branch at https://github.com/davidludwig/macemu, mainly getting building working (on Windows, Mac, and Linux) and fixing bugs that are mostly specific to the SDL backend.

Continuing to support SDL 1.x isn't terribly trivial. There are similarities in the two APIs, however SDL2 is sufficiently different to make source-level compatibility difficult, in some areas.

[rickyzhang82]

@DavidLudwig If it is too much trouble, I'm fine with discontinuing support for SDL 1.x. Thanks for your work in SDL 2.x. I will volunteer to be your testers.

[asvitkine]

I would prefer we keep support for both. We can just fork the relevant files - e.g. video_sdl2.cpp

…

On Sep 3, 2017 6:56 AM, "Ricky Zhang" ***@***.***> wrote: @DavidLudwig <https://github.com/davidludwig> If it is too much trouble, I'm fine with discontinuing support for SDL 1.x. Thanks for your work in SDL 2.x. I will volunteer to be your testers. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#118 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABE8OcviDZQ9X17YRoJjEQlvZlBo617ks5seoXygaJpZM4O1REl> .

[DavidLudwig]

I can see ways to do that, and can give it a shot.

I do wonder if there is a sufficiently strong reason to support SDL 1.x, over time. It doesn't appear to be maintained all that much, outside of the occasional bug fix, and there has not been a release in over five years. In the meantime, SDL2 seems to get a release roughly every year, and is much more actively maintained.

The advantages to SDL 1.x largely seem to be:

1. code exists that already uses it - a big reason, IMO (although, I'd argue that SDL2 does do a better job of supporting current, commodity hardware and OSes)
2. supported older host platforms

[rickyzhang82]

@DavidLudwig Another strong reason: If it ain't broke, don't fix it.

Replacing what works with something else need another round of testing. Keeping both is a reasonable conservative approach. The suggestion that using video_sdl2.cpp is a good one. It should minimize the number of #if and #else in patching.

[DavidLudwig]

I'll plan on keeping the SDL 1.x code in-place, for the time being, and allowing for compile-time switching of SDL's major revisions.

I still have some bugs to look through, so I'm not quite ready to put together a specific, pull request just yet.

In the meantime, I made an issue on my branch to restore the SDL 1.x code-paths: DavidLudwig#30 . There are a few more steps than splitting off the video files (with Autotools reconfiguration being the one that frightens me the most!), but it doesn't look like too much extra work, yet.

[DavidLudwig]

FYI, my branch does, now, have the ability to build against either SDL1 or SDL2. If both are available, SDL2 is chosen. If --with-sdl1 is passed into autoconf, it will be chosen. There isn't, yet, a way to force SDL1 when making Win32 builds with MSVC, or with Xcode 8. If that is wanted, I am open to suggestions on how to implement that, otherwise, I'll leave it as-is.

I do still have a bunch of clean-up to-do, and want to further investigate some bugs, before putting together a pull request, though. I'm happy to hear out suggestions.

Many, many thanks to everyone who's tried this out, and/or submitted bug reports on this!

[kencu]

I don't know if it's worth the trouble, but for testing at least, my understanding is that to to use SDL1 in Xcode you would make a new target (? duplicate an existing target) and then change the relevant linked libraries and source files to the SDL1 versions. Not that I've done a lot of this -- I use the autotools method (or cmake) to make almost everything.

[DavidLudwig]

Either that (make a new target), or modify the existing target to use and bundle SDL.framework (SDL1), instead of SDL2.framework. Or use autotools to try making a build, using --with-sdl1 to force the use of SDL1, if you have both on your system.

…

On Tue, Sep 12, 2017 at 8:09 PM, Ken ***@***.***> wrote: I don't know if it's worth the trouble, but for testing at least, my understanding is that to to use SDL1 in Xcode you would make a new target (? duplicate an existing target) and then change the relevant linked libraries and source files to the SDL1 versions. Not that I've done a lot of this -- I use the autotools method (or cmake) to make almost everything. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#118 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdC0O3oWPXynbIt1OLyy-jDw8RD-U4jks5shx1MgaJpZM4O1REl> .

[kencu]

Sounds like you got it. I found this http://samwize.com/2014/05/22/create-multiple-targets-slash-apps-for-1-xcode-project/ and this https://www.appcoda.com/using-xcode-targets/ but no doubt there are more / newer / better. Thanks for making this SDL2! I'm certain in no time 99% of all builds will use it.

[rickyzhang82]

@DavidLudwig

I just give a try on your prerelease6.

For SDL2 autotool build, I'm still seeing issue to bring up GTK pref UI. In pre-release6, GTK preference UI just freeze. However, I can bring up emulation by disabling preference UI ./BasiliskII --nogui true

For SDL1 autotool build using --with-sdl1, pref UI and emulation runs OK.

I have carefully check which SDL library by invoking ldd BasiliskII

[DavidLudwig]

I just released Prerelease 7. Does it work any better with that (vs Prerelease 6)? If not, what steps do you use to create such a build, and on what host?

…

On Tue, Sep 12, 2017 at 9:08 PM, Ricky Zhang ***@***.***> wrote: @DavidLudwig <https://github.com/davidludwig> I just give a try on your prerelease6. For SDL2 autotool build, I'm still seeing issue to bring up GTK pref UI. In pre-release6, GTK preference UI just freeze. However, I can bring up emulation by disabling preference UI ./BasiliskII --nogui true For SDL1 autotool build using --with-sdl1, pref UI and emulation runs OK. I have carefully check which SDL library by invoking ldd BasiliskII — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#118 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdC0Lao-kfaNLWQOcHX7O2PIr2mwuLWks5shysOgaJpZM4O1REl> .

[rickyzhang82]

Sorry, it is a typo. I mean SDL2 Prerelease 7.

Please cherry-pick my commit rickyzhang82@fb8b450 and run BasiliskII/src/Unix/build.sh which pick up SDL2 if it is present.

[DavidLudwig]

@rickyzhang82 , what did you use as a build environment, and for what target platform?

[DavidLudwig]

@rickyzhang82 , also, while I'm familiar with cherry pick integration in some source control systems, I'm not familiar with it in git. If you send me the commands to run (to cherry-pick integrate it), I'll be happy to try it out on a fresh clone of my repo!

[rickyzhang82]

Fedora 4.11.11-300.fc26.x86_64

git co -b test-build
git remote add ricky-macemu https://github.com/rickyzhang82/macemu.git
git fetch ricky-macemu
git cherry-pick fb8b450 

[DavidLudwig]

Thanks!

I just tried it on a similar build of Fedora, 4.11.8-300.fc26.x86_64. To note, a 'sudo yum upgrade' tells me that I'd be upgrading to 4.12.x. This copy of Fedora was from an install I made into VirtualBox, a few days ago.

I was able to cherry-pick the commit. The initial 'git co -b test-build' command failed, with git telling me "git: 'co' is not a git command". The rest of the commands ran, successfully.

I cd'ed into BasiliskII/src/Unix, then ran ./build.sh. It built a copy of BasiliskII.

I ran BasiliskII with the following command:

./BasiliskII

... and the attached prefs file.

BasiliskII launched into the GUI. I clicked Start, and my copy of System 7.5.5 booted up, without error.

Any thoughts, @rickyzhang82 ? If you think it'd help, I could try getting an exact version of Fedora, but I am unsure if that'd help. Might you have a customized install of anything on your system, such as GTK+, or something else? Also, what language was that system set up to display GUI content, in? Maybe that's the key?
basilisk_ii_prefs.txt

[DavidLudwig]

@rickyzhang82 , if you have a spare moment, any chance that you could try reproducing that error, but also adding the following to your prefs file, and seeing if it makes a difference?:

sdlrender software

[rickyzhang82]

@DavidLudwig

I was able to cherry-pick the commit. The initial 'git co -b test-build' command failed, with git telling me "git: 'co' is not a git command". The rest of the commands ran, successfully.

Sorry, my bad. git co is my shortcut to commit.

Any thoughts, @rickyzhang82 ? If you think it'd help, I could try getting an exact version of Fedora, but I am unsure if that'd help. Might you have a customized install of anything on your system, such as GTK+, or something else? Also, what language was that system set up to display GUI content, in? Maybe that's the key?

It may be related to GTK. I will dig it deeper. I can replicate the same issues in Fedora installed on my all three different physical machines which use NVIDIA OpenGL or Intel OpenGL library. I don't customize my Fedora boxes due to the fact that it always keep updating with latest software. The locales of all three are English.

sdlrender software

I tired this prefs on my XPS13 9360 laptop with 4.12.9-300.fc26.x86_64. I can see GTK pref UI without crash. However, the emulation screen doesn't look right under screen win/1920/1000. There are a large black portion in the upper of emulation guest OS and also width doesn't extend to the edge. My laptop has 1920x1080 resolution. I'd expect that it cover my whole screen except a small portion in the menu bar in GNOME3. See below:

I guess the culprit is the differences between Physical OpenGL library vs Software render OpenGL library. I think for you to replicate my issue you need a real install of any Linux which uses hardware OpenGL instead of software render OpenGL in virtual machine.

Here is SDL1 screenshot:

Both screenshot uses the same pref file except that the first one runs in prerelease7 built with SDL2 with sdlrender software, while the latter one runs in prerelease7 built with SDL1 without sdlrender software

[DavidLudwig]

Regarding the SDL2 screenshot: the SDL2 backend is scaling the guest OS' display to the host OS' window-size. At present, the size in the prefs is what is used for the guest OS' display-size. If the host window is resized (which is possible with the SDL2 backend, but not the SDL1 backend), the guest OS' display size remains the same, and the image is scaled as-appropriate. Further, the SDL2 backend will attempt to preserve the aspect ratio of the guest OS' display size, drawing 'black bars' either above and below, or to the left and right, of the scaled image.

The pixel distortion that's shown in the SDL2 screenshot is due to SDL2's default, software/non-GPU scaler being used, which only supports nearest-neighbor scaling. I am looking into the possibility of adding a bilinear-filter to this, to improve the image quality (if and when using the software renderer).

[DavidLudwig]

Regarding the GTK hang, if, by chance, anyone finds a way to reliably reproduce this, preferably in a re-createable VM, or a VM image that they wouldn't mind sending me (I have both VirtualBox and Parallels/OSX installed), I'd be happy to take a look at it. I'd like to see if there is a way to either fix it, or anticipate the fault ahead of time and switch to the software rendering path.

[rickyzhang82]

Regarding to SDL2, I didn't resize my guest OS windows. I'd rather BII honors whatever guest OS window resolution I provide in preference. The scale up/down only happens if I try to resize by myself. Only at that time it resize in the same ratio as guest OS resolution. At any time, it should not have anything to do with host OS resolution. If it depends on host OS resolution, what's the point you provide resolution in preference UI?

GTK hang happens if your using OpenGL hardware library. This consistently occurs in OpenGL Linux library of NVIDIA graphics card and Intel iGPU. But I don't see that in my Mac OS X with your commit. It picks up OpenGL:

Mac OS X:

Ricky@imac:~/repo/github/dl-macemu/BasiliskII/src/Unix$ ./BasiliskII
Basilisk II V1.0 by Christian Bauer et al.
Reading ROM file...
Using SDL/coreaudio audio output
WARNING: Cannot find vendor 'cocoa' in keycode translation file /Users/Ricky/repo/68K.Mac/BasilikII/BasiliskII_keycodes.
Using SDL_Renderer driver: opengl

Key code table in Mac OS X has a minor issue which is not compatible between SDL1 and SDL2. I'm looking into it.

BTW, good works in scaling up. I like this new feature.

[kencu]

Hi David; I was looking to give this a try. Are you interested in rebasing these patches onto the current version (20171230 or so) of BasiliskII? I'm not sure what the status is of having this integrated in BasiliskII trunk.