I’ve been thinking about ways of hopefully getting OpenGL and SDL to
play nice…Unfortunately I’m new to OpenGL, so I am unsure of the best
way to do this. From what I have read it seems that I should be able to
make OpenGL render to a framebuffer and then use SDL to copy this buffer
to the screen. (Using double buffering once this is implemented). Does
this sound like the right way to do things?
emblem
Um…could you please explain what double buffering is? I know nothing of
it.
Paul Lowe
xpaull at ultraviolet.org
emblem wrote:> I’ve been thinking about ways of hopefully getting OpenGL and SDL to
play nice…Unfortunately I’m new to OpenGL, so I am unsure of the best
way to do this. From what I have read it seems that I should be able to
make OpenGL render to a framebuffer and then use SDL to copy this buffer
to the screen. (Using double buffering once this is implemented). Does
this sound like the right way to do things?emblem
I’ve been thinking about ways of hopefully getting OpenGL and SDL to
play nice…Unfortunately I’m new to OpenGL, so I am unsure of the best
way to do this. From what I have read it seems that I should be able to
make OpenGL render to a framebuffer and then use SDL to copy this buffer
to the screen. (Using double buffering once this is implemented). Does
this sound like the right way to do things?
I sounds good from what little I know about OpenGL. Anyone know exactly
how to feed a framebuffer to OpenGL? Do you have to create a “GL context”?
If so, how?
I am in the middle of implementing double-buffering, along with a better
way of using hardware acceleration in general. It’s currently broken, but
for a sneak preview, check out the code in CVS (for instructions, see the
download page.)
Um…could you please explain what double buffering is? I know nothing of
it.
Double buffering is where you allocate two framebuffers in video memory,
and write to the one that is not being displayed, and then “flip” betwen
them, as each one is displayed in turn. This is generally used to prevent
"tearing" artifacts which are caused by the monitor refresh displaying the
framebuffer while you are in the middle of modifying it.
Does anyone have a simpler explanation? What that clear?
I sounds good from what little I know about OpenGL. Anyone know exactly
how to feed a framebuffer to OpenGL? Do you have to create a “GL context”?
If so, how?
I am a beginner with OpenGL, but here is what I know:
OpenGL is platform independent, so there are things like the current front
and back framebuffer or auxiliary framebuffers, but it is not defined
where they come from.
Initialization is done by platform dependent functions (prefix wgl on
Windows, glX on X) and those initialization functions need a device
context (usually taken from a window).
BTW, 3dfx glide also takes a window handle in its init function, it can be
NULL for fullscreen, but it is definitely needed for Voodoo Rush.
I still believe, that providing a window handle is the best solution for
people who want to use SDL with 3D graphics.
Sam Lantinga writes:
I’ve been thinking about ways of hopefully getting OpenGL and SDL to
play nice…Unfortunately I’m new to OpenGL, so I am unsure of the best
way to do this. From what I have read it seems that I should be able to
make OpenGL render to a framebuffer and then use SDL to copy this buffer
to the screen. (Using double buffering once this is implemented). Does
this sound like the right way to do things?I sounds good from what little I know about OpenGL. Anyone know exactly
how to feed a framebuffer to OpenGL? Do you have to create a “GL context”?
If so, how?I am in the middle of implementing double-buffering, along with a better
way of using hardware acceleration in general. It’s currently broken, but
for a sneak preview, check out the code in CVS (for instructions, see the
download page.)
a small snippet of code to show how I get OpenGL to point to a window
with GTK:
Display *dpy;
XVisualInfo *vi;
GLXContext glx_context;
dpy = GDK_WINDOW_XDISPLAY( window->window );
vi = glXChooseVisual( dpy, DefaultScreen(dpy), dblBuf );
if (vi == NULL)
{
vi = glXChooseVisual( dpy, DefaultScreen(dpy), snglBuf);
if(vi == NULL)
{
FATAL("ERROR: glXChooseVisual failed.\n");
MyGLErrorExit();
}
else
DEBUGMSG(0,"Got a single-buffered display.\n");
}
else
DEBUGMSG(0, "Got a double-buffered display.\n");
if (vi->c_class != TrueColor)
DEBUGMSG(0, "Non-TrueColor visual selected\n");
DEBUGMSG(0, "Selected visual = %ld\n",vi->visualid );
glx_context = glXCreateContext( dpy, vi, None, GL_TRUE);
then in my render loop:
glXMakeCurrent( paneInfo.dpy,GDK_WINDOW_XWINDOW(paneInfo.myDrawArea->window),paneInfo.glx_context);
vector<Thing*> &reqList = GetList( WE_Render );
for( u_int i = 0; i < reqList.size(); i++ )
{
DEBUGMSG(0, "Rendering the %s\n", reqList[i]->GetID() );
reqList[i]->Render( paneNumber );
}
glXSwapBuffers(paneInfo.dpy,GDK_WINDOW_XWINDOW(paneInfo.myDrawArea->window));
jeff
Jeff wrote:
Your code used GLX, which I don’t think is multi-os.
This is how I plan to solve the problem:
Problems with this:
- Initialize SDL to use direct video memory at 16bpp.
- Create my own 32bpp framebuffer for MesaGL to render into.
- Use Hermes conversion library (Very Fast) to send 32bpp buffer to 16bpp
video memory.
The SDL 32 bpp conversion routines are as fast as Hermes. In fact, SDL
uses the assembly versions of the Hermes library routines whenever possible.
If you initialize SDL at 16 bpp, SDL may be converting from 16 bpp to
whatever the screen is really at. You’re better off initializing SDL to
32 bpp and then converting only once, inside SDL.
Problems with this:
- How do I get SDL to just give me a pointer to video memory (Assuming I
get a fullscreen mode DGA or DirectX)
Call SDL_LockSurface(screen) and then directly modify screen->pixels;
You’ll probably want to lock the surface around each block of Mesa
rendering calls.
- How do I do the OpenGL initialization to a framebuffer (I assume this is
just a matter of me reading GLX sources)
Yup.
- I’ll need some sort of WaitRetrace so that I don’t get the "tearing"
effect. (Feature Request)
I don’t plan to have WaitRetrace() exactly, since I implemented it once,
and it wasn’t as useful as I thought it would be. Instead I’ll have SDL_Flip()
which will wait for retrace and swap buffers in a double-buffering scheme.
grin
emblem writes:
Jeff wrote:
Your code used GLX, which I don’t think is multi-os.
sure it is, it will work on any system that runs X (multiple multiple
OS’s in fact). If you insist on running something on ms, as I said I
showed how I did that using GTK, but all it does it get contexts and
swap buffers, those calls are just for convenience and wouldn’t be
hard to write into SDL
j
sure it is, it will work on any system that runs X (multiple multiple
OS’s in fact). If you insist on running something on ms, as I said I
showed how I did that using GTK, but all it does it get contexts and
swap buffers, those calls are just for convenience and wouldn’t be
hard to write into SDL
Hello to all, why not making a SDL port of GTK ? If in the same time we put a
little font there could be used as error messages for the one that would likle
to have an error system ?–
Stephane Magnenat
Stephane.magnenat at urbanet.ch
Your code used GLX, which I don’t think is multi-os.
sure it is, it will work on any system that runs X (multiple multiple
OS’s in fact)
Anyone insisting on maintaining compatibility with X should
be shot and hung. MIT has declared X11R6.3 as the end of the
line. Let it die.
If you insist on running something on ms, as I said I
showed how I did that using GTK, but all it does it get contexts and
swap buffers, those calls are just for convenience and wouldn’t be
hard to write into SDL
Yeah, but what about BeOS and MacOS?
If OpenGL layer needed to be added for compatibility, it
had better be Glut, and NOT wgl, glx, or gtk.
David Sowsy writes:
Your code used GLX, which I don’t think is multi-os.
sure it is, it will work on any system that runs X (multiple multiple
OS’s in fact)Anyone insisting on maintaining compatibility with X should
be shot and hung. MIT has declared X11R6.3 as the end of the
line. Let it die.
who insisted on maintaining compatability with X ? all that i said is
that GLX IS multi-os capable
If you insist on running something on ms, as I said I
showed how I did that using GTK, but all it does it get contexts and
swap buffers, those calls are just for convenience and wouldn’t be
hard to write into SDLYeah, but what about BeOS and MacOS?
If OpenGL layer needed to be added for compatibility, it
had better be Glut, and NOT wgl, glx, or gtk.
glut will work just as well 
j
I’ve been thinking about ways of hopefully getting OpenGL and SDL to
play nice…Unfortunately I’m new to OpenGL, so I am unsure of the best
way to do this. From what I have read it seems that I should be able to
make OpenGL render to a framebuffer and then use SDL to copy this buffer
to the screen. (Using double buffering once this is implemented). Does
this sound like the right way to do things?
That might work, although you’re breaking portability by putting OpenGL
and SDL together. For example, if I use MesaGL in my code, then it will
only work on an OS to which Mesa is ported - although it may just be a
matter of changing link library names in the makefile based on platform,
since I believe that MesaGL and OpenGL are API compliant…On Sun, 11 Oct 1998, emblem wrote:
Scott M. Stone <sstone at pht.com, sstone at turbolinux.com>
Head of TurboLinux Development/Systems Administrator
Pacific HiTech, Inc (USA) / Pacific HiTech, KK (Japan)
http://www.pht.com http://armadillo.pht.co.jp
http://www.pht.co.jp http://www.turbolinux.com
sure it is, it will work on any system that runs X (multiple multiple
OS’s in fact). If you insist on running something on ms, as I said I
showed how I did that using GTK, but all it does it get contexts and
swap buffers, those calls are just for convenience and wouldn’t be
hard to write into SDLHello to all, why not making a SDL port of GTK ? If in the same time we put a
little font there could be used as error messages for the one that would likle
to have an error system ?
I’m not sure that this really flows with SDL’s design goals – this
project in and of itself, while it takes only one line to suggest, would
probably take the better part of a year to implement…On Sun, 11 Oct 1998, Stephane Magnenat wrote:
Scott M. Stone <sstone at pht.com, sstone at turbolinux.com>
Head of TurboLinux Development/Systems Administrator
Pacific HiTech, Inc (USA) / Pacific HiTech, KK (Japan)
http://www.pht.com http://armadillo.pht.co.jp
http://www.pht.co.jp http://www.turbolinux.com
Well, if you are talking about porting GTK to use the SDL library, it would be
the wrong thing for the job, unless your entire windowing system resides inside
one window. (eg. you have a little window with a windowing system inside it)
If you are talking about SDL using gtk to display error messages etc, it would
not be useful for anything but X11 windowed mode (not dga), in which case, you
might aswell just print messages to stderr, or into your SDL window/screen,
depending on what type of error message it is.On Sun, Oct 11, 1998 at 08:05:27PM +0200, Stephane Magnenat wrote:
Hello to all, why not making a SDL port of GTK ? If in the same time we put a
little font there could be used as error messages for the one that would likle
to have an error system ?
–
– Michael Samuel
Your code used GLX, which I don’t think is multi-os.
sure it is, it will work on any system that runs X (multiple multiple
OS’s in fact)Anyone insisting on maintaining compatibility with X should
be shot and hung. MIT has declared X11R6.3 as the end of the
line. Let it die.
So? X11R6.4 is out, they backed down on the licensing policy, so XFree86
will be incorporating it into XFree86 4.0… I don’t see how X is dead in
any way, really. It’s only dead when it stops being supported and when
people stop developing apps and libraries that use it.On Sun, 11 Oct 1998, David Sowsy wrote:
If you insist on running something on ms, as I said I
showed how I did that using GTK, but all it does it get contexts and
swap buffers, those calls are just for convenience and wouldn’t be
hard to write into SDLYeah, but what about BeOS and MacOS?
If OpenGL layer needed to be added for compatibility, it
had better be Glut, and NOT wgl, glx, or gtk.
Scott M. Stone <sstone at pht.com, sstone at turbolinux.com>
Head of TurboLinux Development/Systems Administrator
Pacific HiTech, Inc (USA) / Pacific HiTech, KK (Japan)
http://www.pht.com http://armadillo.pht.co.jp
http://www.pht.co.jp http://www.turbolinux.com
Anyone insisting on maintaining compatibility with X should
be shot and hung. MIT has declared X11R6.3 as the end of the
line. Let it die.
Um, isn’t there a X11R6.4 in the work or maybe even already out?
Also, did anybody try SDL-Doom on Win32 recently? I couldn’t get it to
work at all!
Pierre Phaneuf
Web: http://seventh.ml.org/~pp/
finger: pp at seventh.ml.orgOn Sun, 11 Oct 1998, David Sowsy wrote:
Anyone insisting on maintaining compatibility with X should
be shot and hung. MIT has declared X11R6.3 as the end of the
line. Let it die.Um, isn’t there a X11R6.4 in the work or maybe even already out?
yeah, it’s out. XFree86 4.0 will supposedly use it.On Mon, 12 Oct 1998, Pierre Phaneuf wrote:
On Sun, 11 Oct 1998, David Sowsy wrote:
Also, did anybody try SDL-Doom on Win32 recently? I couldn’t get it to
work at all!Pierre Phaneuf
Web: http://seventh.ml.org/~pp/
finger: pp at seventh.ml.org
Scott M. Stone <sstone at pht.com, sstone at turbolinux.com>
Head of TurboLinux Development/Systems Administrator
Pacific HiTech, Inc (USA) / Pacific HiTech, KK (Japan)
http://www.pht.com http://armadillo.pht.co.jp
http://www.pht.co.jp http://www.turbolinux.com
Anyone insisting on maintaining compatibility with X should
be shot and hung. MIT has declared X11R6.3 as the end of the
line. Let it die.
What do you recommend as a replacement?
Yeah, but what about BeOS and MacOS?
Port GTK to them!
njhOn Sun, 11 Oct 1998, David Sowsy wrote: