Hi all,
after a sdl update the rendering of my game is again broken (yay); my
game was built using the “common practice” of initializing opengl with
sdl, convert surfaces to textures and then use opengl drawing calls. I
tried to keep this functionality aligned with the development of sdl
1.3 but i’m starting to believe that it is going to be a wasted
effort.
As you might recall, some changes at the viewport level broke the
engine of the game but i was able to reset the viewport with the
classic glMatrixMode(GL_PROJECTION) and glLoadIdentity(), however with
the latest changes to rotation on iOS, every time a rotation event is
detected, the video mode is changed, and the viewport changes as well,
breaking the drawing of my code.
The same applies for other window events (like MAXIMED and RESTORED)
and I’m losing track on where (and mostly how) i should reset the
rendering context of my game.
So this brings to my question: is using SDL-1.3 for setting up the gl
context and then using raw opengl calls for drawing still a viable
practice? I’m starting to believe that a complete port to SDL-1.3 apis
only would easen development a lot, expecially while the new sdl
version is not yet stable.
What does everybody think? Any suggestions besides porting the drawing
code to 1.3?
Best,
Vittorio
Yes, you should be able to use OpenGL with SDL 1.3 with no problems. It
should only get tricky if you mix the render API calls with OpenGL calls.
I’m CC’ing Ryan, so he can comment on the iOS rotation issue, but in general
we’ve tried to structure it so you don’t need to rebuild the OpenGL context
at any point. If you are running into this, it should be reported as a bug.
Thanks!On Wed, Apr 6, 2011 at 12:59 AM, Vittorio G. <vitto.giova at yahoo.it> wrote:
Hi all,
after a sdl update the rendering of my game is again broken (yay); my
game was built using the “common practice” of initializing opengl with
sdl, convert surfaces to textures and then use opengl drawing calls. I
tried to keep this functionality aligned with the development of sdl
1.3 but i’m starting to believe that it is going to be a wasted
effort.
As you might recall, some changes at the viewport level broke the
engine of the game but i was able to reset the viewport with the
classic glMatrixMode(GL_PROJECTION) and glLoadIdentity(), however with
the latest changes to rotation on iOS, every time a rotation event is
detected, the video mode is changed, and the viewport changes as well,
breaking the drawing of my code.
The same applies for other window events (like MAXIMED and RESTORED)
and I’m losing track on where (and mostly how) i should reset the
rendering context of my game.
So this brings to my question: is using SDL-1.3 for setting up the gl
context and then using raw opengl calls for drawing still a viable
practice? I’m starting to believe that a complete port to SDL-1.3 apis
only would easen development a lot, expecially while the new sdl
version is not yet stable.
What does everybody think? Any suggestions besides porting the drawing
code to 1.3?
Best,
Vittorio
VittorioOn Wed, Apr 6, 2011 at 7:01 PM, Sam Lantinga wrote:
Yes, you should be able to use OpenGL with SDL 1.3 with no problems.? It
should only get tricky if you mix the render API calls with OpenGL calls.
I’m CC’ing Ryan, so he can comment on the iOS rotation issue, but in general
we’ve tried to structure it so you don’t need to rebuild the OpenGL context
at any point.? If you are running into this, it should be reported as a bug.
Thanks!
On Wed, Apr 6, 2011 at 12:59 AM, Vittorio G. <vitto.giova at yahoo.it> wrote:
Hi all,
after a sdl update the rendering of my game is again broken (yay); my
game was built using the “common practice” of initializing opengl with
sdl, convert surfaces to textures and then use opengl drawing calls. I
tried to keep this functionality aligned with the development of sdl
1.3 but i’m starting to believe that it is going to be a wasted
effort.
As you might recall, some changes at the viewport level broke the
engine of the game but i was able to reset the viewport with the
classic glMatrixMode(GL_PROJECTION) and glLoadIdentity(), however with
the latest changes to rotation on iOS, every time a rotation event is
detected, the video mode is changed, and the viewport changes as well,
breaking the drawing of my code.
The same applies for other window events (like MAXIMED and RESTORED)
and I’m losing track on where (and mostly how) i should reset the
rendering context of my game.
So this brings to my question: is using SDL-1.3 for setting up the gl
context and then using raw opengl calls for drawing still a viable
practice? I’m starting to believe that a complete port to SDL-1.3 apis
only would easen development a lot, expecially while the new sdl
version is not yet stable.
What does everybody think? Any suggestions besides porting the drawing
code to 1.3?
Best,
Vittorio
On Wed, Apr 6, 2011 at 7:01 PM, Sam Lantinga wrote:
Yes, you should be able to use OpenGL with SDL 1.3 with no problems. It
should only get tricky if you mix the render API calls with OpenGL calls.
I’m CC’ing Ryan, so he can comment on the iOS rotation issue, but in general
we’ve tried to structure it so you don’t need to rebuild the OpenGL context
at any point. If you are running into this, it should be reported as a bug.
Thanks!
On Wed, Apr 6, 2011 at 12:59 AM, Vittorio G.<vitto.giova at yahoo.it> wrote:
Hi all,
after a sdl update the rendering of my game is again broken (yay); my
game was built using the “common practice” of initializing opengl with
sdl, convert surfaces to textures and then use opengl drawing calls. I
tried to keep this functionality aligned with the development of sdl
1.3 but i’m starting to believe that it is going to be a wasted
effort.
As you might recall, some changes at the viewport level broke the
engine of the game but i was able to reset the viewport with the
classic glMatrixMode(GL_PROJECTION) and glLoadIdentity(), however with
the latest changes to rotation on iOS, every time a rotation event is
detected, the video mode is changed, and the viewport changes as well,
breaking the drawing of my code.
The same applies for other window events (like MAXIMED and RESTORED)
and I’m losing track on where (and mostly how) i should reset the
rendering context of my game.
So this brings to my question: is using SDL-1.3 for setting up the gl
context and then using raw opengl calls for drawing still a viable
practice? I’m starting to believe that a complete port to SDL-1.3 apis
only would easen development a lot, expecially while the new sdl
version is not yet stable.
What does everybody think? Any suggestions besides porting the drawing
code to 1.3?
Best,
Vittorio
Renderers and direct OpenGL use don’t mix; use one or the other.
Might we ask why this is? Is there some sort of internal state that
gets stepped on? I ask because I tried to get 1.3’s OpenGL renderer to
work with CEGUI last year and couldn’t figure out what SDL was doing
that would make it not work.
Alternatively, is there a barebones demo somewhere that shows how to
get 1.3 (for window management, input handling, image conversion, etc)
running with a pure OpenGL window? Can that be done?
Thanks,
-JustinOn Tue, Aug 23, 2011 at 11:18 PM, Ryan C. Gordon wrote:
Renderers and direct OpenGL use don’t mix; use one or the other.
Might we ask why this is? Is there some sort of internal state that
gets stepped on? I ask because I tried to get 1.3’s OpenGL renderer to
work with CEGUI last year and couldn’t figure out what SDL was doing
that would make it not work.
Can’t renderers have any backend (e.g. DirectX?)On Wed, Aug 24, 2011 at 10:58 AM, Justin Coleman wrote:
On Tue, Aug 23, 2011 at 11:18 PM, Ryan C. Gordon wrote:
Renderers and direct OpenGL use don’t mix; use one or the other.
Might we ask why this is? Is there some sort of internal state that
gets stepped on? I ask because I tried to get 1.3’s OpenGL renderer to
work with CEGUI last year and couldn’t figure out what SDL was doing
that would make it not work.
Can’t renderers have any backend (e.g. DirectX?)
Specifically, I want to use OpenGL for the graphics on this project,
for several reasons. Among them is that it’s not limited to Windows.
So, whatever the eventual solution, I’ll need an OGL context and
window to render to.
If I can do that and get SDL’s input/event handling and window
management (resolution, depth, etc) by using another Renderer, that
would probably be just fine.On Wed, Aug 24, 2011 at 12:01 PM, Patrick Baggett <baggett.patrick at gmail.com> wrote:
On Wed, Aug 24, 2011 at 10:58 AM, Justin Coleman <@Justin_Coleman> wrote:
On Tue, Aug 23, 2011 at 11:18 PM, Ryan C. Gordon wrote:
Renderers and direct OpenGL use don’t mix; use one or the other.
Might we ask why this is? Is there some sort of internal state that
gets stepped on? I ask because I tried to get 1.3’s OpenGL renderer to
Yes. If you’re using OpenGL, you’re setting OpenGL state, and so is SDL,
and both assume they control the whole state machine.
More importantly: you might not be using OpenGL behind the scenes of an
SDL renderer. It might just as easily be Direct3D.
Alternatively, is there a barebones demo somewhere that shows how to
get 1.3 (for window management, input handling, image conversion, etc)
running with a pure OpenGL window? Can that be done?
That’s the preferred way to use SDL, at least as far as I’m concerned.
Here’s a simple piece of skeleton code that shows how to do it:
If I can do that and get SDL’s input/event handling and window
management (resolution, depth, etc) by using another Renderer, that
would probably be just fine.
In case this hasn’t been clear: SDL’s “renderer” is slightly higher
level than OpenGL (and might actually be a software renderer behind the
scenes, depending on the platform). It’s completely optional, and if you
want to do more than very simple 2D games, completely limiting.
If you just want to make some windows and draw into them with OpenGL,
that’s the normal thing SDL is used for. It’ll still supply you with
input events and such, and get out of your way so you can draw whatever
you want with OpenGL.
Awesome, that’s just what I was looking for. I guess I overlooked it
because of the mention of Android. For some reason I thought the only
way to have SDL 1.3 control the window was by using a renderer; I’m
glad to see that’s not the case.
-JustinOn Wed, Aug 24, 2011 at 4:28 PM, Ryan C. Gordon wrote:
Renderers and direct OpenGL use don’t mix; use one or the other.
Might we ask why this is? Is there some sort of internal state that
gets stepped on? I ask because I tried to get 1.3’s OpenGL renderer to
Yes. If you’re using OpenGL, you’re setting OpenGL state, and so is SDL, and
both assume they control the whole state machine.
More importantly: you might not be using OpenGL behind the scenes of an SDL
renderer. It might just as easily be Direct3D.
Alternatively, is there a barebones demo somewhere that shows how to
get 1.3 (for window management, input handling, image conversion, etc)
running with a pure OpenGL window? Can that be done?
That’s the preferred way to use SDL, at least as far as I’m concerned.
Here’s a simple piece of skeleton code that shows how to do it:
So, what is the function SDL_GL_CreateContext if we can’t mix opengl
direct rendering and sdl renderers ?
It’s for direct renderering. You don’t create a GL context for the
rendering API (even if it creates one behind the scenes). To add to the
confusion, windowing systems let you have more than one GL context for a
given window, so SDL doesn’t prevent you from calling CreateContext, but
you won’t get the results you expect, even if it seems to work at the
moment.
By means of a bad analogy: if SDL were a networking library, and you
asked me why you couldn’t send Netware packets over a TCP socket, I’d
have to shrug my shoulders and say: they can accomplish the same goals
(sending data over a network), but you can’t interchange them.
SDL’s higher-level renderer API and it’s API for managing an OpenGL
context accomplish the same goals (drawing things to the screen), but
you can’t interchange them.
if you need rotation, scissoring, clip planes, render-to-texture, advanced techniques, or 3D graphics; SDL’s rendering system is not for you.------------------------
EM3 Nathaniel Fries, U.S. Navy
Paul.On 08/24/2011 10:39 PM, Ryan C. Gordon wrote:
So, what is the function SDL_GL_CreateContext if we can’t mix opengl
direct rendering and sdl renderers ?
It’s for direct renderering. You don’t create a GL context for the rendering API (even if it creates one behind the scenes). To add to the confusion, windowing systems let you have more than one GL context for a given window, so SDL doesn’t prevent you from calling CreateContext, but you won’t get the results you expect, even if it seems to work at the moment.
By means of a bad analogy: if SDL were a networking library, and you asked me why you couldn’t send Netware packets over a TCP socket, I’d have to shrug my shoulders and say: they can accomplish the same goals (sending data over a network), but you can’t interchange them.
SDL’s higher-level renderer API and it’s API for managing an OpenGL context accomplish the same goals (drawing things to the screen), but you can’t interchange them.
While I understand the necessity with not mixing using the managed renderers and direct OpenGL, I have to say it would be interesting to have a way to support it.
I see it as the managed renderer is like programming in C and then doing direct OpenGL is like dropping down to assembly. Generally it is bad practice because there are all sorts of register tracking and handling going on that the assembly code may screw up the whole program just by using the wrong register.
However, if it there was support for something like:
SDL_OpenGL_BeginDirect();
glBegin(GL_LINES)
…
glEnd()
SDL_OpenGL_EndDirect();
But that would require ensuring the rendering backend is OpenGL and not DirectX or Software.
I’m not sure I see a real viable use for this, I can see it being a hobby project to see what it takes to implement it if anyone should get bored
Agreed.? SDL is a high-level interface that greatly simplifies most of what you need to do, but there are some exceptional cases where you need the raw GL API to get stuff done.? Saying “in that case, you have to scrap the renderers entirely” is kind of ridiculous.? A BeginDirect/EndDirect API would be very useful to ensure that the renderer state remains consistent and doesn’t stomp the underlying low-level API.________________________________
From: micah.brening@gmail.com (Micah Brening)
Subject: Re: [SDL] is sdl1.3+opengl still a viable practice?
While I understand the necessity with not mixing using the managed renderers and direct OpenGL, I have to say it would be interesting to have a way to support it.
I see it as the managed renderer is like programming in C and then doing direct OpenGL is like dropping down to assembly. Generally it is bad practice because there are all sorts of register tracking and handling going on that the assembly code may screw up the whole program just by using the wrong register.
However, if it there was support for something like:
SDL_OpenGL_BeginDirect();
glBegin(GL_LINES)
…
glEnd()
SDL_OpenGL_EndDirect();
But that would require ensuring the rendering backend is OpenGL and not DirectX or Software.
I’m not sure I see a real viable use for this, I can see it being a hobby project to see what it takes to implement it if anyone should get bored
I would suggest to write a simple program that represent a typical use case. Perhaps on a wiki page ?
Also, I’m interested in giving an hand.
Regards.
Paul.On 08/31/2011 05:36 PM, MBrening wrote:
While I understand the necessity with not mixing using the managed renderers and direct OpenGL, I have to say it would be interesting to have a way to support it.
[…]
However, if it there was support for something like:
SDL_OpenGL_BeginDirect();
glBegin(GL_LINES)
…
glEnd()
SDL_OpenGL_EndDirect();
But that would require ensuring the rendering backend is OpenGL and not DirectX or Software.
I’m not sure I see a real viable use for this, I can see it being a hobby project to see what it takes to implement it if anyone should get bored
There are only two reasons I can think that this would be useful.
mixing 2D with 3D. However, I’d think this should be done very carefully if at all.
the same reason someone would drop down to assembly, “complete” control. It’s possible in some instances that the use of call lists could give a performance boost. Or maybe the use of shaders would help.
In the second reason, I’d think this would be more targeted to mainstream games/application rather than hobby games. And if it’s pretty much mainstream, you’d think they’d be directly using OpenGL or DirectX rather than an abstract renderer that sits on top of it.
I see it as the managed renderer is like programming in C and then doing
direct OpenGL is like dropping down to assembly.
There’s a reason that some compilers are removing support for this, too.
Even assuming the renderer is using OpenGL on the backend (and using a
compatible version of OpenGL…your glBegin() example fails on the GL3
core profile), you can’t reasonably protect two independent pieces of
code from stepping on each other’s GL state, especially as the app may
have knowledge of GL extensions that don’t even exist today.
Anyone that’s ever done any significant OpenGL (or Direct3D) work has
run into a situation where they wrote some code, tweaked a different
part of the renderer, and saw it break a totally unrelated piece of
rendering code because of a state change they didn’t expect (or know to
worry about). And that’s when they own all the code.
This isn’t like locking a surface, poking around in it, and unlocking it
again. OpenGL is a massive state machine, with a million corner cases
and gotchas.
If you’re doing almost anything fancy (“fancy” like GL_LINES, even!),
you’re going to not want to use the renderer API. If you have any need
of OpenGL at all, you’re not going to want to use the renderer API.
