The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

bumping a waaay old discussion just to point out that it is absolutely
possible to do!!
Instead of using the renderer system it is sufficient to create
explicitly the gl context: for anybody interested you can take a look
how i did so here
http://code.google.com/p/hedgewars/source/detail?r=a55aab5929507c3a36d0fd4d481487851adeee49

Vittorio

On Wed, Apr 6, 2011 at 7:01 PM, Sam Lantinga wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I had some problems in context switching with creating explicitly a new gl context.

Someone can tell me if i correctly use the API please (i posted a demo program at http://forums.libsdl.org/viewtopic.php?t=7327&sid=367dc50cc939d7a11f4144620e981a79) ?

Regards.

Paul.

On 08/23/2011 10:48 AM, Vittorio G. wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Renderers and direct OpenGL use don't mix; use one or the other.

--ryan.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Tue, Aug 23, 2011 at 11:18 PM, Ryan C. Gordon wrote:


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,

-Justin
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Wed, Aug 24, 2011 at 10:58 AM, Justin Coleman wrote:


Can't renderers have any backend (e.g. DirectX?)

On Wed, Aug 24, 2011 at 12:01 PM, Patrick Baggett
wrote:

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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 08/24/2011 05:18 AM, 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 strange, but my demo program works now.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.


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:

http://lists.libsdl.org/htdig.cgi/sdl-libsdl.org/2011-July/081493.html

(that second SDL_GL_CONTEXT_MAJOR_VERSION should have been MINOR ...
typos...)

--ryan.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.

--ryan.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Wed, Aug 24, 2011 at 4:28 PM, Ryan C. Gordon wrote:

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.

-Justin
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.

--ryan.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

if you need rotation, scissoring, clip planes, render-to-texture, advanced techniques, or 3D graphics; SDL's rendering system is not for you.

Thank you for all these details.

Paul.

On 08/24/2011 10:39 PM, Ryan C. Gordon wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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: MBrening
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


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 08/31/2011 05:36 PM, MBrening wrote:

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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

There are only two reasons I can think that this would be useful.

1) mixing 2D with 3D. However, I'd think this should be done very carefully if at all.
2) 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.

Still, it's a cool idea :-)

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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:>

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:


--
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

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hello !



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

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org