🚀 go-pugleaf

In article <Bw2z59.AM5@news.cso.uiuc.edu> jas37876@uxa.cso.uiuc.edu (John A. Slagel) writes:
>     2. Along the same lines, add another feature to the replace the logical
>	AND feature when writing pixels to something like IF, which only
>	changes the screen pixel if the one you're writing is non-zero.
>	This would allow the use of REP MOVSB with odd-shaped sprites. But
>	then, *GASP* we would only have 255 colors instead of 256 !!!!
Why not implement a skip/draw decoder ? 
It works this way:
a) set line_lenght register (note ,regular vga has a register like this
                             you just have to expand its use)
b) set pen_pointer register (kinda raster pointer)
b.1) set line_pointer (same value of pen_pointer so this can be set
     in the same access if the card designer has spare space for the
     support circuits needed)
c) send image description bytes to the display memory window using REP MOVSW
   ( this way you can move 16 bit in one shot)
   (an 8 bit card could serialize access, while a 16 bit card could pump
    in data at top speed)
   thru a decoder working this way:
     value:            action:          pseudocode:
   data byte == 0      go to next line (add line_lenght to line_pointer
                                        mov line_pointer to pen_pointer)
   data byte > 127     plot pixel      (mov (data_byte-127) to [pen_ponter++] )
   0 < data byte < 128 skip pixels     (add data_byte to pen_pointer)

A decoder like this could speed up odd-shaped sprite drawings
( more than an odd-shaped sprite drawing using a "don't draw" value)
and add a little sprite data compression ( a sequence of "null" pixels
becomes just one byte)
A sequential machine doing this decoding is easy to implement.
Sprites would have just 128 colors instead of 256
(but background would have 256 colors as usual)
think i can live with so little colors :-) .
Note:
Flipping left/right or upside/downs such sprites wouldn't be a big problem
(just add 2 direction flags to the decoder (one for lines & one for rows)
 the way the D flag works for MOVSB/MOVSW & thinker with the initial values
 of line_pointer and pen_pointer before drawing and when changing line )
Note 2: 
Yeah! this make the skip/draw sprite editor a little more complex than a
"plain sprite" editor,it needs an encoder/decoder routine added to the
usual code ( this way you edit a matrix of points & later you encode it
when saving to file or before animation).



Lorenzo Micheletto mike@sabrina.dei.unipd.it

p.s. Forgive my possible mistakes, usually i write in italian
     (but can understand english very well)