Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!uunet!munnari.oz.au!brolga!uqcspe!batserver.cs.uq.oz.au!warwick
From: warwick@batserver.cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Fast Raster Routines Needed.
Keywords: TT video modes
Message-ID: <7125@uqcspe.cs.uq.oz.au>
Date: 31 Jan 91 23:56:57 GMT
References: <1991Jan23.005852.28904@sbcs.sunysb.edu> <1991Jan31.183155.8948@ataritx.uucp>
Sender: news@uqcspe.cs.uq.oz.au
Reply-To: warwick@batserver.cs.uq.oz.au
Lines: 27

In <1991Jan31.183155.8948@ataritx.uucp> dwh@ataritx.uucp (Dave Hanna) writes:

>In article <1991Jan23.005852.28904@sbcs.sunysb.edu> mrose@libserv1.ic.sunysb.edu (Michael Rose) writes:
>>	Also, does anyone know how the bit planes are set up in the new
>>TT specific graphics modes?  In the 320x480x8 mode, does one byte equal
>>one pixel?  

>    NO!  The 320x480x8 mode is merely an extension of the X 2 and X 4
>planar modes:  2 bytes hold plane 1 data for the first 16 pixels, followed
>by 2 bytes for plane 2 for the first 16 pixels...

Which is just as well !  Who wants 256 colour sprites????  Can you imagine
how SLOW it would be to draw up a sprite if you HAD to set all bitplanes?

One common way for Fast Raster Routines (ie. the subject line), is not to
draw on all bitplanes.  That is why we have them that way.

Perhaps Michael has too many fond memories of 8 bit Ataris, when you only
had 2 bits per colour index anyway, so it didn't matter.

I imagine there is also a hardware concern that places bitplanes as they
are too, if anyone could expound?
--
________________________________________________________

	This .signature intentionally left blank
________________________________________________________