Game-Related Cocoa Questions

Member
Posts: 268
Joined: 2005.04
Post: #1
I've just begun to learn Cocoa and I had some game-related questions to ask.

1) Is NSImage the best/fastest way to store the graphics? I know this is what Hooptie and Jewl Toy use and was just wondering if anybody used anything different.

2) What's the absolute fastest way to draw the graphics on the screen? Hooptie and Jewel Toy use compositeToPoint. Are there any optimizations that can be made to make it faster (smaller bit-depth, make the size a power of 2, etc)?

3) NSTimer is what you use to create a main game loop that fires every 1/30 of a second? I'm assuming something like a while loop is Very Bad CodeƓ.

I think that's it for now.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
RE: 3

If the standard Cocoa event loop provided by NSApplicationMain proves difficult to manage for any reason, you can in fact run the event loop yourself.

If, however, you're using any kinds of standard UI elements, you're almost certainly better off using the standard event loop rather than trying to dispatch the events yourself...
Quote this message in a reply
rjz7584
Unregistered
 
Post: #3
1) This depends - What do you mean by best? Right now, speed wise, no, not by a long shot. NSImage is quite slow. However, once "Jagwire"/OS 10.2/10.5/whatever comes out and we get Quartz Extreme, this will change for many machines. NSImage is the easiest to work with- just don't try and do fullscreen stuff with it. So, if best is easiest, yes. Trust me, unless you have done OS 9 programming in the past, you don't want to have to deal with gWorlds and CopyBits and stuff.

2) To make your game faster:

Never ever use [[NSBezierPath bezierPathWith... to fill in a solid color. Instead, use NSRectFill(SomeRect)

This can be up to twice as fast!

Make your window an NSBackingStoreNonretained. Because it won't be stored, your drawing will be faster.

Try and avoid [someNSImage lockFocus] at all costs. Always check to see if you need to update the sprite. If not, just return what you already had. lockFocus causes it to be recached, and that's very slow.

3) Using an NSTimer is the way to go if you know you are not drawing too much stuff at once. This will make your game try it's best to go 30 frames per second, which is what you want. However, if you process slowly, you may miss a tick, and then you'll have to wait for the next 1/30 of a second to roll around. Also depends on what machine you target. On a G4, you'll probably never miss a tick unless you are doing extreme stuff.

I admit it, I'm biased, but http://homepage.mac.com/rjz7584 has many good examples of making games with Cocoa. (I'm the guy who runs it)

Good luck!
Quote this message in a reply
Member
Posts: 268
Joined: 2005.04
Post: #4
Quote:1) This depends - What do you mean by best? Right now, speed wise, no, not by a long shot. NSImage is quite slow. However, once "Jagwire"/OS 10.2/10.5/whatever comes out and we get Quartz Extreme, this will change for many machines. NSImage is the easiest to work with- just don't try and do fullscreen stuff with it. So, if best is easiest, yes. Trust me, unless you have done OS 9 programming in the past, you don't want to have to deal with gWorlds and CopyBits and stuff.

Dang, I was afraid NSImage was going to be this slow. The problem with Quartz Extreme is that it requires a good video card, the problem being that the only video cards my computer has at the moment are a Rage II and a Voodoo 3. Both of them completely worthless for OpenGL and QE. I have used gWorlds and CopyBits/Mask before and have no problem with using them, but can you call those from Cocoa? I was trying to go pure Cocoa and avoid Carbon, but looks like that's going to be impossible.

Quote:Never ever use [[NSBezierPath bezierPathWith... to fill in a solid color. Instead, use NSRectFill(SomeRect). This can be up to twice as fast! Make your window an NSBackingStoreNonretained. Because it won't be stored, your drawing will be faster. Try and avoid [someNSImage lockFocus] at all costs. Always check to see if you need to update the sprite. If not, just return what you already had. lockFocus causes it to be recached, and that's very slow.

Great tips. Thanks!

Quote:3) Using an NSTimer is the way to go if you know you are not drawing too much stuff at once. This will make your game try it's best to go 30 frames per second, which is what you want. However, if you process slowly, you may miss a tick, and then you'll have to wait for the next 1/30 of a second to roll around. Also depends on what machine you target. On a G4, you'll probably never miss a tick unless you are doing extreme stuff.

I was going to go the Hooptie route and set the timer to fire more than I need to so if I do miss a tick I won't have to wait a whole 1/30 of a second to update.

Quote:I admit it, I'm biased, but http://homepage.mac.com/rjz7584 has many good examples of making games with Cocoa. (I'm the guy who runs it)

I'll check it out. Thanks.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Newbie book on cross-platform game making? and some questions... mac_girl 11 6,017 Feb 19, 2007 01:22 PM
Last Post: mac_girl
  Carbon C/ Cocoa API Questions Stalin55 3 3,179 Jul 3, 2006 02:07 PM
Last Post: OneSadCookie
  Noob Cocoa and Carbon Questions MonitorFlickers 15 6,071 Feb 23, 2006 06:01 PM
Last Post: Tesselate
  Pointer-related woes (C/C++) sealfin 2 2,509 Jan 18, 2006 01:22 PM
Last Post: sealfin