[Shader] Smooth pixel filtering

2013/12/16 vlag <valentin.soudier at gmail.com>

OMG, I would have never found it by myself ^^

You’re perfectly right, switching to a uniform sampler2DRect works just
fine \o/
So I documented a little about these rectangle sampler, and it seems that
they are prefered and optimized for post-processing effects (it gets much
easier for the programmer to work with non-normalized texture coordinates).
The main drawback is that some fetch sampler features are unavailable for a
rectangle sampler.

Found on another forum :

Quote:

  • Rect samplers support CLAMP, CLAMP_TO_EDGE, CLAMP_TO_BORDER wrapping.
    Fetch samplers return undefined results for border texels.

  • Rect samplers support filtering, including min/mag crossover (even
    though there is only one LOD, the switchover may change from nearest to
    linear filtering.) Fetch samplers only support nearest filtering.

  • Rect samplers support shadow comparison. Fetch samplers don’t.

These points are utterly unimportant with shader usage and 2D games. All
you want
to do is fetch each pixel, apply some custom effects onto it, and send it
to the screen.

Am I guaranteed that using sampler2DRect into shader sources will always
work with SDL and a OpenGL / ES2 context ?

No, and that will likely be a problem. Which texture target is bound
(normal, rectangle) is
in no way exposed by SDL, so ultimately, the best you can do is look at
SDL’s source
code and mimic the way it behaves. Currently, you could eg. check for the
rect texture
extension, and if that’s present assume that SDL will use it. But this
internal behavior
can change without notification and will then very likely break your
shaders without any
warning.

Quote:

Rectangular textures are more of an incompatibility than a feature in my
eyes.

I’m still pretty new with modern display features. Why should rectangle
sampler be avoided ?

Because they’re a deprecated functionality. Originally, textures in opengl
could only have
dimensions that were a power of two (256, 512 …). To allow for
arbitrarily sized textures,
a separate extension with its own texture type was created (which also
carried a bunch
of subtle changes compared to normal textures): rectangle textures. But
eventually, someone
must have realized that this was a useless over complication, and finally
arbitrary dimensions
in regular textures were implemented (initially exposed as an extension as
well,
GL_ARB_texture_non_power_of_two, but later made part of Core in 2.0), and
ever since
rectangle textures have faded into darkness as a useless feature (they’re
not even present
in GLES2). I think the best SDL could do is just drop the rect texture code
path, and either
go with fittingly sized regular textures when npot support is present
(which should be 99%
of the cases), and fall back to their already existing code path that
rounds up the texture
dimensions to powers of two on old hardware. This would at least allow
consistent shader
usage without fear of unforeseen breakage.> Anyway, a big thanks to everybody !

2013/12/16 Jonathan Dearborn

As a quick fix, one could even just make rendererdata->GL_ARB_texture_rectangle_supported
to be false when npot is available.

You would still hit the code path that extends the texture dimensions to
the nearest
power of two though, so whether npot is available or not wouldn’t change
much. You
might just as well always set it to false.

Am I guaranteed that using sampler2DRect into shader sources will always
work with SDL and a OpenGL / ES2 context ?

No, and that will likely be a problem. Which texture target is bound
(normal, rectangle) is
in no way exposed by SDL, so ultimately, the best you can do is look at
SDL’s source
code and mimic the way it behaves. Currently, you could eg. check for the
rect texture
extension, and if that’s present assume that SDL will use it. But this
internal behavior
can change without notification and will then very likely break your
shaders without any
warning.

You can probably determine this by checking the width/height values
returned by SDL_GL_BindTexture (http://wiki.libsdl.org/SDL_GL_BindTexture)

Gabriel.

Grr.? What idiot went and deprecated rectangle textures?? Probably the same morons on the GL committee who deprecated Quads.? They apparently don’t understand the meaning of “deprecated” over there:? it is part of the process of replacing something with something even better.? It does not mean taking something useful out and leaving nothing to replace it with.? That’s just called “stupid.”

Rectangle textures are far more useful than 2D textures, because they can be accessed in actual pixel coordinates.? Until they come up with a way to do that for 2D textures, there’s no good reason not to use rectangle textures.

MasonOn Monday, December 16, 2013 9:07 AM, Jonas Kulla wrote:

2013/12/16 Jonathan Dearborn

As a quick fix, one could even just make rendererdata->GL_ARB_texture_rectangle_supported to be false when npot is available.

You would still hit the code path that extends the texture dimensions to the nearest
power of two though, so whether npot is available or not wouldn’t change much. You
might just as well always set it to false.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You can use texelFetch to access individual texels using non-normalized
coordinates.

See here for more information:
https://www.opengl.org/wiki/Sampler_(GLSL)#Direct_texel_fetches

2013/12/16 Mason Wheeler > Grr. What idiot went and deprecated rectangle textures? Probably the

same morons on the GL committee who deprecated Quads. They apparently
don’t understand the meaning of “deprecated” over there: it is part of the
process of replacing something with something even better. It does not
mean taking something useful out and leaving nothing to replace it with.
That’s just called “stupid.”

Rectangle textures are far more useful than 2D textures, because they can
be accessed in actual pixel coordinates. Until they come up with a way to
do that for 2D textures, there’s no good reason not to use rectangle
textures.

Mason

On Monday, December 16, 2013 9:07 AM, Jonas Kulla wrote:
2013/12/16 Jonathan Dearborn

As a quick fix, one could even just make rendererdata->GL_ARB_texture_rectangle_supported
to be false when npot is available.

You would still hit the code path that extends the texture dimensions to
the nearest
power of two though, so whether npot is available or not wouldn’t change
much. You
might just as well always set it to false.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

? What? rectangle textures aren?t deprecated. In fact, they only have guaranteed support in OpenGL 3.1 and higher (or as an extension.)On Dec 16, 2013, at 1:22 PM, Mason Wheeler wrote:

Grr. What idiot went and deprecated rectangle textures? Probably the same morons on the GL committee who deprecated Quads. They apparently don’t understand the meaning of “deprecated” over there: it is part of the process of replacing something with something even better. It does not mean taking something useful out and leaving nothing to replace it with. That’s just called “stupid.”

Rectangle textures are far more useful than 2D textures, because they can be accessed in actual pixel coordinates. Until they come up with a way to do that for 2D textures, there’s no good reason not to use rectangle textures.

Mason

On Monday, December 16, 2013 9:07 AM, Jonas Kulla wrote:
2013/12/16 Jonathan Dearborn
As a quick fix, one could even just make rendererdata->GL_ARB_texture_rectangle_supported to be false when npot is available.

You would still hit the code path that extends the texture dimensions to the nearest
power of two though, so whether npot is available or not wouldn’t change much. You
might just as well always set it to false.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Ok, according to SDL sources, I just avoid the fetch sampler usage on the GLSL shader side with https://github.com/christopho/solarus/commit/51932e064ef9828c0a2f20383063b6719786fa28

I’ll change this if SDL provide a reliable way to force/choose between the two types.
I’m open to any discussion about a better workaround :wink:

Thanks again !

Btw. I’m not sure whether you know this - but
https://github.com/aras-p/glsl-optimizer offers a great way to optimize
your shaders for each platform. The advantage is that you could write
one shader that is readable but maybe not very performant, give it to
the glsl-optimizer and it will spit out an optimized version for your
platform. That might (or might not, I haven’t checked) also solve your
sampler problems on those platforms that don’t support it.Am 16.12.2013 21:18, schrieb vlag:

Ok, according to SDL sources, I just avoid the fetch sampler usage on
the GLSL shader side with
https://github.com/christopho/solarus/commit/51932e064ef9828c0a2f20383063b6719786fa28

I’ll change this if SDL provide a reliable way to force/choose between
the two types.
I’m open to any discussion about a better workaround Wink

Thanks again !


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

http://www.caveproductions.org/


https://twitter.com/MartinGerhardy

2013/12/16 Alex Szpakowski

? What? rectangle textures aren?t deprecated. In fact, they only have
guaranteed support in OpenGL 3.1 and higher (or as an extension.)

My bad. I assumed that since I almost never see them anywhere, and they’ve
been
shoved off in GLES2, that they’ve been officially deprecated, based on the
ARB’s “let’s
eliminate all duplicate ways to do the same thing”.

Ok, finally it seems that since there is no real shader abstraction library for now, the better approach is loading shader sources from a lua script (for the Solarus engine which already use lua).
Sending some parameters to the lua script like video_driver, sampler_type and language_version should be enough to cover every possible cases and allow to return an implementation of shader sources for every possible runtime context and optimisation/portability needs.

With that, each writers of a shader are free to choose to define the same comportement for each sampler type or not, to write a different implementation for opengl than opengles2 (or not), or make a shader usable for old GLSL languages version or optimize it with newer.

Except if someone see a more flexible way to do, I’ll go with it.
Thanks you all :slight_smile:

I don’t know, if you simply google it there seem to be plenty of options.
Many people have wanted to do what you want to do and so there are
solutions for that in different places named different things. I I think it
all depends on how far you want to be compatible and reliable. Last time I
got into that I researched what the popular game engines we’re using and
what you mention what specifically one of the solutionsOn Dec 17, 2013 8:26 PM, “vlag” <valentin.soudier at gmail.com> wrote:

Ok, finally it seems that since there is no real shader abstraction
library for now, the better approach is loading shader sources from a lua
script (for the Solarus engine which already use lua).
Sending some parameters to the lua script like video_driver, sampler_type
and language_version should be enough to cover every possible cases and
allow to return an implementation of shader sources for every possible
runtime context and optimisation/portability needs.

With that, each writers of a shader are free to choose to define the same
comportement for each sampler type or not, to write a different
implementation for opengl than opengles2 (or not), or make a shader usable
for old GLSL languages version or optimize it with newer.

Except if someone see a more flexible way to do, I’ll go with it.

Thanks you all [image: Smile]


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I’m sorry, my phone sent that email way before I was done editing so the
predictive text from voice and editing we’re not done and I was not
finished. Please excuse any thing that seemed rude or stupid . I’m not sure
what to support it seems like there’s a war going on with OpenGL types and
cplusplus and Java being pushed hard . It seems like they are always
claiming that X 11 is bloated and obsolete and the Java people I talked to
keep saying everything else is over complicated and unnecessary . I like
cplusplus and OpenGL types and at this point that’s all I want. Maybe angle
is my best solution. I can publish to Windows store or Google Play or other
places without even worrying about it and maybe it’s not about money, I’m
rambling I don’t know I think it’s nap time lolOn Dec 17, 2013 8:26 PM, “vlag” <valentin.soudier at gmail.com> wrote:

Ok, finally it seems that since there is no real shader abstraction
library for now, the better approach is loading shader sources from a lua
script (for the Solarus engine which already use lua).
Sending some parameters to the lua script like video_driver, sampler_type
and language_version should be enough to cover every possible cases and
allow to return an implementation of shader sources for every possible
runtime context and optimisation/portability needs.

With that, each writers of a shader are free to choose to define the same
comportement for each sampler type or not, to write a different
implementation for opengl than opengles2 (or not), or make a shader usable
for old GLSL languages version or optimize it with newer.

Except if someone see a more flexible way to do, I’ll go with it.
Thanks you all [image: Smile]


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org