[Stevos]

I need seriously fast graphics. I really don't want to touch OpenGL if I can avoid it.

What I'm doing is writing a game, somewhat similar in feel and such to the Legend of Zelda: A Link to the Past for Super Nintendo. My Nintendo cost like a hundred dollars...here on my $3000 piece of hardware, I should be able to recreate that performance.

Someone is going to say I ought to just use Carbon if I know what's good for me. I don't want to use Carbon =]

Hopefully Apple can speed up NSImage and NSView in 10.4, because imo I shouldn't even think about optimizations until I've got something working...but my initial steps show that getting something working depends GREATLY on optimizations.

Any help? Even if you just write "Use OpenGL or Carbon" that might be OK. I just don't see why Quartz is so darn slow.

[smeger]

You're going to get better performance if you use OpenGL or Carbon, if for no other reason than that calling a function is way quicker than sending an Objective-C message.

But, if you decide to use Cocoa, here are a few things that can speed things up. In your NSView subclasses, override isOpaque whenever possible to return YES. Check out NSInvocation - you can avoid messaging overhead by using it. Panther adds some new compositing options in NSView that'll let you do some optimization in your drawRect: method. Try to use NSCell subclasses inside of a one NSView subclass instead of doing a whole bunch of views.

Good luck!

[11011001]

Seriously, for simple 2D graphics OpenGL is not a large obstacle. In fact it's very simple. In the time it will take you to learn some other API to do your fast graphics you can learn everything you need to do them in OpenGL.

Go through the tutorials at NeHe. I got up to tutorial 15 in a day. Serious. OpenGL is that SIMPLE. You only need up to like tutorial 10 or so.

Anyways, you'll want to set the width of your OpenGL view port, or whatever it is, to whatever resolution you want. This will give you OpenGL coordinates that map directly to pixels.

[VLich]

Many of the Cocoa drawing classes are designed to be easy to use rather than fast. (As far as I know there isn't any Cocoa fullscreen support either). You can do all of your drawing outside of Cocoa routines and use NSBitmapReps to blit images to the screen. This technique will probably be fast enough, but writing all of that graphics code could be a pain. At any rate, try to keep the number of NSViews, NSImages, etc to a minimum.

If you really want fast graphics, I second the OpenGL suggestion. You could write a few simple classes that wrapped the OpenGL calls and use them draw your sprites. You might also look into a toolkit such as SpriteWorld, although I don't think any are written for Cocoa/Objective C.

One further note, If you are using NSBezierPath to draw and fill simple shapes you can replace them with the simpler graphics functions like NSRectFill(). I don't know how much faster they are, but at the very least they don't seem to anti-alias by default.

[Chuckit]

Originally posted by VLich:
(As far as I know there isn't any Cocoa fullscreen support either).

Actually, Cocoa does support fullscreen. (Specifically, Cocoa links with CoreGraphics, which provides functions for capturing the screen.)

Originally posted by VLich:
You might also look into a toolkit such as SpriteWorld, although I don't think any are written for Cocoa/Objective C.

There's Cocoa Sprite Kit. Performance-wise, I'm told CSK is kind of iffy, but it's probably more mature than an app that hasn't even been designed yet.
Unfortunately, it doesn't seem to have been updated in almost two years.

[absmiths]

Originally posted by Stevos:
I need seriously fast graphics. I really don't want to touch OpenGL if I can avoid it.

What I'm doing is writing a game, somewhat similar in feel and such to the Legend of Zelda: A Link to the Past for Super Nintendo. My Nintendo cost like a hundred dollars...here on my $3000 piece of hardware, I should be able to recreate that performance.

...

Hopefully Apple can speed up NSImage and NSView in 10.4, because imo I shouldn't even think about optimizations until I've got something working...but my initial steps show that getting something working depends GREATLY on optimizations.

First of all, ANY serious game design must consider optimizations up front. If you need seriously fast graphics, then you need seriously well designed code (In addition to using the right API).

Secondly, don't underestimate your poor little Nintendo. That machine was designed specifically for gaming, and some serious optimizations went into it.

Thirdly, I wouldn't wait for Apple to make serious optimizations to standard general-purpose API classes since these classes are used EVERYWHERE and perform as required most of the time. To add performance enhancements which a game designer might need would increase the memory footprint of each instance and likely break expected functionality (Like when SUN added automatic double-buffering to Swing and you instantly had classes performing triple and quadruple buffering because that feature wasn't there early on).

Lastly, I would use a more appropriate language like C/C++ which would make the high performance goal more achievable at the expense of added difficulty all-around. That said, the Omni Group has ported some nice-looking games which seem to achieve very nice performance and I think they are written in ObjC. I would bet, however, that they don't use stock classes exclusively.

[djohnson]

I am guessing the Omnigroup is using some custom frameworks for their graphics. I am currently looking into OpenGL. Looks pretty good since this is basically what it was designed for. It will do 3D and 2D graphics no problem.

From what I can tell, OpenGL is exactly what you want. I have a game idea similiar to what you are wanting and I will use OpenGL. Trust me on this. 8)

http://www.opengl.org

[Angus_D]

Originally posted by djohnson:
I am guessing the Omnigroup is using some custom frameworks for their graphics.

No, they use OpenGL. They obviously won't use Objective-C extensively as most of the code will all be cross-platform C/C++, they just use Obj-C for setting up the environment.

[djohnson]

Ok, I stand corrected.