Generally, when trying to implement some protocol, you are constrained by your hardware and time. But for someone like [EMMIR], that’s not enough. For example, NTSC-CRT is a video signal encoding/decoding simulator with no hardware acceleration, floating point math, or third-party libraries. Just basic C.
While NTSC has officially gone dark in America, people still make their own ATTiny-powered transmitters. NTSC is a bit of a strange standard and is sometimes referred to as never-twice-the-same color, but it does produce a distinct look.
That look is what [EMMIR] was going for. It encodes a message in a ppm format into NTSC and then back in ppm with some configurable noise. It can do this in real-time as an effect in [EMMIR’s] engine or on a rendered image via a CLI. It looks incredible, and there’s something very satisfying. There’s a video after the break showing off the effect. The code is pretty short and easy to read.
People may not realize it but this is fantastic! I saw this of course because many emulators of older consoles (from when video outputs were analog) seek to produce the most accurate representation and this could help bring that accuracy too the next level.
Very cool. In fact, video games designed in the NTSC/PAL era (e.g., for the 8-bit, 16-bit, and even 32-bit video game consoles) sometimes used the “never-twice-the-same color” weirdness as a feature, not a bug. I was a developer on a bunch of games for the Sega Genesis (aka Mega Drive) and worked with some incredible artists. We developed the games on Macs with their beautiful, crisp color monitors, but the artists HAD TO SEE their digital artwork via NTSC on a regular TV. Not because of the fuzzy noise, per se, but for the messy, analog smearing between pixels, especially along horizontal scan lines. The artists produced some amazingly subtle images that contained colors not formally supported by the hardware by using adjacent pixels with color combinations known to bleed from pixel to pixel (see the Genesis/Mega Drive game “Chakan: The Forever Man” – but through NTSC on an old school TV – for some great examples.) This was particularly effective for some primitive anti-aliasing even with only four 4-bit pallets active at once You could even produce a passable pseudo-translucency effect (e.g., under water) by placing a checkerboard pattern of alternating opaque and transparent pixels over other images. Conversely, only certain color sequences would produce a sharp edge. Many of those games actually looked worse as signal formats improved and monitors got bigger, never mind on a “pixel perfect” emulator with even the poorest quality LED/LCD monitor. Reporting live from the Paleocomputing Era…
Thanks for sharing your industry experience! This is something that a lot of emulator users, particularly the younger generation, aren’t aware of: That the art on these consoles was pretty much *always* verified visually on an actual TV or composite monitor (Commodore 1084 and 1702 monitors were fairly common). It was especially important on SNES games, as it had a slightly non-square pixel aspect ratio, so verifying on a 4:3 TV was the only way to view the art with the correct AR.
Back to the Sega Genesis, Vectorman 2 has another great example of that sort of faux-translucency effect on its title screen, using alternating columns of white and completely transparent pixels on a spotlight effect that it uses.
I had used a Commodore 1702 (PAL) as a monitor for my Nintendo /Supet Nintendo and my Sharp computer.
I’m not entirely sure, but I think it had a comb filter, too.
Anyway, Composite (CVBS) video was “okay” for its time. The Luma/Chroma ports on the back could be used for the Super NES, too, which I tried with a third-party cable. However, the S-Video output wasn’t pretty, not at all. Maybe it also had to do with the different voltage levels, not sure. Anyway it showed all the corny dithering patterns (StarWing, F-Zero etc).
Personally, as an ex 1702 owner, I think that the 1702 was awesome due to its boxy design and the analog controls behind the front panel.
But gaming wise.. It’s not as good as some may thing. In fact, I would say the 1702 is a bit hyped/overrated these days. It’s a form of heroism, maybe. I don’t like that. It ruins memories of an otherwise descent video monitor.
To see the NES/SNES/Genesis dithering/half-toning effects “in full glory”, an old school RF connection should be used, too. Even if it’s just for testing. It will also mask jitter and colour bleed and other shortcomings of CVBS (Composite). That being said, a CRT TV or VCR with a quality tuner should be used for an RF connection. One that has an AFC (automatic frequency control) for a stable picture.
Artists have to work within their medium, and NTSC video was their medium, I appreciate what they did with what they had.
Gravis, did you miss the GPU-accelerated filter I added to MAME all the way back in 2011 which does exactly this? It takes the emulated output, encodes it as a composite signal, then decodes it in a second pass, just like this does.
NTSC encoding/decoding has been done and dusted for years, pretty much the thing this does differently amounts to it eschewing GPU acceleration or floating-point in favor of fixed-point arithmetic.
What was your implementation for? Was it for the reason Jon Miller described above?
“Since there it doesn’t include floating point, fixed point with a (…).”
Excuse me?
After hearing Dan Maloney mention rushing to be the first to grab a topic he’s seen in the queue, I sometimes wonder if the more egregious typos are a symptom of racing to be first-to-post, or writers/editors trying to meet the articles/week metric.
Interesting. Looks like CVBS or RF simulation, too.
NTSC via Chroma/Luma (S-Video, Y/C) could look much cleaner.