We've been encountering many barriers in our attempts to compile our SDL/OpenGL game on Mac OS X. The main development OS is Windows but we've also had no problem building the game for Linux operating systems.

The preferred method of library distribution on OS X is through frameworks, and SDL is no different. Since SDL has several sub-libraries, each in a separate framework, the #include code is different between systems. (The OpenGL #include code is also different, for the record.)

#ifndef __APPLE__
#include <GL/gl.h>
#include <SDL/SDL.h>
#include <SDL/SDL_image.h>
#include <SDL/SDL_mixer.h>
#elseif
#include <OpenGL/gl.h>
#include <SDL/SDL.h>
#include <SDL_image/SDL_image.h>
#include <SDL_mixer/SDL_mixer.h>
#endif

This is all fine and dandy but that actually gives me compilation errors in the frameworks' headers themselves, as they refer to files from other parts of SDL with the assumption they're in the same folder. One could edit the headers but other errors happen then. Since frameworks are the "proper" way of distributing libraries in your application bundles, I'm going to assume that there's just something wrong on my end and not that SDL frameworks are completely unusable by anyone.

In addition, a perturbing problem with OpenGL is that it insists that GLuint is not defined. This is baffling, considering you can go to OpenGL/gl.h yourself and plainly see the typedef of GLuint.

I've been struggling with these issues for a while and I'd appreciate it if someone would be able to help with this.

SDL is not a system framework. You should use quotes instead of angle brackets to include SDL, SDL_image, and SDL_mixer.

SDL has a header file for OpenGL, SDL_opengl.h, that keeps you from having to worry about how to include the OpenGL headers on various operating systems. I suggest including SDL_opengl.h instead of gl.h.

Ah, thank you. Have adjusted my code with both of these in mind.

You haven't said how you are trying to compile your code. Are you using Xcode or are you trying to compile using a makefile? If you are using a makefile, you need to link to the Cocoa framework because the Mac version of SDL uses Cocoa. You also need to add the file SDLMain.m to your Xcode project or makefile. SDLMain.m contains glue code that allows you to compile SDL code on Mac OS X.

Sorry, I'm using Xcode. I am also using SDLMain.m and linking to the cocoa framework.


After making those changes to the code and reading your SDL and OpenGL on Mac OS X article, I'm still getting errors:

Parse Issue
Unknown type name 'GLuint'

Almost all the errors are like this, sometimes replacing GLuint with other things such as Mix_Chunk and SDL_Color... basically any defined data type.

Eventually I get a "Too many errors emitted, stopping now." message.

EDIT: On clean and rebuild I've discovered SDLMain is throwing up a ton of errors related to automatic reference counting mode. I'm going to assume I should be compiling with automatic reference counting OFF -- could someone confirm this for me?

Turns out I was being incredibly dense and using #elseif instead of #else. Now it compiles.

However, now the program is crashing with an EXC_BAD_ACCESS signal at SDL_PollEvent(&event).
If I remove the event handling code, the game runs, though obviously without input.

Also, if I force it to skip the splash screen and start the level, it crashes with an EXC_BAD_ACCESS signal at the call to the encryption library I use to encrypt level and save data (Crypto++).

It's also worth nothing that while the splash screen runs, no sound plays on it.

You most likely have a working directory problem where the game can't find your image, sound, and data files. The simplest solution is to open the SDLMain.m file and change the working directory to your app bundle's Resources folder. More detailed information on changing the working directory is in the following article:

SDL Tips for Mac OS X

I'm not really sure what to do with the code in that article. Objective-C confuses the heck out of me.

Though for what it's worth my resources are actually loading, or at least the images are -- on the splash screen, if I disable SDL_PollEvent, I see the splash screen as it would normally display.

I of course still would like to figure out where to put that code, as having the resources in the app bundle would be quite preferable.

Here's my setupWorkingDirectory code:


/* Set the working directory to the .app's parent directory */
- (void) setupWorkingDirectory:(BOOL)shouldChdir
{
if (shouldChdir)
{
char parentdir[MAXPATHLEN];
CFURLRef url = CFBundleCopyBundleURL(CFBundleGetMainBundle());
CFURLRef url2 = CFURLCreateCopyDeletingLastPathComponent(0, url);
if (CFURLGetFileSystemRepresentation(url2, 1, (UInt8 *)parentdir, MAXPATHLEN)) {
chdir(parentdir); /* chdir to the binary app's parent */
}
CFRelease(url);
CFRelease(url2);
}
}

[stuff]

Thank you!




So, here's an update. I noticed something interesting in the GDB logs: http://pastie.org/3772361

This happens when SDL.framework is located in both /Library/Frameworks and the application bundle.

If I remove SDL.framework from /Library/Frameworks, the game refuses to open, OS X complaining that the game's not compatible etc etc.

If I remove SDL.framework from the application bundle... the game runs! Until it crashes at Crypto++, anyway (keep in mind that's a statically linked library, not a framework, as that's all I could find for it on OS X).

EDIT: I've narrowed the problem child down to just SDL.framework... the SDL_* frameworks all work just fine.

EDIT 2: Manage to fix Crypto++. So, now all we have to do is get SDL.framework to play nice...