> Just to clarify, I was referring to home systems, particularly the Genesis and
> PlayStation 1 (and I think the N64) where developers "cheated" additional colors and
> transparency effects beyond the system's true capabilities by employing dithering,
> exploiting the fact that the majority of people would be playing on a TV set using a
> composite or RF connection. Without the signal degradation causing adjacent pixels to
> blend together, the dithering is exposed and it looks really ugly. For example, the
> first Silent Hill on PS1 definitely exploited composite artifacts to simulate
> atmospheric fog effects, and it doesn't look very good on higher-grade video outputs
> (or on emulator).
You're both correct, and allow me to add a third correct observation: There is a third aspect to the presentation, which is not just the signal format, but the transport format, to consider, in addition to the effects of the display device itself.
The signal format, such as "composite US NTSC", can further be affected by how that signal is transported. Things like the quality of the cabling used. An American NES connected to a TV through a shielded cable will still most likely look better than a completely unshielded cable next to something throwing off EMI that interferes with the signal.
Ideally, in my view, an emulator should be nothing more than a presentation for a set of signal-processing and signal-routing nodes, each with the capability of having inputs and outputs. Eventually, MAME will need to contend with having multiple running machine devices, and at this point one had may as well also implement a better system for passing data beyond the boundaries of the simulation/emulation layer, into the presentation layer. At this point, it would be a logical step to have the driver not in fact instantiate "screen" and "speaker" devices, but instead define a set of signal output points. Which could be routed into, say, a default presentation mode of the current flat 2D "screen" device and the current generic abstraction of a "speaker" device. But why not, say, a Commodore 1702 monitor, connected through an unshielded composite cable device? A good emulator should have the modularity to support all of these things.
|
Index 
Flat 
I think you're both right
Reply
