Subject:
RE: Drawing modes
From:
Greg Haerr ####@####.####
Date:
19 May 1999 17:39:07 -0000
Message-Id: <01BEA1EB.F76CC600.greg@censoft.com>
On Tuesday, May 18, 1999 6:44 PM, Alex Holden ####@####.#### wrote:
> After spending a while reading the Allegro code, though I don't really
> understand the bank code (it seems to be to do with making sure
> transactions are properly aligned)
The allegro bank code is some of the most *ingenious* code in
allegro, and is the basis for the trickery to make screen graphics memory
and offscreen graphics memory work the same with common drawing code.
It has nothing to do with allocating a separate buffer, and blitting. This is far
too expensive. Instead, the idea is, that all graphics primitives work on a "BITMAP *"
structure. This structure has both a start memory address, and a set of
banking code proc ptrs. All of the drawing primitives (of which bitblt is also
one) then draw onto the memory address in the BITMAP *. This writes bits
in either screen memory or offscreen memory. The trick is, that the bank
switch code for graphics memory actually switches graphics memory banks,
required by the hardware, while offscreen memory is instead "offseted" by
the total bank size, and the bits drawn there. Cool, huh?
, it does appear that all the drawing
> modes except plain old "set", do in fact read from the buffer, perform the
> operation, and then write it back. So if you do an XOR draw to the Frame
> buffer, for every pixel you write it reads one from the graphics device
> first (well, the banking code will speed things up for hlines() if I
> understand it right by reading several pixels at once, but you get the
> idea).
Don't get confused by the "read-modify-write" cycle that the EGA/VGA
controllers require for the damned hardware. It think this is what you're looking
at. The EGA/VGA doesn't require an rmw cycle for XOR, it requires it for all
writes, and the SET, AND, OR, XOR stuff is controlled in yet another hw register.
That doesn't stop you from allocating a memory buffer, performing
> the operations on that, and blitting the altered regions to the screen
> buffer if you want, but that isn't the way it works normally.
Think of blit as yet another drawing primitive, not the only one.
I'm going to
> get some sleep now, but I'll probably write the other drawing modes when
> I get up in the morning.
>
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
