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

Another OpenGL technique is to use glDrawPixels(). I understand that it is
much faster in 10.2, but I have no used it in a long time because it is
typically much slower than using textures. glDrawPixels() has the advantage
of always working with non-power of 2 image sizes, but it has the
disadvantage of not working correctly when the lower left corner of the
drawn image is off screen for some reason...special case code is needed to
prevent that in some games.

We did a quick and dirty port of a DirectDraw 2D game that on Windows writes
directly to the frame buffer. We used 1024x512 and a 1024x256 OpenGL
textures (together they make 1024x768), modified the game code to draw into
them instead of the frame buffer, and then use OpenGL to draw the textures.
That was the only way we achieved reasonable frame rates, and the game still
requires a Mac that costs 2-3 times as much as a PC that will give the same
or better frame rate...

For games, the performance gap with Wintel is getting bigger and bigger
instead of smaller as far as I can tell, and that is really a shame, because
I much prefer developing on the Mac. There are issues with drivers, card
availability, poor memory/bus performance, very slow CPUs by "modern"
standards, tools support, and culture for games. Apple does not seem to
benefit from Moore's law as much as the competition does, and the compound
interest when it comes to the game performance gap is a real killer :(

I love to program on the Mac, and I hope that the situation improves soon.


----- 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.