I am interesting in using CEGUI as a gui toolkit for all of my
application. This library relies on OpenGL. I would like to know if it
is possible to use an OpenGL programming at the same time as glSDL.
glSDL relies on OpenGL, CEGUI too and so it should be possible to make
them work at the same time. In a more generic context might it be
possible to use glSDL and OpenGL at the same time in an application.
It’s possible, but not officially supported, mainly for two reasons,
the second one being the more important one:
1. Adding the requirement of nice cooperation with other
OpenGL code impacts the optimization possibilities of
the glSDL backend, and may require SDL API extensions.
Whatever glSDL does, it would have to consider the side
effects on any other, unknown code, that shares the
OpenGL context.
2. glSDL is an SDL backend that brings hardware acceleration
to the SDL *2D* API on a wide range of platforms. It is
not intended to be used by applications that will not
run at all without OpenGL, as these are better off using
OpenGL directly anyway.
That is, if you want to use CEGUI, you’ll need OpenGL anyway. So, why
not just use OpenGL directly for your own rendering as well? It’s a
more powerful API, and you could probably gain some performance over
glSDL.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Friday 26 August 2005 13.30, Olivier Delannoy wrote:
I am interesting in using CEGUI as a gui toolkit for all of my
application. This library relies on OpenGL. I would like to know if
it is possible to use an OpenGL programming at the same time as
glSDL. glSDL relies on OpenGL, CEGUI too and so it should be
possible to make them work at the same time. In a more generic
context might it be possible to use glSDL and OpenGL at the same
time in an application.
I am interesting in using CEGUI as a gui toolkit for all of my
application. This library relies on OpenGL. I would like to know if
it is possible to use an OpenGL programming at the same time as
glSDL. glSDL relies on OpenGL, CEGUI too and so it should be
possible to make them work at the same time. In a more generic
context might it be possible to use glSDL and OpenGL at the same
time in an application.It’s possible, but not officially supported, mainly for two reasons,
the second one being the more important one:1. Adding the requirement of nice cooperation with other OpenGL code impacts the optimization possibilities of the glSDL backend, and may require SDL API extensions. Whatever glSDL does, it would have to consider the side effects on any other, unknown code, that shares the OpenGL context. 2. glSDL is an SDL backend that brings hardware acceleration to the SDL *2D* API on a wide range of platforms. It is not intended to be used by applications that will not run at all without OpenGL, as these are better off using OpenGL directly anyway.That is, if you want to use CEGUI, you’ll need OpenGL anyway. So, why
not just use OpenGL directly for your own rendering as well? It’s a
more powerful API, and you could probably gain some performance over
glSDL.
The aim is to use only one Gui toolkit for both 2d and 3d application.On 8/26/05, David Olofson wrote:
On Friday 26 August 2005 13.30, Olivier Delannoy wrote:
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
That is, if you want to use CEGUI, you’ll need OpenGL anyway. So, why
not just use OpenGL directly for your own rendering as well? It’s a
more powerful API, and you could probably gain some performance over
glSDL.The aim is to use only one Gui toolkit for both 2d and 3d application.
What David is saying is use SDL to get the rendering context (needed for
OGL) and then just use CEGUI to do the gui. Don’t let OpenGL’s
powerfull 3D side fool you, it can handle 2D just as well.
HTH,
Richard
Okay I will do that and forget all the knowledges of SDL 2D programming 
Let’s open a book on OpenGL.On 8/27/05, Richard The PC Doc Hancock wrote:
That is, if you want to use CEGUI, you’ll need OpenGL anyway. So, why
not just use OpenGL directly for your own rendering as well? It’s a
more powerful API, and you could probably gain some performance over
glSDL.The aim is to use only one Gui toolkit for both 2d and 3d application.
What David is saying is use SDL to get the rendering context (needed for
OGL) and then just use CEGUI to do the gui. Don’t let OpenGL’s
powerfull 3D side fool you, it can handle 2D just as well.HTH,
Richard
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Olivier Delannoy wrote:>On 8/27/05, Richard The PC Doc Hancock <@Richard_J_Hancock> wrote:
That is, if you want to use CEGUI, you’ll need OpenGL anyway. So, why
not just use OpenGL directly for your own rendering as well? It’s a
more powerful API, and you could probably gain some performance over
glSDL.The aim is to use only one Gui toolkit for both 2d and 3d application.
What David is saying is use SDL to get the rendering context (needed for
OGL) and then just use CEGUI to do the gui. Don’t let OpenGL’s
powerfull 3D side fool you, it can handle 2D just as well.HTH,
Richard
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdlOkay I will do that and forget all the knowledges of SDL 2D programming
Let’s open a book on OpenGL.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Don’t forget the 2D Aspect of SDL. I have found that I haved relied
upon it for 2D applications and fast prototyping. I just switch to OGL
when I need to handle 3D.
Richard
[…]
Don’t forget the 2D Aspect of SDL. I have found that I haved relied
upon it for 2D applications and fast prototyping. I just switch to
OGL when I need to handle 3D.
The problem is that with the resolutions and frame rates people expect
these days, you need hardware acceleration for many applications.
Unfortunately, most platforms lack accelerated 2D APIs supported by
the SDL 2D API, or altogether.
So, supporting only the SDL 2D API means your high bandwidth
application will only run well on the (very few) platforms that
provide decent 2D acceleration. If the application is scalable enough
(supports low resolutions, simplified effects etc), this may be
acceptable - but if you’re doing a 1024x768-only full screen scroller
with loads of translucent sprites, it will probably not be playable
at all on most systems, regardless of video hardware.
OTOH, supporting only OpenGL means your application won’t run at all
on platforms without OpenGL. However, if this is that 1024x768 side
scroller, that’s probably just as well, because if there’s no OpenGL,
there probably isn’t enough oomph in the box anyway.
Of course, the best option, if you can afford it, in terms of
development cost and/or time is to support both SDL 2D and OpenGL
natively. The SDL 2D backend (with appropriate scalability options)
will make it run pretty much anywhere, and the OpenGL backend will
add insane frame rates and practically unlimited special effect
capabilities.
Or you go the easy way; code for SDL 2D and use glSDL for extra speed
where OpenGL is available. That’s what it’s for.
And, to close the circle; this is why you should not use glSDL and
native OpenGL at the same time: Using (as in, “relying on”) OpenGL
directly basically eliminates the whole point of using glSDL instead
of the much more powerful OpenGL API.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 29 August 2005 21.12, Richard “The PC Doc” Hancock wrote:
[…]
Okay I will do that and forget all the knowledges of SDL 2D
programming
Let’s open a book on OpenGL.
Fine, if you’ll be needing the power of OpenGL anyway, the best way is
to use it directly, or via wrappers/helpers designed specifically for
the job.
However, do you really need OpenGL for all of your applications?
I see why you want to use one single GUI toolkit for all applications
- but you do realize that the side effect of this is that your games
will not run at all, or will “run” at slide show frame rates on
machines without accelerated OpenGL…?
Another option is to chose a different GUI toolkit, or to add support
for the SDL 2D API to the one you’re using.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 29 August 2005 19.00, Olivier Delannoy wrote:
However, do you really need OpenGL for all of your applications?
I see why you want to use one single GUI toolkit for all applications
- but you do realize that the side effect of this is that your games
will not run at all, or will “run” at slide show frame rates on
machines without accelerated OpenGL…?
Good point, although most systems now a days have enough power to handle
a basic OGL program in software mode. However I will agree with using
the right tool for the right job.
Another option is to chose a different GUI toolkit, or to add support
for the SDL 2D API to the one you’re using.
In other words, if the program is prodominatly 2D, stick with SDL and a
gui that uses it. Or, if your program is mainly 3D, go with OGL and use
a system similar to what is made over at Ionware Productions.
Richard
However, do you really need OpenGL for all of your applications?
I see why you want to use one single GUI toolkit for all applications
- but you do realize that the side effect of this is that your games
will not run at all, or will “run” at slide show frame rates on
machines without accelerated OpenGL…?Good point, although most systems now a days have enough power to handle
a basic OGL program in software mode. However I will agree with using
the right tool for the right job.
Another option is to chose a different GUI toolkit, or to add support
for the SDL 2D API to the one you’re using.
In other words, if the program is prodominatly 2D, stick with SDL and a
gui that uses it. Or, if your program is mainly 3D, go with OGL and use
a system similar to what is made over at Ionware Productions.Richard
On 8/30/05, Richard The PC Doc Hancock wrote:
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
I am interested in portability but in a limited portability I do not plan to
support all system available throught ATI. It’s not a commercial product,
it’s not a serious project it’s only something we try to make well and that
is a source of knowledge for me. I am writing something like a configurable
game engine. The user load modules providing functionnalities depending on
it’s needs. If the user need OpenGL support it load SDLOpenGL module, if he
is interested in the Ogre. If the user want a GUI Toolkit he will used CEGUI
or write it’s own module. I am currently the main user of this system and I
am not interested in learning multiple GUI or in multiplying modules. Using
glSDL implies OpenGL and it’s a requirement that did not bother me at all.
That’s why I am really interested in trying to link glSDL to CEGUI. (CEGUI
mainly consists in drawing quads in front of the camera. (just like glSDL).
My first idea was to load and use glSDL and to add the drawing of cegui
right after glSDL. I am not sure if it’s the good way to do thing. And this
discussion should have been a technical discussion on how to integrates both
of this tool together.
I know that it was not a perfect solution at all and that I should use a 2D
gui toolkit instead in order to keep SDL 2d and OpenGL in two different
context. But I am not sure that it’s better to not provide 2D support
because it should be done another way. In fact I think it’s also an
interesting experiments.
I am currently the main user of this system and I am not interested
in learning multiple GUI or in multiplying modules.
That’s a good reason for using glSDL - you need only the SDL 2D API.
Using glSDL implies OpenGL and it’s a requirement that did not
bother me at all.
Actually, glSDL just allows you to use OpenGL - CEGUI would be what
adds the OpenGL requirement.
If you don’t activate glSDL, SDL just uses the default 2D backend
instead. (Or, in the case of the old wrapper; glSDL passes the
affected calls through to SDL instead of “redirecting” them to
OpenGL.)
That’s why I am really interested in trying to link glSDL to CEGUI.
I see. Well, it should work with current versions of glSDL, but you
have been warned; mixing glSDL and OpenGL is not officially
supported. There is a risk of future versions of glSDL breaking your
code if you do this.
[…]
My first idea was to load and use glSDL and to add the drawing of
cegui right after glSDL. I am not sure if it’s the good way to do
thing.
Well, as it is, glSDL basically just translates every SDL blit into an
OpenGL “blit”, instantly, one by one. As long as you do the SDL and
OpenGL calls in the right order, they should also be rendered in that
order. (In current versions of glSDL, that is. Been thinking about
buffering and doing batch rendering in some way, but I’m not sure
it’s worth the effort.)
Use SDL_Flip() instead of SDL_GL_SwapBuffers()! (I think
SDL_GL_SwapBuffers() would work with current versions of glSDL, but
don’t be surprized if it doesn’t.)
Finally, keep in mind that glSDL assumes that it’s not sharing OpenGL
with anyone, so it will set up matrices and stuff the way it wants
them and then assumes they’ll stay that way. If you need to change
certain things, you need to restore them before making further glSDL
calls. Read the glSDL source for details.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Thursday 01 September 2005 09.20, Olivier Delannoy wrote:
I am currently the main user of this system and I am not interested
in learning multiple GUI or in multiplying modules.That’s a good reason for using glSDL - you need only the SDL 2D API.
Using glSDL implies OpenGL and it’s a requirement that did not
bother me at all.Actually, glSDL just allows you to use OpenGL - CEGUI would be what
adds the OpenGL requirement.If you don’t activate glSDL, SDL just uses the default 2D backend
instead. (Or, in the case of the old wrapper; glSDL passes the
affected calls through to SDL instead of “redirecting” them to
OpenGL.)That’s why I am really interested in trying to link glSDL to CEGUI.
I see. Well, it should work with current versions of glSDL, but you
have been warned; mixing glSDL and OpenGL is not officially
supported. There is a risk of future versions of glSDL breaking your
code if you do this.[…]
My first idea was to load and use glSDL and to add the drawing of
cegui right after glSDL. I am not sure if it’s the good way to do
thing.Well, as it is, glSDL basically just translates every SDL blit into an
OpenGL “blit”, instantly, one by one. As long as you do the SDL and
OpenGL calls in the right order, they should also be rendered in that
order. (In current versions of glSDL, that is. Been thinking about
buffering and doing batch rendering in some way, but I’m not sure
it’s worth the effort.)Use SDL_Flip() instead of SDL_GL_SwapBuffers()! (I think
SDL_GL_SwapBuffers() would work with current versions of glSDL, but
don’t be surprized if it doesn’t.)Finally, keep in mind that glSDL assumes that it’s not sharing OpenGL
with anyone, so it will set up matrices and stuff the way it wants
them and then assumes they’ll stay that way. If you need to change
certain things, you need to restore them before making further glSDL
calls. Read the glSDL source for details.//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Thanks I will try and give some feedback here.On 9/1/05, David Olofson wrote:
On Thursday 01 September 2005 09.20, Olivier Delannoy wrote: