[ryochiji]

I'm writing a 3D graphics engine (just for the fun of it) which is coming along just fine, except for one thing. I'm getting terrible frame rates from the renderer mostly because I'm using QuickDraw (in Carbon). Simply clearing the buffer and flushing it to the window gives me 31-33fps on my Pismo 400.

The question I have is, are there other alternatives to QuickDraw? Does anyone know anything about Quartz or CoreGraphics? Anyway to get some hardware acceleration?

I've considered using OpenGL to do the 2D stuff, but it's kind of an over kill, and besides, it defeats the purpose (okay, not that this project has any purpose to begin with, but that's besides the point).

TIA

[ryochiji]

Update:
I get decent performance if I set the screen to 16-bits (thousands) and use offscreen gworlds. Still not getting that 100+ fps that hw acceleration should give me though.

[ryochiji]

ack, double post

[ 06-03-2001: Message edited by: ryochiji ]

[beeduul]

Check out Stepwise's WWDC session coverages. There's some talk about the +/- of using OpenGL for your 2D graphics:
http://www.stepwise.com/SpecialCover...C2001/504.html

[aleph_null]

You can, of course, treat OpenGL as a 2D drawing environment if you really want to deal with the nitty-gritty details of 3D rendering. But ... why would you want to? (I know, I know... ) My impression is that there's still plenty of work to do on top of the projection, culling, lighting, etc, routines OGL will do for you to get a really nice engine going. I guess it does depend on which parts of the whole thing you're most interested in. I also believe you can customize the OGL pipeline quite a bit, via callbacks.

You should be able to use CoreGraphics for anything you can do with Quickdraw. I haven't used it myself, but from the WWDC session about it, it doesn't look too tough for basic drawing stuff. And you get alpha blending and transforms for free.

I don't know, but I'm guessing that, for now, here's how fast the various APIs will be, for your purposes:

1. OpenGL (2D or 3D)
2. Quickdraw
3. CoreGraphics

OpenGL has the "fastest pipeline in the system," as mentioned at the 2D graphics OpenGl WWDC session. And CoreGraphics would be much faster for a lot of complicated operations, but I think QD, being simpler, might have less overhead for such things as polygon painting, and so on. But maybe I'm wrong.

By the way, if you're on X, using Quickdraw in Carbon, you shouldn't need to use offscreen GWorlds. All windows on X are already double-buffered. Perhaps you're flushing too often?

g'luck


[edited: clarifying my highly-scientific speed ratings...]

[ 06-04-2001: Message edited by: aleph_null ]

[ryochiji]

Originally posted by aleph_null:
<STRONG>I guess it does depend on which parts of the whole thing you're most interested in.</STRONG>

What I have now is little bits of what would constitute an entire 3D graphics library (not just the engine). I have some routines for creating and managing 3D objects and worlds, and of course, some basic rendering. For an example, creating a cube and rendering it could be done in two simple lines of code.

Really, it's just one of those things I always wanted to do. I'm just re-inventing the wheel, but it's a good way to learn how the technology really works. So I have no ambitious goals other than to see how far I can go.

By the way, if you're on X, using Quickdraw in Carbon, you shouldn't need to use offscreen GWorlds. All windows on X are already double-buffered. Perhaps you're flushing too often?

Yes, in theory. But for some reason, drawing to an offscreen gworld and then copybit-ing that to the window buffer is faster than drawing directly to the window buffer (go figure).

(See below for latest update...)

[ryochiji]

Update:

I've discovered that flushing the window buffer is actually a major bottleneck (commenting out QDFlushPort (sp?) increases frame rates 150-180%). And because buffer-less windows apparently never really worked on OS X, I've all but ruled out the QD route.

The approach I'm investigating now is CoreGraphic's DirectDisplay API. From what I can tell, drawing directly into the display's bitmap is the only way I can draw directly to the screen, under OS X. Or more specifically, I'd draw into a buffer, and blit that to the display bitmap.

I'll keep posting my progress on this forum, just in case there are any secret followers :-)

[swcrissman]

I take it you would have already, but have you looked at any of Apple's sample game code w/ draw sprockets? From what I understand, Drawsprocket is alive and well under OS X, and I know it has excellent 2d calls to make use of.

Also, Another forum you might want to post on for this particular type of question is the idevgames.com forum, which is a mac gaming community site. They have several tutorials on various graphics methods, and there are some very good game programmers who frequent the forums there that can probably answer this particular type of question very well.

Hope that's helpful.

Spencer

[PMan88]

On a related topic, is there anyway not to use Quartz and instead use QuickDraw. Think of how fast this could speed up your system. No PDF-decoding all the time for your processor.

[ryochiji]

Originally posted by swcrissman:
<STRONG>I take it you would have already, but have you looked at any of Apple's sample game code w/ draw sprockets? From what I understand, Drawsprocket is alive and well under OS X, and I know it has excellent 2d calls to make use of.</STRONG>

Actually, that's one solution I hadn't considered. For some reason I was under the impression that DSp was less than "Alive and well" under X. Obviously, I was wrong. I haven't had time today to read up on stuff, but it seems like a viable solution.

[ryochiji]

Originally posted by PMan88:
<STRONG>On a related topic, is there anyway not to use Quartz and instead use QuickDraw. Think of how fast this could speed up your system. No PDF-decoding all the time for your processor.</STRONG>

Well, QuickDraw seems fast enough, but flushing the buffer to the window seems slow.

So what I'm _really_ looking for is a fast way to flush my offscreen gworld (under QD) or CG context buffer to the screen. One thing I haven't tried is to make an offscreen gworld in vram, which possibly may solve this problem.

Anyway, to answer the question, to the best of my knowledge, when you use QuickDraw, you don't use Quartz. So yes, there is a way to not use Quartz (at least in Carbon apps -not sure about Cocoa).

[PMan88]

I don't really understand offscreen gworlds, because I'm just getting in to Cocoa. What I was wondering if there is someway to re-route all functions and subroutines that draw with Quartz to instead draw with QuickDraw for the whole OS. This could speed up the OS a lot, because graphics cards are accelerated for QuickDraw, not Quartz.

[aleph_null]

Originally posted by PMan88:
<STRONG>What I was wondering if there is someway to re-route all functions and subroutines that draw with Quartz to instead draw with QuickDraw for the whole OS. This could speed up the OS a lot, because graphics cards are accelerated for QuickDraw, not Quartz.</STRONG>

"Quartz" actually encompasses more than the drawing routines. It's a part of, or is identical with -- I'm not sure -- the OS X native window server architecture. The window server is pretty much embedded in OS X, and all of X's fancy graphics tricks depend on its core functionality.

So actually, when you use Quickdraw on OS X, you're also, unavoidably, using Quartz. This is true at least to the extent that the Quickdraw algorithms write to pixels in a CoreGraphics Context, and so those pixels may be treated as any other CoreGraphics context. This is why the OS can do the genie trick thing on a window whose contents are drawn by Quickdraw. Unlike in Classic, where you could get pretty easy access to hardware and draw directly to the screen, all drawing in OS X must be mediated by the window server. (Which means you might not be able to write to a GWorld in VRAM, ryochiji. In fact, a recent discussion on a dev list I subscribe to seemed to indicate this was the case on OS X. But I'm not 100% sure of that.)

So Quickdraw itself is not too different in X, but it really sits inside of Quartz, and couldn't be substituted for it.

(Other window managers may be run on top of Darwin, of course, including something that has a Quickdraw-like API, but then it wouldn't be Apple's version of OS X.)

hope this made some sense....

[ 06-06-2001: Message edited by: aleph_null ]

[ryochiji]

I've finally had some time to work on this project (Yay, Sunday!). I was able to nearly double the frame rate by using DrawSprockets, which is still incomplete in OS X, but useable. I'm getting 53fps in a 640x480 @ 16bit/pixel context, which is much better than the 27fps I was getting in a normal window of the same size (with the monitor set to 16bits).
Presumably DrawSprockets uses HWA when available (and I'm assuming it is on my Pismo), but if that's the case, I'm not sure how OpenGL gets 100+ fps on the same machine at higher resolutions... Must be some low-level magic.