I’m having 2 issues with SDL on mac os x. One has to do with
controllers, SDL reports a failure to intialize if IOHIDIterator cannot
be created. But this isn’t nescessarially true, cause this could also
mean that there are no controllers. So to ffix this I changed Lines 614
to 615 In SDL_sysjoystick for the darwin target from:
SDL_SetError(“Joystick: Couldn’t create a HID object iterator.”);
return -1;
To:
SDL_SetError(“Joystick: Couldn’t create a HID object iterator.”);
return 0;
Which lets SDL programs that would normally fail thinking SDL
failed to continue.
I’m not sure this is the correct thing to do.
My other issue involves the interaction of GLUT and SDL.
glutInit creates an NSApplication and assigns it to the current run
loop. This causes problems because in main, SDL does the same thing.
One way I’ve been able to partially circumvent this issue is to
make SDLApplication a subclass of GLUTApplication and then do a
[SDLApplication poseAsClass:[GLUTApplication class]];
I also have it not execute any of the menu manipulation or nib
loading functions.
This works… kinda. The app no longer dies on glutCreateWindow and
glutInit does not complain that it’s been called twice, but the app is
incapable of any opengl updates. This would also requires a special
version of SDLMain if one would be using GLUT and another if not.
The other way I’ve found is to move some of the handy SDL setup
jazz to my application and then jsut not allow SDL to include SDL_Main.h
or link with SDLMain. This works, but requires a good deal of dirty
hacking I dislike.
The best way I think would be not to initialize an instance of
SDLApplication unless the developer request video to ge enabled, or
opengl. As I’m not sure of how to program for SDL or how it’s
structured. Is this really the best way to go about this?
Sorry for the quick explanation. If anyone wants more details I'll
be happy to provide.
-Corey O’Connor
Lead Programmer
DogHeadBone Software
@Corey_O_Connor
303-929-3517
www.dogheadbone.com