iDevGames Forums

Full Version: Noob Cocoa and Carbon Questions
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2

MonitorFlickers

hey everyone. I've got some noob questions I was wondering if I could get help with. I'm currently learning Objective C and the Cocoa frameworks after a long history of various BASIC languages (REALBasic, futurebasic, etc.) But i've had trouble finding out the answer to the following questions that are kinda bugging me:

1- I'm learning Carbon right now, too. Is Carbon going to be around for a long time or will it be deprecated eventually and completely replaced with the Cocoa fameworks?

2- Will the Carbon frameworks be compatible when Apple switches to intel?

3-Is Cocoa/Obj C the right combo for me to learn if I'm looking for speed and power? I'm not looking to program a 3D fps, but if I wanted to, is that even possible with Cocoa?

If anyone could help me out with these questions it would clear up a lot of confusion for me- thanks for the help, this site looks great!
1) Every indication is that Carbon'll be around forever.

2) Carbon works fine on Intel.

3) If you're just making games, there's not a great deal to choose between Carbon and Cocoa. However, virtually nobody knows anything about Carbon any more, because Cocoa is nicer to use for everything except game programming, so it's a lot easier to get help with Cocoa problems.
If you want to have your games as portable as possible (without using SDL or GLUT, that is), Carbon is the way to go. That way, whoever is porting it (whether it's you or somebody else) only has to translate the function calls for events, graphics contexts, etc., rather than also having to also translate the language. Once you learn what you need to about either, you won't need a whole lot more to program a game since it usually makes calls to other APIs and your own functions, since you'll be doing more low level stuff rather than system level and GUI stuff.
That's just rubbish. Carbon is just as hard to port as Cocoa.
Quote:irtually nobody knows anything about Carbon any more
Rubbish! Go on the carbon mailing list.
(Larry... now that's a name in my idol cabinet)

Quote:3-Is Cocoa/Obj C the right combo for me to learn if I'm looking for speed and power? I'm not looking to program a 3D fps, but if I wanted to, is that even possible with Cocoa?

A benchmark I saw said that ObjC function calls are about 3-times as slow as C++ function calls.

Quote:2- Will the Carbon frameworks be compatible when Apple switches to intel?

If you mean will frameworks you make work with intelapple?
No, you will have to re-compile them.

If you mean will carbon be supported with intelapple?
Yeah, they'd better
Try asking a Carbon question here, iDevApps, or the IRC channels and see how many people know about Carbon Wink

Yes, an ObjC message send is slower than a C++ virtual function call (though not by very much on 10.4 with fast dispatch turned on), but the amount of time you spend in Cocoa in a game is small...

MonitorFlickers

awesome, thanks for the help! Smile
MonitorFlickers Wrote:1- I'm learning Carbon right now, too. Is Carbon going to be around for a long time or will it be deprecated eventually and completely replaced with the Cocoa fameworks?

Yes, it will be around. Apple is trying not to "prefer" either Carbon or Cocoa.

Quote:2- Will the Carbon frameworks be compatible when Apple switches to intel?

Yes.

Quote:3-Is Cocoa/Obj C the right combo for me to learn if I'm looking for speed and power? I'm not looking to program a 3D fps, but if I wanted to, is that even possible with Cocoa?

The performance difference between them is negligible for most purposes (yes, even 3D games). OpenGL code is straight C anyway.
Dont say noob questions or whatever, its not helpful.

Marjock

Quote:Yes, an ObjC message send is slower than a C++ virtual function call (though not by very much on 10.4 with fast dispatch turned on), but the amount of time you spend in Cocoa in a game is small...

Are you saying you'd use C/++ functions rather than obj-C functions, usually, then?

-Mark
All the system level user interface code like windows, tool palettes, dialog boxes for switching resolutions and preferences, etc., would be done in obj-C to take advantage of Cocoa. The game rendering loop being in C/C++ will likely comprise, at the very least, 85% of the overall code. Note: You could do the whole thing in Cocoa, but keeping the core rendering code in straight C/C++ is faster and it's also easier to port.

Tesselate

I am also just starting with Mac OS X.

I am in the middle of trying to port an application I wrote in C++ under Linux on a PC that generates sound in real time. Under Linux it used SDL and PortAudio, both of which work under Mac OS. A straight port worked, BUT I can't go full-screen
under SDL on the Mac, apparently.

So I translated it all into Objective-C and Cocoa, believing Apple's website about using Cocoa for new applications. It is *three times* as slow! (Same compiler option: fastest.) In fact it is unusably slow.

Now I guess I'll try Cocoa for the GUI and C/C++/Carbon for the number-crunching.
(Except I don't know anything about Carbon.)
You don't really need to know anything about Carbon if you're using Cocoa for the GUI.
@Tesselate: it is perfectly possible to go fullscreen using SDL on OS X, with the usual...
Code:
SDL_SetVideoMode(<width>, <height>, <depth>, SDL_SWSURFACE | SDL_FULLSCREEN ); /* (This is from memory, as I have this wrapped as part of my library.) */
...what errors did you encounter?
UT2k4 is proof that you can go full-screen in SDL just fine Wink

ObjC messages have a substantial overhead to them; you'll want to avoid them in performance-critical situations. With the "fast ObjC message dispatch" option (compiled code works on 10.4+ only) that overhead is reduced, but is still a little more than a C++ virtual function call.

Aside from that, ObjC is no slower than C++...
Pages: 1 2
Reference URL's