New CRT shader - Any interest?

RetroArch Additions Shaders
#81

There are several issues with interlacing that I think can only really be fixed with more metadata from the cores. Currently most cores output both fields (e.g. 480 vertical pixels) to indicate that the content is interlaced. We have no way of knowing which field is the current field and which is the previous. As a consequence:

  • We might display the wrong one and basically add a frame of lag.
  • We might get the NTSC phase offsets wrong. I’ve been struggling with how to do this. Even in standard NTSC the phase cycle is four fields long when interlacing. Some systems might be even more complicated. We kind of need to know where we’re at to make it work. We can make a guess and maybe it will be close enough, though. Unless this is what you’ve figured out?

crt-beans currently supports interlacing by either:

  • Showing one field at a time (properly offset and with the proper scanline sizes). There is a toggle for the “phase,” i.e. which field is current depending on whether the frame count is odd or even. This can cause issues on some LCD panels due to charge accumulation. You can basically get a weird flickering that persists even after the interlacing is gone.
  • Rendering both fields and blending them together. This works great for systems with 480p output to give them that 480i feel. If the two fields are different, you’ll get combing artifacts, though.
  • VGA line doubling (default on the VGA preset) that will line double the lower resolution VGA modes. I don’t really deal with anything above VGA resolutions.
2 Likes
#82

finally found someone who cares about CRT interlacing!

true, I noted this before

unfortunately, interlaced seems so underrated, RF is underrated too

#83

The main thing I was concerned about with the Multiscan support in Scanline Classic was automatically enabling the line doubler at a certain point and adjusting the spacing between active lines based on resolution (the scanlines disappear at a high enough resolution). This support is relevant for computers. If you don’t care about computers or a rare type of HD CRT, it’s not relevant.

I think the field order is deterministic based on core for many systems and the behavior is documented. A simple macro system that can make defines based on the emulated system would be good enough, e.g.

#ifdef __SYSTEM_SNES
#define EVEN_FIELD_FIRST 0
#endif
#84

@beans lots of interest indeed! I just updated my shaders and found yours. Trying it out at the moment, and I like what I’m seeing a lot, it is next gen GTU. Excellent work :smiley: