request: RetroArch compatibility

[eadmaster]

i'd like to ask a rewrite of the filter to be usable with RetroArch:

• option 1: as a bsnes (CPU) filter
• option 2: as a OpenGL shader

[gigaherz]

I will look into option 1. Option 2 should be relatively simple to implement, but I have never coded in GLSL yet.

Note: option 2 would have to be a full rewrite, it doesn't make sense to reuse any of the C code in a shader. option 1 may be possible to be a sort of adapter to convert bsnes plugin calls to the internal rpi-style functions, so it's a much simpler job.

[gigaherz]

I'm unable to find any information about bsnes "cpu" filters. There's one line in the FAQ but that's all. Everything else talks about opengl/d3d shaders.

I also was unable to find anything in the source, mostly because I wasn't able to figure out the code structure. If you can provide any more information, it would be appreciated, otherwise I'm abandoning option 1.

Time to look at shaders.

[eadmaster]

CPU filters have been removed in the latest releases. You have to look the source code of bsnes <=0.88 http://code.google.com/p/bsnes/downloads/detail?name=bsnes_v088-source.tar.xz&can=1&q=

[gigaherz]

Cg conversion: https://gist.github.com/3993749

The actual code is so simple I won't bother giving it a copyright.

[gigaherz]

Since I'm not in the mood to mess with porting it to a bsnes plugin, I'll close this issue as having completed option 1. You can feel free to open another one specifically for bsnes if you want.

[eadmaster]

The shader option is better since it is more portable. Btw the final result looks too similar to the old "dot" shader maybe it's just my GPU not rendering them correctly? see these comparison shots: http://eadmaster.altervista.org/tmp/lcd3x/retroarch_dot.png http://eadmaster.altervista.org/tmp/lcd3x/retroarch_lcd3x.png http://eadmaster.altervista.org/tmp/lcd3x/VBAm_lcd3x.png

[gigaherz]

That's because you are using the basic lcd3x, but I configured it as an lcd3x with scanlines.

You can remove the yfactor from the shader and the scanlines will be gone. and maybe decrease a bit the lcd brightness so that the effect is deeper. Play around ;P

I also don't see the LCD effect in that picture... strange.

[eadmaster]

ok, better, but i guess still not looking as it should... maybe it's just my AMD APU... can you post a shot? see also these: http://eadmaster.altervista.org/tmp/lcd3x/real_gg.JPG http://eadmaster.altervista.org/tmp/lcd3x/kegafusion_lcd3x.png http://eadmaster.altervista.org/tmp/lcd3x/ssnes_lcd3x_yfactor.png

[gigaherz]

updated: https://gist.github.com/3993749

[eadmaster]

ok, this looks fine! I think it's better with scanlines disabled (see the real Game Gear shot).

[eadmaster]

One final request: is it possible to have also optional motion blur? (it is present in many old portable LCDs)

[gigaherz]

On the shader? That'd have to be a libretro feature. It requires access to the previous frames' pixels, which means the app needs to save it somewhere in a render target to use later as a texture. If the feature exists, I suppose it could be done, otherwise, ask someone else ;P

[eadmaster]

I understand, i've seen this strange motionblur shader (not sure what its purpose is exactly) https://github.com/libretro/common-shaders/blob/master/Motionblur/Motionblur-blue.cg thank you btw!

[gigaherz]

That seems to be a shader that applies motion blur to the blue channel only ... but I suppose it serves as an example. Note however that software motion blur is not exactly the same as simulating an LCD with slow response times. I may try to implement it into the shader, but it will have to wait until tomorrow.