Re: Double hires mode color artifacts

[Dirk Thierbach <dthierbach@usenet.arcornews.de>]

Michael J. Mahon <mjmahon@aol.com> wrote:

>> And that gets to the core of the problem: How strongly do the extra
>> samples influence the hue? Because...

> Enough to make the RGB-ized displays look decidedly different from
> the composite displays that most games and graphics were designed for.

You mean RGB-ized by hardware, or by an emulator? I guess many, if not
most games and graphics actually look better (at least for my taste)
if any display method just ignores the color artifacts. After all,
it's the "intention" of the program that counts here. OTOH, it's nice
to be able to show the artifacts as an option.

Do you happen to have concrete examples if similar 4-bit-patterns
where leading or trailing bits produce a very different hue?

>> I've implemented hires in a reasonably fast way by using tables
>> which guarantee 4 bit samples for every pixel, and at the moment I
>> am wondering if this is enough for double hires, or if I have to
>> make the window a bit larger to be able to display the color
>> artifacts with reasanble accuracy.

> It isn't just double hi-res, it's lo-res and even normal hi-res.  All
> 4-bit renditions of these displays are unfaithful to the rendition of
> an analog NTSC monitor.  

The difference is that in double-hires the high bit of each byte is
ignored. That makes the tables smaller, so I could instead add extra
sample bits and still have a reasonable size. Assuming that it's worth
to do it and there are really examples where the results are different;
see above.

What I am about to implement could also display just the 4 bit
positional "blocks" mentioned in the TN as a solid color (i.e., no
sliding window). Are there programs that use double hires in that way,
and would look better in this mode?

> All Apple II video can be processed in exactly the same way,
> regardless of "resolution".

Yes, but sometimes it makes sense to sacrifice accuracy for speed or
memory consumption :-) 

- Dirk