Is there a patch for that? At the moment I’m considering to mix match
old and new code for PPC and intel binaries but this way sounds
interesting for older intel systems/OS X, too.
There is, but I was waiting for him to post it because I’m not in a
position to answer questions about it. It’s been long enough, I’ll track
it down and post it anyway. Might be a few days.
Update: he says he sent it to this list, but it’s still awaiting moderator
approval!
ok, did the bisecting and got to the result (english translation in brackets):
Die erste fehlerhafte Revision ist (First faulty revision):
?nderung(Changes): 5619:8e0dd46ad0e0
Zweig(Branch): SDL-1.2
Nutzer(User): Ryan C. Gordon
Datum(date): Sun Aug 21 10:10:42 2011 -0400
Zusammenfassung(changelog): Don’t allocate a new NSGraphicsContext on every call to QZ_UpdateRects().
I hope this helps, apart from it misbehaving for Exult, I got a report from someone building Dosbox with the same screen of white/gray.
When I revert that change to src/video/quartz/SDL_QuartzVideo.m in current merc, the white/gray screen is no more and instead correct display.
Ryan, since this is working for you, any idea what Exult or Dosbox might do wrong that it doesn’t work there? Or other way round, which test program that comes with SDL to test this with?
To revive this thread, is there a recipe to persuade this to compile under XCode 4.x under Lion? Right now, it throws a fit because of missing project requirements : the 10.4u SDK and GCC 4.0.
To revive this thread, is there a recipe to persuade this to compile
under XCode 4.x under Lion? Right now, it throws a fit because of
missing project requirements : the 10.4u SDK and GCC 4.0.
You could just bump the SDK versions in the project settings, but it
might not be as trivial as I’m suggesting it is. I imagine we have the
10.4u SDK path hardcoded somewhere, whereas modern Xcodes offer a simple
setting that handles all that for you.
Another option is to use build-scripts/fatbuild.sh, which will get you a
Universal Binary that supports 10.4 on PowerPC and x86, and 10.6 for
x86-64 (and will notice that Xcode4 doesn’t include PowerPC support and
remove just that target from the Universal Binary…building with Xcode
3 will include the PPC support).
To revive this thread, is there a recipe to persuade this to compile
under XCode 4.x under Lion? Right now, it throws a fit because of
missing project requirements : the 10.4u SDK and GCC 4.0.
You could just bump the SDK versions in the project settings, but it
might not be as trivial as I’m suggesting it is. I imagine we have the
10.4u SDK path hardcoded somewhere, whereas modern Xcodes offer a simple
setting that handles all that for you.
Another option is to use build-scripts/fatbuild.sh, which will get you a
Universal Binary that supports 10.4 on PowerPC and x86, and 10.6 for
x86-64 (and will notice that Xcode4 doesn’t include PowerPC support and
remove just that target from the Universal Binary…building with Xcode
3 will include the PPC support).
I’ll try that script, but assume it will fail unless I can force it to target 10.6 for x86. There’s no 10.4u support on Lion without the 3rd party hack to pull GCC-4.0 and 10.4u from XCode 3 into XCode 4. If it doesn’t work, I’ll try the 3rd party XCode 4 hack
I tried adjusting the project settings for the project in XCode 4 earlier today, but was unable to dislodge the, seemingly embedded, references to 10.4u and GCC-4.0. Puzzling.
It’s actually fairly easy: Just update the SDK to a more modern one and remove the various compiler flags (I believe they’re marked as “Obsolete”) and things should compile fine.
It’s actually fairly easy: Just update the SDK to a more modern one and remove the various compiler flags (I believe they’re marked as “Obsolete”) and things should compile fine.
I tried, but XCode wouldn’t let me. I see a bunch of user defined settings that seem to be impossible to delete. I used the ‘verify build settings’ option to try and clean it all up, but whilst XCode tells me everything is fine, the project whines about GCC-4.0 and 10.4u references.
It’s actually fairly easy: Just update the SDK to a more modern one and remove the various compiler flags (I believe they’re marked as “Obsolete”) and things should compile fine.
I tried, but XCode wouldn’t let me. I see a bunch of user defined settings that seem to be impossible to delete. I used the ‘verify build settings’ option to try and clean it all up, but whilst XCode tells me everything is fine, the project whines about GCC-4.0 and 10.4u references.
Well, I could delete those easily when I tried… I’m not in front of my Mac right now so I cannot say but when I get to it I’ll test it again and report.
Just a silly question: you tried deleting them both with righclick->delete and with the backspace key, right?
It’s actually fairly easy: Just update the SDK to a more modern one and remove the various compiler flags (I believe they’re marked as “Obsolete”) and things should compile fine.
I tried, but XCode wouldn’t let me. I see a bunch of user defined settings that seem to be impossible to delete. I used the ‘verify build settings’ option to try and clean it all up, but whilst XCode tells me everything is fine, the project whines about GCC-4.0 and 10.4u references.
Well, I could delete those easily when I tried… I’m not in front of my Mac right now so I cannot say but when I get to it I’ll test it again and report.
Just a silly question: you tried deleting them both with righclick->delete and with the backspace key, right?
Yes No error was shown, but nothing was deleted. Yay for XCode!
I tried the build script and get this (presumably towards the end of the process) :
Generating dependencies for …/…/src/cdrom/macosx/SDL_syscdrom.c
Generating dependencies for …/…/src/timer/unix/SDL_systimer.c
make: Nothing to be done for `all’.
sh: ./…/build-scripts/mkinstalldirs: No such file or directory
lipo: can’t create output file: .libs/libSDL-1.2.0.dylib (No such file or directory)
Yes No error was shown, but nothing was deleted. Yay for XCode!
I tried with a fresh pull from the repository. That went better. The trick seems to be to select the very top level of the project, not the individual targets. You can then remove these user-defined settings and the build then seems to complete with no fuss. Thanks for the suggestion that it ought to be easier - it made me take another, closer, look.
I got the shell script to work as well by manually creating build/.libs. It seems that, for some reason, the script doesn’t manage to do this itself.
Hmm. So I have the framework compiled and dropped it into place. The game now fires up, but all of the colours are screwed up. The game uses SDL_image 1.2.7 because anything later than that causes sprites to no longer load (I still need to bisect that and see what change caused that - I’m guessing something to do with ImageIO, but cannot be sure). Nonetheless, this used to run fine under SnowLeopard with the ‘final’ SDL 1.2 release. Did I overlook something that would cause this glitch?
I’ll try that script, but assume it will fail unless I can force it to
target 10.6 for x86.
fatbuild uses the newer SDK, but targets 10.4 (as opposed to what the
Xcode project is doing right now, which is hardcode the path to the
10.4u SDK and thus target 10.4 by default).
No error was shown, but nothing was deleted. Yay for XCode!
