Carbon or Cocoa for Games

[Nick]

Which API do you use and why?

[sealfin]

Neither, SDL (http://www.libsdl.org/); fast, free, easy, lots of documentation, cross-platform, and allows access to OpenGL, lots and lots of plug-in libraries for sound loading/playback, image loading, ad nauseum.

[arekkusu]

Both, depending on what needs to be done. You can freely mix and match the two.

Cocoa is nice for overall app ease of use (events, document architecture, prefs, windowing etc)
Carbon has a native pixel format (ARGB GWorlds) and some useful Mac APIs are still Carbon-only (Quicktime, Resource Manager.)

[Josh]

Cocoa, because I don't see the point of making it harder on myself by using Carbon.

[Steven]

For games, neither - Allegro for cross-platform ability. For other apps, Cocoa, for ease of use and because it's so much more intuitive than Carbon.

[AnotherJake]

Almost all Cocoa for any system UI stuff with plenty of Carbon thrown in here and there as needed for other things like QT. I try to replace Carbon code as Apple comes up with more/better Cocoa for equivalent functionality. 100% daily dosage of C for the actual game code and OGL and OAL for graphics and sound. No Cocoa or Carbon is allowed past my timer callback, so I guess I can't really say I use either for the actual game.

[PowerMacX]

Cocoa, Carbon and SDL!!!
Well, I don't use Cocoa for games directly, but SDL uses it internally. I usually don't use Carbon, but for my entry on CreateMacGames latest contest I had to use speech synthesis and, as usual, while it was easier to set up and use on Cocoa, Carbon let's you control a lot of things not implemented in the Cocoa wrapper (like, for instance, the speed & pitch of the synth. voice).

Now, if I ever make a game wich requires a heavy GUI, Cocoa is the right choice.

[BeyondCloister]

I use Cocoa as I came into Macs at the OS X stage so had no past history pre OS X and hence no need to reuse any existing code.

I also use Cocoa as I enjoy using Objective-C. You may ask why and I will tell you. It makes a nice change from the kind of coding I do in my day job.

[Superpig]

Cocoa, because when I went into #idevgames and said "Can anyone help me get started" mdavis1982 pointed me to his template, which was written in Cocoa. :rolleyes:

[Malarkey]

Cocoa here because my home programming experience on the Mac started with OS X. Though I have played around with SDL and GLUT. And I've been meaning to start learning OpenGL as well.

[Taxxodium]

Cocoa, because I feel it's closer to the system than Carbon (which is not really true, but it's just a feeling I have).

Also, with Cocoa some tasks are easier to code than with Carbon. The only thing that bothers me is that Cocoa doesn't have support for 2D arrays, but that's easily solved.

However, I sometimes use some Carbon functions, for example CGDisplay's functions are very handing, especially when you wanna do fades.

Basically I use Cocoa and C for just about anything, not just for games.

[Josh]

However, I sometimes use some Carbon functions, for example CGDisplay's functions are very handing, especially when you wanna do fades.Technically, I'm not sure CGDisplay functions are part of Carbon but rather CoreGraphics.

[OneSadCookie]

For most games, you'll be using very little of either. They each have their specific ups and downs as far as games go. Personally, I'm not a fan of AGL, so I tend to go with Cocoa, but I wouldn't say that either is necessarily a better choice.

Of course, as soon as you need a standard Mac OS widget, Cocoa wins hands-down.

[DoG]

Which API do you use and why?

The poll is pretty borked. Carbon and Cocoa are not exclusive of each other (au contraire!), and most of the time you will use some parts of Carbon, even if you are coding in Obj-C. Also, just because some API is in C, it doesn't mean it's part of Carbon (QT, OpenGL, for example).

Carbon also contains a lot of stuff for which object-orientation doesn't work well enough to create a Cocoa wrapper.

Cocoa is dependent on the Obj-C language, and vice versa. Cocoa & Obj-C provide a very good object-oriented environment, if OO is your kind of tea. Also, Cocoa has a more advantageous learning curve than Carbon, but in the end you can do the same thing with either API.

Personally, I find Cocoa excellent for UI related things, but prefer to steer clear of Obj-C for performance reasons, hence prefer to code in C++ for core things (despite OSC's crusade againts evil).

[PowerMacX]

The poll is [...] evil

;) That's why I posted (last post, 7 months ago! before this thread resurrected), but didn't vote.

[Hog]

Also, Cocoa has a more advantageous learning curve than Carbon, but in the end you can do the same thing with either API.


yeah, after two years of casual Carbon programming you can do just about as much as with the Cocoa you've just learnt after starting with it a few days ago, which doesn't mean you will be able to do it on the fly.

[iefan]

Personally, I find Cocoa excellent for UI related things, but prefer to steer clear of Obj-C for performance reasons, hence prefer to code in C++ for core things (despite OSC's crusade againts evil).

C++ isn't that much better than Objective-C speed wise. Really, the only thing I'm not a huge fan of it in Objective-C is the brackets for message passing. I don't have a better solution though, so I don't worry about it. As for speed, hand tuned loops in pure C, without any C++ or Objective-C, would be the best. Though with compilers getting smarter and smarter all this crap I learned to make my programs smaller and faster 10 years ago isn't nearly as important.

So what do you do, build your view in Cocoa, your model in C++ and all the controller in C? What a mess, blah. Though you can do it however you wish! :)

[maaaaark]

I program my games in C++ with my Mac specific stuff tied into Cocoa ObjC calls.

[JustinFic]

I use SDL, with some Carbon stuff sprinkled here and there if I absolutely need it.

Another advantage to SDL + OpenGL combination is you are using nearly all cross-platform code. Porting is (almost) a copy-paste deal.

Cocoa rocks for small tools though.

[BinarySpike]

Carbon!

Simply because I HAVE to support 9...
(and I still haven't found time to learn Cocoa)

[skyhawk]

Carbon!

Simply because I HAVE to support 9...

no you don't... If you support OS 9, you're helping the communist win!

[PowerMacX]

Carbon!

Simply because I HAVE to support 9...

Occupation: Hobby programer
:p

[minimum message length filler /]

[Hog]

(and I still haven't found time to learn Cocoa)

if you are using Carbon then you must have plenty of time to learn Cocoa, ... not to think of all surplus time you would have if you used Cocoa.
if you really have to support OS 9 then Carbon is not the best choice either. OS 9 has poor Carbon support. Carbon is pretty crappy on OS 9. (not fully implemented and never will be)

[Corun]

SDL or Cocoa depending on whether I want cross platform or not.

SDL is easy to use. Highly Cross Platform. OpenGLy. Events are easy peasy.
Cocoa is easy to make UIs with. Objective-C. A bit annoying to do GL in but easy if you make a template for it.

Carbon is hard to use. Bad for UIs. Not cross platform. OS 9 is history, it doesn't even run without classic on the new macs. I only use it when there is some specific feature that it has and cocoa doesn't (like better speach synthesis).

Is quicktime part of Carbon? I think of it as a seperate api. But either way, Quicktime is good too :-).

[Duane]

Quicktime is a C API. If apple loves QT and Cocoa so much, they should make it easier for people to use them.

C and Objective-C go hand-in-hand. I like to use C for my OpenGL bits, plus Cocoa for the classes, event, and communication management.

Cool. When did I become a mentor? :???: :D :cool:

[MrBeardsley]

Quicktime is a C API. If apple loves QT and Cocoa so much, they should make it easier for people to use them.

I think with Quicktime 7 that is exactly what they are doing.

[Duane]

good :D I think then we will find much more movie apps other than just "editing" apps, that basically are just apps that allow you to add frames, move sections of movies, etc. think more snapz pro competitors. :D