Hacker News Reader

Comment by torarnv | Hacker News Reader

Thank you for writing this!

I recently started playing around with RetroArch, and found it quite hard to make sense of all the shaders it comes with. :) Looking forward to the coming articles to get a better understanding of the parts that make up the pipeline from raw RGB pixels to something that looks like what I remember playing on my TV as a kid.

One question to the article: Do emulators generally have the color correction/gamma adjustments built in? If so is there typically a flag to turn it off, so it can be done in shaders instead?

View on HN

I would imagine most emulators do not include colour-correction or gamma adjustments for RGB-native consoles, unless the "native" colours are particularly ugly.

For example, the original NES does not work with RGB, but with analogue NTSC signals, so an emulator has to do something to make the output appear on an RGB screen, and that implicitly involves colour-correction.

The SNES and Genesis do work with RGB, and the output is good enough to look reasonable on modern monitors, so most emulators would probably leave it as-is.

The Game Boy Advance works with RGB, but the built-in screen on earlier models was (as the article describes) low contrast, and games were made garish to compensate. Later models of GBA used better screens, and the GBA Player for the Gamecube output straight RGB to an ordinary television, so later games often used more sensible palettes, or even provided a palette option in the main menu. Thus, GBA emulators probably provide their own colour-correction, and almost certainly make it optional.

I have had good results encoding/decoding the NTSC signal. You get crosstalk artifacts for “free”

https://www.gamasutra.com/view/news/125898/Opinion_CRT_Emula...

> the original NES does not work with RGB, but with analogue NTSC signals

I mean, the video hardware (video DAC? rasterizer?) in a NES is for NTSC/PAL, but that doesn't mean that NES palettes are specified in a YIQ colorspace or anything. The palette data is RGB; you don't have to do anything special to fill a NES-emulator framebuffer beyond what you'd be doing to render a GIF. (The gamma transforms mentioned in the article can be done during blitting with a LUT, but they could also just be done by applying a real gamma-curve transform to the framebuffer texture during screen compositing.)

The NESDev wiki says[1]:

> Unlike many other game consoles, the NES does not generate RGB or YUV and then encode that to composite. Instead, it generates NTSC video directly in the composite domain, which leads to interesting artifacts.

So far as NES software is concerned, it just tells the NES to use particular palette entries, and the NES hardware is responsible for coming up with an NTSC signal to send to the television. Because NES software doesn't care about specific RGB values, and because converting NTSC-to-RGB is hard, most emulators use an RGB palette for output, but fans have created a lot of alternative palettes over the years[2], and none of them are "correct".

[1]: https://wiki.nesdev.com/w/index.php/NTSC_video

[2]: http://firebrandx.com/nespalette.html

> and none of them are "correct".

Presumably whatever palette-entry-to-RGB encoding Nintendo's own emulators (e.g. NES VC, NES Online, the NES classic) use, should be considered at least somewhat "canonical", no?

And I don't mean because Nintendo has any special "auteur" control over what NES games "should" look like (they never expressed such control, since they never shipped a NES with a screen!)

Rather, I mean that the palette maps Nintendo uses in their emulators are probably the same maps Nintendo used, in the other direction, to do the original conversion of the RGB palettes of their PC art-assets, into NES palettes to wire into the hardware. I.e., if Mario's red coveralls in Donkey Kong (a Famicom launch title, so likely ported during hardware development) renders as #800000 on Nintendo's emulators, that's probably the same RGB color that was in the PCX file's palette that informed the tuning of the NTSC rasterizer's output for that particular palette entry.

Nintendo's RGB palettes have typically been what many would call "crap". Probably the NES Classic got closest. Wii VC was way too dark. None of them too horribly accurate.

I don't think they used PCX along the way at all. At one point, they'd digitize graphics by using LEDs to scan filled-in graph paper, one tile at a time. I think the closest Nintendo ever got to actually having an official RGB palette for the NES in the old days was the RGB PPU palette (which was very, very different from the colors output by the composite PPU).

The NES PPU is fairly well understood, and palettes can actually be calculated based on that (as opposed to some of the user-created palettes done with visual analysis). All of Nintendo's RGB palettes (AFAIK) are known and dumped.

They did ship this in concert with Sharp.

https://en.wikipedia.org/wiki/Sharp_Nintendo_Television

What about PAL and NTSC-J NES systems? It seems that the NYSC color system would just be one signal generation target among the 3.

Reply on news.ycombinator.com