Ryan, I’ve seen enough people ask if the two can be used together
that I wonder if it’s worth making it explicitly supported. I have a
very simple demo program showing how it can be done, but it’s a bit
clumsy at the moment because of some basic assumptions:
-
You should create the window, the GL context, and the renderer, in
that order.
-
You should find the opengl render driver yourself if possible and
create your renderer using it. (I have no idea if that’s actually
necessary if your window is created as an OpenGL window?)
-
SDL’s render state should be treated as “magic”. That means you
should preserve its ortho matrix, and probably its blendfunc as well.
It’s easy enough to recreate other matrices (basically identity) and
set the color to a known state like ? opaque white.
-
Depth test (and anything else of the sort) needs to be disabled
prior to calling SDL’s render functions.
-
SDL_RenderPresent instead of SDL_GL_SwapBuffers.
Those assumptions work. It could work a little better if I
disregarded them, though. Creating my own ortho matrix gives me the
ability to use a resizable window that works as expected. Letting
SDL find the opengl render driver works too. And I restore the color
and blend mode SDL expects (in fact I can usually just use SDL’s
blend mode since I’d call the same functions the same way 99% of the
time anyway!) But ? it might not be future-proof.
If we want to officially support mixing the two in some fashion, I
see two ways to do it. Either we need to expressly state SDL’s
expectations, expose GL_ResetState, or a bit of both. Exposing the
reset function will cause some unnecessary state thrashing, but
really if one wants speed, one should move their 2D SDL code to use
GL natively.
Bonus: Exposing the reset function gives you all of the OpenGL
targets basically for free. I don’t know enough D3D to know if
D3D_Reset does quite the same thing, but I know it must be a “cheap”
function given how many times the D3D renderer has to call it. 
(BTW, is there any good reason why the OpenGL renderers all take byte
input and then call glColor4f? glColor4ub is pretty standard as an
accelerated path, in my understanding even on OpenGL ES v1?)
JosephOn Wed, Oct 30, 2013 at 03:49:13PM -0400, Ryan C. Gordon wrote:
I have changed my window creation to use SDL_CreateWindowAndRenderer
using just the SDL_WINDOW_OPENGL flag (I don’t need fullscreen) to get a
window and renderer.
You want SDL_CreateWindow() and not any of the Renderer stuff (that’s
a simple 2D drawing API that is using OpenGL behind the scenes, which
you don’t need if you’re using OpenGL directly.
I don’t get a GL context, I just use GL calls to draw, then call
SDL_RenderPresent. That seems to work.
This is sort of working by accident for you, because the rendering
API is also using OpenGL. Here’s what you should do to create a
800x600 window:
SDL_Init(SDL_INIT_VIDEO); // make sure that didn’t fail.
SDL_Window *window = SDL_CreateWindow(“My Game’s Name”,
SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 800, 600,
SDL_WINDOW_OPENGL);
// make sure that’s not NULL.
SDL_GLContext glctx = SDL_GL_CreateContext(window);
// make sure that’s not NULL.
SDL_GL_MakeCurrent(window, glctx);
// now it is safe to call GL functions.
// draw some stuff, and when you want to put it to the screen…
SDL_GL_SwapWindow(window);
// and repeat.
–ryan.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
