Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vertical retrace

My advise is to blit to an 8, 16, or 24 bit AGP OpenGL texture, draw the
texture on a quad, and let the OpenGL drivers worry about communication
between main memory and VRAM as well as frame buffer swapping. My limited
experience with a 450 G4 system is that Mac CPU->Bus performance is so bad
that attempting to write anything directly to VRAM is a horrible waste of
CPU time. It is much faster to write to main RAM and let dedicated DMA
handle the transfer to VRAM (at least in our test cases). Apple's Fast
texture demo,
http://developer.apple.com/samplecode/Sample_Code/Graphics_3D/OpenGLFastTexD
emo.htm, is the fastest way that we have found to get anything on screen on
a Mac. I don't know anything about OS 9 though.

Using OpenGL on OS X will also partially solve your problems with windowed
games and overlaid windows, menus etc. but has all of the associated
performance drawbacks of requiring bi-directional bus transfers.



----- Original Message -----
From: "Zack Morris" <email@hidden>
To: <email@hidden>
Sent: Thursday, September 12, 2002 11:20 PM
Subject: Re: vertical retrace


> Hi, this isn't exactly related to VBLs, but it IS related to flicker.
> We are having a problem where our games flicker. It only seems to happen
on
> Quartz Extreme machines. We think this is because we are unable to get the
> base address of the main device (since Quartz Extreme takes over the whole
> monitor with OpenGL). Sometimes we like to blit directly to VRAM to avoid
> the VBL pauses associatd with QDFlushPortBuffer(). Now our blits are
> getting skipped and only the flushing "shows". Are we right about Quartz
> Extreme and no longer being able to blit to VRAM?
> Is there a way to flush to VRAM without blocking in
QDFlushPortBuffer()?
> Like, unlock the window's pixmap, flush, do a bunch of work in the game,
and
> then only lock the pixmap while we need to draw to it? See? It seems to
me
> that if the window manager was designed correctly, the flush could almost
be
> offloaded and handled by another thread, another processor, or even the
> video card itself. This would actually give a huge speedup. But I think
we
> just leave the window locked all the time right so, so our flush (and even
> GetNextEvent()) takes 1/75 of a sec or thereabouts, so is pretty much
> unuseable. The GetNextEvent() flushes anything that has accumulated in
the
> dirty region I guess.
> Maybe we could try CopyBits() to the device. Perhaps it has low level
> access to VRAM? Any thoughts?
> Right now all of our games are horribly broken on OS X 10.2. We have
> even lost the ability to run our 8 bit games as 16 bit with a conversion
> blitter (we called it "High Color Mode"). Basically this was an ultra
fast
> blitter that took each 8 bit pixel and looked it up based on the current
> CLUT, and translated it to 16 bits on the main device. That way our games
> could look smooth for Aqua, even though they were 8 bit. The conversion
was
> essentially free, because the processor was just standing around with its
> hands in its pockets waiting for the slow PCI or AGP bus. We had even
> optimised the blitter to do multiple pixels at a time. But now that's all
> in the toilet, unless we can somehow use DrawSprocket() or some routine to
> get the base address of VRAM in Quartz Extreme. Doing a conversion in
main
> memory and then waiting for the flush is simply too slow.
> Sorry for the long letter, but we have been working a lot trying to
get
> our games running on 10.2 and simultaneously not ruin them for OS 9, so
> haven't had time to test all cases. If anyone has an 8 bit game with a
> windowed interface, they probably also know how much of a nightmare this
can
> be. An important side note is that it's very very ugly to run the game in
8
> bit under DSp, and then pause the context in order to show dialogs or
switch
> out of the game. That's what gave us the idea for high color mode, but
now
> we can't write to VRAM. Also you can't have an 8 bit window because the
> back buffer is 16 bit and this issue will never be resolved because 8 bit
> windows are not supported (according to Apple) Thank you for your time,
>
> Zack Morris
> Z Sculpt Entertainment
> email@hidden
> http://www.zsculpt.com
> _______________________________________________
> mac-games-dev mailing list | email@hidden
> Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/mac-games-dev
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
mac-games-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/mac-games-dev
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: vertical retrace (From: Zack Morris <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.