New Shader class in SFML 2 to replace PostFx

[Laurent]

I thought the problem wasn't fisheye, but globalShader

It is fisheye with globalShader

Is it because you are using a RenderImage?

Yes, the internal texture of a render-image is flipped compared to a regular image. And the effect doesn't take that in account.

[panithadrum]

I thought the problem wasn't fisheye, but globalShader

It is fisheye with globalShader

Is it because you are using a RenderImage?

Yes, the internal texture of a render-image is flipped compared to a regular image. And the effect doesn't take that in account.

May I ask why? Some sort of optimization?

[Laurent]

No, it's just the way OpenGL draws to a render-texture. Actually, it forces me to add some ugly hacks to handle it.

[klusark]

Whenever I try to use sf::Shader::CurrentTexture it does not link telling me "unresolved external symbol "public: static class sf::Image const sf::Shader::CurrentTexture"". This also happens in the Shader example. I have linked sfml-graphics.lib and other graphics do work fine. I am using SFML2 revision 1399.
Thanks.

[Laurent]

You forgot to define SFML_DYNAMIC.

[heishe]

why did you remove the preprocessing step? seem very odd. what you had in there was a very clean, very easy to use version of the GLSL shader language.

[Laurent]

Basically, people had to learn GLSL and then unlearn a few things and replace them with SFML specific stuff. I find it more natural to use plain GLSL.

[heishe]

Basically, people had to learn GLSL and then unlearn a few things and replace them with SFML specific stuff. I find it more natural to use plain GLSL.

Mhm, yeah that is true I guess. I remember getting confused with the GLSL syntax a few times when I started using it together with the "sfmlglsl".

But without all the gl_Whatever stuff in the shader files it just seemed way more streamlined with the rest of SFML to me.

Maybe a solution would be to write a more detailed tutorial about pixel shaders in general?

I know it would cost you time, but you wouldn't have to go into syntax specific things like "put a ; after every statement". You'd just have to tell people: This is how you address pixels of a texture, this is how you manipulate it's color, and this is how you put it out to the screen. And maybe something like: "A pixel shader does that, and it works like this" etc.

Or you could somehow provide us with the preprocessing code so we can include it in our code ourselves?

But whatever, it isn't too big of a deal I guess. It's one of the few (if not only) 2D libraries where we even get to use pixel shaders so I'm happy

[Laurent]

I know it would cost you time, but you wouldn't have to go into syntax specific things like "put a ; after every statement". You'd just have to tell people: This is how you address pixels of a texture, this is how you manipulate it's color, and this is how you put it out to the screen. And maybe something like: "A pixel shader does that, and it works like this" etc.

It's even simpler with the current design: "read any GLSL tutorial and you're ready to use sf::Shader".

Or you could somehow provide us with the preprocessing code so we can include it in our code ourselves?

You're free to implement a different shader syntax and the proprocessor that goes with it. You can pick the code in sf::PostFx and base your implementation on that.