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: Annoying CGDisplayCapture Fades?

> But the question that is nagging me is why are you trying to prevent
> the volume popup?

Well, I can go on a rant so long that you wouldn't believe it. What it
comes down to, is that apple has abandoned 8 bit windows on OS X (also
640x480 for BeginFullScreen...a tragic decision). This means that all of
our old games are horribly incompatible with OS X. You'll notice that our
game engine has always been able to show and hide the menubar/dialogs etc.
during the game. In 9, our games lived happily with the mac interface.
In X, apple never bothered to smooth the windows and menus with a
correct palette when you go to 8 bit mode (so it's dithered and ugly). Our
solution is to run the game in 16 bit mode, and do a blitter from 8 bit to
16 bit directly to the monitor when the menubar is hidden.
Over the AGP, this means that we spend all the time waiting for the
bus, so we don't lose much with the translation. It's less than twice as
slow to blit directly to a 16 bit monitor.
When the menubar becomes visible, or we go to a window instead of full
screen, we blit to the back buffer and then do a normal flush to the screen.
That is okay since people assume a window will run slower and more laggy
than full screen. But think about that 8 bit to 16 bit conversion. Even
with our best blitter, it's essentially a 1 pixel at a time operation (we've
optimized it to 32 bits by doing 2 pixels at once, but that doesn't help
much). Translating to the back buffer of the window and flushing to the
screen is MUCH slower than drawing directly to the screen. It's something
like 4 times slower to translate, and then twice as slow to copy to the
monitor.
ANYWAY our fast blit to the monitor breaks a lot of rules. If we don't
take over the monitor with CGDisplayCapture(), the window manager fights
with us if we cause the volume popup. We see a black box behind it because
it's trying to copy the back buffer of the window, which has been skipped
since we did a blit from our own buffer to the monitor.
If CGDisplayCapture() wasn't ruined, we would just take over the screen
when the menubar hides, and put the monitor back when it shows. Apple has
decided that lots of fades and flickers are more "convenient" than a simple
takeover.
What this all comes down to is that we might be trapped into blitting to
the back buffer and flushing to the screen. I believe that BOOM does this.
Sadly, this is not an option for an old-style scrolling game like our Retro.
The first iMac is marginally fast enough to run the game this way. It is
several times slower than running the whole game in 16 bit mode! That is,
if we were to convert the graphics to 16 bit as we draw them to the gworlds
and spend god knows how long reprogramming our sprite routines for 16 bit
(some of which we have already done though). Oh, and take a double-memory
size hit too. This is insanity when Retro ran just fine on my old 7200/75.
This is the tip of the iceberg. It would take a small book to go into
depth about palettes/cluts, why we were forced to use drawsprocket, infinite
incompatibilties with CoreGraphics and switching an app out, blah blah blah.
I added it up, and my partner and I have lost about 1 man-year of work to
carbonization. That's why our website has been so stagnant. That's why you
don't see old 8 bit games being carbonized, or if they are, they show no mac
interface (menus, dialogs, etc). If we were a larger company and didn't
have day jobs, we would have closed our old games and written post mortems.
We are small enough that we actually can take the time to carbonize our old
games and not alienate our users.
Oh, and believe it or not, what little money we make comes mostly from
these "primitive" 8 bit games. I don't mind saying the I feel betrayed by
Apple and can see DRASTIC room for improvement in huge sections of the
Carbon API and imported CoreGraphics functions. Don't get me wrong, I
actually like OS X now and use it full time (haven't gone back to 9 since
Jaguar came out, ha ha). But our programming lives have been a living hell
since OS X was released.
I simply need a way to take over the monitor seemlessly. DrawSprocket
has lots of flickers and flashes. BeginFullScreen used to work but I just
got an email that evidently it has some problems in 10.2.
CGDisplayCapture() has extraneous flickers. Shoot, this turned into another
rant! Sorry for the long letter,

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: Annoying CGDisplayCapture Fades? (From: David Duncan <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.