The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Hi everyone !

I've just ported a SDL1.2 game using software surfaces to SDL2, and exclusively use SDL_Texture to have a huge speedup.
The last point is that the game offer the possibility to choose a smooth display filter (Scale2x and HQ4x). It was previously done with pixel manipulations since it was not a costly operation with SDL_Surface.

Now that we use SDL_Texture, I've heard that the only way to reliably do pixel manipulations is to use GLSL pixel shader.
I'm pretty new with modern display features, so I'll ask some question before eating the documentation

* Is it possible to apply a GL pixel shader on the SDL_Renderer directly, since I just want to modify the final result ?

* If no, is there a way to apply it on each textures or should I let the possibility to still use SDL_Surface with all smoothed modes ?

* Last question, but it's not related to SDL so I might search by myself : if apply a shader on the renderer is possible, is that gonna work on mobile platform using GL ES too ?

Thanks to all readers, and I apologize for my bad English !

First of all: If you're going to use GLSL, it will only work with OpenGL SDL_Renderers. So, no Direct3D. I'm unsure about OpenGL:ES.

Secondly: Just use an SDL_Surface if you're going to do A LOT of manipulations on the CPU. Alternatively, use SDL_Texture (with streaming, I think) and eat the little performance loss.

Thirdly: You can tell the GPU to scale the texture for you by giving SDL_RenderCopy a destination rectangle that is bigger(or smaller) than the original image. I believe you can ask SDL to give it a hint on how you want the renderer to scale it, but that's just about it: a kind suggestion that it isn't obligated to follow.



On Tue, Nov 26, 2013 at 3:10 AM, vlag wrote:

1) Ok, since the portability of the app is more important than performances, I'm ok to drop the Direct3D support ( but not the OpenGL ES so I'll investiguate ).

2) The only pixel manipulations are these smooth pixel filters, so if I can apply a shader directly on the renderer, I guess using static SDL_Texture should be the best choice.

3) Tell the GPU to do bilinear interpolation will works for the Scale2x filter, since it's pretty much the same result, but not for the HQ4x one which is a little more elaborate ( http://www.hiend3d.com/hq4x.html ). Except if it is possible to set a custom hint to scale textures ?

By the way, thanks for your answer

On Tue, Nov 26, 2013 at 4:38 PM, vlag wrote:


If you only want bilinear interpolation just  use:


        SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "1");



... before creating your texture.



That texture will be blitted with bilinear interpolation, with direct3d the system can do also better with "2" (that's anisotropic, it's the same as HQ4x?), read the doc here anyway:


http://wiki.libsdl.org/SDL_HINT_RENDER_SCALE_QUALITY



AFAIR this setting is "per texture".


--
Bye,
 Gabry

I don't want to use the native bilinear interpolation, because we only have Scale2x and HQ4x filter for now, but we surely add some more later.

To elaborate a bit, what I really want to do is to still use SDL_Texture, write an abstraction class which will compile some arbitrary shaders (not known at the compilation time), and "apply" one of these shader on the renderer at each SDL_RenderPresent (.

Is there some kind of hack (or a proper way) to do this ?

2013/11/26 vlag


I think you won't get around using OpenGL directly. SDL2 doesn't expose
GPU shaders (for obvious reasons).


Jonas 

SDL2 doesn't expose GPU shaders because they're dependent on the renderer (OpenGL uses GLSL, Direct3D uses HLSL). However, one could probably make their own shader language for SDL which will then be converted to the shader relevant to the renderer, just like SDL_Texture.



On Tue, Nov 26, 2013 at 6:48 PM, Jonas Kulla wrote:

That would require building a full-fledged compiler into SDL, with a defined grammar, a lexer, a parser, and multiple code generator backends. I'm not sure anything like that would be within the scope of SDL.




On Tuesday, November 26, 2013 2:48 PM, Ivan Rubinson wrote:

SDL2 doesn't expose GPU shaders because they're dependent on the renderer (OpenGL uses GLSL, Direct3D uses HLSL). However, one could probably make their own shader language for SDL which will then be converted to the shader relevant to the renderer, just like SDL_Texture.
On Tue, Nov 26, 2013 at 6:48 PM, Jonas Kulla wrote:




_______________________________________________SDL mailinghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Which is exactly why SDL doesn't have that.



On Wed, Nov 27, 2013 at 2:12 AM, Mason Wheeler wrote:

Yeah, this is definitely extension library territory.


The proper way to do it is to write an extension library for SDL2. No
one's done it yet, because it's the sort of thing that scares people
off, but it should be quite possible. I'd suggest looking at the
parser stage of TCC: I've thought about how it would be a nice library
to have before, and always come to the conclusion that using the TCC
parser as a starting point would probably be the fastest route to the
goal. If you actually go this route, then I'd suggest that you start
by renaming the parser functions, so that someone else can later use
TCC itself for a software backend.

Just remember before you jump into such a project: compiler design is
not always the most straight-forward of processes, so do the simple
stuff first.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

No one has done it because at that point you'd be using either direct
calls to the video API or a premade full-blown engine from elsewhere.
SDL2 only provides the basics (and SDL1 didn't even provide that).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Just do the "shaders" on the CPU.



On Wed, Nov 27, 2013 at 7:41 AM, Sik the hedgehog wrote:

Hm ok, write an abstraction class for shading language is a little too much for what I want, since I'm ok to drop the Direct3D support and use only GLSL. I'm even ok to force the OpenGL ES2 driver if it's the only one supported on the 5 main platforms.
So let's say I just want to write a class that will compile a GLSL shader and apply it on the renderer, the whole thing is to know if it's possible before starting any code writing.



That mean don't using SDL_Texture and revert to SDL_Surface. This is the easiest way but definitively not the faster one (maybe the only way for what I want ? ).


Anyway, thanks for you help ! I really appreciate

If you need shaders, my suggestion would be to go for OpenGL or OpenGL ES directly. If you are not familiar with the APIs, you will face a higher learning curve in the beginning but you'll gain flexibility and performance in the long run.

The trouble with shoving shaders in a shader-unaware abstraction is that it will cause trouble sooner or later. SDL may be using shaders internally (it has to, for OpenGL 3+ and OpenGL ES 2+) and substituting these for your own is just asking for trouble.




2013/11/27 vlag

It is. My code does it. You just have to make sure that you preserve SDL's internal state, which means you query the active shader program (and anything else you change in the GL state machine) and then restore it once you're done.


Mason



On Wednesday, November 27, 2013 1:06 AM, vlag wrote:

#yiv9938926162 #yiv9938926162 -- #yiv9938926162 #yiv9938926162 body { font-size:11;} #yiv9938926162 #yiv9938926162 font, #yiv9938926162 th, #yiv9938926162 td, #yiv9938926162 p {} #yiv9938926162 p, #yiv9938926162 td {font-size:11;} #yiv9938926162 a:link, #yiv9938926162 a:active, #yiv9938926162 a:visited {} #yiv9938926162 a:hover {text-decoration:underline;} #yiv9938926162 hr {height:0px;border:solid 0px;border-top-width:1px;} #yiv9938926162 h1, #yiv9938926162 h2 {font-size:22px;font-weight:bold;text-decoration:none;line-height:120%;color:#000000;} #yiv9938926162 #yiv9938926162 .yiv9938926162bodyline {border:1px solid;} #yiv9938926162 #yiv9938926162 .yiv9938926162gen {font-size:12px;} #yiv9938926162 .yiv9938926162genmed {font-size:11px;} #yiv9938926162 .yiv9938926162gensmall {font-size:10px;line-height:12px;} #yiv9938926162 .yiv9938926162gen, #yiv9938926162 .yiv9938926162genmed, #yiv9938926162 .yiv9938926162gensmall {} #yiv9938926162 a.yiv9938926162gen, #yiv9938926162 a.yiv9938926162genmed, #yiv9938926162 a.yiv9938926162gensmall {text-decoration:none;} #yiv9938926162 a.yiv9938926162gen:hover, #yiv9938926162 a.yiv9938926162genmed:hover, #yiv9938926162 a.yiv9938926162gensmall:hover {text-decoration:underline;} #yiv9938926162 #yiv9938926162 .yiv9938926162forumlink {font-weight:bold;font-size:12px;} #yiv9938926162 a.yiv9938926162forumlink {text-decoration:none;} #yiv9938926162 a.yiv9938926162forumlink:hover{text-decoration:underline;} #yiv9938926162 #yiv9938926162 .yiv9938926162postbody {font-size:12px;line-height:18px;} #yiv9938926162 a.yiv9938926162postlink:link {text-decoration:none;} #yiv9938926162 a.yiv9938926162postlink:visited {text-decoration:none;} #yiv9938926162 a.yiv9938926162postlink:hover {text-decoration:underline;} #yiv9938926162 #yiv9938926162 .yiv9938926162code { font-size:11px;color:#3FB753;border-style:solid;border-left-width:1px;border-top-width:1px;border-right-width:1px;border-bottom-width:1px;} #yiv9938926162 .yiv9938926162quote { font-size:11px;color:#444444;line-height:125%;border-style:solid;border-left-width:1px;border-top-width:1px;border-right-width:1px;border-bottom-width:1px;} #yiv9938926162 Hm ok, write an abstraction class for shading language is a little too much for what I want, since I'm ok to drop the Direct3D support and use only GLSL. I'm even ok to force the OpenGL ES2 driver if it's the only one supported on the 5 main platforms. So let's say I just want to write a class that will compile a GLSL shader and apply it on the renderer, the whole thing is to know if it's possible before starting any code writing.

SDL shouldn't probably get it either. I think we can mostly agree
that's beyond SDL's scope.

Given how SDL's 2D renderer gets used, though, including a couple of
shaders in the renderer drivers that support them for a few major mag
filters wouldn't go unappreciated. Bicubic and either hq4x, 4xBRZ,
or both, are the obvious choices. Obviously if you're using an
OpenGL that doesn't support shaders, you're going to get your choice
of GL_NEAREST and GL_LINEAR. :)

You should be able to do bicubic even on DirectX 8 class hardware
even with pre-2.0 pixel shaders. That'd give you GF4-era hardware
support, and anything shipped with Windows post-XP is gonna have
better than that. Even Intel GMA will do the job, and that'll take
you back about 10 years now.

Actually Intel GMA and just about anything with DirectX 9 class
should do hq4x and 4xBRZ just fine I suspect.

OpenGL ES v2 would likely require a slightly different shader than
one for OpenGL desktop written for maximum compatibility. Some
OpenGL ES v1 APIs I guess expose shader functions because they're
actually OpenGL ES v2 hardware—but I don't see major reason to bother
with it for ES v1 since support would be spotty, you'd have v2
anyway, and anything using v1 natively probably has a 240x320 or
smaller screen anyway. Not much point in going out of your way. :)

Joseph


On Wed, Nov 27, 2013 at 05:04:09AM +0200, Ivan Rubinson wrote:


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Just to be sure, by "My code does it", you mean your code uses a GLSL shader when rendering on window, or that it apply a shader with SDL_Texture/Gl textures copying ?
Anyway, I'd be happy to see the piece of code if you agree, it can learn me a lot on the way to use shaders, in addition with the official SDL exemple ;)

@Joseph Carter
Ok so modern (or not) GPUs should be able to do some simple (or not ) pixel filtering using shaders, but my first question was mostly on software side, basically where is the limit of using GLSL shaders with SDL :)

Thanks again.

There's no limit to GLSL shaders with SDL if you know what you're doing.




On Mon, Dec 2, 2013 at 4:02 AM, vlag wrote:

My code applies shaders while rendering both textures and entire render targets to the current window. :)

You can find the entire codebase at http://code.google.com/p/turbu/source/ It's in Delphi. Run a search for "dm_shaders" for units that use the shader code. But the basic rule is, any code that does rendering outside of SDL's system has to restore any OpenGL state that it modifies before going back to SDL.

In the shader code, that means doing something like this:

procedure RenderWithShaders;
var
currentProgram: GLint;
begin
glGetIntegerv(GL_CURRENT_PROGRAM, @currentProgram);
try
//do rendering here
finally
glUseProgram(currentProgram);
end;
end;




On Sunday, December 1, 2013 7:56 PM, Ivan Rubinson wrote:

There's no limit to GLSL shaders with SDL if you know what you're doing.

On Mon, Dec 2, 2013 at 4:02 AM, vlag wrote:




_______________________________________________SDL mailinghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yeah, thanks for the code sample, it's really helpful :)

By the way, I tried to work with shader the last few days, and I've not reached my goal to apply a shader when rendering.
It work fine when I copy a Gl texture or a SDL_Texture to the renderer, but not if I try to apply the shader just before swapping the window by calling SDL_RenderPresent() (and restore it after).
It also don't work if I try with the SDL official shader exemple, where we just use the OpenGL API.

Do you confirm that it is really possible to apply a shader when rendering, or should I apply and restore the shader at each SDL/OpenGL draw to the renderer?

What do you mean when you say "apply the shader just before swapping the window by calling SDL_RenderPresent() (and restore it after)"?

You cannot use a shader to modify the contents of the default framebuffer. If you want to apply it as a post-processing step (as you seem to imply here), you'll need to render your whole scene into a texture and then use that texture as an input to your shader.





2013/12/6 vlag

You guessed right, apply a post-processing shader is exactely what I want to do :)

Ok, this is what seemed to me. The only reason what I didn't do that before is because I heard that render to a texture is slow and not supported by every modern hardware.
Am I right and should I apply the shader separately for each textures, or a hardware that support pixel shaders always support rendering to textures ?

2013/12/6 vlag


Most OpenGL 2.0 capable  hardware with up to date drivers is able to render to off-screen

buffers, so unless you want to target over 10 year old hardware, you should just assume
that this is always possible.

OpenGL 2 capable hardware seems to be old enough to assume it as a minimum requirement :)

So now I wonder about the speed.
Is it faster to copy all textures on a render texture, and then apply the shader when copying on the window renderer, or to apply and restore the shader each times a texture is copied on the window renderer (and keep working without rendering to textures) ?

2013/12/6 vlag


That entirely depends on your workload. If you render a lot of geometry per frame,

it is generally advisable to render everything to a screen sized texture and then

render it to the screen using your post processing shader. If it's just a handful of

things you are drawing, it might not be worth it. As always in the graphics world:

Profile, profile, profile!

AFAIK, binding a shader costs more than binding a texture (or, more accurately, binding a sampler to a shader.)

Minimizing state changes is always a performance win, so if you can get away with binding the shader once then I'd suggest doing just that. As Jonas said, you'd have to profile in order to get exact numbers.



2013/12/6 Jonas Kulla

Thanks ! That's exactely what I wanted to know :)



Yep, that's indeed the best things to do now :)

I think I got enough global informations to have a good overview of where I go, and be able to continue by myself.
I'll come back on this thread if something goes wrong ;)

Thanks a lot everybody !

Hi again :)

I'm getting lost with GLSL uniform variables.
I've reorganised the code to render on an intermediate SDL texture, bind it and draw it on the screen using OpenGL and a custom GLSL shader program if needed.

Everything seems to work except the uniform sampler2d, which means (if I understood correctly) that the shader can't access to the texture, and then display a black screen. If I don't 'apply a shader, everything works fine.

The C++ code can be found on the github page of the Solarus engine : the Shader class here https://github.com/christopho/solarus/blob/master/src/lowlevel/Shader.cpp and the VideoManager::shaded_render() method here https://github.com/christopho/solarus/blob/master/src/lowlevel/VideoManager.cpp#L497
The shader program seems to not find the binded texture using uniform variable.

Here is the test shader code (from the SDL exemple, so there is no error on this side)
Vertex shader :


Fragment shader :


Two questions :
* Do you know a reliable way to debug a shader ?
* Any advice on how to proceed or what I forgot / make wrong (knowing that the official SDL testshader.c exemple works fine) ?

I'm open to all comments about the code

2013/12/14 vlag


Okay, first off, debugging shaders is really hard. I think most people still rely on the
"printf debugging" equivalent here, which is to use different outputs (eg. flat colors)
and see how the shaders behave.


First of all, I would check that your geometry (your quad) is fine otherwise, by not
sampling from the texture and instead outputting a constant color:


gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);


Looking at the SDL2 source for the desktop GL renderer, it should be doing the right
thing during SDL_GL_BindTexture, as long as it is not a YUV texture (!!).

Sorry I forgot to mention that.
Yes the quad is drawed fine. With your exemple, the expected red rectangle is displayed.

That why I'm pretty sure the problem is related to the uniform variables.
How is the shader program supposed to 'bind' the texture to the sampler exactely ? It just check the given texture unit ?

I also wondered about these YUV textures too. It seems to be ok since the intermediate render texture is created with a packed32 pixel format

2013/12/15 vlag


Yeah, the sampler2D uniform basically just holds the number to the texture unit
from which the bound texture will be sampled from. Since all uniforms are initialized
to zero at program link time, you will sample from texture unit 0 (the default) without
having to do anything else, so in simple cases like this just plain binding the texture
should work (assuming the active texture unit is always kept at 0).
 



I think you shouldn't be worried about them unless you specifically told SDL to
create one.


At this point, I can't really find anything looking at your code. Maybe you could
verify that you're getting correct tex coords in the shader (by drawing them as
a color), and if that's correct, I would run the program through something like
apitrace to make sure the correct texture is bound to unit 0 (this will also let
you verify that the texture has the correct contents you want). You can find it
here: https://github.com/apitrace/apitrace (most distributions should have it
in their repositories though).

Just wanted to chime in; as a GL newbie, this exact scenario played out for me too. I hope a GL pro can shed light on what is going wrong, and then we'll be able to answer future enquiries with a wiki link.


Regards, 
Jeremy J.

Sent from my iPhone

On Dec 14, 2013, at 9:06 PM, Jonas Kulla wrote:

Ok I'll try to debug this way later, there is 2 major bug to fix before, due to the new Video managment ;)


In case someone still want to take a look on sources, there is new locations of shader-related code :
Shader : https://github.com/christopho/solarus/blob/master/src/lowlevel/Shader.cpp
Video::shaded_render : https://github.com/christopho/solarus/blob/master/src/lowlevel/Video.cpp#L503

You also may want to look at :
Video::create_window : https://github.com/christopho/solarus/blob/master/src/lowlevel/Video.cpp#L158 and
Video::initialize_video_modes : https://github.com/christopho/solarus/blob/master/src/lowlevel/Video.cpp#L682

Thanks you all

2013/12/16 vlag



Hey,


I went ahead and tried debugging this myself. Funnily enough I discovered that I had downloaded
and played with the solaris engine before, no idea why I didn't remember that =P Anyway, I
captured a trace of a little gameplay, and I think I have caught the culprit: for whatever reason,
SDL2 defaults to rectangle textures, even when the npot2 extension is available. The glsl syntax
for sampling from these is different from normal textures, ie.


    uniform sampler2D tex;
    void main() { glFragColor = texture2D(tex, gl_TexCoord[0].st); }


with normal textures becomes


    uniform sampler2DRect tex;
    void main() { glFragColor = texture2DRect(tex, gl_TexCoord[0].st); }


with rectangle textures (really it's just a 'Rect' appended everywhere). Looking at the SDL2
sources, it seems rectangle textures will always be preferred when their ARB extension
is present. The way SDL2 internally deals with this with their own shaders is by simply
prepending two defines when the rectangle extension is present:


    #define sampler2D sampler2DRect
    #define texture2D texture2DRect




Jonas

That seems like it should be fixed.  I would expect npot to be preferred.

Jonny D



On Mon, Dec 16, 2013 at 5:08 AM, Jonas Kulla wrote:

2013/12/16 Jonathan Dearborn


Hm, I pulled in the latest changes from hg, but this part from
render/opengl/SDL_render_gl.c (GL_CreateTexture) is still unchanged:


    if ((renderdata->GL_ARB_texture_rectangle_supported)
        /* && texture->access != SDL_TEXTUREACCESS_TARGET */){
        data->type = GL_TEXTURE_RECTANGLE_ARB;
        texture_w = texture->w;
        texture_h = texture->h;
        data->texw = (GLfloat) texture_w;
        data->texh = (GLfloat) texture_h;
    } else {
        data->type = GL_TEXTURE_2D;
        texture_w = power_of_2(texture->w);
        texture_h = power_of_2(texture->h);
        data->texw = (GLfloat) (texture->w) / texture_w;
        data->texh = (GLfloat) texture->h / texture_h;
    }



Am I missing something? According to this, rectangle textures are still
unconditionally preferred when available.

I meant in the near-future sense.  Rectangular textures are more of an incompatibility than a feature in my eyes.  A proper patch would probably add renderdata->GL_ARB_texture_non_power_of_two.

Jonny D



On Mon, Dec 16, 2013 at 10:49 AM, Jonas Kulla wrote:

2013/12/16 Jonathan Dearborn


Ahh, grammar fail on my part =P You meant "should be fixed" as in
"ought to be fixed", I see. Yeah, I totally agree, I was really surprised to find
rectangle textures in the SDL2 sources in the first place, as it's mostly a relic
of the past with very widespread npot support these days. I think it wouldn't
be too hard to add it, possibly just a check for the npot extension in the block
of code I posted that has higher priority than the rect texture check.

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 :



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




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


Anyway, a big thanks to everybody !

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

Jonny D



On Mon, Dec 16, 2013 at 11:29 AM, Jonas Kulla wrote:

2013/12/16 vlag


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.
 


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.




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.
 

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




Gabriel.

2013/12/16 Jonathan Dearborn


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.

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
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 mailinghttp://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:

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 ;)


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:

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

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



2013/12/16 Mason Wheeler

2013/12/16 Alex Szpakowski


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

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 solutions On Dec 17, 2013 8:26 PM, "vlag" wrote:

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 lol On Dec 17, 2013 8:26 PM, "vlag" wrote: