NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/graphics/14271

Text File | 1993-01-28 | 3.8 KB | 71 lines

Newsgroups: comp.graphics
Path: sparky!uunet!ftpbox!news.acns.nwu.edu!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!haven.umd.edu!darwin.sura.net!spool.mu.edu!uwm.edu!rpi!utcsri!psych.toronto.edu!dstampe
From: [e-mail] (Dave Stampe)
Subject: Re: 256 color faster than 16 color ...why?
Message-ID: <[e-mail]>
Organization: Department of Psychology, University of Toronto
References: <[e-mail]> <[e-mail]>
Date: Wed, 27 Jan 1993 04:31:03 GMT
Lines: 60

[e-mail] (David Cornejo) writes:
>>    I've done some tests and found out that 256 is indeed much faster
>>than 16 color at the same resolution.  Why is this?  I tested
>>320x200x16 vs. 320x200x256, and 640x480x16 vs. 640x480x256, and
>>800x600x16 vs. 800x600x256.  I figure that that covered all the
>>memory ranges pretty well.  The 256 color out performed the 16 color
>>by anywhere from 10%-40%!!!   The only possible explantion I can
>>think of is that with 256 color they can to fast byte operations on
>>memory vs. messing around with 4bits and shifting and all that.  Is
>>this theory at all on the right track?
>
>I believe this is right or at least on the right track...
>
>In 16 color mode, the video memory is organized as 4 planes of 1 bit each,
>requiring a lot of diddling of I/O ports & masks before you output the pixel.
>Even when you write the pixel, you're not actually writing to the video
>memory - the card has to jump through some hoops to write it to the memory
>for you. In 256 color mode, I believe that you have direct (or at least
>fast buffered) access to flat video memory. Michael Abrash (I hope that's
>correct) covers this frequently in his column in Dr Dobbs, so you can check
>back issues for a better explanation (I'm doing this from memory). I think
>he has a book or a set of article reprints available too.
>
It depends what you're doing.  If you're doing pixel-by-pixel accesses
(drawing a non-horizontal line, or texture mapping as in Castle Wolfenstein)
then it's faster.  However, for almost anything else, multipixel accesses
are faster.

You can modify 8 pixels per access for fills with 16 color, and you need
2 accesses (read-modify-write) for fills that don't access the full byte
of pixels.  Use write mode 3, so you just load the color register once,
then use the pixel mask as the data.

For 256 color, use the X mode type of accesses to get access to 4 pixels
at once.  There are a number of techniques to use in this very nonstandard
mode, but you can do fills and masked writes much like 16 color.  This is
what Michael Abrash's articles discuss.

ADirect access speed: I've measured several cards, and the 256-color
access is not very much faster than the 16-color access, taking into
account the algorithmic differenced I discussed above.  Something like
20% less "stall" on a write access for 256 color, and it's not present
in some cards.

As an example: REND386.  Its blitter is twice as fast in 16 color mode as
in 256 color mode.  The 256 color mode uses a varient of X mode, and can
fill 20,000 polygons of 100 pixels each per second.  It can clear a
320x200 screen in 20 milliseconds (10 ms with ATI VGA cards).  All
the speeds are twice as fast with 16 color.  Of course, once the rest of
the renderer pipeline is added in, the speed difference between 16 and
256 color modes is only 25% or so.>
>

--------------------------------------------------------------------------
| My life is Hardware,                    |         Dave Stampe          |
| my destiny is Software,                 | [e-mail]    |
| my CPU is Wetware...                    | [e-mail]   |
| Am I a techno-psychologist, or just an engineer dabbling in psychology?|
---------------------------------------------------------------------------