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------------------------
C is the God’s Programming Language
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:
**
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
C is the God’s Programming Language
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2013/8/9 neoaggelos
**
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??
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.
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 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).On 10/08/2013, at 9:18 AM, Gabriel Jacobo wrote:
–
john skaller
@john_skaller
http://felix-lang.org