It probably makes a better sense to look through commit history after 2.0.3 to see if there are some fixes to backport, rather than trying to fix anything later than 2.0.3. The latter will be too much of effort and perhaps not much benefit.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
SDL2 for older MacOS X
- Thread starter lauland
- Start date
- Sort by reaction score
It probably makes a better sense to look through commit history after 2.0.3 to see if there are some fixes to backport, rather than trying to fix anything later than 2.0.3. The latter will be too much of effort and perhaps not much benefit.
Yeah, we do not want to comment them out, since, for example: https://developer.apple.com/documentation/appkit/nscursor/operationnotallowed
This one should be available in 10.0+: https://developer.apple.com/documentation/appkit/nsborderlesswindowmask
Do Apple docs lie (that happens occasionally) or it is disabled due to a bug, not due to being unavailable?
I was solely focused on getting it working, and if it wasn't critical, just bypassing it for the time being to get things running. Apple docs do lie occasionally, and names change quite a bit.
Regardless, those things specifically wouldn't work on Tiger, hence my suggestion of protecting them with maybe 10.6 or higher (who knows about 10.5, but treating it as Tiger is ok for our purposes).
Up to you. I could do more work on newer versions similar to what I did if you wish, with the caveat that I'm on Tiger.
Minor update, addressing discussed issues, on top of your patch. This is untested: https://github.com/barracuda156/SDL/commit/02d7a6984b1decd1909372afa7900854856de40a
I will try building now.
I forgot one thing here. Anyway, this is the updated version: https://github.com/barracuda156/SDL/commit/03dda56c9840a1c54a2e5b82d1c482c261a6c646
Could you please check if this looks okay and does not break anything for you?
Ok, added: https://github.com/macos-powerpc/po...c7113ac6a0a9e107/devel/libsdl2-cocoa/Portfile
Verified with ffplay6 and lite-xl that it is functional.
Verified with ffplay6 and lite-xl that it is functional.
Works with mpv too, once I rebuilt it without x11. (There is probably a way to select that at runtime, but I didn’t bother looking for that.)
I could even play 4k video, kinda. It is not really usable on 2.3 Dual, but it does not even freeze, just plays slowly.
Even if it works on par with x11 in terms of performance, it is more convenient – no need in X server.
Which opengl: Cocoa uses the one in /System/Library/Frameworks/OpenGL.framework
Tested and verified. If I use the env var to specify that one, there's no effect on Cocoa (it already knew to find it there), but using X11 driver it then can't open a Window (ie have to use the X11 opengl with X11).
Your changes look VERY good, very well done. I'm not at home right now, but will test them when I get a chance.
I tested the cocoa vs x11 drivers with testgl2 and testrendercopyex. The difference in framerate was noticeable, but not earth shattering. In both using cocoa I'd get just over 500 "fps", not sure if that was actually frames or what, but that's the numbers they reported. Running the same tests using the x11 driver showed in the 470 range, so not even 10% faster. But definitely cocoa is more "mac like". I think things like copy paste, drag and dropping icons, multiple windows, and more, will be much smoother using cocoa.
Tested and verified. If I use the env var to specify that one, there's no effect on Cocoa (it already knew to find it there), but using X11 driver it then can't open a Window (ie have to use the X11 opengl with X11).
Your changes look VERY good, very well done. I'm not at home right now, but will test them when I get a chance.
I tested the cocoa vs x11 drivers with testgl2 and testrendercopyex. The difference in framerate was noticeable, but not earth shattering. In both using cocoa I'd get just over 500 "fps", not sure if that was actually frames or what, but that's the numbers they reported. Running the same tests using the x11 driver showed in the 470 range, so not even 10% faster. But definitely cocoa is more "mac like". I think things like copy paste, drag and dropping icons, multiple windows, and more, will be much smoother using cocoa.
I have a real-world benchmark – to play 4K vids without frame dropping and up to 60 FPS. Will try on the Quad – stayed home for a couple of days, and 2.3 is too slow for this task.
Meanwhile:
It looks like you have libsdl2-cocoa set up as a port with the new patches. I did selfupdate, and then sudo port install libsdl2-cocoa, but it got 404's trying to fetch SDL2-2.32.6.tar.gz.
Let me know if I did something wrong. Otherwise I can test applying the patches by hand.
So, what is the state of powerpc SDL3? Probably similar, but worse, my guess, right?
Let me know if I did something wrong. Otherwise I can test applying the patches by hand.
So, what is the state of powerpc SDL3? Probably similar, but worse, my guess, right?
SDL2-2.32.6.tar.gz is the source, so probably you have an old curl. If you do not want to rebuild the base against the modern one, you may download the source manually and place it into /opt/local/var/macports/distfiles/libsdl2-cocoa.
Likely you already have the same in distfiles/libsdl2-powerpc, so then just copy it.
There is not much to test it with, the only port using it is tomato-tox, which seems to work – at least X11 GUI is working.
curl: I admit I totally don't understand what is going on with it and why it is such a pain, but know you'd already posted good info on it...I'll go back and read what you said and see what it involves. If I'm testing stuff, I might as well do it right and "rebuild the base", once I have half a clue what that means
(I do understand I have old version, just not how all the moving parts in macports deal with it and how to fix it)sdl3: tomato-tox, what a weird thing! I had trouble even figuring out what it was. Yeah, there doesn't seem to be anything really compelling for SDL3, so will leave it for another day. (And chances of it "just working" on tiger are likely not good).
I think that the system curl cannot handle https, which is probably required by GitHub, so you cannot fetch any sources from there. Why it works for most ports is because MacPorts own distfiles allow usage of archaic curl. Since there is no `libsdl2-cocoa` port in MacPorts, neither option works. The same will happen when MacPorts distfiles do not have a needed version of some port’s source.
Solution is to have a proper, working curl. Bootstrap a separate tree in /opt/bootstrap (or anywhere in a separate prefix), configuring it with `--without-startupitems --with-applications-dir=/opt/bootstrap`, once that is installed, rebuild main installation, configuring it with `--with-curlprefix=/opt/bootstrap`. No need to reinstall any ports.
Ok, on May 19th you provided detailed instructions on how an /opt/bootstrap can be used to get a better curl and I've tried following them, but ran into problems as it wants to build its own gcc, etc etc etc. We could go into those, but...all of this is just to get a better curl that can handle https, is that correct?
My goal was to get mpv to test a cocoa SDL2 and specifically opengl, and, also to use your macports to get the libsdl2-cocoa to see if that built on tiger with the patches, but I'm wondering if this is worth all the trouble. There's just so many dependencies, trouble with different packages, dealing with curl, etc. I've already installed all the dependencies possible that I could (including at least 4 gcc's), with my bad curl, etc. This has become a bit of a pain, and I think I've lost sight of the original purpose.
So, stepping back, maybe just abandon mpv for now, etc. I'd like to continue testing your macports for tiger, and do my part to make sure it works as much as possible. But am not sure if that's the way, or what still needs testing. If you think debugging the process of doing /opt/bootstrap for a new curl (on tiger) would be a useful thing, maybe that? ie if I don't have a better curl, I'm stuck?
My goal was to get mpv to test a cocoa SDL2 and specifically opengl, and, also to use your macports to get the libsdl2-cocoa to see if that built on tiger with the patches, but I'm wondering if this is worth all the trouble. There's just so many dependencies, trouble with different packages, dealing with curl, etc. I've already installed all the dependencies possible that I could (including at least 4 gcc's), with my bad curl, etc. This has become a bit of a pain, and I think I've lost sight of the original purpose.
So, stepping back, maybe just abandon mpv for now, etc. I'd like to continue testing your macports for tiger, and do my part to make sure it works as much as possible. But am not sure if that's the way, or what still needs testing. If you think debugging the process of doing /opt/bootstrap for a new curl (on tiger) would be a useful thing, maybe that? ie if I don't have a better curl, I'm stuck?
That does not make much practical sense. Keep in mind, I use 10.6 and 10.5, so no idea what 10.4 needs for curl.
You can do much easier then, rebuilding the base against its own curl. Just configure as `--with-curlprefix=/opt/local` and rebuild.
P. S. If you already have a tree in /opt/bootstrap, you may check what it wants with minimal curl:
Code:
sudo port -v install curl -brotli -http2 -idn -psl -zstd
Last edited:
@lauland Building against its own curl should work, at least I did that a few times myself, when wanted to save time. (The curl is not “bad”, just the base was configured with /usr/bin/curl by default.)
If this still does not work for w/e reason, let me know, I will build a bootstrap_curl installer for you.
If this still does not work for w/e reason, let me know, I will build a bootstrap_curl installer for you.
Ok, extremely stupid question maybe. Why not just replace /usr/bin/curl? I know that'd non-standard, modifying the os, possibly evil, may cause incompatibilities, etc etc etc. But seems like it'd be far simpler?
I think you may have already provided a link to a bootstrap_curl...I'll look in the past posts for that.
FYI The /opt/bootstrap build didn't complete due to errors building apple-gcc-42 (or whatever the exact name is). For the record it it failed when "comparing stages".
You can move it out and make a symlink to there. Though it will be equivalent to rebuilding against MacPorts own curl, but more fragile.
There is none for Tiger atm. For 10.5 and 10.6 there is.
Don’t bother building the whole gcc for the sake of curl, IMO, it is really a waste of effort. There are alternative solutions.