Fastest way to draw?

ibullard
Unregistered
 
Post: #1
I've been searching for a couple of days now and I'm at a loss. All I want is a double-buffered screen (both full-screen and windowed versions) so I can blit my screen onto the backbuffer ad flip it onto the screen in the fastest possible way.

In my search for the answer, I've come across several API's that seem to do what I want: QuickDraw, DrawSprockets, Quartz, and DirectDisplay. It's frustrating because nobody comes out and tells you what to use for MacOS X.

The Quartz way to do it was covered in another thread here but it was also stated that it's not the fastest way (just the easiest).

QuickDraw is spoken of like it's the red-headed step-child that no one likes but seems to do what I want it to do (although the available samples are confusing).

DrawSprockets appears to be mainly OS 9, I see very little/no mention of using it for X.

DirectDisplay seems to only provide gamma fades, screen resolution changes, and access to the screen itself. No double-buffering, no flipping, etc.


It seems the fastest way to have a double-buffered OS X game is to use a combination of DirectDisplay, Quartz, and QuickDraw. Am I on the right track or just reading water?
Quote this message in a reply
ibullard
Unregistered
 
Post: #2
That last part should read "treading water." Grin
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #3
The fastest way will be OpenGL Smile

QuickDraw should perform well, too, as windows in OS X are already double-buffered, so that part of the equation is easy. Basically there are only two things to worry about with QuickDraw -- GWorlds and CopyBits.

I would use one of DrawSprocket and CGDirectDisplay to go to full-screen (probably CGDirectDisplay), and one of Quartz, OpenGL and QuickDraw to do the drawing (probably OpenGL).

My opinion there, of course.
Quote this message in a reply
Member
Posts: 269
Joined: 2005.04
Post: #4
DrawSprocket is OS 9 only. You can count it out. Quartz produces some stunning graphics, and is very easy to use, but it is sloooooooow. QuickDraw (GWorlds, CopyBits, etc) is certainly the hardest way to go, but it's the only way to go if you want speed. It's also the only way to go if you want to support OS 8/9 as well as X. I've never heard of DirectDisplay, so I couldn't say anything about it.

Want an easy route that's also fast? Go with SpriteWorld. Although the most current stable release isn't carbonized, you can get an alpha carbonized version here. As just a comparison, on my G3 with the SwirlyX example from Cocoa Sprite Kit (which uses Quartz) I get 8fps (no, I'm not lying). With a similar sprite test from SpriteWorld I get over 200fps.

So it's either require a G4 and use the incredibly easy Quartz (and get beautiful anti-aliasing and other effects) or go the harder and faster route with QuickDraw/CopyBits/GWorlds. If anyone knows a way to actually get acceptable speed out of Quartz I'd love to hear it. I'd much rather use Cocoa and Obj-C, I just can't justify the massive speed hit.
Quote this message in a reply
ibullard
Unregistered
 
Post: #5
I plan on making an OpenGL version of my renderer but it'd require a lot of video RAM to work well so I'm making a software renderer first. I'm using my own blitters because I'm blitting compressed images (RLE/VQ compression), which is why I want such low-level access and sprite libraries won't help.

So all I need is a pointer to an offscreen buffer to draw to and a way to display the buffer in full-screen and in a window in OS X as quickly as possible. Heh "All I need". No biggie.

So it sounds like I should start reading up on Quartz for windowed mode, DirectDisplay for full-screen, and QuickDraw for both (accessing the buffer, clearing the buffer, accelerating uncompressed blts)?

Oy. Apple needs to work on it's "commitment to gaming." Doing this on windoze is a lot easier.

Ian
Quote this message in a reply
Member
Posts: 269
Joined: 2005.04
Post: #6
Quote:I'm using my own blitters because I'm blitting compressed images (RLE/VQ compression), which is why I want such low-level access and sprite libraries won't help.

Well, SpriteWorld supports RLE sprites and it also has a custom blitter called BlitPixie that is insanely fast.

Quote:Oy. Apple needs to work on it's "commitment to gaming."

Tell me about it. ^_^
Quote this message in a reply
Unregistered
Unregistered
 
Post: #7
Quote:
Well, SpriteWorld supports RLE sprites and it also has a custom blitter called BlitPixie that is insanely fast.

I'm all for libraries and free code when you're just trying to make a game. However, my goal isn't just to make a game. I want to learn the Mac platform, including assembly language. Using someone else's sprite engine just takes away all my fun.

Ian
Quote this message in a reply
ibullard
Unregistered
 
Post: #8
I found an excellent example of what I want in the Quake source code on this website, in case anyone else is interested.

Ian
Quote this message in a reply
wally
Unregistered
 
Post: #9
I wouldn't worry about using too much VRAM in OpenGL. OpenGL is smart about memory usage when space gets tight by using LRU/MRU texture paging. Also, you can disable MIPMAPS so that there is only one version of your texture stored on the card.
Quote this message in a reply
ibullard
Unregistered
 
Post: #10
I used to work in the driver group at ATI so I have a pretty good idea of what goes on in both OpenGL and Direct3D.

That said, using OpenGL for a 2D game is really only a good idea with the current set of video cards that have DXTC compression and high amounts of video RAM (16MB maybe, 32MB is better). That cuts out a lot of machines that can run the game. Even with DXTC, I can only get 4x-6x compression of images but with VQ+RLE I can get 12x-16x compression. That means the difference between 32MB-48MB and 96MB-128MB of images in 8MB of RAM.

All numbers aside, I'm doing this for fun. I love writing assembly and tuning blitters and I like the old skool games so I'm doing this the hard way. I plan on making a version of the engine that uses OpenGL to draw but I do that sort of thing in my day job so it isn't all that fun for me.

Ian
Quote this message in a reply
peacha
Unregistered
 
Post: #11
You really worked for ATI?
Well, do you know if they are working on the drivers for my poor old Rage Pro Mobility? If I knew how to make video-card drivers I would have tried (said tried) to make one myself :eek:
Quote this message in a reply
ibullard
Unregistered
 
Post: #12
I left ATI to enter the game industry about four years ago so I can't tell you for sure but I highly doubt that they have anyone working on it. When I was there we fixed a couple of bugs in drivers for the old cards but that wasn't the normal situation. For the most part the Rage Pro has probably been put out to pasture.

Please note that I'm speaking from past experiences, I'm not an employee of ATI, and I do not speak for ATI.
Quote this message in a reply
peacha
Unregistered
 
Post: #13
I hate bugging (begging) people, but... could you please give me some info in order to try making a minimal driver... don't you have any snippet/knowledge for a video driver usable on OSX? (I know my question might seem absurd, but...). As far as I know drivers "just" put/get data in/from of communication ports... maybe knowing which ports and what data in which context... At least I would have something to start with Grin

(How cool would a project on iDG be to make a driver for the poor OSX souls using old iMacs/iBooks Cool, that would mean good publicity for "our" community too).
Quote this message in a reply
CMagicPoker
Unregistered
 
Post: #14
Im interrested about that too :-D

My poor imac 333mhz. How slow is OSX on it? I dont know, didnt bought it because of that :-(

I think it's one of the reasons why Apple chose the opensource way.
Us the poor guys we have to do all the dirty jobs while Apple can play with its Extreme Quartz toys.


about the original question...
If the 3D card can do it it will probably be faster than in software.

If what you want is a software rasterizer, you should draw in local ram (the cheap ram, the 128mb for 25$, this kind of ram) and when youre done, copy the entire thing on screen, using CopyBIts I think.
If your AGPXx makes it faster to draw dirrectly on vram, draw in the backbuffer and switch them when youre done.

I am not sure if im right, sorry.
Quote this message in a reply
ibullard
Unregistered
 
Post: #15
It's not quite that simple. You have to map the hardware's capabilities to the API which can be a complicated task (if not impossible for some hardware/API's). As an extreme case, imagine trying to create an OpenGL driver with a 3D card that doesn't support textures. Now that isn't the case here but it gives you an idea of what you have to deal with. The less the hardware matches the API, the more work you have to do.

That said, I'm going to stop talking about it right here. As a former ATI employee with proprietary knowledge (and a extreme desire not to get involved with driver development again) I don't feel comfortable discussing details. Sorry.

Ian
Quote this message in a reply
Post Reply