SDL through OpenGL

I don’t understand why there is so much concern over making SDL draw
through OpenGL. I’m all for being able to use them together, but I imagine
most people would be using SDL for window management, input, and audio,
and OpenGL for graphics, not using SDL’s 2D graphics capabilities at all.
This is certainly how I will use it. Functions to facilitate transfering
between GL textures and SDL surfaces make sense, but reimplementing all of
the graphics functions to draw through OpenGL just seems like a waste of
effort. Besides, OpenGL’s limitations - such as power of two textures and
lack of framebuffer level access - just make the 2D API a bad fit.—
This signature has been infected by the signature virus.
Please help me spread and copy me to your .signature.

(Andy Hefner)

Well, my reasoning is… Because I can! Isn’t that the reason for most open
source software? :slight_smile:

Frankly, it will not be hard at all to get everything implemented. I have
all the code for 16-bit rendering done already (exept for HW surfaces). I
just have to figure out this X I/O error… :slight_smile:

Civ: CTP (as well as Q3A and Myth2) arrived here today. Perfect timing! Now
I can use it to test my code! :slight_smile: That should be interesting.

-Kenton Varda

PS. Another reason why I’d like to implement the 2D code is because I want
to use that cool Quake-style console library that runs on SDL. :slight_smile:

Andy Hefner wrote:> I don’t understand why there is so much concern over making SDL draw

through OpenGL. I’m all for being able to use them together, but I imagine
most people would be using SDL for window management, input, and audio,
and OpenGL for graphics, not using SDL’s 2D graphics capabilities at all.
This is certainly how I will use it. Functions to facilitate transfering
between GL textures and SDL surfaces make sense, but reimplementing all of
the graphics functions to draw through OpenGL just seems like a waste of
effort. Besides, OpenGL’s limitations - such as power of two textures and
lack of framebuffer level access - just make the 2D API a bad fit.

I don’t understand why there is so much concern over making SDL draw
through OpenGL. I’m all for being able to use them together, but I imagine
most people would be using SDL for window management, input, and audio,
and OpenGL for graphics, not using SDL’s 2D graphics capabilities at all.
This is certainly how I will use it. Functions to facilitate transfering
between GL textures and SDL surfaces make sense, but reimplementing all of
the graphics functions to draw through OpenGL just seems like a waste of
effort. Besides, OpenGL’s limitations - such as power of two textures and
lack of framebuffer level access - just make the 2D API a bad fit.

Well, any 3D game will still need some 2D output. Doubly besides which once
you start losing compatibility, well, all hell breaks loose. I, of course,
want to use SDL as a better, more game-oriented replacement for GLUT, so it
doesn’t really matter for me. I’m suspecting that they’re just there for
compatibility reasons, also in case you end up with a “GL or bust!” system
(like an SGI machine. Civ:CTP on an SGI machine… mmmm…)

Nicholas

----- Original Message -----
From: vector7@crosswinds.net (Andy Hefner)
To: sdl at lokigames.com
Date: Tuesday, December 14, 1999 6:03 PM
Subject: [SDL] SDL through OpenGL

Andy Hefner wrote:

I don’t understand why there is so much concern over making SDL draw
through OpenGL. I’m all for being able to use them together, but I imagine
most people would be using SDL for window management, input, and audio,
and OpenGL for graphics, not using SDL’s 2D graphics capabilities at all.
This is certainly how I will use it. Functions to facilitate transfering
between GL textures and SDL surfaces make sense, but reimplementing all of
the graphics functions to draw through OpenGL just seems like a waste of
effort. Besides, OpenGL’s limitations - such as power of two textures and
lack of framebuffer level access - just make the 2D API a bad fit.


This signature has been infected by the signature virus.
Please help me spread and copy me to your .signature.

(Andy Hefner)

I certainly agree with you on a whole. Currently we are using SDL for
input/audio
for cross-platform availability to Windows and OpenGL exclusively for
graphics.
This makes our game cross-platform when it comes to input/audio and most of
the
OpenGL drivers (though too many graphics card vendors take bad shortcuts in
their
drivers).

And to answer 2D capabilities. Most 2D aspects can be covered by playing
tricks
with the optimized portions of OpenGL drivers, like drawing on quads, or
rendering
relatively low frame rate menus in Open GL. Look, if you play
Unreal: Tournament
they are rendering into OpenGL for all there 2D menus, through a scripting
language.
Slow+usually slow implementation=really slow, but for game selection,
controls, and
configuration of other parameters this is usually acceptable and certainly
does not
need to be high frame rate.

-Alan Carr
http://www.denizengames.com

I certainly agree with you on a whole. Currently we are using SDL for
input/audio
for cross-platform availability to Windows and OpenGL exclusively for
graphics.
This makes our game cross-platform when it comes to input/audio and most of
the
OpenGL drivers (though too many graphics card vendors take bad shortcuts in
their
drivers).

In that case, would you mind explaining what exactly you used? I need to
implement this into SDL so that both WGL and GLX are supported, and I’d be
curious to know how you handled it.

-Alan Carr
http://www.denizengames.com

Nichola

vining at pacificcoast.net wrote:

I certainly agree with you on a whole. Currently we are using SDL for
input/audio
for cross-platform availability to Windows and OpenGL exclusively for
graphics.
This makes our game cross-platform when it comes to input/audio and most of
the
OpenGL drivers (though too many graphics card vendors take bad shortcuts in
their
drivers).

In that case, would you mind explaining what exactly you used? I need to
implement this into SDL so that both WGL and GLX are supported, and I’d be
curious to know how you handled it.

-Alan Carr
http://www.denizengames.com

Nichola

We are just using our WGL and GLX calls for initialization,
and even those have wrappers to make them generic for a
higher level interface. Once you are initialized there is
only one other thing that is Windows/X Windows specific and
that is the page flip operation, which you guessed it, is
wrapped too. Not much to it really.

Just pick up the OpenGL Programming Guide, (which is finally
out for Version 1.2 btw) and there is an appendix that goes
through the X Windows/Windows/AGL(Apple) and even lowly OS/2.
What support you get from each is questionable, but I haven’t
had any problems at all with X Windows/Windows maintainability.

If you want to know more gory initialization code/details let
me know.

-Alan Carr
http://www.denizengames.com
"Screenshots!? We don’t need no stink’ screenshots!"

We are just using our WGL and GLX calls for initialization,
and even those have wrappers to make them generic for a
higher level interface. Once you are initialized there is
only one other thing that is Windows/X Windows specific and
that is the page flip operation, which you guessed it, is
wrapped too. Not much to it really.

I don’t care about that; I know all that. What I’m curious to know is what you
used for input… DirectInput or Windows-based input?

-Alan Carr

Nicholas Vining