The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

So I just pushed a patch for 1.2 that does some serious surgery, but
should fix the incompatibility with Lion.

This was a much bigger change than I wanted it to be. I would appreciate
if people would test this against their projects, 2D and 3D, both on
Lion and earlier versions of Mac OS X.

Reports of success and failure are welcome.

If you aren't using Mercurial, here's a .zip file of the current source
code:

http://treefort.icculus.org/SDL/SDL12-lion-compatible.zip

If you're using Mercurial, just run "hg update SDL-1.2" to get the
latest 1.2 code (and "hg update default" to go back to 1.3).

Thanks!

--ryan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Sun, Jul 17, 2011 at 6:16 AM, Ryan C. Gordon wrote:

I tested this on Snow Leopard 10.6.8 with my game Classic Invaders
which is 2D and uses software surfaces.

In fullscreen mode there was a problem, the screen appears to be
pushed down (see the screenshots at the links provided). I verified
that this doesn't happen
with 1.2.14.

http://www.noquarterarcade.com/images/screenshot-latest-SDL.png
http://www.noquarterarcade.com/images/screenshot-SDL-1.2.14.png

--
Todd Steinackle
http://www.noquarterarcade.com/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Tested on Snow Leopard 10.6.8 on my about-to-be-released game Midnight Mansion HD, and it works fine as far as I can tell. At least on my Dual Core 2 system. (non-64 bit) I don't see any "pushed down" issue when fullscreen. Works just as well as the former Mercurial 1.3 release from a few days ago.

Snow Leopard 10.6.8

My system can't run Lion, so sorry, no idea how it does on that.

EDIT: My bad, just realized you wanted us to test 1.2. I am running 1.3. I'm guessing 1.3 was already compatible with Lion?

hey,

I'll run the pygame test suite through it tonight on snow leopard.

cheers,




On Sun, Jul 17, 2011 at 11:16 AM, Ryan C. Gordon wrote:

Hmm, I bet this is because [NSWindow center] doesn't _actually_ center
the window (Apple decided it was more visually pleasing to be slight
off-center vertically).

I'll take a look.

--ryan.



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This is fixed now in Mercurial, thanks for pointing it out!

--ryan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

this is the error when building with xcode 4.1 on Lion.
[BEROR]error: There is no SDK with the name or path '/Developer/SDKs/MacOSX10.4u.sdk'



I changed a few things in the settings of the xcode project to do with the version of gcc, and got it to compile.

I also found the old SDKs in /Developer-old/SDKs which I symlinked in.

When building Standard DMG I get this at the end...
"""Error Starting Executable 'Standard DMG'
No executable file specified.
Use the "file" or "exec-file" command."""


Maybe if I linked the gcc-4.0 from there in it could work too.  Not sure.


Dropping the new SDL.framework into /Library/Frameworks, instead of the old one fails with my old install of pygame.

I'm still having troubles getting pygame to compile with the new SDL that I made, but I'll report back once I've got it working.


cheers,



On Tue, Jul 19, 2011 at 4:37 AM, Ryan C. Gordon wrote:

Tested 5576. 2D and 3D seem to work OK in Lion and Snow Leopard. 2D frame rate is much lower, in the mid 20's trying to blit 1440x900 on a core i5. Unfortunate but not surprising.

In Mac OS X 10.4.11, the screen is extremely misaligned vertically after switching from 640x480 to 1024x768 on my PowerBook G4, 2D mode.

Gregory

On Jul 17, 2011, at 6:16 AM, Ryan C. Gordon wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

the 569 pygame tests pass on OS X 10.7.

I haven't compared the speed to previous versions, or done any manual testing.

cheers,





On Fri, Jul 29, 2011 at 2:44 AM, Gregory Smith wrote:

Tested with Exult and xU4 (for which I needed to build the framework).
Works fine on Lion and SL.
DOESN'T work fine on PPC Tiger, fullscreen is misalligned, not centered but alligned downwards with the lower half not showing.

Apart from this error, are there any plans for releasing SDL 1.2x anymore?

Big problem now with code checked out just two hours ago.
Going into fullscreen in Lion, Leopard and Tiger (PPC) doesn't "work", meaning the screen goes gray. Switching back to windowed mode will leave the game window gray :(

The working SDL-1.2 branch (and binary from that date still works correctly) is from July 30th. Something in between killed it

how do I move "back in time" with mercurial so I can track which change killed it?

On 8/26/11 4:27 PM, Dominus wrote:

"hg update CHANGESET"

Where changeset is a Mercurial changeset id, like "cf638ceb1f2c" (which,
btw, might actually be the specific changeset that caused the problem).

You might also want to read "hg help bisect", which automates narrowing
down a range of revisions until you find the one that introduced the bug.

Fwiw, fullscreen is working on Lion here, but I haven't tested older OS
versions.

--ryan.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.

On my PPC machine I'm still having the fullscreen issue I wrote about above.
see http://imageshack.us/photo/my-images/192/windowp.png/ for the windowed mode and http://imageshack.us/photo/my-images/593/fullscreenq.png/ for what it did to the fullscreen mode (I'm controling my Tiger through remote desktop, that's where the icons in the fullscreen image come from). It worked correctly before the Lion fullscreen fixes landed.

On Aug 26, 2011, at 6:47 PM, Dominus wrote:


My colleague ended up putting checks in to use the old code path pre-Lion, and the new fullscreen code only when running in Lion. This also avoids the tremendous speed hit with the new code path on older machines.


Gregory

Sigh, we'll have to do that too, I suppose.

Apple's tactics to force you to stop supporting older OS releases are
starting to feel welcome. :)

--ryan.



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yes, one can see what that is good for sometimes ;)

I forgot to mention, that the PPC problem seems to only show on real PPC machines, running it under Rosetta fullscreen showed the full screen (though take that with a grain of salt, since that was on Leopard running in a VM).

And I forgot to say thanks for pointing me at hg bisect. Thank you

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.

On Sep 2, 2011, at 2:06 PM, Dominus wrote:



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.


Gregory

Hello,

a trackpad Lion issue is has been reported:
    https://bitbucket.org/pygame/pygame/issue/79/pygame-incompatible-with-osx-lion-trackpad#comment-639548

"I recently upgraded to lion from snow leopard. Pygame worked very well with SL, but with the new enhanced features of lion's trackpad, the pygame mouse module doesn't seem to work very well.
The first time I click pygame.mouse.get_pos() works correctly, however any subsequent clicks (even though the event.type passes MOUSEBUTTONDOWN criteria) do not show an updated mouse position. A double tap seems to reset this behavior. Is it something wrong with my pygame configuration? Or is it to do with pygame mouse module itself?"
Is anyone else able to test with a trackpad and Lion?  My trackpad seems to work on an old model macbook pro... but I know the new trackpads are quite different, so maybe that's the issue.


cheers,



On Sat, Sep 3, 2011 at 1:42 AM, Gregory Smith wrote:

On Fri, 2 Sep 2011, Gregory Smith wrote:


Update: he says he sent it to this list, but it's still awaiting moderator
approval!

Gregory

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Thanks for the update, Gregory.

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.

I'm aware that there's an option in https://github.com/thinkyhead/Legacy-XCode-Scripts, but wondered if that was the best way forward.

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).

--ryan.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Thanks for the speedy reply.

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 :D

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 a few compiler flags (I believe they're marked as "Obsolete") and things should compile fine.
You might also need to change the compiler to the system default one.

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)

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?

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).

--ryan.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org