Sign in to follow this  
  • entries
    375
  • comments
    1136
  • views
    297496

Owee

Sign in to follow this  
superpig

108 views

My experiences thus far with Mac development? Painful.

XCode's fine as an IDE. In fact I've had a play with a number of the tools and it's all good. The problem is with the documentation. Perhaps MSDN's been spoiling me, but the Apple developer network documentation is just a horrible mess. I've more or less given up on the documentation that was installed with XCode (because the search seems useless) and I'm using Google to search the online docs (because the search seems useless).

There's just no shape to it. I've been going through the 'getting started' pages, and it seems like there's at least two ways to make Mac apps - Cocoa and Carbon - but Carbon is described as 'an interface to make porting apps from OS9 to OSX easier.' Does that mean it's legacy? Can I use it? Is it going to prevent me from accessing any system features? Can I mix it with Cocoa? Cocoa's problem is that it appears to be built around window-based applications in Objective-C - can I use it for full-screen games? Can I mix Objective-C with C++ code? Are there performance hits involved? How does Objective-C's message-passing mechanism work under the hood? What happens if I send a message to an object that doesn't support it? All of these are questions that I have not yet found answers to.

I gave up on that after a while and started trying to find docs on more specific components - say, 3D graphics. I know that OpenGL is the graphics API du jour on the Mac, which is fine, I've used OpenGL in the past. As on Win32, there presumably needs to be a set of functions (Windows calls them 'WGL') to tie OpenGL into the rest of the OS's windowing system. What do I find? There seems to be at least three ways of doing OpenGL in MacOS - CGL, or 'Core OpenGL;' AGL, or 'Apple GL,' which is apparently built on CGL; and Cocoa OpenGL, which is class-based and built on CGL. Urgh.

It seems a lot like Linux development, except that the many millions of libraries which all do the exact same thing are pre-installed instead of being scattered around SourceForge.

I'm considering giving up and just using SDL, like I've done in the past... but I'm not using SDL on Windows, so I'd end up having to abstract it (yes, abstract an abstraction). I think I'll pick up the SDL source code and try and figure out how it does things...

Maybe, when I'm done, I'll write an article on all this.
Sign in to follow this  


6 Comments


Recommended Comments

They're evil because they lack easily-usable documentation? O_O

I've found a couple of helpful people over at iDevGames who have kindly provided me with some code to use as an example. I should have fullscreen Pong by the end of the day [grin]

Share this comment


Link to comment
Have you considered using GLFW? I'm using it at the moment for Win32/Linux development, and while I do plan to remove it (at least from the Win32 version) at some future date, it works for now. It should support MacOSX, although I haven't had luck compiling my app on that yet.

Share this comment


Link to comment
Actually, I think I'm sorted. One thing I'm trying to avoid is using some kind of multiplatform abstraction layer, because I'm going to be abstracting platforms *anyway* (and abstractions of abstractions are bad things). I also need to stay close to the metal - as close to the OS as possible, because this stuff is going to be the OS as far as my game is concerned.

Funnily enough, having gotten the OpenGL stuff sorted I'm finding that realtime updates aren't easy (there's a message processing loop, but you're strongly discouraged from implementing it yourself). Looks like I'm implementing multiple threads from the get-go, which is probably not a bad thing [smile]

Share this comment


Link to comment
I've been using xcode for a couple weeks now and I still can't even figure out how to "manually" make an sdl / sdl/opengl project without using the pre-made projects. I tried creating a new c++ project and copying exactly the folders/resources/settings in one of the pre-made sdl projects but it doesn't work. Also, I can't find any info on linking the sdl framework into the executable itself so the end user won't need to install sdl separately. Bah!

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now