OpenGL SDL "Back-end" for Mac OS X

[DonnyViszneki]

I run Mac OS X. I also have a pretty big monitor. Unfortunately because of the negative synnergy of CPU-blitting games and Mac OS X's modern composition layer, Battle for Wesnoth at my 1792 x 1344 screen resolution ran really slow. In fact, even lower resolutions ran really slow. I was dissatsified. So I decided to see what the current state of the OpenGL "back-end" for SDL was.

Well, Google didn't reveal much, or perhaps I didn't spend enough time looking. At any rate, a regular on the SDL mailing list, David Olofson, had long ago created an SDL wrapper that needed to be dropped in at compile time. There is supposedly a drop-in replacement for the SDL dynamic library being developed. Personally I don't think it's getting much attention since it really wouldn't be that hard to do, and it's supposedly been in development since 2003. So I decided to build Battle for Wesnoth from scratch using this compiler hack written by Olofson.

Let me tell you, it was not easy to get Wesnoth to build on my system. (Do Wesnoth developers on Mac OS X use XCode? I could easily rewrite the configure script to build on Mac OS X. I use an sdl-config hack to build using frameworks without XCode.) But once I finally did, the performance boost was amazing. (Also I got to see some of the newer graphics that have been added since I last downloaded my Mac OS X binary of Wesnoth, they're really good!)

The point of all this is I was wondering what extra steps -- if any -- are used when creating the Mac OS X binary. I want to know because I'd like to donate a binary which uses the glSDL backend written by Olofson. The performance improvement on Mac OS X should have been humungous. But it wasn't. So I decided to take a look at the code.

Well I didn't really have enough time to look through it all, so could anyone tell me if BfW does anything funny like blitting from the screen (dirty rectangles is an example of this) or using intermediate surfaces (an example of that I noticed was having a "map image.")

If I could get a run-down of all this stuff, I could alter the source code slightly and have an excellent hardware-accelerated Mac OS X binary available for everyone. Thanks.

OH ALSO --- Is there a way to turn on an FPS display in Wesnoth? At the 1024x768 resolution, it seemed like there might have been a performance boost, but I have no way of telling definitively.

[Dave]

I'm afraid I don't understand -- was the performance boost large, or wasn't it? One part of your message seems to say it was, and another says it wasn't.

Anyhow, yes, we do use intermediate surfaces in some areas.

You can use the --fps switch to see the frames per second.

David

[DonnyViszneki]

Ugh, I'm sorry. I started writing this whenever I tried it at 1024 x 768. At the time I wrote that, I thought I was seeing a huge performance boost, because I had been playing at 1792 x 1344, and going back to 1024 x 768 was a huge huge difference.

I realized half-way through writing it that I must have been playing at the default resolution. D'oh. So I changed it and saw even less performance than I was before building with glSDL.

Looking at the code it doesn't look like there is that much blitting, so I could hypothetically write a patch to just use OpenGL natively. But if I did this I'd want to be using the CVS version. Can you tell me which CVS module to get?

Sorry again.

[Sithrandel]

I use XCode to produce the packages I make as I always try to produce as Mac-like an application as possible. I also try, wherever possible to keep the core code as pure as possible, with minimal __APPLE__ specific code. This might mean it would run slower in some cases, but personally I believe that is worth it. Of course others may share different views.

If, however, there are alternative library versions / glue code / etc which could be embedded in the application to provide a speed boost, that would be good to investigate.

It is also desirable to have Wesnoth build from the command line for those who like to do so and a number of users have binaries produced in this way

[DonnyViszneki]

Well I build from the command line, but like you, I wanted to distribute "mac like" binaries (which means using frameworks.) My compromise using SDL was to download and install SDL frameworks (had to build my own SDL_mixer framework iirc because the installer on the site at the time was broken,) and I created an sdl-config script that looks something like this:

Code: Select all

#!/bin/sh
for param in $@
do if [ "$param" = "--cflags" ]
then echo -DTHREAD_SAFE -I/Library/Frameworks/SDL.framework/Headers  -I/Library/Frameworks/SDL_image.framework/Headers -I/Library/Frameworks/SDL_mixer.framework/Headers -I/Library/Frameworks/SDL_net.framework/Headers -I/Library/Frameworks/SDL_console.framework/Headers
else if [ "$param" = "--libs" ]
then echo -framework SDL -framework OpenGL -lobjc -framework Cocoa -framework QuickTime /Users/donny/Desktop/SDL-1.2.8/src/main/libSDLmain.a
else if [ "$param" = "--version" ]
then echo 1.2.8
fi ; fi ; fi ; done

As you can see the location of my so-called "SDLmain" is in a queer place, but it gets the job done, and it's okay with me because "SDLmain" gets statically linked anyhow. Using XCode you're probably more familiar with using the NIB.

Anyhow, the second step to creating a mac-like binary is to add a Mac OS X .app target to your makefile. Here's mine from the project I'm currently working on:

Code: Select all

macosx : PengIce.app/Contents/MacOS/PengIce
PengIce.app/Contents/MacOS/PengIce : pengice
        mkdir -p PengIce.app/Contents/MacOS
        mkdir -p PengIce.app/Contents/Frameworks
        mkdir -p PengIce.app/Contents/Resources
        cp -r data/ PengIce.app/Contents/Resources/
        cp -r /Library/Frameworks/SDL.framework/ PengIce.app/Contents/Frameworks/
        cp -r /Library/Frameworks/SDL_net.framework/ PengIce.app/Contents/Frameworks/
        cp pengice PengIce.app/Contents/MacOS/PengIce

You could of course make this the default target if the current platform is mac os x. Personally I haven't done that for my project because I like to keep my .app bundle the same version that I have given to my friends so we can play it together, while the "development" version just windws up in the root project directory.

Also, you could make this target more efficient. My code here will copy the frameworks each and every time I build the "macosx" target. Wheras with another minute of effort you could have it only copy-over the frameworks whenever they need to be updated.

OH one more thing I do, is in my configuration script I define the data directory and things like that. Whereas by default it's just "data," when I build a Mac OS X binary I make it "PengIce.app/Contents/Resources"

Also, for the record I'm not sure if the directory being named "Resources" is a rule or just a convention. Do you know anything about it? Thanks for telling me.

[Sithrandel]

Also, for the record I'm not sure if the directory being named "Resources" is a rule or just a convention. Do you know anything about it? Thanks for telling me.

Resources is one of the key directories if following Apple's guidelines. They are guidelines, but pretty strong. They are all part of making a well behave Mac application. The end user shouldn't be poking around in there much, but unless you have a superb reason for renaming the key directories, don't

Some of the directories have direct impact on the launch process (e.g. difference between Shared-Frameworks and Frameworks)

Of course, sub folders are less critical

[ott]

Great to hear of your success. Have a look at the documentation at the wiki, for instance http://wesnoth.slack.it/?CompilingWesnoth and http://wesnoth.slack.it/?CompilingWesnothOnMacOSX and please consider adding your own comments.

The commandline build currently works out of the box, assuming a few libraries are installed via fink. A patch for the autoconf files would be great: it would be nice to be able to use either frameworks or libraries installed in the library path, by using our own sdl-config if one is not found. However, adding support for the frameworks is going to be futile unless we can rely on some basics, like where they are installed. Unfortunately, as you point out, the SDL framework distribution seems very flaky in this regard.

Perhaps you could also consider submitting some patches to the SDL folks to fix up their Mac framework distributions.

[DonnyViszneki]

Thanks for the advice Ott, I sent it to the mailing list.

[DonnyViszneki]

I can't believe I forgot to mention that I found on the SDL mailing list that on December 23 2004, there was a beta release of the glSDL "SDL backend" that automatically utilizes OpenGL for hardware accelerated blitting by merely linking the library to your application in place of the normal SDL runtime library. It is available here:

http://icps.u-strasbg.fr/~marchesin/sdl ... inal.patch

[ott]

Please also try playing the game with different bpp settings -- the current version in CVS now autodetects a more appropriate bit depth on Mac OS X and doesn't try to run the game in 16 bits anymore. As far as I can tell, the new default of 32 bits is not only better looking, it is also no slower on my hardware, and may actually be faster.