MAMEWorld Forums - EmuChat - Re: Here's an example of the rotate png scanlines...

> > > Best I could manage with my phone. The image is richer, and the colors brighter,
> > than
> > > either D3D and png, or HLSL, because they're actual hardware scanlines produced
> by
> > > the synthesis of the resolution with the right png file. And the image isn't
> being
> > > 'masked'.
>
> I love the combination of integer scaling + a .PNG overlay
> The resulting picture is so much brighter and clearer than most existing crt shaders
> it's fascinating.
>
> Looks much better in real life because the RGB 'strips' that I've added to every
> pixel 'shine' and as a result, simulate a kind of 'life' to the pixels and a
> simili-dithering instead of full plain color areas.
> It's not using any kind of smoothing nor shades of grey, everything is pure RGB
> colors on a single .PNG file, so It's very sharp and colorful but not 'pixel-ey'.
> Considering a normal 60Hz LCD is producing more or less smearing and can have a
> relatively insufficient brightness output when too much stuff is overlayed, this
> method actually works best.
>
> Of course many people won't accept the black borders area, but it's possible to
> integer-scale the other way and make the picture bigger than the screen in some cases
> (of course that means creating a new .PNG to match the different scaling factor too!
> quite the hassle)
>
> Too bad screenshots kind of fail at showing how good it looks in practice:

Your overlay is pretty good. Like you say, the image stays pretty bright. That's because you have a lot of pixels that don't have the RGB pattern on top of them lowering the brightness. CRT shaders can keep a bright high contrast look too. It's really just a matter of keeping the scanlines bright and sharp, having an aperture mask that doesn't lower the brightness too much, and not letting the shader blur the pixels too much.

Timothy Lottes had a blog post a few months ago where he talked about a non-realtime CRT shader. One of his ideas is how to properly apply tone-mapping in a CRT shader to get back the brightness without losing quality in the aperture mask effect. I added a quick and dirty tone-mapping step to my local copy of his GLSL CRT shader and it looked pretty nice. I never fixed it to do exactly what he described though, but I may do that soon and post it here if it looks good. The images are missing from the blog post now, but you can read the post here: http://timothylottes.blogspot.com/2015/09/tonemapping-slot-mask-simulation.html

He had several ideas that wouldn't work with the GLSL system. I don't know which of them are feasible in the new BGFX shader system that MooglyGuy has been working on. I suppose I can try to make a version of Lottes' shader for the new system once it's in the main MAME branch. I guess that would be a good way for me to learn how the new system works.