On Friday, February 21, 2003, at 02:23 PM, Woody Zenfell, III wrote:
> On Friday, February 21, 2003, at 01:01 PM, Br'fin wrote:
>> Seems like there should be a less memory intensive way of fading out
>> the other monitors, go figure.
> FWIW when I wrote a small Mac game many, many years ago, the preferred
> way to fade the screen was through "gamma fades"; IIRC, there was a
> small freeware library called ColorGamma or something that I used.
> Anyway, my game simply left the non-game displays faded down to black
> (except when the menu was displayed or the program switched out, of
> course). This may have other unpleasant effects (esp. in the case of
> a disorderly program exit), might not have worked on all Macs, or may
> not even be relevant anymore... but it didn't require the creation of
> any additional windows etc.
At least MacOS X wise, a failed program is just tossed out and system
Gamma resets on its own it would seem. Though a consideration for other
platforms. My biggest problem, if anything, is that I never got
multiple monitors working on MacOS X, then again I don't have a second
monitor to play with.
A bigger color related problem is 256 colors under MacOS X, oof.
> Oh and on the main window being stretched to fill the screen - is that
> a good thing? (Note to the casual reader - this is entirely different
> from the "Fill the Screen" checkbox which adjusts the display's
> resolution (in some cases).) Would it be cheaper memory-wise,
> blitting-wise, etc. to use a totally black window in the background,
> whose contents might be able to be represented very efficiently, and
> whose contents never change, and a smaller full-color window that is
> sized to fit the portion of the display that's actually used? (I'm
> sort of making this up as I go along... :) not sure how these things
> really work out in practice.)
Cheaper memory wise, probably makes changing screen-size mid game a
touch problematic. Especially for AlephOne and it's larger screen
sizes. Doesn't really add any excess to copying because update_screen
was already focusing on only a part of the screen.
The bigger overhead for software mode comes in the accidental triple
buffering since AlephOne Carbon doesn't account for the MacOS X window