Is sdl1.3+opengl still a viable practice?

Agreed: I needed rotations myself, so I cannibalised the gles renderer to
write my own. It’s not too hard and only needs to be done once.On 1 Sep 2011 15:25, “Ryan C. Gordon” wrote:

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.

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

In my opinion, what would help most is a working example of OpenGL 2D rendering with all the bells and whistles, in an SDL-oriented way (like using SDL_image loaders, etc).

Then you can just direct anyone who asks for a feature above and beyond the SDL renderers to look at that code.On 08/31/2011 10:24 PM, Ryan C. Gordon wrote:

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.

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

Hello !

In my opinion, what would help most is a working example of OpenGL 2D rendering with all the bells and whistles, in an SDL-oriented way (like using SDL_image loaders, etc).

Then you can just direct anyone who asks for a feature above and beyond the SDL renderers to look at that code.

100%

It would be great to have such master examples,
that will run on any OS that runs SDL and OpenGL.

Maybe also a port of them running on SDL on Windows with DirectX.

They should definitely get a section on the SDL website.

CU