Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
SDL 1.2, 2.0.3 and 2.32 all build and run fine on intel 10.4.
SDL 1.2 and 2.0.3 build and run on intel 10.5 and 10.6...
But there are build issues with 2.32 in X11 opengl driver...will see what I see.
 
https://github.com/macos-powerpc/powerpc-ports ? Hmm...
https://macintoshgarden.org/forum/custom-software-builds-os-x-leopard-32bit ? Hmm...

Hmm...maybe you guys can "SDL2 together"? I know the goals and targets are different, but it seems like there could be some synergy...

If you mean specifically SDL, that could work. If you mean adding (or rather ensuring, since it was not specifically removed) support for 10.5 i386 builds into PPCPorts, well, I have no objections, but I doubt anyone will bother doing the work. My i386 machine stopped booting, and I am not doing this in a VM (also no time to add an extra arch anyway).
 
My thoughts were they are very active in making sure their SDL2 works well, for the countless game ports. They may have patches and/or configuration that might benefit. By taking advantages of their patches, it might help the problems you've seen and/or get a working more modern cocoa driver, etc. And the idea of working on Intel, is it may help even 10.6.8 ppc, just by knocking out problems and weirdness. But, who knows, maybe I can act like a bee, and cross pollinate if I see something useful...

Ok, barracuda156, so previously I believe you'd reported problems with SDL2, building, but not running. From what I remember, two of the configurations was a 10.5.x G5, and then 10.6.8 ppc, in general.

Let me know if you did see problems with 10.5.x, and I can specifically try and reproduce them, and look at that. If I don't see the problems on my G4, we can then narrow it down to something on your system.

If you had problems with 10.6.8 ppc, let me know exactly which version you were using, because, if I were to look into SDL2 issues on it, I would want to install as closely a version as you are using.
 
My thoughts were they are very active in making sure their SDL2 works well, for the countless game ports. They may have patches and/or configuration that might benefit. By taking advantages of their patches, it might help the problems you've seen and/or get a working more modern cocoa driver, etc. And the idea of working on Intel, is it may help even 10.6.8 ppc, just by knocking out problems and weirdness. But, who knows, maybe I can act like a bee, and cross pollinate if I see something useful...

Ok, barracuda156, so previously I believe you'd reported problems with SDL2, building, but not running. From what I remember, two of the configurations was a 10.5.x G5, and then 10.6.8 ppc, in general.

Let me know if you did see problems with 10.5.x, and I can specifically try and reproduce them, and look at that. If I don't see the problems on my G4, we can then narrow it down to something on your system.

If you had problems with 10.6.8 ppc, let me know exactly which version you were using, because, if I were to look into SDL2 issues on it, I would want to install as closely a version as you are using.

I need to verify again, but as far as I recall Cocoa backend is broken with ATI GPU on 10.5.8 ppc64 and [regardless of GPU] on 10.6.8 A5 image (ppc). X11 backend works everywhere (at least without GL).
I am kinda surprised no one complained about A5 image, but I have not seen a confirmation it works for anyone either. To me it seems that while 10.6.8 Nvidia image has some issues with GL, on A5 image situation is far worse.

I do not have any issues with building on any of these systems. It just does not run on affected ones.

P. S. Also 2.0.6 Cocoa fails with Bus error everywhere (but this is not a reference case, since it fails uniformly, and that could be an issue with patches rather than SDL as such).
 
Ok, if we can nail down what exactly to test, I'd be happy to take a look, but I'll need specifics, as much as possible, to get test cases.

Cocoa driver for SDL 2.0.3 (with opengl) worked for me on all systems (10.4/10.5 ppc, 10.4/10.5/10.6 intel) I tested last week, except for G4 Leopard with ATI Rage 128, which worked once I put a ATI Radeon card in the machine.

This is using my source from early Summer, so something may have broken since then (you mentioned "2.0.6"), or it may be your particular machines (g5, card, drivers, X11, etc). If you like, I can try and get the latest source (let me know the port name and which server), so we can figure out which.

SDL 2.32.4 X11 with OpenGL worked for me on PPC Leopard (with different ATI Radeons, and updated X11), but again, my sources are older than what you are using. I did run into that X11 (apple/xquartz) weirdness, and needed to update it, so it may be your particular X11.

I don't have any Nvidia mac cards, so obviously won't be able to test that.

If you'd like me to test on PPC Snow Leopard, let me know exactly which image you are using, there seem to be multiple ones out there, possibly from multiple people. And then there's patches on top of them? And obviously I'll need XCode...and probably your macports? I've got some time, so I don't mind looking, but want to make sure I'm runing the same one you are. (If we're different, we've got too many variables from the start).
 
Last edited:
I don't have any Nvidia mac cards, so obviously won't be able to test that.
If you'd like me to test on PPC Snow Leopard, let me know exactly which image you are using, there seem to be multiple ones out there, possibly from multiple people.

Since you do not have Nvidia hardware, there is only one relevant image to test – where Cocoa does not work for me in SDL2 – it is A5. See: https://macintoshgarden.org/apps/mac-os-x-1068-powerpc-alpha-build-3-macrumors
I do not think this is G5-specific, since there is no ppc64 involved.

And obviously I'll need XCode...

It should be sufficient to install “official” (= my) sources on top of official Xcode 3.2.6 (that is, darwin-xtools, make and bsdtar). That leaves some binaries in /usr/bin and /Developer/usr/bin still broken (no ppc slices), but those can functionally be replaced by ports (i.e. if you need, say, gperf or m4, just install/activate respective ports, and those will be picked). It will also normally work to replace select binaries with ones from 10a190 (or rebuild them), but that can be avoided in most cases.

and probably your macports? I've got some time, so I don't mind looking, but want to make sure I'm runing the same one you are. (If we're different, we've got too many variables from the start).

I follow the same procedure on my installations which I recommend to others (including removal of alternative X11), so it should be reproducible. So yeah, just install A5 image, Xcode 3.2.6, bootstrap_curl, PPCPorts and toolchain components which I mention, run port sync and install w/e needed.

P. S. Just in case, I cannot rule out completely that the issue is on my end, however so far it seems consistent: on A5 SDL2 Cocoa does not work (I have/had more than one installation), while on 10a190 and 10.6.8 “Nvidia” (which uses relevant components from 10a190 and not 10.5.8) it works fine.
 
Ok, to be clear, you are saying the only SDL problems on 10.5 are with Nvidia, correct? With ATI there are no problems? If that's the case, then maybe I have a good excuse to get around to flashing an Nvidia card.

The fact that it works on "older" versions (10a190 and "Nvidia"), but not A5 sounds like a red flag...if I'm following correctly. Is this not a problem with A5 10.6 ppc itself, and not ports or anything that could be fixed in SDL?
 
Ok, to be clear, you are saying the only SDL problems on 10.5 are with Nvidia, correct? With ATI there are no problems? If that's the case, then maybe I have a good excuse to get around to flashing an Nvidia card.

The whole matter is somewhat a mess. There is no “state of art” implementation for GL and related stuff at all for us (and not possible to rebuild from source, since no sources are available).
10.5 works fine with 32-bit ppc and any supported cards, but 10.5 has older GL, no IOSurface etc. It is inferior by design.
10a190 has the latest of what exists, but it is a developer build, which has some bugs. Support for Nvidia cards is more complete in it, however I had rather nasty system freezes when using SDL2 with GL there. With ATI no freezes, but no hardware acceleration.
10.6.8 Nvidia image borrows from 10a190, so it has the latest stuff with latest bugs LOL
10.6.8 A5 borrows from 10.5.8, which is supposed to be more stable, but turned out is semi-broken, at least in my testing.

On 10.5.8 SDL2 ppc64 has no working Cocoa with ATI cards.

The fact that it works on "older" versions (10a190 and "Nvidia"), but not A5 sounds like a red flag...if I'm following correctly. Is this not a problem with A5 10.6 ppc itself, and not ports or anything that could be fixed in SDL?

A5 uses older frameworks borrowed from 10.5.8, because 10a190 does not support CoreImage with ATI cards. However now I doubt it was the right move – on 10a190 (and Nvidia image, borrowing from 10a190) at least it works.
 
Hmm...very confusing. I'm not sure how to proceed or be of much help, in the case of 10.6.8. Without a stable foundation...or, in this case multiple semi-stable ones...it isn't possible to tell when there are problems if it is with the foundation or with what is being built on it. It doesn't sound like the problems are with SDL at all, but maybe you're thinking tweaks to it to get around limitations? (Like not using a particular gl extension that isn't working or is missing?)

On 10.5.8 ppc64, I'm assuming you're building SDL2 (and all of ports?) 64 bits, correct? I did see problems on my 32 bit machine, but they were related to X11's GLX. Note that the SDL2 X11 driver is usually still built and included even when the Cocoa one is in there. I mention that in case you may be having GLX problems (SDL2 may still be opening it). Be sure "glxinfo" works and shows it is accelerated (not using software renderer, which is what I saw at first). Want to be sure the problem is not with your X11 (indirectly).
 
Hmm...very confusing. I'm not sure how to proceed or be of much help, in the case of 10.6.8. Without a stable foundation...or, in this case multiple semi-stable ones...it isn't possible to tell when there are problems if it is with the foundation or with what is being built on it. It doesn't sound like the problems are with SDL at all, but maybe you're thinking tweaks to it to get around limitations? (Like not using a particular gl extension that isn't working or is missing?)

If you can just install existing A5 image and try using SDL2, that will be very helpful. Maybe I am just doing something wrong after all, or maybe it is some local hardware-caused issue.
It is useful to verify independently. A5 is the “reference” in a sense of community settling on it for quite a while. If there is a bug, it is better it is confirmed, and then it can be fixed. If I am missing some part locally, then I unnecessarily abstain from Cocoa backend on it.

Since you have everything pre-built, this should be a matter of an hour or two.

On 10.5.8 ppc64, I'm assuming you're building SDL2 (and all of ports?) 64 bits, correct?

Yes, everything on ppc64 is ppc64, aside of MacPorts base.

I did see problems on my 32 bit machine, but they were related to X11's GLX. Note that the SDL2 X11 driver is usually still built and included even when the Cocoa one is in there. I mention that in case you may be having GLX problems (SDL2 may still be opening it). Be sure "glxinfo" works and shows it is accelerated (not using software renderer, which is what I saw at first). Want to be sure the problem is not with your X11 (indirectly).

How did you solve this issue, to get hardware acceleration with GLX?
 
If you can just install existing A5 image and try using SDL2, that will be very helpful. Maybe I am just doing something wrong after all, or maybe it is some local hardware-caused issue.
It is useful to verify independently. A5 is the “reference” in a sense of community settling on it for quite a while. If there is a bug, it is better it is confirmed, and then it can be fixed. If I am missing some part locally, then I unnecessarily abstain from Cocoa backend on it.

Since you have everything pre-built, this should be a matter of an hour or two.
Oh! If you mean just try running a version that I'd previously built, such as on Leopard, to see that it works, I could definitely do that. I can certainly just install A5 and try running what I already have, as a sanity check. For a further check, I can test the same scenario on Intel (ie running a previously built version on Snow Leopard).

Setting up an A5 dev environment along with ports, and trying building it, is another thing entirely, and sounds more like several hours of work.
Yes, everything on ppc64 is ppc64, aside of MacPorts base.
Ok, then I can't reproduce the problem. It is working on 32 bit ppc leopard for me.
How did you solve this issue, to get hardware acceleration with GLX?
I had to install version 2.3.3.2 of xquartz from https://www.xquartz.org/index.html. I first tried the next higher version than what shipped with Leopard, and then kept trying each version until I found the oldest one that worked. This is with a Radeon 7000, with a Rage 128 all GLX programs crash with a "Context" error.

It may be possible to do hardware GLX acceleration on Leopard with a Rage 128 with some combo of X11/drivers/etc, but it's not worth the time to figure out since I have a spare Radeon, and all my other g4 class machines do also. (I already tried the newest Leopard supported xquartz, 2.6 I think, and it didn't help).

If you aren't getting hardware acceleration for GLX, chances are it may be your X11 install, be it apple or macports, etc.
 
Ok, installed A5 according to instructions from MG, but just that. No XCode, or mac/powerpc-ports, or anything else. And some interesting results.

First off there is some task continuously spawning (and failing?), but the console logs just fill and fill with blank lines with just process numbers. I'm not complaining and know this might just be an A5 thing (trying to launch some system process for which there is no powerpc version), but want to mention it in case this is something with my machine. Let me know if this is "normal" for A5.

Apple's X11 that comes with A5 is broken, which I'm sure you know. It looks like all program binaries are Intel only, even though the dylibs are tri-arch. I tried running just the app binaries from my Leopard XQuartz 2.3.3.2 and the libs that came with A5 are too old.

So instead I copied the entire /usr/X11 and /Application/Utilities/X11.app over, so I'd have SOME sort of working X11 environment. This worked fine and glxinfo reported accelerated 3d with Radeon 7000.

I tested the three SDL versions, using my source from earlier this year, built with just clean Leopard and XCode, and no macports, so no dependencies on anything. The libs installed in /usr/local:
SDL-1.2's testgl worked fine with acceleration using the cocoa driver.
SDL-2.0.3's testgl2 reported "No displays were added", using cocoa driver (did not test X11 driver).
SDL-2.32.4's testgl2 worked fine with acceleration using X11 driver.

Reported frames-per-second for testgl, testgl2 and glxgears were about the same as on Leopard, which isn't surprising.

Will test similar situation on Intel (try SDL built on Leopard, on Snow Leopard), to see if the 2.0.3 cocoa driver works. That will tell us if the problem is with A5 or with SDL...or as much as can be told that way.

I can't promise I'll look into SDL-2.0.3's cocoa driver, but I might. I really don't like using a beta os where so many things are missing, it's like trying to fix a car while you're driving down the street. I know missing things can be replaced in some ways, but it's still so messy.
 
  • Like
Reactions: barracuda156
This sounds like what I am getting as well.
That's good! Hopefully that means we can then (mostly) count on a few different things then:
1. The official SDL2 source hasn't drifted too far from what I have (probably).
2. Building on Leopard vs building on A5 didn't change anything.
3. The ports build process is similar enough to doing without, so not a compiler or other tool problem.
4. Our hardware being different didn't make a difference.
5. Your X11 version probably isn't a problem (me using a wildly different one doesn't matter).

These were some major variables I was concerned would skew any trusting any test results. I didn't like how many different potential points of failure there were, and this eliminates, or at least makes a lot less likely, a bunch of them.

So, a few things I can do, even still just building on Leopard, so maybe no need for me to have an A5 dev env:
1. I can add a bunch of debug printf's, etc, to the 2.0.3 cocoa driver and see exactly where it is failing on A5. May not be able to fix it, but at least determine why it fails. Guessing it will be OpenGL libs.
2. Test the X11 driver in 2.0.3...forgot to do this. Chances are it will be fine and accelerated.
3. Look at the 2.3x.x cocoa driver for Leopard. I only ever tried "fixing" it on Tiger. Leopard should be "better", but just to gauge how difficult it would be. Could also try Intel Snow Leopard which'd be even "more better", and would tell me what it'd take for A5, even without building on it. (So neither of these strictly has anything to do with A5).
4. Test the same scenario, but on Intel. i.e. try libs built on Leopard on Snow Leopard. This will help with #1 above, as if we see the same thing we know it is more the driver, and less A5.
 
Last edited:
  • Like
Reactions: barracuda156
I don't know if it is of interest to you, but with a bit of hacking I was able to get the Cocoa driver from SDL 2.0.3 to work with SDL 2.32.4, and run with accelerated OpenGL on 10.5.8. It wouldn't be hard to use it with a newer SDL 2.3x.x.

I tested it on A5, and it just printed "INFO" and quit. There is a bug/feature in the SDL 2 logging functions on MacOS X (at least in the SDL 2.32.4 that I have) where it tries to use NSLog, but doesn't do it quite correctly. I believe I had a "fix" to make it use stderr instead (which SDL 2 does on linux) at some point, and will try that again, so I can at least see the error on A5.

EDIT: So I fixed the logging output and you'll NEVER guess what it said on A5! Yep..."The video driver did not add any displays". So, will be adding some debug printf's the hacked Cocoa driver to see what I can see...
 
Last edited:
  • Like
Reactions: barracuda156
I don't know if it is of interest to you, but with a bit of hacking I was able to get the Cocoa driver from SDL 2.0.3 to work with SDL 2.32.4, and run with accelerated OpenGL on 10.5.8. It wouldn't be hard to use it with a newer SDL 2.3x.x.

This is awesome! Please share the patch or make a PR, whichever convenient.

I tested it on A5, and it just printed "INFO" and quit. There is a bug/feature in the SDL 2 logging functions on MacOS X (at least in the SDL 2.32.4 that I have) where it tries to use NSLog, but doesn't do it quite correctly. I believe I had a "fix" to make it use stderr instead (which SDL 2 does on linux) at some point, and will try that again, so I can at least see the error on A5.

EDIT: So I fixed the logging output and you'll NEVER guess what it said on A5! Yep..."The video driver did not add any displays". So, will be adding some debug printf's the hacked Cocoa driver to see what I can see...

I think I saw this phrase or something very similar. Hopefully we find some solution to this, native SDL2 is far more convenient to use.
 
Ok, found the problem with the 2.0.3 Cocoa driver and A5. Bad news is there's a CoreGraphics call that on A5 doesn't seem to work (CGDisplayCopyDisplayMode), good news is you only have to change a single line in the driver. (Tested vs Snow Leopard on Intel, where it does work, so definitely bug/unimplemented in A5).

In SDL_cocoamodes.m:

/* !!! FIXME: clean out the pre-10.6 code when it makes sense to do so. */
#define FORCE_OLD_API 0

Change the 0 to 1, and it will use pre Snow Leopard calls, which work fine on A5 (and, of course, on Tiger and Leopard).

----

I followed your instructions, and used the downloads at https://macos-powerpc.org/installation.html and was able to build both versions of SDL2 on A5. Both 2.0.x and 2.3x.x work with Cocoa and accelerated opengl. (This was just raw source folders, no macports still)

The Cocoa driver I have for 2.3x.x is the 2.0.x one, hacked to work with the newer SDL2, so a wholesale replacement of src/video/cocoa for "modern" SDL2, as opposed to patches. Not sure how (or if!) you'd want to handle/integrate it for the port, I'll leave that up to you. It is a bit of mess currently (debug printfs, etc), and I left some things unfixed, so I'll clean it up, and can just put the whole tar'd cocoa folder as an attachment relatively soon.
 
  • Like
Reactions: barracuda156
Ok, found the problem with the 2.0.3 Cocoa driver and A5. Bad news is there's a CoreGraphics call that on A5 doesn't seem to work (CGDisplayCopyDisplayMode), good news is you only have to change a single line in the driver. (Tested vs Snow Leopard on Intel, where it does work, so definitely bug/unimplemented in A5).

In SDL_cocoamodes.m:

/* !!! FIXME: clean out the pre-10.6 code when it makes sense to do so. */
#define FORCE_OLD_API 0

Change the 0 to 1, and it will use pre Snow Leopard calls, which work fine on A5 (and, of course, on Tiger and Leopard).

Awesome! I will try that.

----

I followed your instructions, and used the downloads at https://macos-powerpc.org/installation.html and was able to build both versions of SDL2 on A5. Both 2.0.x and 2.3x.x work with Cocoa and accelerated opengl. (This was just raw source folders, no macports still)

The Cocoa driver I have for 2.3x.x is the 2.0.x one, hacked to work with the newer SDL2, so a wholesale replacement of src/video/cocoa for "modern" SDL2, as opposed to patches.

This is what the port does as well: https://github.com/macos-powerpc/po...f28c8d04/devel/libsdl2-cocoa/Portfile#L90-L94

Not sure how (or if!) you'd want to handle/integrate it for the port, I'll leave that up to you. It is a bit of mess currently (debug printfs, etc), and I left some things unfixed, so I'll clean it up, and can just put the whole tar'd cocoa folder as an attachment relatively soon.

Great, thank you. I will make a patch on top of official source (i.e. old one, not from the latest backwards, of course).
We still use 2.0.3, right?
 
Ok, this is based on SDL 2.0.3, but should work dropped into SDL 2.3x.x. If it doesn't let me know the version.

For some reason either my browser or the site isn't letting me attach the gzip'd tar files. So I've temporarily added them to the MG page I set up:

"test" is the full changes, but there are a few things related to "drop files" and "touch events" I'm not sure how to test and guessed the code, it is likely correct, but I'm not positive. "safe" includes the code I'm not sure of commented out with "???" next to it.

Because this has been more fruitful, and A5 much more usable, than I expected, I could possibly look into some other things in a similar vein.
 
Last edited:
  • Like
Reactions: barracuda156
FYI, I believe I see the same issue on sl ppc A5 in the Cocoa driver for my copy of SDL 1.2.15 (CGDisplayCopyDisplayMode is failing). This causes the Cocoa driver to not work on A5. Same SDL 1.2.15 source works fine on Leopard and on Intel Snow Leopard.

Let me know if SDL 1's Cocoa driver is working on your A5 machine.
 
  • Like
Reactions: barracuda156
FYI, I believe I see the same issue on sl ppc A5 in the Cocoa driver for my copy of SDL 1.2.15 (CGDisplayCopyDisplayMode is failing). This causes the Cocoa driver to not work on A5. Same SDL 1.2.15 source works fine on Leopard and on Intel Snow Leopard.

Let me know if SDL 1's Cocoa driver is working on your A5 machine.

I vaguely recall is doesn’t, but need to verify.
 
Ok, this is based on SDL 2.0.3, but should work dropped into SDL 2.3x.x. If it doesn't let me know the version.

For some reason either my browser or the site isn't letting me attach the gzip'd tar files. So I've temporarily added them to the MG page I set up:

"test" is the full changes, but there are a few things related to "drop files" and "touch events" I'm not sure how to test and guessed the code, it is likely correct, but I'm not positive. "safe" includes the code I'm not sure of commented out with "???" next to it.

Because this has been more fruitful, and A5 much more usable, than I expected, I could possibly look into some other things in a similar vein.

This is what we had earlier, have you seen it? https://github.com/barracuda156/SDL/commit/03dda56c9840a1c54a2e5b82d1c482c261a6c646

Upd. I guess this is a newer version: https://github.com/macos-powerpc/po...les/0003-Cocoa-adjustments-to-fix-build.patch
 
Last edited:
In SDL_cocoamodes.m:

/* !!! FIXME: clean out the pre-10.6 code when it makes sense to do so. */
#define FORCE_OLD_API 0

Change the 0 to 1, and it will use pre Snow Leopard calls, which work fine on A5 (and, of course, on Tiger and Leopard).

This has fixed SDL2 Cocoa output on A5 image. Great!
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.