Bingo! That makes sense it was the sharpening. I think we’re amazingly close now actually. What do you think? I mean with noisey images you’re never going to get it exactly right but that ringing is a lot more subtle and closer to the one produced in the shader.
The colours are off and I’m wondering why that might be - even in your images all the different options display different colours. The ones above are particularly red in the brickwork though.
Here are my latest two images, top one 1/30 and the bottom one at 1/60.
Quite why mine are orange and the CRT ones are red I’m not sure. What is actually correct red or orange?
There is no correct when it comes to NES color palettes. I’d say the bottom is closer to what I consider “correct,” the bricks should be brown without an obvious red tint, IMO.
NES isn’t a system you want to use for color correction purposes imho. Like NESguy stated, there’s no real accuracy to be had with NES pallets.
So as long as you get the other things down, the color correction portion should be the easiest part I’d imagine, as we have a decent amount of documentation for NTSC color stuff.
Colour is a rabbit hole, you probably want to make sure the shader handles basic stuff like maybe dithering and such first. A better example than NES emulation is probably the PS1, the (fat) PS2 can play those games via it’s own hardware emulation. I had a look at the a menu of Street Fighter Alpha 3, because I just had that at on the USB disk I’m using along with Castlevania Chronicles and Final Fantasy Origins. Here’s a screenshot taken with PCSX-Rearmed:
Here is a part in RGB:
Here in composite:
I mean the main section of color is pretty straightforward imho, as NTSC has a color standard, as does PAL, if I’m not mistaken.
It’s when you get into how different hardware actually handled that, is where things get murky imo.
How different consoles output that signal, how different CRTs pull in that signal, how different CRTs actually process the signal before the electron gun fires.
So when you say dithering what exactly are you talking about with regards to a CRT shader? I know what dithering is btw just trying to understand what part you think it plays.
I assume he’s referring to the Genesis primarily, which made heavy use of dithering for both “adding” colors and simulating transparencies, over “dirtier” signals.
Yes but that’s in the original artwork though or is there some piece of hardware in the megadrive’s output circuitry doing things on top of the relatively standard NTSC/PAL conversion?
In a very general sense, I would expect a CRT shader with options of RGB and composite input to display dithering differently. There is such a thing as RGB dithering obviously, but I would for example expect a shader to be flexible enough to degrade the composite signal in such a way as to allow the blending of pixels for instance. Maybe, this isn’t quite as basic as I think, lol. To me this is like “this is a good reason you should actually use composite for this content”.
I had proposed separate “modules” for composite outputs for the different systems to account for the differences in the output side that enabled the dithering tricks. These effects weren’t due to the TV’s composite input characteristics alone.
I’ve kinda been doing this using custom settings for Blargg NTSC Filter to recreate the output side, while my raw shader preset represents the TV’s input side.
Right yes ok so you’re talking about the dithering in the original artwork that gets ‘noised’ during transmission to the CRT which is what my first thoughts were when you mentioned dithering.
Essentially this should happen when using ntsc-adaptive.slangp no? I haven’t tested the megadrive again yet. I’ll give it a spin!
Sorry, I can’t comment on the actual capabilities of NTSC-adaptive, it’s obviously more flexible than those old 256px NTSC etc. shaders that were there first (great). My personal project in the near future is trying to explore the capabilities of MAME-HLSL a bit for the purpose of colour artifacting (=turn something monochrome into colour on a specific platform).
I will however leave another link, concerning dithering, this is a video that explains Playstation dithering in detail, mentioning for example how it’s an actual hardware feature:
N64 did hardware level blending. At least I think it was hardware.
At 8:40 there’s also talk about the N64, there’s actually quite an amount of different examples shown, it’s great. (I’m not associated with the channel in any way 
)
N64 and PS1 both have hardware-level dithering, though PS1’s is just a basic pattern overlay.
Re: NTSC simulation in general, you can isolate the NTSC passes from MAME-HLSL and, while I don’t think they generally look as good as ntsc-adaptive (which is just the ntsc-256/320-px shaders mooshed together with some logic to choose which one to use), they do expose a lot more signal values for tweaking. See: dannyld’s mega drive rainbow thread for more details.
I like the idea of different modules for different systems. The TurboGrafx 16 for example was known for having a very clean composite output, while the Genesis was terrible.
To do this we would need to get all the systems to one person so they can be connected to the same display, in order to eliminate the display as a variable. Or just get the raw captures from different people, but that seems harder?
So most of the above stuff as far as I can tell is stuff that should be emulated by whatever core we’re using at the time as in it falls outside the domain of a CRT shader. Certainly PS1 and N64 dithering falls into that camp. What we’re really interested in are the black boxes that is the output circuitry. I’m not terribly certain a whole lot of progress has been made in this area of emulation - there was a video on the SNES circuitry I watched a couple of years back that talked about it. I’ll try and find it.
It was actually an article I was remembering and it sounds like they actually did emulate the things I was talking about
NTSC aka Never The Same Color 
