[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Double hires mode color artifacts
Dirk Thierbach wrote:
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.
If simple graphics are intended, I agree, but many games actually
had rather artistic screens--suggesting far more than one would
expect of an Apple II, given its resolution and color limitations.
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.
I've suggested a very simple table-driven algorithm that should do
quite well. Of course, only the parts of the screen that change
(meaning all pixels within 14 or so dots of any changed dot) would
need to be updated at most once per frame.
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.
That's correct. The only "Y blending" would result from defocusing
of the analog monitor, and can probably be neglected.
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.
This doesn't alter the size of the frame buffer--only the size of the
table used to map the color of each pixel in the buffer. Although a
14-bit table would be 16K x 4 = 64K bytes (at 32-bits/pixel), it would
still fit easily in second level cache, and references to it would have
a lot of locality in most practical cases.
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.
The recipe is simple: map host pixels to one or more 14MHz Apple
"dots" and to get the color for each pixel, shift in the next Apple
dot (1 or 0) into a 14-bit shift register and use the register for
an index into a 32-bit color table.
The only thing missing is the DSP-like algorithm to construct the
color table. That would be a neat exercise for someone who wanted
to learn more about DSP techniques. ;-) Once the table is built
(for a particular monitor class), it is a constant. Other tables
could be swapped in to do more "standard" color mappings, so the
actual video algorithm wouldn't have to change (of course, it would
be overkill for a simple mapping, but who cares?).
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.
Sure, some do--but it's a special case of the more general method.
If you use the general sliding window, the "blocked" case just works
if it is used.
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.
Admittedly, 64KB is a little tight, but there is still plenty of
locality in the color lookup, and you don't have to convert more
than a small fraction of a screen every frame--an Apple II just
isn't that fast. The page-flipping case can be handled by actual
frame buffer page flipping.
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.
Of course, I was actually hoping for 14 bits. ;-) But 12 is probably
quite good as well.
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.
That would be an interesting experiment.
I'm kind of accustomed to 2MB L2 caches... ;-)
The part that is not done is the DSP simulation of a "typical" NTSC
monitor (it would be nice to pick a real one, like the AppleColor
Composite monitor) to construct the color table.
Of course, the algorithms to fill in the table for simpler assumptions,
like "4-bit sliding window", are implicit in existing code.
-michael
NadaPong: Network game demo for Apple II computers!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."