SDL2 for older MacOS X

[lauland]

Ok...after a break, I consulted with one of my cats (she demanded attention, and to play), and came to this conclusion: It is not likely possible to easily fix any too recent "cocoa" folder to work. But...if you replace the ENTIRE cocoa folder, I can get the very old one to work with pretty much any SDL2 version. Yes, this is FAR from ideal, but it does work. I've had very good luck with doing entire drivers for classic MacOS and Amiga with the very latest SDL2.

I should have known there'd be just too many changes and not sure why I tried. With that said, I'll get the tree building and working on Tiger, with the ancient cocoa driver. I'll use the "original" SDL2 that I first pulled from the git you provided, and probably won't need the other one.

We'll run into things that are disabled when built on Tiger, like the Keymap thing, but will work them out one at a time. Once I have it working I can get the changes back to you via git, you can try a build, if it hitches, we'll fix it, etc. Like I said, far from ideal, but if you want cocoa, this is a semi-decent way to get it.

OpenGL should be enabled by default if you use a configure close to the one I quoted previously.

We won't have any of the newer stuff, such as gles/egl, so it is a non-issue.

For testing I use the tests that come with SDL mostly, in "test". Do configure inside that and make. There's stuff to test EVERYTHING, including gl. Otherwise I have a trivial little game demo SDL2-Game-Master here https://macintoshgarden.org/apps/sdl2-macos-9-rough-draft

 

[barracuda156]

Ok...after a break, I consulted with one of my cats (she demanded attention, and to play), and came to this conclusion: It is not likely possible to easily fix any too recent "cocoa" folder to work. But...if you replace the ENTIRE cocoa folder, I can get the very old one to work with pretty much any SDL2 version. Yes, this is FAR from ideal, but it does work. I've had very good luck with doing entire drivers for classic MacOS and Amiga with the very latest SDL2.

I should have known there'd be just too many changes and not sure why I tried. With that said, I'll get the tree building and working on Tiger, with the ancient cocoa driver. I'll use the "original" SDL2 that I first pulled from the git you provided, and probably won't need the other one.

We'll run into things that are disabled when built on Tiger, like the Keymap thing, but will work them out one at a time. Once I have it working I can get the changes back to you via git, you can try a build, if it hitches, we'll fix it, etc. Like I said, far from ideal, but if you want cocoa, this is a semi-decent way to get it.

OpenGL should be enabled by default if you use a configure close to the one I quoted previously.

We won't have any of the newer stuff, such as gles/egl, so it is a non-issue.

Just to clarify: given that the version of Cocoa you made today builds fine (I cannot confirm at the moment if it works), do you think the older Cocoa gonna work better, or is it just easier to go that way, or did you establish that today’s version compiles but does not work?

Presumably if we just apply the same changes you have already made plus a few trivial amendments to unbreak build on 10.6, we gonna have a successful build. EGL can be disabled by configure option, or if we need X11 EGL, then Cocoa EGL can be cut out from sources.

 

[lauland]

Ok, I have the old driver working in the 2.32.7 tree. Verified it is using cocoa, as it works with no X11 app running.

Tested framerate against X11 driver and it is better, but not mind blowing.

Let me know how to get it to you.

(The newer version did not build on tiger, only the older one, I know that doesn't matter to you, but that's I'm working on...patching the newer one for post-tiger would be a different project)

 

[barracuda156]

Ok, I have the old driver working in the 2.32.7 tree. Verified it is using cocoa, as it works with no X11 app running.

Tested framerate against X11 driver and it is better, but not mind blowing.

Let me know how to get it to you.

If it is vastly different from existing Cocoa, then there is no point in applying that as a series of patches, of course.
You could just zip the folder (assuming nothing external is to be changed), or otherwise replace the whole folder in the git branch, `git add src/video/cocoa`, `git push origin`, share the repo URL.
Or any other way in fact, it makes no difference if it is in a form of drop-in source files or a commit replacing cocoa.

 

[lauland]

If it is vastly different from existing Cocoa, then there is no point in applying that as a series of patches, of course.
You could just zip the folder (assuming nothing external is to be changed), or otherwise replace the whole folder in the git branch, `git add src/video/cocoa`, `git push origin`, share the repo URL.
Or any other way in fact, it makes no difference if it is in a form of drop-in source files or a commit replacing cocoa.

Exactly. A bit of a mess, and unclear how to fold it in or distribute it outside a wholesale replacement. The diff's would be absolutely huge. I have no idea what you should do with it as far as a "port". But, it is a reliable way to get cocoa for older machines with latest SDL2.

I believe the zip I shared from earlier will work, as-is, so you should try that, I didn't need to make any changes for 2.32.7.

A couple of the driver functions are still wrong, so I'll work on those.

I know, a bit disappointing, but it is what it is.

 

[barracuda156]

Exactly. A bit of a mess, and unclear how to fold it in or distribute it outside a wholesale replacement. The diff's would be absolutely huge. I have no idea what you should do with it as far as a "port". But, it is a reliable way to get cocoa for older machines with latest SDL2.

Well, I am not gonna submit anything to upstream MacPorts, so there is no need to bother with compliance with some customary practices of it. But while nothing technically prevents us from having 3k loc patch, it is arguably impractical and complicates understanding of changes made.

The “correct” way would be to take the source, whichever it is, closest to what you want, and apply patches onto that (only Cocoa folder, not all the set of patches for SDL).
Then what is left is a technicality, which I will implement: fetch two versions of SDL2, delete cocoa folder from the current one, move a legacy version of it from extracted supplementary source tarball into its place, apply your patches on top of that.
The quick and dirty way is to dump the whole folder into /devel/libsdl2-cocoa/files and use that.

I believe the zip I shared from earlier will work, as-is, so you should try that, I didn't need to make any changes for 2.32.7.

A couple of the driver functions are still wrong, so I'll work on those.

It would be helpful to settle on a version which you currently consider the best choice and confirm that it actually works on your system. Then I can handle adjusting that for 10.6, in case any adjustments needed at all.

 

[barracuda156]

Using git will be nice, since otherwise we quickly end up with multiple versions of the code and a lack of clarity what is the correct one.

But I can do git stuff on my end, for example, if you upload ready files (like you did above). If you remember what was the base version you used, I will use that to apply your changes.

 

[lauland]

Using git will be nice, since otherwise we quickly end up with multiple versions of the code and a lack of clarity what is the correct one.

But I can do git stuff on my end, for example, if you upload ready files (like you did above). If you remember what was the base version you used, I will use that to apply your changes.

Ok, attached has all warnings fixed, and fixes a missing return val and a parameter or two for a couple driver functions. All minor and were actually unused or harmless, but is as correct as it can be.

I get warnings about "use '-fobjc-exceptions' to enable Objective-C exception syntax", but that can be added to CFLAGS via configure, and also should be harmless without it.

On Tiger or Leopard (but not Snow Leopard) will get a warning "method definition for '-handleTouches:withEvent:' not found", but that probably can't be helped as cocoaTouchType probably isn't defined for them. It was already inside "#if MAC_OS_X_VERSION_MIN_REQUIRED >= 1060" so I can tell it WILL be there for Snow Leopard.

It works as a drop in replacement for any 2.32.x as far as I can tell. Will likely work on older to a point, for what its worth. It defintiely works with 2.32.7 on my system.

 

[lauland]

Just checking, joystick and audio work for Snow Leopard for you, correct? If so, working on them is very low priority for me, as in, I'll work on them for Tiger when I need them at some point, but will otherwise punt.

 

[barracuda156]

Just checking, joystick and audio work for Snow Leopard for you, correct? If so, working on them is very low priority for me, as in, I'll work on them for Tiger when I need them at some point, but will otherwise punt.

Joystick no, but I do not have any use case where it would be needed. Audio is working, yes.

P. S.
Is it needed to rebuild dependents when switching between Cocoa vs X11 SDL? (In that case I can make variants.)

Is it possible to switch between two backends at runtime, if one SDL is built with both?

 

[lauland]

Once I get an MacOS 9 SDL2 game port that needs joysticks, I'll work on it for that platform, and probably do Tiger too. I had a lot of fun playing with joysticks for SDL 1.2 on MacOS 9.

The cocoa driver doesn't have any new dependencies, as cocoa is part of MacOS X. In fact, if you left the x11 driver out completely, it'd have less. But right now it's including both, so no.

The env var SDL_VIDEODRIVER is supposed to let you switch, so "export SDL_VIDEODRIVER=x11" SHOULD use the x11 instead of cocoa, but it isn't working for me.

In fact, there seems to be a problem with SDL_Log in general. I see "INFO" and "DEBUG" but blank lines. Could just be a tiger thing, I'll look into it. When I set SDL_VIDEODRIVER=11, it just says "INFO" so it is trying to tell me something important!

(FYI testdisplayinfo and testaudioinfo both are designed so they don't display or play anything, but just show you info about the drivers that are built in and your hardware).

This file lists all the environment variables you can set that SDL apps can use:

SDL/include/SDL_hints.h at SDL2 · libsdl-org/SDL

Simple Directmedia Layer. Contribute to libsdl-org/SDL development by creating an account on GitHub.

github.com

 

[lauland]

Found it, there's a bug in main SDL2, where it fprintf's the "level" of the log to stderr, but then calls NSLog for the rest of the message.

 

[lauland]

Hmm...with that sorted, I saw an error about finding libGL...I did:
export SDL_OPENGL_LIBRARY=/usr/X11R6/lib/libGL.dylib

But with SDL_VIDEODRIVER=x11 it now just hangs.

So it looks like switching video drivers at runtime may run into a problem with GL...it may be opening cocoa's GL, which then conflicts with X11 trying to also use GL.

I'll try setting SDL_OPENGL_LIBRARY to point to cocoa's and see if that works...

I'm thinking it may be the GL renderer, which is separate from the way SDL uses GL for video display.

No...export SDL_RENDER_DRIVER=software doesn't help.

export SDL_OPENGL_LIBRARY=/System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib doesn't work if the driver is X11, it give GL errors, but using the cocoa driver it has no effect, since that's the GL it's already using.

It is some opengl thing tho, I'm pretty sure.

 

[barracuda156]

Hmm...with that sorted, I saw an error about finding libGL...I did:
export SDL_OPENGL_LIBRARY=/usr/X11R6/lib/libGL.dylib

But with SDL_VIDEODRIVER=x11 it now just hangs.

So it looks like switching video drivers at runtime may run into a problem with GL...it may be opening cocoa's GL, which then conflicts with X11 trying to also use GL.

I'll try setting SDL_OPENGL_LIBRARY to point to cocoa's and see if that works...

I'm thinking it may be the GL renderer, which is separate from the way SDL uses GL for video display.

No...export SDL_RENDER_DRIVER=software doesn't help.

export SDL_OPENGL_LIBRARY=/System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib doesn't work if the driver is X11, it give GL errors, but using the cocoa driver it has no effect, since that's the GL it's already using.

It is some opengl thing tho, I'm pretty sure.

Mesa may work for GL.

However, any of those will need X server to display anything whatsoever. Do you have it running? No X11 app gonna work otherwise.

 

[lauland]

Mesa may work for GL.

However, any of those will need X server to display anything whatsoever. Do you have it running? No X11 app gonna work otherwise.

Mesa is a whole other subject. Can look into some point.

Yep, I definitely had the X11 app open, so it was something else going on. I switched to the version of SDL2 without cocoa and it worked fine. So there is a conflict in the version with both drivers, and the x11 one in it can't be used if cocoa is there. It may or may not make sense to have both of them enabled. There may be bugs or problems in SDL2 itself that we're running into. My feeling is it is related to opengl, but I may be wrong.

 

[barracuda156]

Mesa is a whole other subject. Can look into some point.

Yep, I definitely had the X11 app open, so it was something else going on. I switched to the version of SDL2 without cocoa and it worked fine. So there is a conflict in the version with both drivers, and the x11 one in it can't be used if cocoa is there. It may or may not make sense to have both of them enabled. There may be bugs or problems in SDL2 itself that we're running into. My feeling is it is related to opengl, but I may be wrong.

Okay, got it.

I think we rather make a separate port for Cocoa backend (and retire libsdl2-legacy), not only that gonna be more robust but also practical: no need to know how to hack environment, just switch between ports, also Cocoa one will have no dependencies, which is much more convenient than pulling in X11 stuff when it is not even needed.

Setting in the main libsdl2 controls a preference for a specific backend port. So the logic is already there, we just need to add libsdl2-cocoa.

 

[lauland]

That sounds like the most sane thing to do. We might be able to figure out how to get the different drivers to work, or we might find it's a bug in main SDL and doesn't even work with the very latest on the very latest hardware!

Either way, we're dealing with a mutant SDL, so having it be its own separate thing isn't bad at all.

The log thing definitely is a bug in SDL, but it's minor enough its not worth fixing. It should be sending the "INFO" lines to NSLog also, but they are accidentally sent to stderr and lost if you run things from the finder. Since its only useful for debugging no big loss.

FYI There was one function I didn't fix, but just disabled, which was:
- (BOOL)applicationNSApplication *)theApplication openFileNSString *)filename
in SDL_cocoaevents.m.

Newer SDL needs a window, for SDL_SendDropFile but I couldn't figure out how to get the correct one so I just have it return FALSE. I don't know when that function is used, probably when icons are dropped on windows, and just left a "LAULAND" note in a comment there. I think there's a way to find the "current window" and that would probably work, but I didn't try that.

Maybe return (BOOL)SDL_SendDropFile([filename UTF8String],NULL); would work?

 

[barracuda156]

That sounds like the most sane thing to do. We might be able to figure out how to get the different drivers to work, or we might find it's a bug in main SDL and doesn't even work with the very latest on the very latest hardware!

Either way, we're dealing with a mutant SDL, so having it be its own separate thing isn't bad at all.

The log thing definitely is a bug in SDL, but it's minor enough its not worth fixing. It should be sending the "INFO" lines to NSLog also, but they are accidentally sent to stderr and lost if you run things from the finder. Since its only useful for debugging no big loss.

FYI There was one function I didn't fix, but just disabled, which was:
- (BOOL)applicationNSApplication *)theApplication openFileNSString *)filename
in SDL_cocoaevents.m.

Newer SDL needs a window, for SDL_SendDropFile but I couldn't figure out how to get the correct one so I just have it return FALSE. I don't know when that function is used, probably when icons are dropped on windows, and just left a "LAULAND" note in a comment there. I think there's a way to find the "current window" and that would probably work, but I didn't try that.

Maybe return (BOOL)SDL_SendDropFile([filename UTF8String],NULL); would work?

BTW, the last zip has sources with 10.6-specific issues which I mentioned above already fixed? I was off, so did not try building it yet. Will give it a go soon.

Also, could you say which SDL version you used for Cocoa fixes? Diffing against that will minimize the patch and make it more readable.

 

[lauland]

I only tested on 10.4, so it may or may not include fixes for 10.6. You must test it. It probably doesn't have the keymap thing you found, for example. There's code in there protected by #ifdef's that would only be active on 10.6 or higher that I never tested and may still need fixes, which we can do.

I used the code from the 2.0.3 port I got from your site for the cocoa folder, fixed it enough to run with 2.32.x. It might be possible to hack something a bit newer to work, but that was a known good working version. If you diff against that port (just the cocoa folder) my changes will be very obvious.

It's a far from perfect solution, and a better cocoa driver could be created given time, but this was easy to do.

 

[barracuda156]

I only tested on 10.4, so it may or may not include fixes for 10.6. You must test it. It probably doesn't have the keymap thing you found, for example. There's code in there protected by #ifdef's that would only be active on 10.6 or higher that I never tested and may still need fixes, which we can do.

I used the code from the 2.0.3 port I got from your site for the cocoa folder, fixed it enough to run with 2.32.x. It might be possible to hack something a bit newer to work, but that was a known good working version. If you diff against that port (just the cocoa folder) my changes will be very obvious.

Ken’s old port for 2.0.3 (no idea if tested on ppc, but I think it was on 10.5 i386) had a drop-in replacement for joystick module (perhaps borrowed from a yet earlier version). Presumably it worked (I did not verify that personally, but no reason to doubt him here). You may want to check if that works, it could be an easy solution to the problem.

 

[lauland]

The old 2.0.3 port's audio worked fine on tiger, joystick built and seemed to "work" but I didn't test with an actual stick. If I were really serious about tiger SDL2, I could take both and do the same thing I did with the cocoa driver and make them drop in replacements.

FYI I did try "dropping them in" to 2.32.x but both need a lot of work to get working/building, possibly more than the cocoa one, and I didn't seriously look at either, just wanted to see what'd happen.

So it's something I'd do if there were a compelling reason, like something interesting SDL2 I needed on tiger, but won't until then.

 

[barracuda156]

I used the code from the 2.0.3 port I got from your site for the cocoa folder, fixed it enough to run with 2.32.x. It might be possible to hack something a bit newer to work, but that was a known good working version. If you diff against that port (just the cocoa folder) my changes will be very obvious.

Yeah, it is minimal: https://github.com/barracuda156/SDL/commit/bea57b58789800e3b8e27f3deb0a5e5f01c08b6f
> 15 files changed, 107 insertions(+), 22 deletions(-)

 

[lauland]

Seeing it that way there are a few lines I just commented out, but we may want to protect with #ifdef SOME_VERSION_OR_WHATEVER. Things that are definitely not Tiger, but I don't know what os version they were added.

These kinda bother me:
nscursor = [NSCursor operationNotAllowedCursor];
[windata->nswindow setStyleMask:NSBorderlessWindowMask];
[contentView setWantsBestResolutionOpenGLSurface:YES];

For those you might try protecting them against pre 10.6 and see if they build on your system.

And, as I mentioned, but don't know how to fix off top of my head:
return (BOOL)SDL_SendDropFile([filename UTF8String]);

None of these are critical, but while we're at it, might as well do it right.

 

[barracuda156]

BTW, it is probably not hard to get a bit later Cocoa working, at least for 10.5+. For example, here is the history from 2.0.7 release down: https://github.com/libsdl-org/SDL/commits/b89cac6761e9ab48e1b6149a0da90d47baf6f925/src/video/cocoa

There is a breaking commit: https://github.com/libsdl-org/SDL/commit/4a468739f832615dcc21f52e695659e5e93da2cb – but it is small and easy to revert. Otherwise it seems that 10.6 was still supported in 2.0.7 by upstream and fixes for < 10.7 were added (which is what makes it potentially worth bothering with).

Upd. Ah, I think I get what made 2.0.3 a fix-point. This brilliant commit: https://github.com/libsdl-org/SDL/commit/0e45984fa036fff1912c62fee3ed4f5481f3c324
That’s beyond ridiculous.

 

[barracuda156]

Seeing it that way there are a few lines I just commented out, but we may want to protect with #ifdef SOME_VERSION_OR_WHATEVER. Things that are definitely not Tiger, but I don't know what os version they were added.

These kinda bother me:
nscursor = [NSCursor operationNotAllowedCursor];
[windata->nswindow setStyleMask:NSBorderlessWindowMask];
[contentView setWantsBestResolutionOpenGLSurface:YES];

For those you might try protecting them against pre 10.6 and see if they build on your system.

And, as I mentioned, but don't know how to fix off top of my head:
return (BOOL)SDL_SendDropFile([filename UTF8String]);

None of these are critical, but while we're at it, might as well do it right.

Thank, I will check.

P. S. I think we should just trash instances of meaningless at best upstream code like

#if MAC_OS_X_VERSION_MAX_ALLOWED < 1070
# error SDL for Mac OS X must be built with a 10.7 SDK or above.
#endif /* MAC_OS_X_VERSION_MAX_ALLOWED < 1070 */

instead of adding #if macros to bypass them.