This questions is partially for my own knowledge, and partially because I am looking for someone to write an article for iDevGames on this very subject.

I have been working with Cocoa recently, I'm quite proficient with the general stuff, but something has bothered me; There seems to be a major performance issue with CoreGraphics, even simple tasks, like blitting a normal image seem to take quite a bit longer than they should. Maybe I'm just missing something.

So here is a call for tips on fast drawing, and just general speed tips for Cocoa games. Anyone?

Quote:Originally posted by Griggs
There seems to be a major performance issue with CoreGraphics, even simple tasks, like blitting a normal image seem to take quite a bit longer than they ? [/b]

1. Be more specific?
What are you using for drawing etc?
Are you using quartz? or GWORLDs, and copybits etc?

2. What hardware are you running on?
and maybe what short of frame rates are you seeing?

There was a nice article on optimizing Objective C linked from the iDevGames front page a little while back. Lots of good stuff in there.

As for optimizing Quartz, I imagine the CoreGraphics functions would be marginally faster than their Cocoa counterparts (though I have to admit I don't know), and make sure you're not recreating your NSBitmapImageRep each time you want to blit

I would also guess that (for those with the hardware), Quartz Extreme will make blitting performance very much a non-issue. Apple's OpenGL implementation is very very fast at getting textures to the graphics card (if you use all the right proprietary Apple extensions...).

GoodDoug might be able to share his thoughts on this area, as he seemed to learn some tricks with his uDevGame 2001 entry.

The Inkubator Project's Hooptie doesn't use CoreGraphics directly, instead it uses NSImage and still manages to squeeze a fair bit out of Quartz. Tips include:

1) Don't update the whole game screen for each round of updating, update parts of it using NSView's lockFocus and unlockFocus.

2) Expect NSTimer to be unreliable, hence set the timer to trigger more often than you want and use gettimeofday() to determine whether to do an update.

3) Allow for "lost time".

4) Load all images into memory before hand by using the lockFocus and unlockFocus methods of the NSImage's you'll be using (with no drawing in between).

If you make use of these ideas please consider contributing to the Inkubator project or at least giving our humble project a mention.

Yes, I should have been more specific. Indeed I am talking about the standard Cocoa stuff, NSImage and so on. I am at home using GWorlds and such, but I also really like Cocoa, so I want to figure out how to get good performance from it.

Thanks Mark, those are exactly the kind of tips I'm looking for.

I don't know if this matters at all but I see it a lot when people move OS-9 code to carbon under X using GWorlds... and that is that windows are automatically double buffered for you on X... so people who where doing there own double buffering under 9 where ending up with triple buffering or a third copy of all their Gworld Data on X.

Not sure if this sort of rule applies to the NSStuff having not played with it at all yet myself.