17 ms·

Color Emulation

527 points by bane 7y ago

simias 7y ago
Accurate screen emulation is important for many retro games, and not just because of color issues. For instance the GameBoy didn't support transparency so some clever devs would make sprites blink very fast to make them appear transparent. Since the GameBoy screen had a fairly slow response time the ghosting would effectively blend the sprite with the background. If you emulate the game on a modern low-latency monitor you just get a flickering sprite. See for instance the claw's shadow in this gameplay video for Link's Awakening: https://youtu.be/UQlP9sHf5Ho?t=825 https://youtu.be/UQlP9sHf5Ho?t=825 (although this video is way worse that what you'd see in an emulator because the framerate of the video doesn't line up with the GB's ~60fps display, so it doesn't even flicker all the time). An other example is games using the blurriness of analog video signals to blend things together: https://www.retrorgb.com/hd-retrovison-shows-transparency-color-depth-restoration-algorithm-to-minimize-dithering.html https://www.retrorgb.com/hd-retrovison-shows-transparency-co... Basically you interlace two images at a high enough frequency and let the analog artifacts blend them. Once again doing playing that on a modern LCD screen without post-processing ruins the effect.
- tobr 7y ago
  Has anyone tried to simply point a camera at an old screen, say a CRT screen, take a photo of one pixel at a time at a few different levels of brightness, then add all the photos together to render arbitrary images? As far as I can imagine, it should capture the behavior of colors and the fuzzyness between pixels very well. You could even set up a small still life around the monitor, and get accurate reflections and ambient light in the room. Stuff like the smoothed out flickering that you mention would still need to be emulated, of course.
  - grenoire 7y ago
    There are shaders to render such 'artifacts' programmatically at about a thousandth of the cost of what you describe. It could potentially be more accurate in the way you describe it, but then what kind of blending mode do you use?
    - tobr 7y ago
      I think you would first find the two closest brightness levels for each pixels, and blend appropriately between them - then simply use additive blending to composite all the pixels together. A naive approach would require compositing as many images as the number of pixels in the input signal, which seems extremely expensive, but in practice I’m sure you could optimize it quite a bit, as most of the area of each photo would be almost completely black.
      - grenoire 7y ago
        If you can arrange lighting perfectly in your CRT studio, you could take only the difference against the all-off state. You could extract the pixel islands' positions and composite only these smaller chunks afterward. It could work out, but just not sure if it's worth all the hassle. It seems akin to the way you would do a stop-motion video, I suppose.
        tobr 7y ago
        You would need to be in a pitch black room with only one pixel at a time lighting the scene. If you want additional light sources in the room they could be photographed and blended in with the same technique.
        grenoire 7y ago
        "You could even set up a small still life around the monitor, and get accurate reflections and ambient light in the room." I think this would be a final additive pass after the pixel setup. Would also allow you to turn it off selectively... The more I think about it the more I want to try it out.
        tobr 7y ago
        I think you would need to get the reflections in the same pass. It’s basically ray tracing in real life: emit light from a bunch of points (screen pixels), “calculate” how they bounce through the room (ie adjust the brightness of the corresponding photo), and combine them all into a single image.
  - leni536 7y ago
    It's actually a great idea, assuming that background light levels are properly taken care of and the camera is well calibrated to a linear colorspace. Unfortunately "pixels" don't really blend linearly when transferred over a composite cable and there are some games that use NTSC artifacts to achieve certain colors.
  - lostgame 7y ago
    This is brilliant. I’d just love to see what this would look like.
  - aidenn0 7y ago
    Brightness is a non-local effect. i.e. if you change one pixel, the rendering of the adjacent pixels can change. Also, the rendering is different depending on how the signal made it into the CRT; in particular composite video does not preserve certain things about the image, and in some cases developers took advantage of this/ Most famously the genesis had a poor composite encoder, which was taken advantage of by many games; Sonic 3 in particular looks bad even on a CRT with a real Genesis if you use RGB or component output.
    - zellyn 7y ago
      Even color is a non-local effect. Turning two colored pixels on side-by-side on an Apple II makes them white. I can give you an unbounded amount of detail why :-) https://zellyn.github.io/apple2shader/ https://zellyn.github.io/apple2shader/
  - cr0sh 7y ago
    While not really what you're asking about - how about fractals using video feedback (essentially analog fractal computation): https://www.youtube.com/watch?v=Jj9pbs-jjis https://www.youtube.com/watch?v=Jj9pbs-jjis
- arayh 7y ago
  ZAS is a good example of blinking backgrounds quickly to introduce more complex backgrounds: https://cloud.githubusercontent.com/assets/16804570/21383939/8bbd7b9e-c7ab-11e6-8a87-bf74c52a777e.gif https://cloud.githubusercontent.com/assets/16804570/21383939...
byuu 7y ago
Hi all, article author here. My background is I wrote emulators for 24 systems and counting (higan and bsnes), and I want to try my hand at technical writing, in hopes of encouraging more people to get involved with emulation. I'll hopefully get better over time and with more feedback. I'll be writing more about video emulation in the near future. I would like to cover techniques for interframe blending (the flickering shadow), composite artifacts (the waterfalls in Sonic the Hedgehog), color bleed (translucency in Kirby's Dream Land 3), screen curvature, scanlines, color subcarriers (and how shifting it causes shakiness you see in composite video), interlacing, phosphor decay, phosphor glow, aperture grilles, non-1:1 RGB pixel layouts (Game Gear LCD), etc. I'm intending to write about all things emulation there, in fact. I want to cover input latency reduction/mitigation, removing audio aliasing above the Nyquist limit using FIR and IIR low-pass filters, designing thread schedulers and priority queues, provide mirroring and organizing of PDF datasheets for all the ICs used in retro gaming systems, etc. Basically, I want to cover all the stuff you don't usually find in "how to write an emulator" tutorials. All the polishing stuff that takes a new emulator to a well-polished emulator. It's not ready yet (the site is brand new), but I'll have an RSS feed at byuu.net/feed in a couple of days if anyone's interested in this sort of content. Thanks for reading ^-^
- guipsp 7y ago
  Thank you for taking the time to write your expertise down. Even if the article doesn't get much attention right now, the value of writing down knowledge is often understated.
- _pmf_ 7y ago
  Very, very much appreciated.
- DCKing 7y ago
  Thanks for the attention to detail you're bringing to emulation. Looking forward to the articles you're intending to write!
- Tepix 7y ago
  Good stuff! I like having both options - using the colours the displays were unable to display properly at the time or - on the other hand - getting as close as possible to the original experience.
t0mek 7y ago
> The first detail is that most computer monitors run in 24-bit color mode, which provides 8-bits of color detail for the red, green, and blue channels. But most older game systems do not specify colors in that precision. > For instance, the Sega Genesis encodes 9-bit colors, giving 3-bits per channel. > The solution to this is that the source bits should repeat to fill in all of the target bits. 000 -> 000 000 00... 010 -> 010 010 01... 011 -> 011 011 01... 111 -> 111 111 11... This is interesting and efficient approach. Interpolating a 3-bit number (0-7) into a 8-bit one (0-255) can be done by dividing the first one by 7 (to normalize it) and the multiplying it by 255 (to stretch it to the full range). The operation order can be changed to avoid having smaller-than-1 floating numbers in the first step. So, we basically need to multiply each number by 255/7~36.4. 0 -> 0 * 36.4 = 0 1 -> 1 * 36.4 = 36 2 -> 2 * 36.4 = 73 3 -> 3 * 36.4 = 109 ... 7 -> 7 * 36.4 = 255 So, these multiplications give exactly the same results as repeating the bits in the byuu's article and bits operations are much cheaper. I have some intuition on how does it work (we're increasing each "part" of the number by the same factor), but not a math explanation.
- RetroSpark 7y ago
  The calculation `red = r << 5 | r << 2 | r >> 1` is equivalent to `red = floor(r * (1 << 5 | 1 << 2 | 1 >> 1))`, which is `red = floor(r * 36.5)`.
  - byuu 7y ago
    I thought it would be good to get people familiar with bit-twiddling, as you will be doing a whole lot of that when writing retro emulators. This is one of my favorite sites on the internet: https://graphics.stanford.edu/~seander/bithacks.html https://graphics.stanford.edu/~seander/bithacks.html
    - RetroSpark 7y ago
      Absolutely, couldn't agree more. I just wanted to clarify why the bit-shifting approach was equivalent to the previous comment's multiplication by 36.4. > This is one of my favorite sites on the internet: https://graphics.stanford.edu/~seander/bithacks.html https://graphics.stanford.edu/~seander/bithacks.html Yes - I also enjoyed the book "Hacker's Delight", but haven't got round to reading the second edition yet.
RetroSpark 7y ago
The Sega Master System has 6 bit-per-pixel color, 2 bits for each of red, green and blue. You would expect values 00, 01, 10 and 11 for each color to represent 0%, 33%, 66% and 100% voltage on the corresponding pin of the Video Display Processor. However, I once connected an SMS to an oscilloscope and found voltage levels much less evenly-spaced than this - and they were quite different for different console models. Even if the voltages had been evenly spaced, would it have been correct to use evenly-spaced values (0, 85, 170 and 255) for each of r, g and b in an emulator? I believe this would be correct, assuming that the gamma curve of a modern monitor matches that of a 1980s/90s TV - which should be the case for a monitor calibrated to sRGB?
- BearOso 7y ago
  Brightness doesn’t correlate linearly to voltage level. sRGB is representative of the final output, so the brightness would correspond to 0, 33, 66, 100, and the voltages would be the inverse application of the gamma to those values.
jbverschoor 7y ago
Check out CRT Royale / CRT-Royale-kurozumi which also does some phosphor fading. https://github.com/libretro/common-shaders/tree/master/crt/shaders/crt-royale https://github.com/libretro/common-shaders/tree/master/crt/s... Sonic https://www.youtube.com/watch?v=u77TUkFHNyI https://www.youtube.com/watch?v=u77TUkFHNyI Streetfighter https://youtu.be/xrpm8o17cHE?t=903 https://youtu.be/xrpm8o17cHE?t=903 Other resources: https://www.resetera.com/threads/crt-shaders-scanlines-ot-because-1080p-is-all-the-ps-i-got.7235/ https://www.resetera.com/threads/crt-shaders-scanlines-ot-be... https://www.youtube.com/watch?v=qBzB0YdHn64 https://www.youtube.com/watch?v=qBzB0YdHn64
- stelonix 7y ago
  Ok, I gotta say: none of the shaders or scanlines I've tried before ever came close to what I'm seeing in those videos; to the point I'd think "uh looks nice but that's not how I remember from the 90s". Now that crt royale... Color me impressed! Gonna try it as soon as I get access to a PC.
  - DCKing 7y ago
    I've heard people say for CRT Royale to be truly effective you need to use it on a 4K TV. It apparently needs the additional resolution to truly shine. Having said that, it already looks really impressive to me on a 1080p TV.
1wd 7y ago
It would be interesting to add three photographs to each example: Original retro system display, un-corrected on modern display, corrected on modern display.
- byuu 7y ago
  It is extraordinarily hard to photograph handhelds that lack backlighting, and I left my CRT back in the US so that's also out ^-^; It would be a good idea to get some extreme close-up photos of the screens however, I'll keep that in mind for a future post.
  - mark-r 7y ago
    In the US you can't even give away a CRT these days, you have to pay someone to take them. It might be hard to locate one depending on where you are, but once located maybe you could offer to take it off their hands?
rossy 7y ago
I've always wondered if you could just stick a colourimeter on a GBA SP and generate an ICC profile for it, then use that profile to adapt the colours to your display. It probably wouldn't be that easy, but there are colour management tools and libraries available that are designed for adapting colours between devices, so if you could somehow obtain a device profile for the GBA LCD, it might be possible to use it to produce very accurate colour emulation.
- thristian 7y ago
  As I understand it, colorimeter expect the display to output a particular colour or shade and measure it precisely. You probably couldn't run colorimeter software on a GBA, but you could write homebrew that let the user manually cycle to the correct patterns at the right times. Some issues would be: - There's at least three models of GBA display: the original front-lit display, the GBA SP back/front-lit display, and the later GBA SP backlit-only display, and they probably all have different profiles - It's probably not possible to use a colorimeter on the original front-lit GBA display, because with a colorimeter clamped on top of it, it would always look black - Colour-correction software that works with ICC profiles is typically built for print/still image work, so it expects a single high-resolution image with high-precision output, not a 60fps stream of very-low-resolution images. Maybe it's fast enough to run in real-time, who knows?
  - rossy 7y ago
    Yeah, writing homebrew to get the GBA screen to display whatever a screen displays under a colourimeter, and getting that to work with the actual colourimeter might not be so easy. I think getting a device profile for the frontlit SP would be the most interesting, since I've heard it produces colours more like the original GBA than the backlit one, but maybe a colourimeter designed for backlit PC monitors would have trouble with it. I don't think performance would be an issue though. mpv can do colour management in real time by generating a LUT from the ICC profile and applying it to each frame with GPU shaders.
    - MartijnBraam 7y ago
CodexArcanum 7y ago
One thing I've been thinking about lately with emulation: why can't we replicate and use the original hardware more easily? There's lots of knockoff console replicas out there, so it seems like the chips can still be manufactured. Wouldn't it be fairly cheap to build a board/chip that contained either the original chip designs from classic computers/consoles, or hardware-level emulated chips? Seems like you could stuff several of those retro chips onto a single expansion board. Then emulation software could tap into this "emulation expansion board" to make use of the real chips. Is this all crazy talk or does any of that make some sense?
- thristian 7y ago
  There's lots of knockoff console replicas out there, but most of them are software emulation running on the moral equivalent of a Raspberry Pi, and the rest are often quite inaccurate approximations of the original hardware, with many incompatibilities with published games. Without access to the original designs, hardware emulation is in the same position as software emulation: you need to do a ton of research and development. A company called Analogue[1] makes FPGA recreations of a few classic consoles, but they're pretty expensive, and took a lot of effort to design. In fact, byuu (the author of the OP) was consulted fairly heavily during the design of their SNES reproduction. Basically, if you have to do a lot of research anyway, you might as well go with the product that has zero marginal production cost (i.e. software) and save yourself a bunch of manufacturing expenses for the same result. [1]: https://www.analogue.co/ https://www.analogue.co/
  - CodexArcanum 7y ago
    Ah, that's good to know! That's a fun fact about byuu helping with the FPGA SNES that they built as well, really interesting! Thanks for the knowledge share!
spookthesunset 7y ago
> the Sega Genesis encodes 9-bit colors, giving 3-bits per channel I love systems that didn’t align everything on an 8 bit boundary. Are there any modern systems that aren’t 8-bit aligned?
- Dylan16807 7y ago
  Are you sure the Genesis didn't align things on 8 bit boundaries? Either way, it might be worth mentioning current systems that use 10-bit (30-bit) color. The N64 is notable for using ECC memory modules with ECC disabled, where the CPU sees 8 bits per byte and the GPU uses all 9 bits per byte for some functions.
- mntmoss 7y ago
  It is actually still 8-bit aligned with padding - we are talking about a system with a 68000 and Z80 here. The way the graphics systems of the era accomplished color depths like this was generally to do one of two things: 1. draw them in "planar" mode(multiple bitmap layers of a more convenient depth like 1-bit, then composited together into the full image) vs the "chunky" mode we are familiar with(all color information packed in each pixel of the bitmap). Planar graphics are much less convenient for ordinary drawing tasks, but they allow for a tradeoff between memory usage and fidelity. Put they ease a few kinds of raster effects if you carefully use your palettes. This is what the Amiga OCS had, and VGA in many of the custom modes. 2. Allocate the colors to sprite and tile hardware with limited palettes, so that you can achieve "n colors visible" by carefully combining all the different elements. Each element might be able to sample part of the 9-bit space with a palette of 4 or 16. In the case of the Genesis VDP your limit is ~64 colors visible of 512, with the special Shadow/Highlight mode allowing more. This is not as big of a limitation as it sounds like since the low resolution graphics of the time weren't suited for detailed color values: 4 is enough to do a shadow/midtone/highlight, and 16 allows for substantial color ramps with multiple hues.
nemetroid 7y ago
The part about color precision is similar to three-hex-digit CSS colors, where e.g. #5ce is expanded to #55ccee.
lanius 7y ago
Do "official" emulators handle these details? E.g., SNES games in Nintendo Switch Online
leoziih10 7y ago
Bag

527 points by bane 7y ago

Accurate screen emulation is important for many retro games, and not just because of color issues. For instance the GameBoy didn't support transparency so some clever devs would make sprites blink very fast to make them appear transparent. Since the GameBoy screen had a fairly slow response time the ghosting would effectively blend the sprite with the background. If you emulate the game on a modern low-latency monitor you just get a flickering sprite. See for instance the claw's shadow in this gameplay video for Link's Awakening: https://youtu.be/UQlP9sHf5Ho?t=825 https://youtu.be/UQlP9sHf5Ho?t=825 (although this video is way worse that what you'd see in an emulator because the framerate of the video doesn't line up with the GB's ~60fps display, so it doesn't even flicker all the time). An other example is games using the blurriness of analog video signals to blend things together: https://www.retrorgb.com/hd-retrovison-shows-transparency-color-depth-restoration-algorithm-to-minimize-dithering.html https://www.retrorgb.com/hd-retrovison-shows-transparency-co... Basically you interlace two images at a high enough frequency and let the analog artifacts blend them. Once again doing playing that on a modern LCD screen without post-processing ruins the effect.

tobr 7y ago
Has anyone tried to simply point a camera at an old screen, say a CRT screen, take a photo of one pixel at a time at a few different levels of brightness, then add all the photos together to render arbitrary images? As far as I can imagine, it should capture the behavior of colors and the fuzzyness between pixels very well. You could even set up a small still life around the monitor, and get accurate reflections and ambient light in the room. Stuff like the smoothed out flickering that you mention would still need to be emulated, of course.
- grenoire 7y ago
  There are shaders to render such 'artifacts' programmatically at about a thousandth of the cost of what you describe. It could potentially be more accurate in the way you describe it, but then what kind of blending mode do you use?
  - tobr 7y ago
    I think you would first find the two closest brightness levels for each pixels, and blend appropriately between them - then simply use additive blending to composite all the pixels together. A naive approach would require compositing as many images as the number of pixels in the input signal, which seems extremely expensive, but in practice I’m sure you could optimize it quite a bit, as most of the area of each photo would be almost completely black.
    - grenoire 7y ago
      If you can arrange lighting perfectly in your CRT studio, you could take only the difference against the all-off state. You could extract the pixel islands' positions and composite only these smaller chunks afterward. It could work out, but just not sure if it's worth all the hassle. It seems akin to the way you would do a stop-motion video, I suppose.
      - tobr 7y ago
        You would need to be in a pitch black room with only one pixel at a time lighting the scene. If you want additional light sources in the room they could be photographed and blended in with the same technique.
        grenoire 7y ago
        "You could even set up a small still life around the monitor, and get accurate reflections and ambient light in the room." I think this would be a final additive pass after the pixel setup. Would also allow you to turn it off selectively... The more I think about it the more I want to try it out.
        tobr 7y ago
        I think you would need to get the reflections in the same pass. It’s basically ray tracing in real life: emit light from a bunch of points (screen pixels), “calculate” how they bounce through the room (ie adjust the brightness of the corresponding photo), and combine them all into a single image.
- leni536 7y ago
  It's actually a great idea, assuming that background light levels are properly taken care of and the camera is well calibrated to a linear colorspace. Unfortunately "pixels" don't really blend linearly when transferred over a composite cable and there are some games that use NTSC artifacts to achieve certain colors.
- lostgame 7y ago
  This is brilliant. I’d just love to see what this would look like.
- aidenn0 7y ago
  Brightness is a non-local effect. i.e. if you change one pixel, the rendering of the adjacent pixels can change. Also, the rendering is different depending on how the signal made it into the CRT; in particular composite video does not preserve certain things about the image, and in some cases developers took advantage of this/ Most famously the genesis had a poor composite encoder, which was taken advantage of by many games; Sonic 3 in particular looks bad even on a CRT with a real Genesis if you use RGB or component output.
  - zellyn 7y ago
    Even color is a non-local effect. Turning two colored pixels on side-by-side on an Apple II makes them white. I can give you an unbounded amount of detail why :-) https://zellyn.github.io/apple2shader/ https://zellyn.github.io/apple2shader/
- cr0sh 7y ago
  While not really what you're asking about - how about fractals using video feedback (essentially analog fractal computation): https://www.youtube.com/watch?v=Jj9pbs-jjis https://www.youtube.com/watch?v=Jj9pbs-jjis
arayh 7y ago
ZAS is a good example of blinking backgrounds quickly to introduce more complex backgrounds: https://cloud.githubusercontent.com/assets/16804570/21383939/8bbd7b9e-c7ab-11e6-8a87-bf74c52a777e.gif https://cloud.githubusercontent.com/assets/16804570/21383939...

byuu 7y ago

Hi all, article author here. My background is I wrote emulators for 24 systems and counting (higan and bsnes), and I want to try my hand at technical writing, in hopes of encouraging more people to get involved with emulation. I'll hopefully get better over time and with more feedback. I'll be writing more about video emulation in the near future. I would like to cover techniques for interframe blending (the flickering shadow), composite artifacts (the waterfalls in Sonic the Hedgehog), color bleed (translucency in Kirby's Dream Land 3), screen curvature, scanlines, color subcarriers (and how shifting it causes shakiness you see in composite video), interlacing, phosphor decay, phosphor glow, aperture grilles, non-1:1 RGB pixel layouts (Game Gear LCD), etc. I'm intending to write about all things emulation there, in fact. I want to cover input latency reduction/mitigation, removing audio aliasing above the Nyquist limit using FIR and IIR low-pass filters, designing thread schedulers and priority queues, provide mirroring and organizing of PDF datasheets for all the ICs used in retro gaming systems, etc. Basically, I want to cover all the stuff you don't usually find in "how to write an emulator" tutorials. All the polishing stuff that takes a new emulator to a well-polished emulator. It's not ready yet (the site is brand new), but I'll have an RSS feed at byuu.net/feed in a couple of days if anyone's interested in this sort of content. Thanks for reading ^-^

guipsp 7y ago
Thank you for taking the time to write your expertise down. Even if the article doesn't get much attention right now, the value of writing down knowledge is often understated.
_pmf_ 7y ago
Very, very much appreciated.
DCKing 7y ago
Thanks for the attention to detail you're bringing to emulation. Looking forward to the articles you're intending to write!
Tepix 7y ago
Good stuff! I like having both options - using the colours the displays were unable to display properly at the time or - on the other hand - getting as close as possible to the original experience.

t0mek 7y ago

> The first detail is that most computer monitors run in 24-bit color mode, which provides 8-bits of color detail for the red, green, and blue channels. But most older game systems do not specify colors in that precision. > For instance, the Sega Genesis encodes 9-bit colors, giving 3-bits per channel. > The solution to this is that the source bits should repeat to fill in all of the target bits. 000 -> 000 000 00... 010 -> 010 010 01... 011 -> 011 011 01... 111 -> 111 111 11... This is interesting and efficient approach. Interpolating a 3-bit number (0-7) into a 8-bit one (0-255) can be done by dividing the first one by 7 (to normalize it) and the multiplying it by 255 (to stretch it to the full range). The operation order can be changed to avoid having smaller-than-1 floating numbers in the first step. So, we basically need to multiply each number by 255/7~36.4. 0 -> 0 * 36.4 = 0 1 -> 1 * 36.4 = 36 2 -> 2 * 36.4 = 73 3 -> 3 * 36.4 = 109 ... 7 -> 7 * 36.4 = 255 So, these multiplications give exactly the same results as repeating the bits in the byuu's article and bits operations are much cheaper. I have some intuition on how does it work (we're increasing each "part" of the number by the same factor), but not a math explanation.

RetroSpark 7y ago
The calculation `red = r << 5 | r << 2 | r >> 1` is equivalent to `red = floor(r * (1 << 5 | 1 << 2 | 1 >> 1))`, which is `red = floor(r * 36.5)`.
- byuu 7y ago
  I thought it would be good to get people familiar with bit-twiddling, as you will be doing a whole lot of that when writing retro emulators. This is one of my favorite sites on the internet: https://graphics.stanford.edu/~seander/bithacks.html https://graphics.stanford.edu/~seander/bithacks.html
  - RetroSpark 7y ago
    Absolutely, couldn't agree more. I just wanted to clarify why the bit-shifting approach was equivalent to the previous comment's multiplication by 36.4. > This is one of my favorite sites on the internet: https://graphics.stanford.edu/~seander/bithacks.html https://graphics.stanford.edu/~seander/bithacks.html Yes - I also enjoyed the book "Hacker's Delight", but haven't got round to reading the second edition yet.

RetroSpark 7y ago

The Sega Master System has 6 bit-per-pixel color, 2 bits for each of red, green and blue. You would expect values 00, 01, 10 and 11 for each color to represent 0%, 33%, 66% and 100% voltage on the corresponding pin of the Video Display Processor. However, I once connected an SMS to an oscilloscope and found voltage levels much less evenly-spaced than this - and they were quite different for different console models. Even if the voltages had been evenly spaced, would it have been correct to use evenly-spaced values (0, 85, 170 and 255) for each of r, g and b in an emulator? I believe this would be correct, assuming that the gamma curve of a modern monitor matches that of a 1980s/90s TV - which should be the case for a monitor calibrated to sRGB?

BearOso 7y ago
Brightness doesn’t correlate linearly to voltage level. sRGB is representative of the final output, so the brightness would correspond to 0, 33, 66, 100, and the voltages would be the inverse application of the gamma to those values.

jbverschoor 7y ago

Check out CRT Royale / CRT-Royale-kurozumi which also does some phosphor fading. https://github.com/libretro/common-shaders/tree/master/crt/shaders/crt-royale https://github.com/libretro/common-shaders/tree/master/crt/s... Sonic https://www.youtube.com/watch?v=u77TUkFHNyI https://www.youtube.com/watch?v=u77TUkFHNyI Streetfighter https://youtu.be/xrpm8o17cHE?t=903 https://youtu.be/xrpm8o17cHE?t=903 Other resources: https://www.resetera.com/threads/crt-shaders-scanlines-ot-because-1080p-is-all-the-ps-i-got.7235/ https://www.resetera.com/threads/crt-shaders-scanlines-ot-be... https://www.youtube.com/watch?v=qBzB0YdHn64 https://www.youtube.com/watch?v=qBzB0YdHn64

stelonix 7y ago
Ok, I gotta say: none of the shaders or scanlines I've tried before ever came close to what I'm seeing in those videos; to the point I'd think "uh looks nice but that's not how I remember from the 90s". Now that crt royale... Color me impressed! Gonna try it as soon as I get access to a PC.
- DCKing 7y ago
  I've heard people say for CRT Royale to be truly effective you need to use it on a 4K TV. It apparently needs the additional resolution to truly shine. Having said that, it already looks really impressive to me on a 1080p TV.

1wd 7y ago

It would be interesting to add three photographs to each example: Original retro system display, un-corrected on modern display, corrected on modern display.

byuu 7y ago
It is extraordinarily hard to photograph handhelds that lack backlighting, and I left my CRT back in the US so that's also out ^-^; It would be a good idea to get some extreme close-up photos of the screens however, I'll keep that in mind for a future post.
- mark-r 7y ago
  In the US you can't even give away a CRT these days, you have to pay someone to take them. It might be hard to locate one depending on where you are, but once located maybe you could offer to take it off their hands?

rossy 7y ago

I've always wondered if you could just stick a colourimeter on a GBA SP and generate an ICC profile for it, then use that profile to adapt the colours to your display. It probably wouldn't be that easy, but there are colour management tools and libraries available that are designed for adapting colours between devices, so if you could somehow obtain a device profile for the GBA LCD, it might be possible to use it to produce very accurate colour emulation.

thristian 7y ago
As I understand it, colorimeter expect the display to output a particular colour or shade and measure it precisely. You probably couldn't run colorimeter software on a GBA, but you could write homebrew that let the user manually cycle to the correct patterns at the right times. Some issues would be: - There's at least three models of GBA display: the original front-lit display, the GBA SP back/front-lit display, and the later GBA SP backlit-only display, and they probably all have different profiles - It's probably not possible to use a colorimeter on the original front-lit GBA display, because with a colorimeter clamped on top of it, it would always look black - Colour-correction software that works with ICC profiles is typically built for print/still image work, so it expects a single high-resolution image with high-precision output, not a 60fps stream of very-low-resolution images. Maybe it's fast enough to run in real-time, who knows?
- rossy 7y ago
  Yeah, writing homebrew to get the GBA screen to display whatever a screen displays under a colourimeter, and getting that to work with the actual colourimeter might not be so easy. I think getting a device profile for the frontlit SP would be the most interesting, since I've heard it produces colours more like the original GBA than the backlit one, but maybe a colourimeter designed for backlit PC monitors would have trouble with it. I don't think performance would be an issue though. mpv can do colour management in real time by generating a LUT from the ICC profile and applying it to each frame with GPU shaders.
  - MartijnBraam 7y ago

CodexArcanum 7y ago

One thing I've been thinking about lately with emulation: why can't we replicate and use the original hardware more easily? There's lots of knockoff console replicas out there, so it seems like the chips can still be manufactured. Wouldn't it be fairly cheap to build a board/chip that contained either the original chip designs from classic computers/consoles, or hardware-level emulated chips? Seems like you could stuff several of those retro chips onto a single expansion board. Then emulation software could tap into this "emulation expansion board" to make use of the real chips. Is this all crazy talk or does any of that make some sense?

thristian 7y ago
There's lots of knockoff console replicas out there, but most of them are software emulation running on the moral equivalent of a Raspberry Pi, and the rest are often quite inaccurate approximations of the original hardware, with many incompatibilities with published games. Without access to the original designs, hardware emulation is in the same position as software emulation: you need to do a ton of research and development. A company called Analogue[1] makes FPGA recreations of a few classic consoles, but they're pretty expensive, and took a lot of effort to design. In fact, byuu (the author of the OP) was consulted fairly heavily during the design of their SNES reproduction. Basically, if you have to do a lot of research anyway, you might as well go with the product that has zero marginal production cost (i.e. software) and save yourself a bunch of manufacturing expenses for the same result. [1]: https://www.analogue.co/ https://www.analogue.co/
- CodexArcanum 7y ago
  Ah, that's good to know! That's a fun fact about byuu helping with the FPGA SNES that they built as well, really interesting! Thanks for the knowledge share!

spookthesunset 7y ago

> the Sega Genesis encodes 9-bit colors, giving 3-bits per channel I love systems that didn’t align everything on an 8 bit boundary. Are there any modern systems that aren’t 8-bit aligned?

Dylan16807 7y ago
Are you sure the Genesis didn't align things on 8 bit boundaries? Either way, it might be worth mentioning current systems that use 10-bit (30-bit) color. The N64 is notable for using ECC memory modules with ECC disabled, where the CPU sees 8 bits per byte and the GPU uses all 9 bits per byte for some functions.
mntmoss 7y ago
It is actually still 8-bit aligned with padding - we are talking about a system with a 68000 and Z80 here. The way the graphics systems of the era accomplished color depths like this was generally to do one of two things: 1. draw them in "planar" mode(multiple bitmap layers of a more convenient depth like 1-bit, then composited together into the full image) vs the "chunky" mode we are familiar with(all color information packed in each pixel of the bitmap). Planar graphics are much less convenient for ordinary drawing tasks, but they allow for a tradeoff between memory usage and fidelity. Put they ease a few kinds of raster effects if you carefully use your palettes. This is what the Amiga OCS had, and VGA in many of the custom modes. 2. Allocate the colors to sprite and tile hardware with limited palettes, so that you can achieve "n colors visible" by carefully combining all the different elements. Each element might be able to sample part of the 9-bit space with a palette of 4 or 16. In the case of the Genesis VDP your limit is ~64 colors visible of 512, with the special Shadow/Highlight mode allowing more. This is not as big of a limitation as it sounds like since the low resolution graphics of the time weren't suited for detailed color values: 4 is enough to do a shadow/midtone/highlight, and 16 allows for substantial color ramps with multiple hues.

nemetroid 7y ago

The part about color precision is similar to three-hex-digit CSS colors, where e.g. #5ce is expanded to #55ccee.

lanius 7y ago

Do "official" emulators handle these details? E.g., SNES games in Nintendo Switch Online

leoziih10 7y ago

Bag