mame
mame copied to clipboard
mamedev
Use P1 and P3 Phosphor colors for monochrome monitors
Resolves #5311
Got the wavelengths from https://en.wikipedia.org/wiki/Phosphor and converted them using https://academo.org/demos/wavelength-to-colour-relationship/
Changing the definition of “green” in rgb_t is a bad idea. It’s used as more than a phosphor colour, e.g. when building an RGB palette here: https://github.com/mamedev/mame/blob/mame0262/src/mame/luxor/abc80x.cpp#L282
Would it make more sense for us to have a special class/struct for phosphors? This makes sense notably for P-7 (or P-18?) as used on the canon cat's screen, which is white (like P-4 is, as was typically used on monochrome screens) but has a longer persistence and fades to a yellow-green while fading out, as opposed to P-4 which is short persistence and remains white.
Would it make more sense for us to have a special class/struct for phosphors? This makes sense notably for P-7 as used on the canon cat's screen, which is white (like P-4 is, as was typically used on monochrome screens) but has a long persistence and fades to a yellow-green while fading out, as opposed to P-4 which is short persistence and remains white.
This stuff is easier to handle with shaders, handing off the raw intensity to the shader to let it do what it needs to.
That was the only driver to use green() in that way, looking at palette.h it is obvious that "green", "amber" and "white" are supposed to be the 3 major CRT colors
That was the only driver that used green in that way, looking at the pallette file it is obvious that "green", "amber" and "white" are supposed to be the 3 major CRT colors
should the 3 be renamed in the palette.h file then, to phosphor_green or p1_green or such?
That was the only driver to use green() in that way, looking at palette.h it is obvious that "green", "amber" and "white" are supposed to be the 3 major CRT colors
Ah, I also grepped and concluded the same, I have committed the same change before I saw yours. https://github.com/mamedev/mame/commit/5b43765fd33b89fed7179d35df2d3fea75589b34
It’s a bad place for phosphor colours though. rgb_t is used for colours in many places besides monitor phosphors, and the black() and white() constants are used for zero and unity (e.g. many places in the UI code).
If you want to get into semantics, “white” monochrome monitors typically used the P4 phosphor (also used in monochrome TVs), which is “page white”, and noticeably more yellow than the P18 phosphor.
As @Lord-Nightmare has brought up, phosphors often persist with a different colour to what they emit under direct excitation.
The P4 wavelength on Wikipedia doesn't really convert well so I left it out.
And honestly I hate looking at all the MESS machines looking wrong because green CRTs are not 00ff00 green.
The linked issue is 5 years old as well (I was going through oldest to newest looking for stuff to fix)
It’s a bad place for phosphor colours though.
Then why are they in palette.h in the first place.
It feels like you want a major rewrite but that's just not viable right now, especially for a small change such as a colour.
Other than the abc80x, rgb_t::green() is exclusively used for CRT colours and I think we should stick to that.
I can seperate the entries and write a comment about it so the next person doesn't try to use green() for the palette
MAME is about accuracy and I think this is a step in that direction. "Green" is human perception and the current definition of green is nowhere near what a human would see on an old CRT. https://youtu.be/cznyKsOl3po?si=pqMDkz81h00vHxNJ You can tell this is brighter than 00ff00 Phosphor persistence is something a shader should handle but the color on a monochrome monitor isn't, in my opinion
I agree with @cuavas: util/palette.h is, in principle, the wrong header to put phosphor color definitions. I would prefer that they be placed in a new header in src/devices/video. There were also two different phosphors commonly used by green-screen monitors: P31 and P39.
(The standard colors should ideally be constexpr variables rather than zero-argument functions; the reason I made them functions a few years ago is that the pre-C++17 interpretation of constexpr variables was Not Quite the Right Thing.)
Mapping the peak wavelength at full excitation onto sRGB doesn’t give a good representation of the actual colour either, as the phosphors were intentionally designed to produce broader spectra than that. The colour shifts depending on the beam intensity, too. @Lord-Nightmare is probably right in that the only way to have any chance of making it look right is to have some type to represent monochrome phosphors so shaders can take an intensity signal off one channel and simulate the actual response.
We can't get it "right" without shaders, but we can still make it closer than 00FF00, and it would then be much easier to find all of the drivers wanting to do this in the future when it is possible to take the shader path.
Another thing which might be worth considering is adding the VFD phosphors somewhere. I don't know the actual registered Px numbers for these, but the CIE 1931 XYZ colorspace values for the common ones are shown at https://www.noritake-elec.com/support/design-resources/custom-design/custom-vfd-glass#custom-vfd-glass-08 (these are useful for svg artwork for handhelds; I used the Green/Blue-Green color to figure out the SRGB values for the speak & spell svg, for instance)