mrose@libserv1.ic.sunysb.edu (Michael Rose) (01/23/91)
Hello everyone in Net-Land!!! I was wondering if anyone has or knows of a place where I could find a fast raster drawing routine? I am espescially interested in Low resolution color and monochrome. 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? Life would be so much easier if Atari had set up the screen memory this way, so that raster operations could be performed extremely easily and quickly. Thanks! Take care! ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^_^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ < Michael Rose |Quack! _/.\ | "It is unnatural in a large field > < mrose@ic.sunysb.edu |Quack! /\ -===-/| to have only one shaft of wheat > < mrose@ccvm.sunsb.edu|QUACK! \____/ | and in the infinite Universe only > < mrose@sbccvm.bitnet | _||_ | one living world." - Metrodorus > v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v
dwh@ataritx.uucp (Dave Hanna) (02/01/91)
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... >< Michael Rose |Quack! _/.\ | "It is unnatural in a large field > -- Dave Hanna Atari Microsystems Corp UUCP ...!texsun!letni!ataritx!dwh ...!ames!atari!dhanna
warwick@batserver.cs.uq.oz.au (Warwick Allison) (02/01/91)
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 ________________________________________________________
lunnon@qut.edu.au (02/02/91)
In article <7125@uqcspe.cs.uq.oz.au>, warwick@batserver.cs.uq.oz.au (Warwick Allison) writes: > 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? Arrrgh, Warwick !! The Bitplane arrangement in the ST is lousy for software ops there is no reason to set up more than one plane for some operations whether the planes are interleaved or not. The arrangement in the ST is the result of some very simple DMA hardware which is used to read the video memory. > > 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. See above: The ST way is slow for software no matter how many planes you want to draw on. Only the IBM PC is worse. > > 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? > -- Ok. Ill have a go ( Did you expect anything less ? ) This is guess work but from an engineering point of view this is probably what happens. The Video memory is arranged in words, the same pixel from one two or four successive words are used to form the index into the clut ( Colour lookup table ). The reason for doing this is pretty obvious, since we have 3 modes it is simpler to read n words and always combine the bits in the same way than to combine successive 1 2 or 4 bits within words differently between modes as on a PC thus in low rez the state machine loads 4 registers with memory values. At each video clock interval each of the location is shifted once (left I think ) and a bit falls of the end of each register which are combined in a 1,2,4,8 type way and used to index the clut. In Med then only two fetches are done to register val one and 2 and 4 and 8 are left cleared (twice as fast of course ) the lower two bits of the 4 bit index then is only significant. In high rez only one register is loaded 4 times as fast (well thats the theory although mono timing is different ) All this makes mode switching little more than a counter and a couple of decoders, pretty trivial really. Note that the DMA machine then is not required to permutate its counting in order to access different memory regions ( Which is all that would really be required to have logically distinct planes ) In fact separate bitplanes probably would be trivial al that would be required is to use ( Programably ) the 2 highest bits b15 and b14 in the dma counter as the LSBs on the bus and just b15 in med (of couse this means shifting all the address lines down by a bit to change modes :-) Of course now somebody at Atari will probably send me a big flame and tell me that things are actually different, but do I care ??? No This fits the model and will do for me :-) BOB R.Lunnon@qut.edu.au > ________________________________________________________ > > This .signature intentionally left blank > ________________________________________________________
warwick@batserver.cs.uq.oz.au (Warwick Allison) (02/04/91)
In <1991Feb1.032905.15481@ncsuvx.ncsu.edu> bmott@hobbes.ncsu.edu (Bradford Mott) writes: >> 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? >Actually, if 1 pixel = 1 byte it would be much faster to draw a 256 >color sprite. TRUE! BUT IT IS TOTALLY UNREALISTIC TO WANT 256 COLOURS ON ONE SPRITE!!!!! With only 4 colours, you often use all colours. With 16, you MIGHT consider optimising code that only draws on 3 bitplanes. But with a 256 colour system, you would be crazy to use ALL bitplanes in EVERY sprite. Take the following scheme as an example: 1. Player 1: 8 colours, 0..7 3 bitplanes 2. Player 2: 8 colours, 8..15 4 bitplanes 3. Baddies : 48 colours, 16..63 6 bitplanes 4. Scenery: 192 colours, 64..255 16 bitplanes Now, if the players never overlap on the scenery, it's okay, you don't have to worry about the other bitplanes. If you want players over the scenery, the make it only on, say 16 of the scenery colours - saving bitplanes. If you try to use ALL bitplanes ALL the time with EVERYTHING on the screen, then a machine running at 32 MHz (TT) will be as slow as a 8 MHz (ST) machine for executing graphics operations. Further discussion on this line should probably be in rec.games.programmer! -- . __ |\ warwick@batserver.cs.uq.oz.au: _/ |___/ \ Warwick Allison, / \ Computer Science Department,