Ah! I remembered my username. Lucky guess I suppose - now on to the post…
There seems to be a problem with the way I’m handling OpenGL with SDL2. The problem is when I call SDL_CreateTextureFromSurface, SDL seems to alter the way OpenGL is rendering. At first, everything renders properly, and after calling the function, there’s some oddness that occurs. You can see it in this picture here http://puu.sh/dEEfO/1b50babbe7.jpg . I have it completely narrowed down to that function, but because I don’t have direct access to the source code, debugging it further is problematic. Even more so since not too many people seem to use SDL2 for rendering alongside OpenGL.
I’ve tried multiple things, and the closest success I’ve had is calling SDL_GL_MakeCurrent after calling SDL_CreateTextureFromSurface. Calling that function does restore the quality of the 3d model. However, at that point, SDL2 API 2D draw calls seem to no longer have any effect, so it’s one step forward, and one step back. I’ve also tried various draw loops with mix and matched SDL2 rendering/OpenGL functions, but to no success.
In case someone needs to know, my initialization procedure is as follows:
Generic SDL Init Functions (SDL_Init, etc)
SDL_GL_SetAttribute
SDL_CreateWindow
SDL_GL_CreateContext
SDL_GL_MakeCurrent
glewInit
SDL_GL_SetSwapInterval
SDL_GetNumRenderDrivers/SDL_GetRenderDriverInfo to get the opengl driver index
SDL_CreateRenderer
Then…(to show and set the window to black)
10. SDL_ShowWindow
11. SDL_SetRenderDrawColor
12. SDL_RenderClear
13. SDL_RenderPresent
12. glViewport
After that, I do the usual.
13. (This is where I would call SDL_CreateTextureFromSurface)
14. Initialize OpenGL data for models, textures (using SOIL), and compile shaders.
And at that point, I’m basically at my draw loop, which kind of looks something like this:
Set Render Draw Colour (SDL_SetRenderDrawColor, or glClearColor)
Clear Buffer (SDL_RenderClear or glClear(Color | Depth))
Enable GL_DEPTH_TEST, clear depth buffer bit if using SDL_RenderClear
Use shader, set uniforms, set active texture 0, bind vertex array object, bind texture 2d, call draw, and unbind everything.
Disable GL_DEPTH_TEST
I’m hoping there’s some simple solution to this problem, as I’d love for SDL2 to continue handling text rendering (which is the only thing I’m using SDL_CreateTextureFromSurface for at the moment).
Ah! I remembered my username. Lucky guess I suppose - now on to the
post…
There seems to be a problem with the way I’m handling OpenGL with SDL2.
The problem is when I call SDL_CreateTextureFromSurface, SDL seems to alter
the way OpenGL is rendering. At first, everything renders properly, and
after calling the function, there’s some oddness that occurs. You can see
it in this picture here http://puu.sh/dEEfO/1b50babbe7.jpg . I have it
completely narrowed down to that function, but because I don’t have direct
access to the source code, debugging it further is problematic. Even more
so since not too many people seem to use SDL2 for rendering alongside
OpenGL.
I’ve tried multiple things, and the closest success I’ve had is calling
SDL_GL_MakeCurrent after calling SDL_CreateTextureFromSurface. Calling that
function does restore the quality of the 3d model. However, at that point,
SDL2 API 2D draw calls seem to no longer have any effect, so it’s one step
forward, and one step back. I’ve also tried various draw loops with mix and
matched SDL2 rendering/OpenGL functions, but to no success.
In case someone needs to know, my initialization procedure is as follows:
Generic SDL Init Functions (SDL_Init, etc)
SDL_GL_SetAttribute
SDL_CreateWindow
SDL_GL_CreateContext
SDL_GL_MakeCurrent
glewInit
SDL_GL_SetSwapInterval
SDL_GetNumRenderDrivers/SDL_GetRenderDriverInfo to get the opengl
driver index
SDL_CreateRenderer
Then…(to show and set the window to black)
10. SDL_ShowWindow
11. SDL_SetRenderDrawColor
12. SDL_RenderClear
13. SDL_RenderPresent
12. glViewport
After that, I do the usual.
13. (This is where I would call SDL_CreateTextureFromSurface)
14. Initialize OpenGL data for models, textures (using SOIL), and compile
shaders.
And at that point, I’m basically at my draw loop, which kind of looks
something like this:
Set Render Draw Colour (SDL_SetRenderDrawColor, or glClearColor)
Clear Buffer (SDL_RenderClear or glClear(Color | Depth))
Enable GL_DEPTH_TEST, clear depth buffer bit if using SDL_RenderClear
Use shader, set uniforms, set active texture 0, bind vertex array
object, bind texture 2d, call draw, and unbind everything.
Disable GL_DEPTH_TEST
I’m hoping there’s some simple solution to this problem, as I’d love for
SDL2 to continue handling text rendering (which is the only thing I’m using
SDL_CreateTextureFromSurface for at the moment).
If you only need SDL (I assume _ttf?) for text drawing, why don’t you just
manually
handle texture creation / updating? Is there something in particular
preventing that?
Generally speaking, mixing your own OpenGL code with the render module is a
bad
idea and should always be avoided if possible, because every layer on top
of OpenGL
will expect having full authority over the context and change states at
will without
informing you (cleanly separating this is nigh impossible due to OpenGL’s
global state).
Besides, using the render system for anything more sophisticated than
simple sprite
games, ie. using shaders, is impossible anyway because SDL will silently
use different
texture types depending on the platform. It’s really best to look at it as
an isolated
subsystem that abstracts away OpenGL / Direct3D / software rendering
instead of
an enhancement to regular OpenGL code.
Before even attempting to solve this: the renderer API and using
OpenGL directly are not compatible. You have absolutely no way to
know what the renderer API is doing to the OpenGL state, so this kind
of problems are pretty much expected. (note: surfaces should still be
safe, it’s textures the problematic ones)
Instead of using SDL_CreateTextureFromSurface it’s probably much
better to retrieve the data from the surface directly and upload that
to the texture using OpenGL calls.
Instead of using SDL_CreateTextureFromSurface it’s probably much
better to retrieve the data from the surface directly and upload that
to the texture using OpenGL calls.
Hmm, yeah. This is what I’m going to end up doing because I’d prefer to avoid any more obscure rendering problems in the future. The simple work around seems to initialize all of your OpenGL texture data before calling SDL_CreateTextureFromSurface, but if that isn’t strictly adhered to then there’s crashes and problems. I’m not a fan of that method so if I can convert a SDL_Surface to something compatible with OpenGL, then that works for me.
I don?t understand very well what goes on with mixing OpenGL and SDL2 rendering subsystems, but at any rate, I?ve had some limited experience in doing so with integrating libRocket into my engine via SDL2. It appears to work well in the case of rendering a GUI. I write this in the hopes that the implementation will help shed some light on things or help you better understand things:
My implementation of integrating libRocket with SDL2, derives from [1]. In addition to the original source for OpenGL + SDL2 [1], I’ve added the necessary plumbing for supporting SDL2’s logical viewport.
Interestingly, the suggestion of retrieving the data from the surface directly and uploading the texture using OpenGL calls instead is precisely what this implementation is doing. The two low-level SDL2 GL functions SDL_GL_BindTexture and SDL_GL_UnbindTexture can help with this, among others. Check out the wiki documentation for additional information regarding these two.
