these already exist as shaders in retroarch:
https://github.com/libretro/common-shaders/tree/master/crt (see http://filthypants.blogspot.in/2015/04/more-crt-shaders.html for examples). you can view the source code for each: https://github.com/libretro/common-shaders/tree/master/crt/shaders

i think for most of these you can remove the extra passes (scanlines, blurs, etc) within retroarch shader options until you’re left with just the curvature part of the shader, but even then i think it’s going to be way too slow.

perhaps someone with opengl experience can let you know if there’s any further optimisation possible, but it seems to be a fairly basic opengl warp operation so i’m not optimistic :(

but my understanding is that these shaders split all the various functions into different passes – one shader preset is a load of separate passes, each with a different utility; eg, in a CRT shader, one pass will add scanlines, one will add blurring, one will add the curvature, etc. you can turn off all but the curvature pass, and achieve what the post is describing without touching any code. you can even save that as a new preset. this is exactly what i did when i wanted to use a LCD-type filter for GBA games, without killing my performance by including a load of extra passes i didn’t care for.

you might be in luck in that your project only needs a small resolution, i guess? if you set your retroarch output to that resolution (through the retropie launch menu), it may well cope with a single pass shader ok!

I’m the guy from the RPi forum who said it could be done.

The not wanting to help bit was mainly because I didn’t know what I would have been signing up to – it may have been hundreds of hours work for all I knew. That’s why I suggested you needed to provide people with more information about your project to interest them.

So, having got that out of the way…

That bit of information saying you only need 320×240 resolution is crucial.

The reason the RaspberryPi has problems running the shaders in retroarch is to do with how fast it’s GPU can access memory. Desktop GPUs, which retroarch shaders have been written for, have very fast memory access but, because accessing memory by GPUs is power hungry, mobile GPUs use a different design approach that minimises the amount of memory accesses they have to do to save power. Explanation why [url=http://blog.imgtec.com/powervr/a-look-at-the-powervr-graphics-architecture-tile-based-rendering]here[/url] if you’re interested in the details.

The multiple pass rendering technique that retroarch uses is pretty much the worst case scenario for mobile GPUs because it needs lots of memory accesses. When people say the Raspberry Pi is too slow running these shaders they are typically considering running them at desktop resolutions.

The fact that you only need such a small resolution makes a very big difference. The display you use takes up about 5% of the memory an emulator running at 1080 would. This means there is a good chance the Raspberry Pi could run some of those shaders at a decent frame rate.

dankcushions’s suggestion of trying just the curvature shader is a good one.

There’s a problem you need to consider when doing barrel distortion on a display that is so close in resolution to the game’s. When the vertical resolution after barrel distortion is less than the game’s vertical resolution, you will lose parts of the game screen. This may cause unacceptable problems – you might lose important bits of the game. You might be able to mitigate this with an anti-aliasing shader but they need lots of memory accesses so you might run into performance problems again.