How to do shaders with HF 4+ and OpenFL8?
I am new to shaders and I keep googling and finding all kinds of contradicting answers and examples from varying years back like:
and references to how to use GLSL shaders using -Dnext but only for desktop targets.
What is the state now?
- Should I use GLSL shaders (should work with webgl?) or OpenFLs special own style?
- Where can I learn that OpenFL style if that is recommended?
- I tried to implement the scanline example (using openfl style) but it flipped my screen up-side-down. Should I somehow tell it to start UV from top or something?
- Are filtershaders and per-sprite shaders different things or just applied differently?
- is it possible to load a say .frag file to a FlxShader instead of using @:glFragmentSource and a string?
It indeed depends on your OpenFL version. OpenFL 8, which we recently added support for, supports GLSL shaders on native targets as well as WebGL (which is also the default HTML5 renderer now with OpenFL 8, as opposed to canvas).
Should I use GLSL shaders (should work with webgl?) or OpenFLs special own style?
I don't think OpenFL really has a "special style", apart from
#pragma headerit should be standard GLSL.
Where can I learn that OpenFL style if that is recommended?
Check out the flixel demos that use shaders:
I tried to implement the scanline example (using openfl style) but it flipped my screen up-side-down. Should I somehow tell it to start UV from top or something?
Do you have an example of how to reproduce that? Have you tried comparing your code to the demos?
Are filtershaders and per-sprite shaders different things or just applied differently?
Just applied differently. Filter shaders also don't have support for color transforms, since there's no
FlxSpritethey could get the info from. Although technically, nothing is stopping you from setting those values yourself, Flixel just won't be doing it for you automatically.
Is it possible to load a say .frag file to a FlxShader instead of using @:glFragmentSource and a string?
Yes, you can set the shader source at runtime (
glFragmentSource: http://api.openfl.org/openfl/display/Shader.html#glFragmentSource). I'm not sure I'd necessarily recommend it, as you lose type safety when accessing shader attributes, as the shader can't generate fields for them in that case. In the future, it might be possible to have the best of both worlds: https://github.com/openfl/openfl/issues/1878
The upgrade guide for the transition from OpenFL 3 to OpenFL 8 might also be useful, as it has some info on shaders:
What I meant with "style" is the "openfl_" variables such as "openfl_TextureCoordv" and "bitmap".
Should they be used instead of other GLSL alternatives?
As an example I just simply took the game from the HaxeFlixel book and replaced the post processing with the scanline example from the Filters demo. It feels like UV is not starting at the same point as haxeflixel thinks it does... or I am just not doing it right ;).
I think the
openfl_prefix is mostly just to avoid naming clashes with custom attributes (and to match the GLSL convention of prefixing things - GLSL itself uses
gl_). Those attributes are also set automatically by OpenFL, so it's probably a good idea to use them instead of manually reimplementing the functionality. :) Not sure what you mean by "other GLSL alternatives" exactly.
Sorry for being tired and unclear. "other" = gl_ prefixed variables that you just informed me are set by openfl. Thank you! :)
openfl_ones are the ones set by OpenFL. :)
Meaning that normal gl_ attributes are not set?
So any stolen shaders have to be altered to openfl_ style?
Also the flip bug had to do with me applying the shader to both the camera and game. Why it flips then I don't understand but removing one of them solves it.
I'm not sure if anything needs to be "set" there, isn't that just built into GLSL and "just works" with OpenGL / WebGL? What attributes are you talking about exactly?
To be honest, I don't know too much about shaders.