Shaders implementation

[vlag]

I open this issue to keep a trace of some informations, and because we should discuss some point before fully implement shaders. This is also the last part to let the display fully handled by the GPU.

Since shader filter for the SDL_Texture's GL_TEXTURE_RECTANGLE_ARB encapsulation is implemented, I discovered some very interesting features and projects.

So firstly, we still need to support GL_TEXTURE_2D on the engine side too (GL ES seems to not support GL_ARB). I opened this thread on the SDL forum to be able to get the encapsulated texture type by the current SDL way (and then be sure that the specific code will never be broken). I opened it on the bug tracker too.

This also means that there is a hope to have a reliable shader abstraction on the user side. Here is some interesting projects to cross-compile shaders :

• MojoShader , currently used in Unity (mercurial).
• hlsl2glsl (fork) , was used in Unity 3.0 (github page).
• HLSLCrossCompiler.
• Angle , a GLSL to HLSL Cross compiler, used in SDL2.

On another hand, some projects like the Love2D framework use a few language abstraction for driver and sampler-specific calls. I don't know if it's reliable, especially to handle HLSL shaders, but it should be enough to write GL and GLES shaders without manually handle the driver, sampler and language version in the script, and then avoid some technical issues.

To finish, here is a GLSL optimizer, used in Unity too (github page).

I know shader implementation is not prioritary, especially not the user abstraction, so I just open this issue to not forget ;)

---

Edit : Point to clarify before going further with the shader system :

• Implement GLES and HLSL, or discuss about implementing an abstraction shader feature (probably a third party lib).
• How to pass Textures to the renderer (one render by layer to allow a different shader by layer, one render for the whole frame, one render for the map and another for the HUD) ?
• Parameters to share between engine and shader scripts (or make the shader class exportable to lua to let the decision to quest makers ?).
• How to handle shader files and structure (keep one big lua file or separate into 3 files, make shader class exportable to lua, still list shader files dynamically ?).

[vlag]

In case someone want to test shaders, here is some shader scripts ported from the bsnes project, from the mari0 one, from the libretro/common-shader repo or written after some google research.

To use them, you need to compile the engine with OpenGL support. To do so, add

find_package(OpenGL) include_directories(${OPENGL_INCLUDE_DIR}) target_link_libraries(solarus ${OPENGL_LIBRARIES})

to the CMakeList.txt file anywhere after the AddSolarusExecutable part, and replace

define SOLARUS_HAVE_OPENGL 0

by

define SOLARUS_HAVE_OPENGL 1

into Common.h. Here is current ported shaders, you can place them in data/shaders/videomodes/ :

Smoothing filter shaders :

hq2x : It doesn't seems to be the original hq2x algorithm because the display is not the same than the build-in hq2x, even in the original game (mari0). Its name is hw_hq2x in mode selection. hq4x : Same comments than for hq2x. scale2x : Exactly the same display than the build-in scale2x, but handled by the GPU instead of the CPU. Its name is hw_scale2x in mode selection. xBR-hybrid-v5 : xBR-v3.8c + reverseAA. Ported from the original CG shader using the cg2glsl python script. Except minor displaying issues, this is the best smoothing shader of this list IMHO. xBR-v3.8a (rounded) : Ported from the original CG shader using the cg2glsl python script. xBR-v3.8b (semi-rounded) : Ported from the original CG shader using the cg2glsl python script. xBR-v3.8c (squared) : The successor of the hqNx algorithm. Ported from the original CG shader using the cg2glsl python script.

Fun shaders :

CRT-interlaced curvature edge-detection grayscale heavybloom pip : The only current ported shader which implement a visible time effect (CRT-interlaced is time-dependent too but it's not really visible for players). sepia toon waterpaint

xBR scripts are exactely the same for each scale variant (from 2x to 5x), so I set the default window size to 2x but you can change this very easily. There are some displaying problems if the window size isn't a multiple of the quest size. Else, the result is very impressive ! :) .

Since some smoothing shaders needs the window size to be an integer multiple of the quest one (or even an unique scale), maybe we should add some optional return values in shaders scripts to be able to automatically resize the window to the closest accepted scale when the SDL resize event is triggered.

Except smooth filter shaders, all scripts are quite easily modifiable, to decrease/increase their effects or change some details via definition. I still wish to port xBR-mlvl4 and I think that it should be enough for the first shot :)

Here is a video of current ported shader, and the OSX 1.3.1 Solarus engine, built with shader support and embedding zsdx quest with current ported shaders

[wrightmat]

I found this shader to calculate light points: http://www.mediafire.com/view/8122n5zc5kef9p6/LightFS.txt. I'll just leave that there for when this gets implemented...

[vlag]

It seems to be a 3D shader. All 'uniform' variable at the top of the script are synchronized with the engine, but the only ones I send for now in Solarus are the sampler (= the texture displayed by SDL at the rendering part, in our case), the size of the window, and the elapsed time since the current shader was loaded. Unless I misunderstood something, other ones of the script seems to be related to a 3D environment, like radius or lightPos.

The script can of course be ported to a 2D context, but we have to change extra uniform variable into local ones (not necessarily constant, we can imagine the lightPos value depending on the elapsed time for exemple), but this is maybe too much work for the theoritical result (there is just one texture to display in our case, so we can't end up with the expected '3D effect', just one surface that will be uniformly enlightened, I guess something like a flashlight effect).

Anyway, thank you :)

[vlag]

An update of the most interesting ticket about the shader abstraction :

http://aras-p.info/blog/2014/03/28/cross-platform-shaders-in-2014/

And some link to article/doc/presentation of current projects :

https://docs.unrealengine.com/latest/INT/Programming/Rendering/ShaderDevelopment/HLSLCrossCompiler/index.html https://github.com/James-Jones/HLSLCrossCompiler http://docs.unity3d.com/Manual/SL-Shader.html http://renderman.pixar.com/view/simple-shader-writing (not designed to be embed into a game engine, but the one that have introduced the modern use of shader since 25 years, and which is also not hardware-dependent)

[christopho]

@vlag All your shaders are broken links :(

[christopho]

Added shaders from @vlag to the sample quest repo: https://github.com/solarus-games/solarus-sample-quest/tree/shaders/data/shaders

By the way, libretro has proper GLSL shaders now: https://github.com/libretro/glsl-shaders/