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

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.
References: 
 >Re: vertical retrace (From: Michel Colman <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.