So Many APIs

[Nick]

There seems to be many API's to use when developing games for the Mac. As of now I know there is:
-SDL
-OpenGL
-Cocoa
-Carbon

There are probably many more. My question is why? I understand some things like Cocoa uses Objective-C while Carbon uses C++, but is that the only reason? Also, hypothetically, if I was considering developing a game for the commercial market would I just want to use Carbon and make a 3D game engine or use SDL?

I guess the summary of the post is that I am unsure of which API's to learn and what each one does. Currently I am working on making a 2D sidescroller that (graphics and gameplay wise, but not in a game stealing way) resemble Yoink! (which is a great game). I know that it was written using Carbon. If anyone can point me in the right direction and help me out I would be most appreciative.

[skyhawk]

why are there so many different APIs? to suit many different type of people.

[jSTIN]

If you want to program in Carbon, use SpriteWorld. Besides the scrolling is built into it...

[SOUR-Monkey]

Cocoa and Carbon wouldn't be used for making an actual game anyway, would they? They would be used to glue an interface to an engine, not create an entire engine.

I would recommend trying SpriteWorld and SDL, and if they aren't what you want, use OGL. I tried them both, and decided I would just rather use OGL, even with the far steeper learning curve. It's not that bad anyway, but some of the matrix stuff is difficult for me to understand. Maybe reading up a little on matrix math would be a good idea.

[Skorche]

I think that you have a few things confused or are over-generalizing. Cocoa and Carbon are API's, they have code that helps you write a broad range of applications.

SDL is a bit simpler, it really only has enough stuff in it for games. Nothing for user interfaces, and not much for working with files. It focuses more on multimedia, sound, graphics, and such.

OpenGL is just a graphics library. There is GLUT, which is considered a standard part of OpenGL, but it only knows how to work with input and windows.

So for making a Game, you could use Cocoa, Carbon, SDL, or GLUT to handle input. GLUT is buggy on OSX, so it wouldn't be a bad idea to avoid it, and it can only use OpenGL to draw. SDL is your crossplatform option. Cocoa is the easiest way, but using Carbon will make it easier to port to another OS if you don't wan't to use SDL. Now for your drawing, SDL can do drawing, but is probably the slowest option. OpenGL will work alongside with with any of the above, and is really the only option for 3D. From Carbon and Cocoa, you can use QuickDraw or CoreGraphics. OpenGL is always going to be the fastest way to draw, even for 2D.

If this is just making the situation sound more complicated, I would recommend that you stick with SDL for a while. It's simple, well documented, and you can still grow into OpenGL with it.

[LongJumper]

You can definetly make a game using only Carbon, I did it to learn how to use controls and event handlers. It won't be Doom III, but that doesn't make it not fun. :)

[SOUR-Monkey]

What I meant was that if you use Cocoa or Carbon, you probably won't be writing your whole game in it - you will still be using OGL to draw graphics.
The same applies to OGL, you probably wouldn't write an entire game in it. You would still have to use cocoa or carbon to create a window.

SDL, however, could be used to write an entire game. Using SDL without OGL is slow though.

[NCarter]

Currently I am working on making a 2D sidescroller that (graphics and gameplay wise, but not in a game stealing way) resemble Yoink! (which is a great game). I know that it was written using Carbon.
I'm watching you, Mr. Gravelyn. ;)

Actually, to corroborate what others have said, Yoink only uses Carbon for the user interface / application shell code. No Carbon code is called within the game itself (except via various abstractions); only OpenGL is called directly by the game. You could, in theory, rip the game out of the Carbon shell and put it into a Cocoa or SDL shell instead.

[Nick]

I'm just really confused on how to weave all these API's together to create a game. I think SpriteWorld may help but that just doesn't have the feel I want. I'll probably use it to create a couple games but after that I want to step into more advanced programming. Not that C++ code with SpriteWorld isn't simple but I would like to create my own engines and such.

[NCarter]

I'm just really confused on how to weave all these API's together to create a game.
Ideally, your game code shouldn't use very much of any API. Most of my game code is plain C++, along with native C++ features such as the STL (Standard Template Library, not SDL!). I only call OpenGL in my game code because (a) I don't expect to drop OpenGL in favour of something else in the foreseeable future, and (b) it's easier that way.

You know, I think you're thinking too hard about platform issues when you ought to be having fun writing your game. My suggestion is: ignore Carbon and Cocoa, choose one of GLUT or SDL and learn a bit about it, then dive in and start coding in either C or C++ (whichever your prefer). If you discover you want to base your program in another API later on, it isn't very difficult to make the switch providing you ensure that your game doesn't depend too much on API-specific types and functions.

[EDIT: Oops, forgot to say that you should use OpenGL for your graphics irrespective of whatever other graphics tools your chosen API provides. OpenGL is the best choice for almost any kind of game in my opinion.]

[PowerMacX]

Ideally, your game code shouldn't use very much of any API. ...
I agree with everything you said there. :)


[EDIT: Oops, forgot to say that you should use OpenGL for your graphics irrespective of whatever other graphics tools your chosen API provides. OpenGL is the best choice for almost any kind of game in my opinion.]

Especially on Mac, since every mac includes a OpenGL capable graphics card (on the PC side, there are some graphic cards with broken OpenGL drivers)

[Nick]

OK. I plan on using SDL for now. I hear better things about SDL than GLUT. I guess I'm just new to the way programming games all works. I've been reading some books, online docs, and articles but I must've missed something. Most of them say to pick an API like Carbon or Cocoa or they say that they are going to use Carbon or Cocoa so I'm not sure how to do it without them. I do have knowledge of C++ from when I used to program dumb DOS programs. Any advice from anyone about an article that is more non-API oriented? Thanks for all the current and possible future responses.

[skyhawk]

Especially on Mac, since every mac includes a OpenGL capable graphics card
well, every mac from the past 5-6 years

[joephish]

I'll echo what others have said - definitely recommend SDL. Primate Plunge is pure SDL (with SDL_Mixer for sound/music - very easy to use). It was also incredibly easy to port to Windows - basically a matter of creating a new project with the SDL template in windows and sticking the PP source files in, although I'll admit there were a few specific bugs to stamp out.

SDL is very good, just don't expect to do anything toooo graphic intensive in it or you're screwed. But I think finishing a game which runs slowly is better than getting totally bogged down by the complexity of learning OpenGL, and having to fiddle with getting APIs to work etc, as you're afraid of.

I'm currently learning OpenGL and doing pretty well, but it is waaaaaaay harder than learning SDL. I basically snapped up SDL in a few hours.

Hope this helps!

[NCarter]

Most of them say to pick an API like Carbon or Cocoa or they say that they are going to use Carbon or Cocoa so I'm not sure how to do it without them. I do have knowledge of C++ from when I used to program dumb DOS programs. Any advice from anyone about an article that is more non-API oriented?
Most of the things you need to do when writing games are simply generic programming problems, and books on general C++ programming are probably quite good for this purpose. For example, you need to know how to read and write data, how to handle arrays or lists of objects, how to link objects together in various different ways and so on.

I like Scott Meyer's (http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Meyers%2C%20Scott/002-2728923-4958400) Effective... books for this kind of thing. Meyers talks about generalised problems and demonstrates intelligent ways of addressing them. Some of his examples (in 'Effective C++', I believe - I don't have that one) even use games as a concrete demonstration of an abstract problem! These aren't books for absolute beginners, by the way, but they're good for those who are past the basics to learn about better (or 'right') ways of doing things.

Incidentally, books which focus on specific APIs may still contain useful information or ideas about general game programming issues. You just need to learn to filter out the pertinent bits from the stuff which doesn't concern you.

Of course, don't forget that this forum is also a very good place to ask "how do I..."!

I'm currently learning OpenGL and doing pretty well, but it is waaaaaaay harder than learning SDL. I basically snapped up SDL in a few hours.
Funny, I was going to say that OpenGL is pretty easy to use! :lol: It's difficult to set up until you know what you're doing, but once you're into it it's just a matter of drawing stuff in a loop, especially if you don't mind drawing everything in immediate mode like me. I suppose whether or not you find it easy depends upon what you've done before (I learnt QD3D prior to using OpenGL).

[SOUR-Monkey]

<joephish quote>
Funny, I was going to say that OpenGL is pretty easy to use! :lol: It's difficult to set up until you know what you're doing, but once you're into it it's just a matter of drawing stuff in a loop, especially if you don't mind drawing everything in immediate mode like me. I suppose whether or not you find it easy depends upon what you've done before (I learnt QD3D prior to using OpenGL).

I actually find that OGL is easy to set up, but drawing is something I find difficult. Maybe it is because I haven't yet bothered to implement a model loading routine to any of my apps, and so all my calculations are by hand. The thing I have trouble with is calculating surface normals and stuff for lighting, although recently it has started making more sense to me.

A quick question on the side, if I do put in a model loading routing, will most model formats include calculated normals in the file? That would make it easier, as I could just load the model into a list and forget about it...

[joephish]

Funny, I was going to say that OpenGL is pretty easy to use! :lol: It's difficult to set up until you know what you're doing, but once you're into it it's just a matter of drawing stuff in a loop, especially if you don't mind drawing everything in immediate mode like me. I suppose whether or not you find it easy depends upon what you've done before (I learnt QD3D prior to using OpenGL).

Yeah I realise it's pretty easy to use in terms of the overall design... but if you look at specifics like how to load an image, apply it as a texture to a quad and render properly, with lighting, transformations etc, you have to know a lot to do very little!

I suppose I'm comparing my OpenGL experience with my Blitz3D experience, which is complete genius at simplifying the process. (damnit still waiting for BlitzMAX to come out!)

[JustinFic]

I might be a bit of an oddball here, but I avoid using Carbon/Cocoa as much as possible. My goal is to have 100% cross-platform games. The only Carbon or Cocoa you'll see in my source code is there because it's part of the template SDL project.

I personally use OpenGL for graphics, and SDL for pretty much everything else. OpenGL has a bit of a learning curve but once you have it licked it's really easy to play around with. And it only took a day or so to have SDL and SDL_Mixer working in my games.

[NCarter]

Hey, Nick, I just wanted to let you know that I got your email, but I can't give you a detailed response at the moment because my Mac has just died. :(

I might be without Internet access for a few days, too, but I'll try to get back to you as soon as possible.

[Nick]

Ok thanks.