Carbon vs Cocoa?

Member
Posts: 129
Joined: 2009.03
Post: #1
What are the implications of using Carbon vs Cocoa? (for Mac game development).

The bulk of my game code will be c/c++, and so I'm inclined toward Carbon. But, are Apple phasing Carbon out?

Quote:The development of Mac OS X APIs reflect that of the underlying operating system. Mac OS X is written mostly in C and Objective-C. In particular, Objective-C is ubiquitous in the human interface systems. With Mac OS X v10.5, after a transition where new elements of the Carbon interface specifically referred to the underlying Cocoa system, Apple identified Objective-C and Cocoa as the preferred interface to human interface services. Carbon access to various human interface services in the 64-bit operating environment is not available, and significant new features will not be added to the 32-bit Carbon interface.[4] Most other parts of the system, which have less emphasis on Objective-C, are not so affected.

Does this mean Carbon Apps will not run on 64-bit systems? (maybe I'm being a bit dim here).

So, is it safe (and future-proof) to use Carbon, for Mac game development?

I also have another consideration, with iPhone development, it's a requirement to use Cocoa, and so Carbon is not an option? Is that correct?

So, is it possible to develop a portion of a (Mac or iPhone) game in Cocoa, and have the bulk (game logic etc) in c/c++?

Thanks.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #2
These are good questions.

Your game being all C/C++ has nothing to do with using Cocoa. You would typically only use Cocoa for the OS GUI stuff like basic windowing and menus, etc., and that's all. The rest of your game can remain pristine C/C++.

Cocoa is much much easier to use than Carbon. It doesn't take that long to learn Objective-C, but the Cocoa API takes a little longer to learn your way around. It's much harder to learn and use Carbon in the long run. Most of us ditched Carbon a long time ago -- even those of us who knew how to use it from prior experience. Very few are hanging onto Carbon these days; mostly just the guys who have been programming Macs for twenty years and either find Obj-C/Cocoa disgusting, or haven't convinced themselves that they have the time to learn the new stuff, or come from Windows and think it looks most familiar.

On iPhone, there is *very* little Cocoa needed, and most of that can probably be cut and pasted. Again, the rest of your game can remain pristine C/C++.

It is not recommended that you use Carbon for new application development, because Cocoa is preferred, as that quote already points out. Carbon can't be used for 64-bit apps if you use it for GUI, but it runs on all systems (just not in 64-bit mode). At this point, running in 64 or 32 bit mode isn't really all that big of a deal for the most part. Most apps are still running in 32 bit mode. I've had some improvements in performance from time to time in 64 bit mode, but I wouldn't be worried about it too much right now. Maybe not a good thing into the future though, but I don't have a crystal ball.

So all those things are probably not turning you on because you've looked at Objective-C and Cocoa samples and said, "screw that", right? Well fear not. If you want a supremely native Mac look and feel for all your menus and buttons and other widgets, then yes you should learn Cocoa, but if all you're doing is a game, then I would highly recommend you look into a pre-made windowing framework such as SDL. SDL handles all the dirty details of getting your environment set up for you so you can focus on your game(s) -- no Cocoa or Carbon involved on your part. Smile
Quote this message in a reply
Member
Posts: 194
Joined: 2009.02
Post: #3
Jamie W Wrote:So, is it safe (and future-proof) to use Carbon, for Mac game development?.

Considering the abrupt manner in which apple phased people over from os9 to os x, and how quick they were to effectively deprecate Carbon, I would have to say no, it's not safe. They clearly want to do away with it for good, so it's really just a matter of time.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #4
"Carbon" is a big word. Its an umbrella for many APIs, some of which are more outdated than others. Apart from that, you'd probably do yourself a favour by learning ObjC anyway.

I have no idea what NelsonMandella is getting at, since the transition was an effective seven or eight years from OS9 to OSX, and you'd probably still have support for running a classic VM if it wasn't for the Intel switch. And again, Carbon isn't deprecated as a whole, but some legacy APIs are simply not carried over to 64bit-land.
Quote this message in a reply
Member
Posts: 129
Joined: 2009.03
Post: #5
Many thanks for all your responses.

Yeah, I did look at a few Cocoa code samples, and the Objective-C was unfamiliar to me, and is probably what's driving me towards Carbon..

However, considering that I wanna do iPhone stuff too, I will need to learn some Cocoa and Objective-C anyway, so that's probably the best option for me on Mac too.

I'm in the process of developing my own game engine API thingy, so I can abstract away all the DirectX (on win32), OpenGL and OS stuff (setup windowed or fullscreen mode etc) away from my game. In theory, the bulk of the c/c++ game code will be interchangeable with the Windows (and other platforms) version of my games.

So, probably looking at bare minimal use of Cocoa..

I'm wondering about putting all the Cocoa bits in to the same static library, that I can link to from my game project (from c/c++ code). Is that feasible on both Mac and iPhone?

Also, would SDL allow me to setup a window or fullscreen on a Mac, that I can use OpenGL with?
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #6
DoG Wrote:... And again, Carbon isn't deprecated as a whole, but some legacy APIs are simply not carried over to 64bit-land.

... specifically the GUI APIs, which is certainly no minor omission. If that isn't a signal that Carbon is going to be dead soon, I don't know what is.

Jamie W Wrote:So, probably looking at bare minimal use of Cocoa..
On iPhone, yes, bare minimal for setup. On Mac, not quite so simple. SDL is a better bet on Mac unless you'd be willing to dig deeper for full support.

Jamie W Wrote:I'm wondering about putting all the Cocoa bits in to the same static library, that I can link to from my game project (from c/c++ code). Is that feasible on both Mac and iPhone?
No, not really. Speaking from experience, they're different enough that you won't find it easy to have portable Cocoa code between Mac and iPhone. The C/C++/OpenGL/OpenAL parts could be directly/nearly-directly compatible though.

Jamie W Wrote:Also, would SDL allow me to setup a window or fullscreen on a Mac, that I can use OpenGL with?
Yes, absolutely, that's one of the reasons I recommended it. You definitely need to look into SDL before you jump into ObjC/Cocoa for games on Mac and iPhone. I don't know what SDL's capabilities are on iPhone, because I don't need to use it myself, but definitely look into it.

This may sound like kind of a screwed up way to sell SDL, but I've never had to use it myself because I know how to provide native OS support myself, but one of the things that happens to me quite often is that when I'm searching for a solution for native support I'll wind up on an SDL source page approaching things the same way I do. So let me say this: SDL is not dumb. There are some *very* talented guys who've put in some great code underneath to provide Apple platform support. It's good stuff, and that's coming from a guy who's only judged it from looking at the code! Wink
Quote this message in a reply
Member
Posts: 194
Joined: 2009.02
Post: #7
DoG Wrote:"Carbon" is a big word. Its an umbrella for many APIs, some of which are more outdated than others.

Yes, it is a big word, that's why I said "effectively deprecated".

DoG Wrote:have no idea what NelsonMandella is getting at, since the transition was an effective seven or eight years from OS9 to OSX, and you'd probably still have support for running a classic VM if it wasn't for the Intel switch. And again, Carbon isn't deprecated as a whole, but some legacy APIs are simply not carried over to 64bit-land.

OS X came out in 2002, by 2003/04 you could no longer dual boot, by 2005 classic was removed, and they began deprecating carbon in 2006. I don't mean to beat a dead horse but seven or eight years is quite a liberal interpretation of the timeline.
Quote this message in a reply
Member
Posts: 129
Joined: 2009.03
Post: #8
Ah yeah, I remember someone else suggesting SDL + OpenGL for Mac game dev. I was also thinking to use SDL for inputs (keyboard and joystick etc) too, and this could marry up very nicely with the PC side of things (assuming I can use SDL on Windows, but without the video, as I want to use DirectX).

Is that a good idea? Using SDL for inputs? I've had issues before reading joystick inputs (which didn't work with the last API / game-engine I used), so having that all work in SDL is a real plus!

So, will definitely give SDL a whirl, and and see how I get on. Many thanks for the tip Jake.
Quote this message in a reply
Member
Posts: 353
Joined: 2002.04
Post: #9
Sorry for the OT but, was just checking out your softography Jamie - Nitro and ATR on the Amiga were totally awesome! I used to love the post-apocalyptic level in Nitro, my friends and I wasted hours on Nitro when we were younger.
Muchos respect!
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #10
Jamie W Wrote:Is that a good idea? Using SDL for inputs? I've had issues before reading joystick inputs (which didn't work with the last API / game-engine I used), so having that all work in SDL is a real plus!

Oh yes, I forgot to mention that SDL can do the joystick input for you as well, and that is something you definitely DO NOT want to do yourself on OS X if you can avoid it. I haven't actually used SDL for joystick input myself, so I can't vouch for its convenience, but if it works at all, it'd be way better than treading through HID Manager hell yourself (which is better in OS X 10.5, but still low level insanity).
Quote this message in a reply
Member
Posts: 129
Joined: 2009.03
Post: #11
monteboyd Wrote:Sorry for the OT but, was just checking out your softography Jamie - Nitro and ATR on the Amiga were totally awesome! I used to love the post-apocalyptic level in Nitro, my friends and I wasted hours on Nitro when we were younger.
Muchos respect!

Ah thanks! Seem to be a lot of old Amiga owners in the Mac world! Wink

Well, SDL + OpenGL is looking very nice still! I found a great tutorial (if anyone interested) here:

http://gpwiki.org/index.php/SDL:Tutorial...ith_OpenGL

Main concerns at the moment, are working out what the screen frequency is. I can live with not being able to set the screen frequency, but would be nice to know what it is. Maybe there is an OpenGL way to get it.

Also, having to reload textures when I toggle full-screen to windowed.

I guess it's possible to keep the SDL texture in system memory, and copy that to an OpenGL texture in video memory, then when the copy in video memory goes kaput, I can always refresh it from the SDL copy in system memory. Is that generally the way to handle textures with SDL + OpenGL?
Quote this message in a reply
Member
Posts: 260
Joined: 2005.05
Post: #12
You are on the right track IMHO. Games have little use of the standard GUI components, and that is what Carbon/Cocoa is all about. The non-GUI Carbon/Core stuff will not go away easily, but most of it I stay away from anyway these days. I use low-level Unix file calls, OpenGL, OpenAL. I don't use SDL right now but it is a strong alternative with good portability and many features.

Concerning textures, I find the texture management in OpenGL so smart that I can just upload to VRAM and forget about it. OpenGL will handle swapping of texture data. I have read about strategies to handle texture caching but never found that I needed to care. Even when writing a program where the texture data was many times the available VRAM, OSX/OpenGL handled it smoothly for me.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  is sdl+opengl slower than cocoa/carbon+opengl? Najdorf 9 4,815 Nov 16, 2005 09:45 PM
Last Post: WhatMeWorry
  Carbon vs Cocoa OpenGl Byron Clarke 2 2,836 May 31, 2005 05:47 PM
Last Post: maaaaark
  Carbon (AGL) or Cocoa? webwarrior 20 9,077 Sep 28, 2004 02:18 PM
Last Post: OneSadCookie
  SDL, Cocoa or Carbon? Taxxodium 7 4,482 Jan 10, 2004 10:58 PM
Last Post: OneSadCookie