Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!ucsd!helios.ee.lbl.gov!pasteur!cory.Berkeley.EDU!fadden
From: fadden@cory.Berkeley.EDU (Andy McFadden)
Newsgroups: comp.sys.apple
Subject: Re: //gs screen resolutions...
Message-ID: <21930@pasteur.Berkeley.EDU>
Date: 9 Feb 90 17:50:51 GMT
References: <10078.infoapple.net@pro-generic> <12109@smoke.BRL.MIL>
Sender: news@pasteur.Berkeley.EDU
Reply-To: fadden@cory.Berkeley.EDU.UUCP (Andy McFadden)
Organization: University of California, Berkeley
Lines: 27

In article <12109@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <10078.infoapple.net@pro-generic> sysop@pro-generic.cts.com (Matthew Montano) writes:
>>Some of the newer ones are 640*4X0 resolution still in 16 colors, and
>>they sometimes over power the hardware. Do you know how much 640*400*16 takes
>>up in memory? How about 256 colors per pixel... forget it.
>
>640*400*4 bits (for  16 colors) = 128K bytes
>640*400*8 bits (for 256 colors) = 256K bytes
>
>Hardly out of the question.

...unless you're trying to animate it.  There *are* some interesting things
you can do with color cycling, especially if you have 256 different values for
each pixel (any chance of getting 8-bit values for each R,G,B while we're at
it...?).  Unfortunately it gets more complicated if any of the images overlap.

Still, you could do some things (like moving "stars" to give the impression of
motion) this way while using more conventional means to do others.

Anyway.  While it certainly isn't beyond the //gs (present or future), I'd
have to wonder of 640*400*8 bits is really necessary for anything other than
static pictures (how many desktops really need that much color?  How many
desktops does it take to screw in a lightbulb?)

-- 
fadden@cory.berkeley.edu (Andy McFadden)
...!ucbvax!cory!fadden