BTW, I think the only real solution to this is creating 512-entry palettes. Conveniently, though, that solution will work the same way in every emulator that supports them, so it doesn't really have to be an emulation issue, they could all get it "right" just by using a suitable palette.
I think
Drag's NES Palette Generator does a good job of illustrating why. No matter how you generate an RGB palette to represent the NES output, there's some compromise of saturation or clamping or other distortion of what should be a more continuous (and vivid) set of colours. Proper modelling of emphasis has to be done before that compromise, not after.
If you hand a 64-entry palette to an NES emulator and expect it to come up with proper emphasis, there's really no way to recover the information already lost from clamping or other compromises.
What
zeromus ended up implementing for FCEUX is roughly:
- Generate a reference YIQ colour and its emphasis counterpart for the given NES palette entry (based on Bisqwit's implementation on the Wiki).
- Convert the two YIQ reference colours to RGB.
- Apply the relative adjustment of RGB components between these two reference colours as a multiplier on the given RGB palette colour.
- Clamp the result.
This is obviously not ideal, and there's probably a bunch of different ways to approach the same problem, but it's a solution that makes about as much sense as it can with the information given. The real problem is only being given 64 colour entries to work with, and being expected to synthesize emphasis for it. If the palette already contained this information there'd be no problem to solve, and no additional compromise to make here.
