Andy McFadden wrote:
BLuRry <brendan.robert@gmail.com> wrote:True. But ultimately, I'm going to generate a lookup chart (dynamically generated as needed or pre-generated based on observation, either way) to make my code as efficient as possible.That was my original plan. The trouble with the IIgs RGB output is that it seemed to depend on a large number of pixels on both sides of the current pixel, making for a rather substantial lookup table and a fairly monumental effort to populate it (unless an accurate model could be created). Hopefully the //e output is more rational.
Nope. The issue isn't the Apple II, the issue is *any* video stream designed for its effect in creating NTSC "artifact" colors. What needs to be emululated correctly that has not is the "filtering" function of an analog NTSC monitor decoding composite color video. Anything capable of doing that with reasonable fidelity will need to have a filter window a few pixels wide (I've previously suggested that 12 video bits (a 4096-entry lookup table) might do the job reasonably well). This suggestion is based on the fact that Apple video is generated (in general) by a 14MHz clock, and NTSC chroma processing involves filters with bandwidths of 1MHz or less. So unless a good fraction of a microsecond's worth of video data is considered, those filter functions cannot be faithfully modeled. -michael NadaNet networking for Apple II computers! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it's seriously underused."