Simple textured shader for non-backlit LCD systems (GBC etc.)

[jdgleaver]

Yes, I did consider that - I guess it should be quite easy: just take the fractional part of (bgPixelCoord.xy * INV_BG_TEXTURE_SIZE) when sampling the background.

The only awkward bit is getting the texture size. I couldn’t find a way to determine this programmatically, so you’d need hard-coded values that you’d have to change whenever you wanted to try a different background. If I make all the images fixed-sized in advance, I don’t have to worry about this.

If you can come up with a better way of handling this stuff, I would be grateful!

---

As an aside, how does the external texture vertex coordinate work in the GLSL shader? I determined via brief experimentation that you have to scale TEX0 by ((OutputSize / InputSize) * 256) to get 1:1 pixel mapping on the screen, but I have no idea why… In the SLANG version, it is far more rational…

[hunterk]

Yeah, that’s a good point about not being able to get the size of the textures, and I’ve run into that before and had to rely on goofy magic numbers. I think BACKGROUNDSize should be the same sort of vec4 as SourceSize, but it just straight-up doesn’t work, which I think is a bug (or perhaps just an oversight during implementation).

FAKEDIT: it looks like it may be working with d3d11 but not vulkan, so yeah, that could just be an oversight in the vulkan imlpementation.

For the GLSL texCoord thing, IIRC, it’s usually TEX0 * TextureSize / InputSize or something like that where InputSize is the actual size from the core (256x224 or whatever; that is, NPOT) and TextureSize is the size of the buffer (1024x1024 or whatever). maister (the guy who wrote and implemented the shader specs in the first place while he was still in college) decided this was a bad idea in retrospect and corrected it for the slang spec.

REALEDIT: the way to get the texture size in GLSL would presumably be BACKGROUNDTextureSize or BACKGROUNDInputSize, neither of which seem to do anything. So, if you/we want the shaders to all act the same regardless of driver implementation, it’s probably best to leave it as you have it, though we should probably pare down the number of backgrounds we put on the repo, just so it doesn’t add too much to the download.

[jdgleaver]

OK, thanks for the info. I think you’re right - in lieu of working BACKGROUND*Size parameters, it’s probably best to leave things as they are.

For the reops, I would suggest culling all the backgrounds apart from the default ‘textured_paper.png’ - it’s by far and away my favourite, and people can always add more themselves (e.g. just by grabbing them from the zip files I posted). We might even get other users posting nice textures they have made…

For the GLSL texCoord thing, IIRC, it’s usually TEX0 * TextureSize / InputSize or something like that where InputSize is the actual size from the core (256x224 or whatever; that is, NPOT) and TextureSize is the size of the buffer (1024x1024 or whatever). maister (the guy who wrote and implemented the shader specs in the first place while he was still in college) decided this was a bad idea in retrospect and corrected it for the slang spec.

Right, but where does the factor of 256 come from ?!?

Actually, don’t worry! I’m just happy that it works as-is.

[jdgleaver]

I don’t know if it’s helpful, but I had a few spare minutes and just thought I’d re-bundle the shaders for uploading to the repos. I’ve removed all but the ‘textured_paper.png’ backgrounds, and also added a ‘4k’ variant of each shader (so users don’t have to mess about editing files if they have a super-high-res display). The size of each ‘package’ is ~2 MB, so I guess that’s not too bad?

GLSL: https://drive.google.com/file/d/1JoR1KuZP6BIXtfUecBXAfsU1maaMeM4d

SLANG: https://drive.google.com/file/d/16yW8N43T45D5ZaBUhxT33jEGmQDgtV9e

[hunterk]

Oh yeah, that is helpful, thanks!

I just pushed a version up to the GLSL shader repo with some small changes to make it tile the src pngs programmatically and a parameter to zoom the texture in/out for different texture/screen sizes. That gets the whole package down to a few hundred KB, even with a bunch of backgrounds, but if it looks bad to you, let me know and we can scrap it and use your repo bundle instead.

[jdgleaver]

I just pushed a version up to the GLSL shader repo with some small changes to make it tile the src pngs programmatically and a parameter to zoom the texture in/out for different texture/screen sizes

Oooh - That sounds neat! I’ll check it out once the repo updates (I guess there’s a time lag on github?).

Does the tiling/scaling have any appreciable effect on performance? One of the things I like best about the shader is that it runs on a potato… (I have a hard time finding decent shaders that work on rubbishy Android devices…)

[hunterk]

oh lol, whoops, I hadn’t actually pushed it up, just created the commit (I do that all the time…). Check it now.

Dunno if it affected performance significantly at potato-scale, since I’ve only tested it on a full-size PC, but again, if it’s affected things negatively, just let me know and I’ll dump it for your 2MB bundle.

[jdgleaver]

OK, you really puzzled me for a moment there! Everything was the wrong colour…

I should have mentioned that the generated textures are ‘adjusted’ slightly by the ‘generate_bg.bash’ script - it’s basically a:

convert image.png -brightness-contrast -30x25 image.png
convert image.png -colorspace Gray image.png

…so when you use the src images directly, everything’s too bright and a bit wishy-washy! But this is easily fixed.

I really appreciate what you’ve done with the tiling, but it kinda bugs me how we lose the pin-sharp 1:1 pixel mapping of the background texture. I tried a bunch of games and it looks a bit off to me. I’m not sure that anyone else would notice, but it tickles my OCD…

I guess I prefer my version…?

I feel terrible now… You’ve done something cool, and I’m being annoying about it… I bet you’ll say bad things about me behind my back…

[hunterk]

lol no, it’s fine. We’ll go with your version. The sharpness does look a lot nicer.

[jdgleaver]

Thanks, I appreciate it. You are a scholar and a gentleman!

BTW, it really is good of you to add my bit of code to the repos. I have so much love and respect for the RetroArch project. It feels nice to give a little something back

[RetroFans]

Amazing job,m8! I need to test if these delicious shaders can run smoothly on my Sd801 now

Edit:So it’s amazing smooth,really thank you

[jdgleaver]

Amazing job,m8! I need to test if these delicious shaders can run smoothly on my Sd801 now

Edit:So it’s amazing smooth,really thank you

Glad you like them!

I made sure they run at full speed with all handheld cores on my Fire HD 10, which has a PowerVR GX6250 GPU. The Adreno 330 in your SD 801 has very similar performance, so you should have no troubles at all.

[RetroFans]

Great to know!

[RetroFans]

Hi jdgleaver,any plan making a smooth crt shader for snes/nes/genesis with warpX/Y&glow&scanline effects for old phone? Something like this: https://i.imgur.com/KuNfxoz.jpg

[lilbud]

Could you post a preview of what the black grid version looks like?

[jdgleaver]

Hi jdgleaver,any plan making a smooth crt shader for snes/nes/genesis with warpX/Y&glow&scanline effects for old phone? Something like this: https://i.imgur.com/KuNfxoz.jpg

No, sorry - I’m already quite content with the existing CRT shaders in the repos…

But there is a fair bit of choice, even for old Android devices - and your SD 801 is quite powerful. You should have no trouble running something like crt-hyllian-multipass for example.

If you really want screen curvature, then I would suggest either ‘crt-pi’ or the curved variant of ‘zfast_lcd’ which you can get here: https://retropie.org.uk/forum/topic/13356/new-crt-lcd-shaders-for-rpi3-they-run-at-60fps-at-higher-resolutions-and-are-configurable (read the whole thread!)

One thing to note: for ‘crt-pi’ to work correctly on Android, you might have to force ‘highp’ precision (I’ve had to do this with every Android device I’ve ever owned, due to dodgy GPU chipsets). The quick and dirty way to do this is:

1. Open glsl-shaders/crt/shaders/crt-pi.glsl in a text editor

2. Replace every instance of ‘mediump’ with ‘highp’

(and while you have the file open, you can play with the CURVATURE and SHARPER settings)

I guess the ‘highp’ hack might also be needed for the zfast_crt variants, but I haven’t tried them…

[jdgleaver]

Could you post a preview of what the black grid version looks like?

Sure - here are some quick shots taken with the grid fully black:

(Important note - if you want a dark grid, you will almost certainly have to fiddle about with all the shader parameters mentioned in my first post… the current defaults are for a white grid, and they took a bit of tuning - with a dark grid, you’ll be starting from scratch… also, a mid grey grid will probably look better than full black - I recommend that you experiment!)

[RetroFans]

Thank you anyway,i gonna give it shot!

[lilbud]

Can the brightness be raised to overcome the intense darkening that the grid makes?

[jdgleaver]

Can the brightness be raised to overcome the intense darkening that the grid makes?

Sorry, I was busy yesterday and didn’t see your post…

No, I didn’t include the option to brighten colours - I toyed with it a little, but the results were never satisfactory.

However! You don’t need to make the grid as dark as in the screenshots I posted - here are some more, with different grid intensity/darkness settings:

Note also that much of the ‘darkness’ comes from the background texture being used. If you download one of the zip files in my original post, you will find a number of alternative textures - all of which are lighter than the default (or you can manually increase the brightness of any texture with an image editor).

I would recommend that you just try the shader yourself, and play around with settings/textures!