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.

Jeremiah sent this patch for improved Lion support to the list back in
August, and it still hasn't been approved. Let's see if I can get it
through.

Gregory

Begin forwarded message:



_______________________________________________
SDL mailing list

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

Thanks, I'll give it a try tomorrow.

I just merged this with the rest of the Lionizing work (is that even a
word? It is now!), and put it in revision control. It's hg changeset
6b62ce1bff72.

I completely forgot to credit Jeremiah in the commit message (for which
I apologize).

I've only tested this on Lion. I imagine we'll need another patch or two
to get this solid everywhere, as the 1.2 Quartz target has become a
rather nasty pile of #ifdefs and APIs in various states of deprecation.
Buildbot isn't too upset with it, but I'll test it on other machines soon.

I would encourage others to test it, too. If you've had problems, this
might solve them. If you didn't: maybe now you do. Please test and
report back!

(my quick-and-dirty testing methodology looks like this:

cd SDL-1.2/test

./testgl
./testgl -fullscreen
./testalpha
./testalpha -fullscreen

)

Thanks,
--ryan.

_______________________________________________
SDL mailing list

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

Hi,

I'll test it tonight on my Lion laptop with the pygame unit tests.

cheers!



On Wed, Sep 14, 2011 at 2:52 AM, Ryan C. Gordon wrote:

hmm, ran into some problems. First of all Exult still has problems with the white screen on switching to fullscreen and back as reported in the other thread. Curiosly dosbox doesn't have that problem anymore but then I'm compiling and running Dosbox in 32bit mode if that changes anything.
Except for the white screen issue, Exult runs fine in 64bit on Lion. My 32bit compile crashes on Lion. Same with my Pentagram 32bit build
Curiosly, Dosbox, Exult and Pentagram display (on the terminal) "CGDisplayBaseAddress is obsolete and returning NULL for display 0x42801c0" when switching to fullscreen. So it seems the 32bit build is again having THAT problem. Why it doesn't crash Dosbox now is beyond me.

Further information:
SDL, Dosbox, Exult and Pentagram have been built with gcc 4.0 against the 10.4 SDK (since building it for 10.6 or 10.7 SDK doesn't produce 32bit binaries that run on 10.5 for some reason).

I just put some fixes in revision control that might resolve this; let
me know if it's better for you.

--ryan.

_______________________________________________
SDL mailing list

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

I'll be able to test a bit later. Thanks.

Still the whiteness issue remains. This change set caused it http://hg.libsdl.org/SDL/rev/8e0dd46ad0e0

I *think* the reason you don't see it is because it only happens on *changing* surface fullscreen/windowed mode. AFAIKT the SDL test programs that could showcase it only have the option to start in either mode but not change the mode while running. When I start Exult, Pentagram, Dosbox in fullscreen or windowed mode I don't get the whiteness, only when I change the mode while running do I see this.


(note my above puzzlement that Dosbox didn't crash on fullscreen nor showed the whiteness was because Dosbox was using OpenGL output mode - in surface it behaves as expected, crash in 32bit and whiteness in 64bit mode)

Okay, I'll look into that, too.

--ryan.

_______________________________________________
SDL mailing list

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

ok, tested the new code. Unfortunately this time with this SDL Exult only ran in 32bit mode on the SDK system it was built in 32bit mode for (I'm running Leopard and SL in a VM). Otherwise the console message is *Unable to initialize SDL: Couldn't figure out current display mode.*
When I built Exult against 10.5 SDK it ran in Leopard (but refused to run on Lion and SL).
Something strange.

Another thing I noticed before with the other build, Exult would behave very very slow in fullscreen in the VMs. I only noticed that because it ran quite fine with earlier SDL code in fullscreen (I keep snapshots so I tested it right now).

the culprit is the if FORCE_OLD_API stuff. When I add this back the 32bit builds start again, but will crash on Lion as they are using the deprecated stuff

Btw, I just tried the patch by Gregory/Jeremy and with that I don't have these problems (except the whiteness bug). 32 bit build seems to work fine and doesn't crash on switching to fullscreen. Gonna try how the ppc and 64bit build will behave now.
The patch needed some manual work, especially line 150 (goto ERR_DOUBLEBUF;) needed commenting out because it wouldn't compile as it wasn't defined before. So whatever that does, it won't do anything right now

the only problem I found with Jeremys patch is that the 64bit build crashes when going fullscreen on SL.

The white screen is now fixed, in hg changeset 6e618c16a861.

--ryan.

_______________________________________________
SDL mailing list

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

On 9/15/11 3:48 PM, Dominus wrote:

I removed the FORCE_OLD_API stuff in revision control last night (hg
changeset fc557e459527); are you still having problems?

--ryan.

_______________________________________________
SDL mailing list

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

Yes, my post from the 14th was referring to that. Without the force old api stuff, all the 32bit builds won't start on Lion, failing to init SDL.

Ok, this should _all_ be fixed in revision control now.

Here's what I did:

- Built SDL, testalpha, and testgl as x86 with the 10.4u SDK.
- Ran it on 10.4, 10.5, 10.6, and 10.7.
- Ran ./testalpha, and then hit "t" to toggle fullscreen/windowed, back
and forth, to make sure both transitions worked.
- Same test again, but with ./testalpha -fullscreen
- Run ./testgl, make sure it works.
- Same thing, but with ./testgl -fullscreen.
- Same thing, but with ./testgl -sync
- Same thing, but with ./testgl -fullscreen -sync
- All of the above, but built with x86+10.7 SDK and run on Lion.
- All of the above, but built with x86_64+10.7 SDK and run on Lion.

...and this is all working!

I have not tested any PowerPC builds (so no 10.3 or lower, either). I
don't really care at all about these. If someone cares and there's a
problem, please report it.

I also didn't run testgl with toggling windowed/fullscreen. You can see
what I did in testalpha and replicate it if you have a problem there and
need a test case:

http://hg.libsdl.org/SDL/rev/b442dbd2b6be

I think the only problem that might still be pending is Exult having a
strange offset for video rendering. Let me know if that's still busted, too.

--ryan.

_______________________________________________
SDL mailing list

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

I'll be able to test this evening or maybe tomorrow (CET). But thanks for the hard work on this. I hope everything works fine and I don't need to bug you again

ok, tested and works almost fine, except that the x86_64 built on Lion (SDK 10.7 or 10.6 - tried both) crashes on Snow Leopard on switching to fullscreen with a segfault. This used to work with hg when the fullscreen Lion fix was for all OS X platforms.

Further report:
If I compile both SDL and Exult against SDK 10.6 x86_64 built works fine in fullscreen on both Lion and SL. A built against SDK 10.7 (both SDL and Exult) *used* to work on SL as I wrote earlier.

With SDL's testalpha I made the same test. SDL and test alpha compiled against SDK 10.7 makes test alpha -fullscreen crash on SL with a segfault.

I *can* live with building against SDK 10.6 to make a compatible snapshot, I still wonder though, as it used to work whether it can be made to work again.

On Fri, 16 Sep 2011, Ryan C. Gordon wrote:


Ryan,

That's great to hear. We've got too much going on to test this right
now--we're going with the patch I forwarded for our upcoming release. But
right after that I will try this out. We still have some PowerPC users to
support, so I'll let you know how that goes too.

Thanks for spending time on what must seem old and broken after working on
1.3 :)

Gregory


_______________________________________________
SDL mailing list

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

Gregory, as I wrote earlier in this thread, Jeremys patch also has problems with x86_64 builds on Snow Leopard. To avoid this both SDL and your app need to be build against the 10.6 SDK *if* you build it on Lion. Otherwise it will crash on going fullscreen on Snow Leopard. Also Jeremys patch seems to be incomplete, missing the ERR_DOUBLEBUFF define, probably in SDL_QuartzVideo.h.

Are you specifying a minimum SDK version when you build with the 10.7
SDK, or just building against 10.7?

If you don't tell it you want backwards compatibility, then SDL is doing
the right thing and dropping the pre-10.7 support. The build compiled
against the 10.4 SDK happens to work with 10.7 because of (mostly)
forward compatibility.

You should add this to your SDL build command line...

-mmacosx-version-min=10.4

IDEALLY, you build against whatever the newest SDK you have is, and tell
it that you want to target as far back as 10.4 (in practice, this
doesn't work, because using a newer SDK inserts Mach-O load commands in
your binary that fail on older releases...the true solution involves
figuring out how to stop that from happening and then never looking at
the 10.4 SDK again).

--ryan.

_______________________________________________
SDL mailing list

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

I'm using that for the PPC and 32bit build (where I found out the other day that using the 10.5 SDK and specifying minimum SDK 10.4 works fine). The 64bit builds I did with just pointing at my prefix in the cflags and lflags and curiosly that used to work before for 64bit SDL and 64bit builds of the apps I do snapshots for. That's why I was surprised that this broke suddenly.
But what you wrote makes sense, probably I encountered a fluke before
So I'd better use the minimum SDK in the future. Got to try out how the 10.7 SDK works with min version 10.6 on OSX 10.6. The 10.6 SDK didn't fare to well on OSX 10.5 when I tried that.

Thanks for the explanation.

Dom

Btw, I'm using the forum to write and wonder if my replies are looking ok on the ML or whether I should follow some guidelines to make them more readable on the ML (since I presume that Forum posts are posted to the ML as well).

We're pretty aggressive about removing deprecated APIs now, so if you're
using the 10.7 SDK and don't explicitly ask for compatibility with
earlier versions, we #ifdef out deprecated functionality. This is fairly
new for SDL, but since Apple made that one thing in 10.7 not just
deprecated, but a definite crash, we're trying to protect against these
sort of things now. This wasn't something we've tried before this last
round of Lion fixes, though.

BTW: the thing about the Mach-O load command that doesn't work on older
OSes? It turns out you need to use -mmacosx-version-min=10.4 on the
linker command line too. I just built a Hello World app against the 10.6
SDK, with Xcode 3.2, which causes this problem when you run the app on
10.5...if I make sure it links with that command line, the problem goes
away. Which--pending more testing--might mean it's safe to move to 10.7
and Xcode 4, even if you still need to target Mac OS X 10.4.

(I can't speak to PowerPC support here, though.)

(Also, my apologies to Apple, because I've been blaming them for months
over something that seems to be fixable with a command line argument.)


I'm using the mailing list exclusively, and it looks fine here.

--ryan.


_______________________________________________
SDL mailing list

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

Thanks, that explains it nicely

Got to try this out. I *think* I did use that on the linker line before, too, when compiling Exult. But then probably ran into an incompatibility because I had compiled SDL against a different SDK. So I never succeeded in compiling Exult in 32bit against SDK 10.6 and now 10.7 and being able to run it on 10.5.
Will try now more thoroughly :)


Yup, for PPC you do need Xcode 3.2x in some folder, point to the old compiler and you need to define --host=powerpc-apple-darwin on configure for everything you want to compile in ppc. Xcode 4 itself cannot be made to compile ppc code at all, if I'm not mistaken...

hmm, that failed. Seems that Exult links to libstdc++ and when I compile it against SDK 10.7 on Lion it expects something on Leopard in /usr/lib/libstdc++.6.dylib which isn't there
Of course on Lion it compiles against libstdc++.6.0.9 but on Leopard you have libstdc++.6.0.4
Dyld Error Message:
Symbol not found: __ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i
Referenced from: /Users/hansdampf/Desktop/Exult.app/Contents/MacOS/exult
Expected in: /usr/lib/libstdc++.6.dylib

Just to give another data point, we ran into this issue as well a few days ago. We were unable to link our app under Xcode 4 without removing the CGLSetFullScreen() call. Building the app with Xcode 3.2, even on a Lion system, was okay and the resulting binary ran fine on Lion systems. In our case, the original and tweaked SDL libraries were built with Xcode 3.

In testing our app (Aleph One), we found that the Lion-compatible fullscreen method was much slower on older systems than the CGBaseDisplayAddress() method. So, we put together a version of SDL_QuartzVideo.m that only switches to the new code path on Lion systems. This may be helpful for others who experience the same performance problems we did. Patch is attached against 5574, or you can grab the entire file at:

http://www.whpress.com/aleph/SDL_QuartzVideo.m

Thanks for your updates to this branch! It was a big help in getting our app working properly again under Lion.

- Jeremiah


_______________________________________________
SDL mailing list

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