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.

What is the current state on mixing SDL with native OpenGL rendering commands?? I ask this because of the SDL_GL_BindTexture() function.

This function binds the given texture on the current context. HOWEVER, it requires as a parameter an SDL_Renderer. I get that, as a depency,
this is required, but practically it is rather unhelpful. That's because since you use this, you will probably use direct OpenGL rendering commands, so
you will need a context. Wouldn't it be better to have a function to just get the index of the texture as a GLuint, and then proceed to do glBindTexture
and everything by yourself??

But that brings us to an other problem, which is that the very creation of an SDL_Texture depends on an SDL_Renderer (which again, can't be avoided
for apparent reasons). This forces one, if he does not like the Render API (which I think is awesome, but that's not the matter) or does not want to
use it either fallback to other libraries, or write a function to generate a GL texture from an SDL_Surface( which is what I currently do ).

So I see three cases here:
* Create an OpenGL context and use an SDL_Renderer just for the needs of creating and binding textures
* Use another library ( like DevIL for instance ).
* Use the SDL_Surface method described above.

In the first case, however, when I once tried it in the past, I would have some unexpected behaviour (which were introduced right after using a renderer).
Either way, it seems to me that the whole point of SDL_GL_BindTexture() is not the best option.

What do you think on that?? Am I wrong somewhere?? Is there any other alternative (without adding depencies other than SDL)??

Thanks,
Aggelos Kolaitis

If you're using OpenGL and just want to load textures you shouldn't use the renderer, you should write your own OpenGL loading code.  It's pretty straightforward and easy relative to the rest of the code you'll be writing.

The texture binding API was added for rare cases that I'll let other people explain.



On Fri, Aug 9, 2013 at 12:22 PM, neoaggelos wrote:

2013/8/9 neoaggelos


What's currently in SDL_GL_BindTexture is a middle ground of sorts between the "load the texture yourself" camp, and the "lets's bloat this thing with features" camp


Seriously though, I was the one that made that function. I use the SDL_Render* functions in my engine, and I integrate a couple of libraries which render via OpenGL (libRocket, the Spine runtime). Given that I'm already bringing in SDL, SDL_image, etc, I felt it was appropriate to save some time and effort and not re invent the wheel to load a few textures and set up a few shaders.


Eventually, SDL_GL_BindTexture evolved into SDL_RenderGeometry http://bugzilla.libsdl.org/show_bug.cgi?id=1734 . I don't know if this patch will ever land in the official repo, perhaps it'll take a SDL_Render "spin off" (a satellite library of sorts) for things like this to be accepted.


Regarding the "just get the index of the texture as a GLuint" part, if you look at the implementation on the three GL backends, you'll see that's not quite enough.


-- 


Gabriel.

On 10/08/2013, at 9:18 AM, Gabriel Jacobo wrote:

I think this is a good compromise .. because I have a use for it myself
I'm writing a text editor and currently I just TTF to create a surface
and blit it to the window surface with a software renderer.

However it would be more efficient to pre-load the character set
into the GPU.

So I will change my code to bind textures, still using the software
renderer, then switch to hardware rendering.

Without this functionality in SDL I could not follow such a nice
migration path. Good for "Agile" (whatever that is

The API I miss is filling triangles (more generally polygons).

--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

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