[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:
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.
Both hardware (RGB cards and the IIgs) and software (emulators) do
similarly incomplete emulation of NTSC.
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. ;-)
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. Some people prefer "sharp" over "pretty"--
there's no disputing tastes--but there is also no question about
what the graphic designers were looking at when they did their
designs.
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.
I regard table size as a non-consideration on modern emulation hardware.
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.
The usual "4-bit" implementation quantizes the x-position of the
4-bit groups to one of 140 positions. The hardware actually supports
placing a "4-bit group" at any of 556 positions--the x alignment is
*not* quantized in any way.
This is just one example of how the "usual" view of DHR is quite
different from the reality.
Of course, the fidelity limitations of restricting oneself to a
4-bit sliding window should also be clear, since transitions will
not be properly rendered (for the reasons described earlier).
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 :-)
Not anymore it doesn't. ;-) The speed and capacity of modern
hardware is so far in excess of the Apple II, that placing the
emphasis on fidelity as opposed to space saving is appropriate.
On a gigabyte machine, who cares whether an emulator requires
2MB or 2.25MB?
There are lots of relatively poor color fidelity emulators, but
few (no?) high fidelity NTSC emulators...
-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."