Newbie Inquiries

cmiller Wrote:If you've already learned Objective-C, and are deploying exclusively to the iPhone, then I see little reason to bother with C++.

Short of a hidden std::makeDukeNukemForever part of the STL, I don't think that the additional pains of C++ will really be worth your while.

Objective-C and C++ use entirely different patterns for constructing systems and intermingling the two will be difficult at best. Objective-C, on the other hand, is a light layer on top of C. Intermingling Objective-C and C is easier (though still quite difficult if you're not on top of your game).

You could use CoreAnimation for your game, but I would highly suggest going with OpenGL, as CoreAnimation's uses are quite limited. You can do a lot of interesting things with CoreAnimation, but when you hit the ceiling of what it's designed to do, you usually hit that ceiling very hard.

Thank you for your post. I have a few questions, though. Above as you know, members have advised C++ for game programming on the iPhone among other platforms. I'm aware that C++ is used as a mainstream language for game developers. Does this mean Objective-C is an unorthodox way of gaming programming?

Doobfoo Wrote:Does this mean Objective-C is an unorthodox way of gaming programming?

You can easily use Obj-C for game programming on the Mac, but you'll eventually run into performance problems on iPhone if you use it for things like tight loops and other performance intensive areas. It's okay for general game structuring on the iPhone, but you'll want to stick to C/C++ for the critical stuff. That said, there have been successful games using mainly Obj-C on iPhone.

Again, *most* games will be using C/C++. C++ is harder for beginners to learn, although many have argued that it's easier because of the existence of STL (I think they're crazy). C++ is arguably the most industry-standard language for game programming, although many of us avoid it, and won't even bother answering newbie questions about it. C is easy, simple (for the most part) and pretty straight-forward. If you know Objective-C, you already know C. As cmiller already kind of pointed out, you'd have to make major effort to pick up C++ coming from Objective-C, since the design patterns are entirely different. Since Obj-C and C are more than adequate for any game, why bother moving to C++ if you already know Obj-C and C?

Here are a few facts about who uses C:

All of Pangea's games are programmed in C. Most id games were programmed in C, up to and including Quake 3. I know Carmack would still prefer C, but he's in the engine building business and as I understand it, the customers wanted C++ for whatever crazy reason so he accommodated them. Bungie games were all C, at least until Halo (I presume Halo is C++ because it was swallowed up into a corporate group-think environment).

Of the members here who use C/C++, I would wildly estimate that 75% use C and the other 25% use C++.

AnotherJake Wrote:You can easily use Obj-C for game programming on the Mac, but you'll eventually run into performance problems on iPhone if you use it for things like tight loops and other performance intensive areas. It's okay for general game structuring on the iPhone, but you'll want to stick to C/C++ for the critical stuff. That said, there have been successful games using mainly Obj-C on iPhone.

Again, *most* games will be using C/C++. C++ is harder for beginners to learn, although many have argued that it's easier because of the existence of STL (I think they're crazy). C++ is arguably the most industry-standard language for game programming, although many of us avoid it, and won't even bother answering newbie questions about it. C is easy, simple (for the most part) and pretty straight-forward. If you know Objective-C, you already know C. As cmiller already kind of pointed out, you'd have to make major effort to pick up C++ coming from Objective-C, since the design patterns are entirely different. Since Obj-C and C are more than adequate for any game, why bother moving to C++ if you already know Obj-C and C?

Here are a few facts about who uses C:

All of Pangea's games are programmed in C. Most id games were programmed in C, up to and including Quake 3. I know Carmack would still prefer C, but he's in the engine building business and as I understand it, the customers wanted C++ for whatever crazy reason so he accommodated them. Bungie games were all C, at least until Halo (I presume Halo is C++ because it was swallowed up into a corporate group-think environment).

Of the members here who use C/C++, I would wildly estimate that 75% use C and the other 25% use C++.

C++ is a beautiful and powerful language, but its basic libraries are so sparse and difficult to learn to use that it takes massive effort to learn to use C++ effectively. Going along the lines of my "Shutup and Code" mantra (the idea that if you're not writing code, you're not doing it right), if you've already learned Objective-C (and by extension, C), which is the minimum in order to develop for iPhone, then C++ is completely extraneous. The additional work to learn C++ will not be a significant return on investment.

Objective-C is very fast, and you shouldn't have any problems using it in a tight-loop. There are parts of it which are slow (such as autorelease pools, etc.) which you can identify and fix using a profiler. Honestly, for something like an Objective-C message dispatch, it's not going to be much different than a C++ vtable lookup.

If you're truly having issues, in both languages you're going to end up using C. And even then, if you're still having issues, you're going to end up using assembler.

And then, if you're still having issues, your overall design is messed up. Or you're trying to do too much on too small a processor. But you get the idea.

cmiller Wrote:Objective-C is very fast, and you shouldn't have any problems using it in a tight-loop.

I have. The first game attempt I did on iPhone was all Obj-C/Cocoa. Even with optimizations, Cocoa had to go, but the Obj-C stuff stayed for a while. Then I eventually replaced all of it with straight C and went from 20 fps to 45. That was even using IMPs with Obj-C. Now, truth be told, I'm not anywhere near experienced at getting the best performance out of Obj-C so YMMV. I will say I didn't have the patience to wait ten minutes for Shark to process five seconds of iPhone execution every time, so profiling was like pulling teeth. Going through the hassle of figuring out the Obj-C performance tricks on iPhone wasn't as easy as simply re-coding in C.

That said, all three angles (C/C++/Objective-C) are debatable as to which is good to use on iPhone. All three are plenty powerful enough to make games with on iPhone. As I said already though, C/C++ are more often used for games on iPhone (at least as far as I can tell).

Obviously there's no doubt lower overhead on such small devices is good either way, but I wonder what the *actual* problem is.

My thought on the Obj-C vs C debate hinges on whether people use Obj-C objects for *everything* (IOW, too many things) and thus claim the language itself is the problem, when it's really more of the application of the language that's the issue (not using structs for things that really don't need to be objects). When they go to "C", they not only reduce the memory footprint, but also the number of methods/functions being called because a struct is lighter than an Obj-C object in pretty much every way.

For example...

If every particle in an effect is an Obj-C object with methods to set all of its attributes, that's bound to fail. I wouldn't do it on the Mac, let alone the phone. At minimum you could create an Obj-C object and use direct access to its members for all of the attributes, but when there's gajillions of the things being created, I'd just avoid it being a class, avoid the all, init, release, and probably more retain and release calls (since it's an Obj-C object, I'm betting you'll stick it in an NSArray, which itself means you're adding more overhead over other data structures), which just means tons of overhead for which a struct doesn't have.

If you use C for the intensive bits (objects that get created over and over, a short path of code that gets called gajillions of times), I would imagine you could get away with Obj-C for quite a lot of code. Especially on the 3GS and going forward.

But there's no real way to settle the question of why "Obj-C is too slow" (in my mind) without someone posting code for an Obj-C-built game with performance trouble and being able to investigate it thoroughly.

Both of the games I've written for the phone were all Obj-C thoughout, but they weren't exactly super demanding, so I don't really have any first-hand experience with Obj-C being an issue.

Indeed, there are so many what-if's all over the place. We typically like binary solutions (right or wrong, etc.) but this isn't so easy to do that with. I particularly agree that there may be many who are using too much Obj-C (and Cocoa) and peeing on it for that, and not knowing better. At least I know better, so not even I can say for sure that Obj-C is too slow for iPhone games. All I can say is that I know the way I typically use it, and it won't cut it for what I need -- either because I need too much from it, or I just don't know enough about what I'm doing with Obj-C. TouchFighter OTOH, does some pretty demanding stuff and it works just fine with Obj-C throughout.

Like I said, I cut out stuff that was obviously Cocoa-based like NSArrays and Dictionaries where I knew I could do faster in C with a struct (etc.). That still wasn't enough, and when I started switching more stuff back to C I figured, what's the point of using Obj-C at all at that point? What if this, what if that, what if...

Thanks for all the great responses guys, it's been very interesting to read. I have been reading Programming in Objective-C 2.0 over the last few days.

I am understanding the general terminology and theory behind object oriented programming, but it just seems extremely overwhelming to me right now. I can get through about half of the review questions and then I just suddenly hit a wall.

Perhaps it is better to have a background in another language first, or is this common among newbs? Have any of you heard of Alice - http://www.alice.org/ ? Should I back track a bit and get a solid understanding of programming theory through this literature and then continue? Is it best to just dive in?

Sorry if some things I have said are inane. Thanks to everyone helping me out.

I think when iPhone games are built in C++, it's usually because the developers have C++ experience (and possibly useful libraries) already. Especially for ports - if you're porting a C++ game you want to do the minimum recoding necessary and learn just enough cocoa to get OpenGL started and play some sounds.

If you're starting from scratch on the iPhone, I don't see any reason for using C++. You already have C to fall back on for speed-critical areas, and writing in C++ won't help you port to devices running Android or JavaME.

Also, if you're already struggling to learn two languages (Objective-C and C) then throwing in a third won't speed up the learning process.

Doobfoo Wrote:I think I am going to start fresh with the book Learning C on the Mac, published by Apress and then I will continue with Objective-C.

That sounds like a plan. My Dad is reading that book to learn C (he's done programming in other languages like Ruby a lot for a long time) and he said he'd rate it an A for a total newb. Especially since it talks about Xcode specifically.

Quote:It's quite easy to get side-tracked and move onto something else, so I find.

FreakSoftware Wrote:Obviously there's no doubt lower overhead on such small devices is good either way, but I wonder what the *actual* problem is.

My thought on the Obj-C vs C debate hinges on whether people use Obj-C objects for *everything* (IOW, too many things) and thus claim the language itself is the problem, when it's really more of the application of the language that's the issue (not using structs for things that really don't need to be objects). When they go to "C", they not only reduce the memory footprint, but also the number of methods/functions being called because a struct is lighter than an Obj-C object in pretty much every way.

For example...

If every particle in an effect is an Obj-C object with methods to set all of its attributes, that's bound to fail. I wouldn't do it on the Mac, let alone the phone. At minimum you could create an Obj-C object and use direct access to its members for all of the attributes, but when there's gajillions of the things being created, I'd just avoid it being a class, avoid the all, init, release, and probably more retain and release calls (since it's an Obj-C object, I'm betting you'll stick it in an NSArray, which itself means you're adding more overhead over other data structures), which just means tons of overhead for which a struct doesn't have.

If you use C for the intensive bits (objects that get created over and over, a short path of code that gets called gajillions of times), I would imagine you could get away with Obj-C for quite a lot of code. Especially on the 3GS and going forward.

But there's no real way to settle the question of why "Obj-C is too slow" (in my mind) without someone posting code for an Obj-C-built game with performance trouble and being able to investigate it thoroughly.

Both of the games I've written for the phone were all Obj-C thoughout, but they weren't exactly super demanding, so I don't really have any first-hand experience with Obj-C being an issue.

Objective C is slower in an apple's to apple's comparison. For example, if you made a game in C++ that uses objects for everything, and re-wrote it using Objective-C objects for everything, the C++ version would be faster. Reason being, that an Objective-C object is "dynamic," performing common operations at runtime rather than compile time, such as dynamic type checking, dynamic binding, dynamic dispatch, garbage collection (if enabled), etc... On the other hand, in C++, a class is almost a fancy word for "struct." Type checking, dispatch, etc, are all done "statically," and can be easily circumvented --sometimes, unintentionally. A C++ program may behave unexpectedly in such circumstances, whereas an Objective-C program will crash or throw an exception. This is probably the biggest advantage of a language like Objective-C. C++ has the advantage of performance.

Personally, I'm using Objective-C for Mac-specific stuff, C++ for some data structures, and straight C for everything else.