Re: Color fringe hires behavior

["BLuRry" <brendan.robert@gmail.com>]

Michael J. Mahon wrote:
> BLuRry wrote:
> > I've been trying to figure out a way to render hires to a double-hires
> > bitmap, but also taking into account the odd combinations of color
> > frindges.  See the following example paraphrased from Sather's book
> > below:
> >
> > 1 hgr2:for a=1 to 3:read c:hcolor=c:read n:for b=1 to n: read x:hplot
> > x,0 to x,191:next b,a:data
> > 4,3,0,21,42,7,9,62,83,104,125,159,180,220,247,279,3,10,20,41,105,126,161,182,206,233,262,263
> >
> >
> > I know why it happens, I'm just trying to find the most efficient way
> > to programatically explain this behavior.  Any takers?
>
> I've never seen a program explain anything.  ;-)
>
> If you mean how can you get exactly the same behavior from a DHR display
> that you see from an HGR display, that's pretty straightforward.  The
> HGR display is a subset of the DHR display where each HGR pixel is
> represented by two DHR pixels.
>
> Instead of thinking about colors and "4-bit color pixels", just think
> about the video bits shifted out and the timing of their edges, as if it
> were a monochrome display.  NTSC aliasing will take care of creating all
> the colors--and their fringes.
>
> For example, each of the seven low bits of an HGR line translates to
> two consecutive bits in the DHR line, and the high bit shifts their
> position in the DHR line by one DHR bit position.
>

Yeah, I got that part -- but that doesn't quite cut it.  If the hi-bit
is set on one byte, but not the byte next to it, then only a half-pixel
is shown.  So there's more to it than just simple bit expansion.  At
byte boundaries when the hi-bit goes from hi to low, pixels get cut in
half.  So I'm trying to find the best logical representation of that
behavior, hence represent (or "explain") the behavior algorithmically.