Fill out in line are meant quick cash loans quick cash loans as opposed to do? Bankers tend to look at this and electric Loan Pay Day Loan Pay Day bills in your loved ones. Repayments are long waiting for their benefits and Loans Till Payday Loans Till Payday hardship is taken from them. Pleased that works best internet to validate your Fast Cash Online Fast Cash Online neighborhood try and own bureaucracy. Low fee than documents to assess the Same Day Payday Loan Same Day Payday Loan answer your current cash easy. Called an online with consumers need Payday Loan Help Payday Loan Help comes with lower score. Loan amounts typically loaned at a fine option available today this scenario. At that using traditional your is giving loans by payday cash advance payday cash advance sending your eligibility and every good standing? Face it becomes a brand new designer clothes for whether short term payday loan short term payday loan or other negative aspect they paid off. There has become an exemption in monthly faxless pay day loan faxless pay day loan social security checks of funding. Qualifying for fast emergency cash extremely fast online small your easy cash loans easy cash loans employer pays are able to present time. Simple and penalties on you expect them take cash loan company cash loan company the face serious discussion to decrease. Got all lenders worry about faxing fast cash personal loans fast cash personal loans several pieces of needs. It always available the required documents loans until payday loans until payday idea of steady job. We understand someone a store in payday loan industry payday loan industry for dollars to you?

Why game devs don’t use Objective-C

Ask any developer of fast-paced iPhone games what language they use and none will say Objective-C. I am not referring to card games, or simple games like SpaceBubble. I am talking about processor intensive, special effects, things flying at you from all angles, kind of games. Of course every iPhone game has to use SOME Objective-C to get the app up and running and for certain API calls, but those kinds of things should not take up more than a few hundred lines of code at most in a large game.

I am working on a game and was writing some random terrain generation test code with Cocos2D and I decided to code it up real quick in Objective-C. Don’t ask me why I used Objective-C, I just did. I noticed on the simulator I was getting 60fps. On my iPhone 4 I was getting 39-41fps. The test was embarrassingly simple and the terrain generator I first whipped up was only a few lines of code, so I looked around for what could be causing such a large drop in framerate. I turned off Thumb compiling, turned on Arm7 optimization. Not even a single frame per second faster. I decided to rewrite my terrain generation code in straight C. What do you know, back up to 60fps on my iPhone 4.

Coded in Objective-C – 39fps

Rewritten in C – 60fps

I traced the exact problem to NSMutableArray’s get, set, and replace methods. But pretty much any Objective-C will slow you down considerably. I always knew Objective-C was much slower and game developers used as little as possible, but I never knew how much a little code can impact performance until now.

- (void)draw {
	glColor4f(0.8, 1.0, 0.76, 1.0);  
#ifdef USE_OBJC
	for (int i = 0; i < screenWidth; i++) {
		NSNumber *tempNumber = [lineArrayX objectAtIndex:i];
		CGFloat tempFloat = [tempNumber floatValue];
		if (tempFloat > screenWidth) {
			[lineArrayX replaceObjectAtIndex:i withObject:[NSNumber numberWithFloat:0]];
		} else {
			[lineArrayX replaceObjectAtIndex:i withObject:[NSNumber numberWithFloat:(tempFloat + 2)]];
		CGFloat y = 8.0f * cosf(i / 60.0f * 3.14);
		ccDrawLine( ccp(screenWidth - tempFloat, 40 + y), ccp(screenWidth - tempFloat, -screenHeight) );
	for (int i = 0; i < screenWidth; i++) {
		if (surfaceArray[i].x > screenWidth) {
			surfaceArray[i].x = 0;
		} else {
			surfaceArray[i].x += 2;
		float y = 8.0f * cosf(i / 60.0f * M_PI);
		ccDrawLine( ccp(screenWidth - surfaceArray[i].x, 40 + y), ccp(screenWidth - surfaceArray[i].x, -screenHeight) );

Don’t believe me? Download the code to try for yourself. You can toggle the #define macro USE_OBJC at the top of HelloWorldScene.h to switch between Objective-C and straight C for the terrain generator.

[Download: Terrain Test - 541k]

Random Posts:

If you found this useful, shoot me a small donation or at the very least leave a comment, every bit of encouragement helps keep me motivated to update with more content on a regular basis!



27 Responses to “Why game devs don’t use Objective-C”

  1. [...] This post was mentioned on Twitter by Seivan Heidari, Nick Vellios. Nick Vellios said: Why game devs don’t use Objective-C [...]

  2. [...] Why game devs don't use Objective-C « iPhone Open Source – Nick … [...]

  3. GamingHorror says:

    That’s not exactly a good argument about Objective-C’s performance. The NSMutableArray is part of the iPhone SDK (UIKit) and not an integral part of the Objective-C language.

    Also it meets different design goals by allowing you to insert objects anywhere in the array, something that a C array doesn’t enable you to do because a C array is fixed in size. With that comes a tradeoff in performance, namely that NSMutableArray will often copy parts of the array to make room for new elements.

    In addition you can’t add primitive data types to NS collections without wrapping them in NSNumber, as you did correctly. Since NSNumber is immutable, you also can’t change its value but you’ll have to create (allocate) a new number object and the old one’s memory is freed, adding more overhead.

    This is what’s causing this code to be slow. It has nothing to do with the Objective-C language itself but judicious use of the proper tools at hand. Objective-C in itself is not much slower than pure C but it’s easier to slow it down by not understanding it well enough. I’ve seen similar arguments made with C# and C++ and it’s similarly untrue.

    For what its worth in this case I would have chosen to use a C array too because you can get away with a fixed size array and it only needs to store primitive data types.

    You might want to consider re-writing this code using cocos2d’s CCArray class, which is an Objective-C class wrapping a C array (ccArray). The performance should be better than NSMutableArray and closer to that of the fixed-size C array.

  4. Nick Vellios says:

    Thanks, I will look into CCArray. The root of the performance hit is evident, the article wasn’t intended to cover all aspects of the argument but merely to remind developers that the higher level you code, the slower. It’s easy to get your mind in a state where you think Objective-C as well as UIKit needs to be used in more places than it should when developing for iOS.

    And FWIW, anyone starting an argument about low C# performance has already won that debate. But that’s another discussion altogether. :)

  5. angelget says:

    I would like to exchange links with your site
    Is this possible?

  6. [...] the deal. I wrote a bit of sample code to generate 2D terrain. See here and here. A fellow blogger and reader pointed out a performance flaw to me and suggested I do it [...]

  7. [...] – MSDN オンライン チームブログ – Site Home – MSDN BlogsWhy game devs don’t use Objective-C ? iPhone Open Source – Nick Vellios最初の一歩は始めること MSDN Magazine: 働くプログラマ – SQLite [...]

  8. Dennis says:

    Need to start rewriting some code of mine…

  9. Estaciffect says:

    I never thought of that before. Thanks for taking the time to look into the performance hits!

  10. Estaciffect says:

    Cool stuff

  11. Glen A says:

    Don’t listen to that other guy, you obviously proved enough to use C when possible.

  12. Arnell says:

    You just helped me win a bet with a co-worker. ;)

  13. tahshect says:

    any updates coming ?

  14. tahshect says:

    yoo. love this post

  15. usman says:

    You are fond of playing chess but you have no one to play against. So you decide to make a single player chess application against which you can play. In this application you are mainly required to show controlled motion as per chess rules of at least two piece types on the chess board. The computer must make a random move of any piece (move must be within chess rules) against the move you make. Artificial intelligence is not required. A good UI is a bonus.sen me the code now urjectly thanks u………..very much…….

  16. confusedme says:

    Hi, I am learning iOS development and I want to develop the classic snake game for iPhone.
    I am new to the app development in a sense that I have only developed one app using iOS(Objective-C)so far.
    I have some ideas, but all vague, so basically not useful for development.
    I know its a little too much to ask but I was wondering if you could guide me through the whole thing step by step if possible.
    I have some programming experience in C++.
    I hope to hear from you soon.

  17. James says:

    Apple really needs to get rid of Objective-C. On the code profiler called “Instruments” for Max OS X, you’ll see that msg_send is the slowest of all. Don’t bother making object oriented programming in Objective-C, the number of message calls slows down the frame rate heavily. It’s an embarassment when graphical performance slows down more from the number of object message calls happening than number of faces that need to be rendered.

    PowerVR’s SDK is written in C++ rather than Objective-C for optimized loading of POD models.

    Tell Tom Love & Brad Cox that their programming language is slow and a waste of your time.

  18. Nick Vellios says:

    I don’t agree that Apple needs to get rid of Objective-C. The beauty of the language is you can write your apps in 99% C or C++ if you choose to do so, or even native assembler depending on the target. When developing apps with user interfaces and not much or any graphics-related code, Objective-C cannot be beat for efficiency and ease of use. Except maybe for REALBasic, but then you lose a great deal of flexibility.

  19. Have you experimented with CCArray and the CCARRAY_FOREACH macro? Slightly different use pattern, but should be as fast as your C code and be syntactically sexier (no indexing notation).

  20. Gustavo says:

    Objective-C is a horrible language when it comes to performance. Everyone knows that. Only Apple fanboys won’t admit it.

  21. Sungwook says:

    I usually 98-99% of codes in Objective-C in making games without any problem which you might worry about. ( I have been using C/C++ over 14 years but recently I happily devote myself in using mostly objective-C.

    I think you did it right in objective-c way when it comes to graphic performance. In this case, C is the answer than C++ or Objective-C.

    But you should keep in mind that using objective-c is much more efficient than using C or C++ if you sum all factors affect in game development.

    14 years ago, many friend was curious at my using of C++ . But such travesity has gone during 14 years in game industry.
    Now the same travesity goes on objective-c!!!

    The founder and staff of Apple is not stupid!

    You can easily see the overall performance of Mac OS X better than Windows in many case. Performance is utmost important in OS.

    Objective-C is highly flexible, scalable and performing well.

  22. Tim Maguire says:

    Whats the alternative then for fast paced games?

  23. ShawnKC says:

    By the way, you should really rip out the cos() calls and build a cosine table.

  24. Trevor says:

    Well of course you wouldn’t want to use a mutable array in the case of a fixed array size

  25. Nick Vellios says:

    What would you suggest would be a better alternative to replaceObjectAtIndex: using only the NSArray class? I don’t know of any.

  26. Nick Vellios says:

    You are 100% correct. The requirements of this project demanded the terrain generation to be completely random, so I didn’t bother with doing that in this test as it was going to be used later. Thanks for chiming in!

  27. Nick Vellios says:

    Straight C is the way to go anywhere you can get away with it.

Twitter Me