Re: Double hires mode color artifacts

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

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

>> 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.

> And the intent of the game designers was the view of the game as seen
> by most people, which was with an NTSC display.  Most games were
> designed to look best with the artifacts intact.  ;-)

I beg to differ -- I think often enough the game just wanted to
create "sharp" pixels, and had to live with the fringe color effects
because it couldn't avoid it. Bolo is the first example that comes
to mind.

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

> It's usually not *very* different, just different--particularly
> in the transition from one hue to another.  RGB renditions of
> many Apple II games look blocky and sterile compared to the
> smoother NTSC displays.  

Ok, maybe I'm beginning to see what you're after. But I guess that's
mostly a problem of digital representation in a different resolution,
together with missing analog effects that would modulate the result image
slightly.

It's not so easy to get a real smooth and color gradient (and to
replace a constant hue with a more "wavy" version) unless you magnify
quite a bit, and then it gets slow even on more modern systems. I can
run the emulation at 3x magnification, and it's still faster than the
original, but not much. Maybe better if I can get to integrate the
graphics acceleration in someway, but that's not trivial.

So to avoid the blocky and sterile look, I guess it's more important
to introduce some low frequency noise, and avoid rendering the apple
pixel on host pixel boundaries. A filter of 4 bit width in hires (which 
corresponds to 8 bits in double hires) should be already sufficent for 
that. Maybe I should try it... thought one problem would be that this
only affects information in x, not in y.

>> 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.

> I regard table size as a non-consideration on modern emulation hardware.

Every bit doubles size. And the cache is limited. And I'm not having a 
brand new system here, either. As I said, on 3x magnification it's
still faster, but not much.

What I'm trying to find out is if the trade-off is worth it. At the
moment I'm not convinced, because I neither have a concrete recipe
to actually employ the wider window, nor do I have a convincing case 
where it makes a difference. What a wider filter certainly can do 
(and probably would do in the TV) is to make the hue change from
one repeated pattern to another repeated pattern more steep.

>> 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?

> It will not faithfully represent what DHR is capable of, and the way
> it was often used.

Yes, I know, but that wasn't the point. What I was asking was if it
would make sense to implement this mode (as an alternative to the
"sliding window" mode without quantizing x alignment), because there
are programs which use the display that way. After all, that's how
it's explained in the TN. If there are no programs which do, then
of course one doesn't have to implement this as an alternative.

> On a gigabyte machine, who cares whether an emulator requires
> 2MB or 2.25MB?

My CPU cache cares, because that is only 2x64KB. And cache misses
slow the whole thing down quite a bit.

> There are lots of relatively poor color fidelity emulators, but
> few (no?) high fidelity NTSC emulators...

If you have a concrete algorithm and test cases, I could try to implement
it and we'll see how it looks. As I said, the 4 bit window in hires
already corresponds to 8 bits in double hires, and that's enough to
do interesting stuff. And that's the *guaranteed* case, in the best case
you get 7 bits hires (= 14 bits double hires). That's more than the 12
bits you were asking for, though you don't get this for every pixel.
But it would still be information that's usable, because it's present,
anyway.

And if you can convince me that the result is worth it, I can always
add more bits and see how much slower it gets.

- Dirk