I’m just testing the waters here, to see if there’s sufficient interest for
me to develop a driver for Mesa (a free OpenGL implementation for Linux,
just in case you don’t know) which would work with SDL? It would basically
generate a context for Mesa which would work with the SDL interface and
Mesa’s software renderer… sound good? I’d primarily be interested in
writing it for my own use, because … well, I don’t know, the idea of
having GL + SDL is definately appealing. I don’t know if I could guarantee
support for the 3Dfx, I’d have to look into it. All the changes would be on
the Mesa end…
Does this seem like a good idea to anybody?
Nicholas Vining (Mordred)
e-mail: vining at pacificcoast.net
icq: 20782003
There used to be an SDL demo library called OpenGL which allowed use of
OpenGL on an SDL surface. I can’t seem to find it on the SDL site. Is
it coming back Sam?
I can mail you a copy if you want the old code (from SDL 0.8 I believe).
Later
Mat Tivey
Nicholas Vining wrote:>
I’m just testing the waters here, to see if there’s sufficient interest for
me to develop a driver for Mesa (a free OpenGL implementation for Linux,
just in case you don’t know) which would work with SDL? It would basically
generate a context for Mesa which would work with the SDL interface and
Mesa’s software renderer… sound good? I’d primarily be interested in
writing it for my own use, because … well, I don’t know, the idea of
having GL + SDL is definately appealing. I don’t know if I could guarantee
support for the 3Dfx, I’d have to look into it. All the changes would be on
the Mesa end…
Does this seem like a good idea to anybody?
Nicholas Vining (Mordred)
e-mail: vining at pacificcoast.net
icq: 20782003
having GL + SDL is definately appealing. I don’t know if I could guarantee
support for the 3Dfx, I’d have to look into it. All the changes would be on
the Mesa end…
Does this seem like a good idea to anybody?
This would definately be interesting. As far as support for 3Dfx, I’d
rather see it support GLX standards, that way it works with my G200, 3Dfx,
or Riva TNT as well. :)–
Brian
This would definately be interesting. As far as support for 3Dfx, I’d
rather see it support GLX standards, that way it works with my G200, 3Dfx,
or Riva TNT as well.
I dunno - that seems like far too much work! (and something that’d
definately require some serious research, since I’m not terribly familiar
with GLX) but I’ll look at it.
–
Brian
Nicholas Vining (Mordred)
e-mail: vining at pacificcoast.net
icq: 20782003
----- Original Message -----
From: hayward at slothmud.org (hayward@slothmud.org)
To: sdl at lokigames.com
Date: Monday, December 13, 1999 5:42 AM
Subject: Re: [SDL] SDL Driver for Mesa?
I dunno - that seems like far too much work! (and something that’d
definately require some serious research, since I’m not terribly familiar
with GLX) but I’ll look at it.
I’m not sure how that would work myself. I know that making a MesaGL
program work with GLX merely requires linking them to the GLX library
first (which I assume calls MesaGL).
I have no idea of the complexity involved in doing such a thing, but if
SDL was modified (in some way or another) to make use of Mesa libs, it
should be similar to the above. Just link SDL with GLX rather than Mesa.
And it would be much more useful to a game engine to be able to use GLX!
But, As I heard from followups to this thread, I guess there is
already a GL demo for SDL.–
Brian
Is the goal to make a target window a GL window, or to use GL as the output
for SDL? For example, I create an SDL application and note that it has the
CANDO_GL flag. I create a surface with it, and can do GL functions on it. Or
do you mean something similer to the above, but use GL as an output method
instead of X or DriectDraw?
I ask this one because some GL cards only support full screen mode and are
unattached to X (Voodoo 1 for example). Using mesa doesn’t require X to be
running or even installed, if it is used as the primary display driver.
Jamie Best
hayward at slothmud.org wrote:> >I dunno - that seems like far too much work! (and something that’d
definately require some serious research, since I’m not terribly familiar
with GLX) but I’ll look at it.
I’m not sure how that would work myself. I know that making a MesaGL
program work with GLX merely requires linking them to the GLX library
first (which I assume calls MesaGL).
I have no idea of the complexity involved in doing such a thing, but if
SDL was modified (in some way or another) to make use of Mesa libs, it
should be similar to the above. Just link SDL with GLX rather than Mesa.
And it would be much more useful to a game engine to be able to use GLX!
But, As I heard from followups to this thread, I guess there is
already a GL demo for SDL.
Is the goal to make a target window a GL window, or to use GL as the output
for SDL? For example, I create an SDL application and note that it has the
CANDO_GL flag. I create a surface with it, and can do GL functions on it.
Or
do you mean something similer to the above, but use GL as an output method
instead of X or DriectDraw?
What I am referring to is creating code for Brian Paul’s Mesa graphics
library so that it can use SDL for its device context, as opposed to X
Windows/SVGALib/GGI/whatever. The primary advantage would be that we could
then use pretty-damn-close-to-full OpenGL support easily with SDL, and we
could probably do hardware acceleration too. (I looked at this - in theory,
you can already mix SDL and Mesa if you have a 3Dfx card; just call SDL_Init
or whateveritscalled (I don’t remember right now), then fxMesaCreateContext
and let 'er rip!)
Jamie Best
----- Original Message -----
From: bestj@nationwide.com (James M Best)
To: sdl at lokigames.com
Date: Monday, December 13, 1999 9:45 AM
Subject: Re: [SDL] SDL Driver for Mesa?
It would be much better to put SDL over OpenGL. OpenGL has functionality for
direct frambuffer writing. Hardware accelleration would be hard to implement
using your idea because it would cover up all of the 2D graphics created
through the SDL. By putting SDL on top, all the 2D stuff would show up as
you’d expect it to. Also, it would be better to allow SDL to use GL on all
systems, not just Mesa-based ones.
I am prepared to do this. See my post below, in the main thread. Would you
like to help?
Nicholas Vining wrote:> What I am referring to is creating code for Brian Paul’s Mesa graphics
library so that it can use SDL for its device context, as opposed to X
Windows/SVGALib/GGI/whatever. The primary advantage would be that we could
then use pretty-damn-close-to-full OpenGL support easily with SDL, and we
could probably do hardware acceleration too. (I looked at this - in theory,
you can already mix SDL and Mesa if you have a 3Dfx card; just call SDL_Init
or whateveritscalled (I don’t remember right now), then fxMesaCreateContext
and let 'er rip!)
It would be much better to put SDL over OpenGL. OpenGL has functionality for
direct frambuffer writing. Hardware accelleration would be hard to implement
using your idea because it would cover up all of the 2D graphics created
through the SDL. By putting SDL on top, all the 2D stuff would show up as
you’d expect it to. Also, it would be better to allow SDL to use GL on all
systems, not just Mesa-based ones.
I am prepared to do this. See my post below, in the main thread. Would you
like to help?
I’m way ahead of you… read my other post! I actually looked at both
integrating the two systems so that SDL could effectively replace GLUT, and am
still trying to figure out what’s really the best way of doing it. The reason
that I suggested making Mesa overlay on top of SDL as opposed to the better way
was because that would be a very quick hack - 2 days at most, and I needed a
software renderer for SDL. Then I looked at the whole mess again and decided
that it wouldn’t be practical, and that writing a GL backbone for SDL wouldn’t
be so hard.
The problem which I have of directly binding OpenGL without aiming for a
specific method of creating contexts is that I can’t help feeling that it might
be very difficult to properly handle rewiring all of the systems without
creating a driver for WGL, a different one for GLX, etc. I am only willing to
write a driver for GL + glX, but if somebody else wanted to develop a driver
for GL + GLUT (bleah) or GL + WGL (double bleah) then I suggest that we try to
synchronize our efforts somewhat. Anybody else interested in this little chore?
I definately don’t think we should use GLUT. It’s very convoluted. Plus, if we
have SDL wrapping GLUT wrapping GL, then we’re getting into layers of wrapping
and it becomes a nuisance - plus, that defeats half the point of the exercise.
GL support for Windows is just a damn nuisance, which I am half tempted to try
to stop the eventual addition of support for it simply because that would be
encouraging Windows programming, which is Evil. I swore an oath yesterday that
never again would I work with a library that I didn’t have the source
By the way, Loki is planning on contributing some GL support to SDL, based
on the Quake GL wrappers.
If you actually have any code up and running, is it possible that you could tar
and feather it and dump it off to either my or Kenton’s private e-mails? (You
should have those)
By the way, Loki is planning on contributing some GL support to SDL, based
on the Quake GL wrappers.
If you actually have any code up and running, is it possible that you could tar
and feather it and dump it off to either my or Kenton’s private e-mails? (You
should have those)
or better, put it on the Net so we can all have a look at it :-)–
Daniel Vogel
By the way, Loki is planning on contributing some GL support
to SDL, based on the Quake GL wrappers.
Does this mean I can mix 2D operations like blitting and calls to
OpenGL?
'fraid not. You can create offscreen SDL surfaces and use them in
glTexSubImage2D, or use glReadPixels/glWritePixels to move
data in and out of GL.
The OpenGL specs do not include an LFB, and hacking one will almost
surely be slow to the point of being useless. On consumer hardware,
your best bet is implementing everything as textured triangles
(including 2D operations).
LFB and OpenGL are just not compatible, and low end boards/drivers
usually do not offer good support for pixel/imaging operations.
b.--
“Problem solving is hunting. It is savage pleasure,
and we are born to it.” Thomas Harris, Silence of the Lambs
Actually, you will be able to blit stuff. I just can’t garentee that it
will be fast. I think it will be possible to blit stuff pretty well
using texture memory, but we’ll have to see about that. I will try to
make all the 2D functions as fast as possible.
-Kenton Varda
Bernd Kreimeier wrote:> Daniel Vogel wrote:
By the way, Loki is planning on contributing some GL support
to SDL, based on the Quake GL wrappers.
Does this mean I can mix 2D operations like blitting and calls to
OpenGL?
'fraid not. You can create offscreen SDL surfaces and use them in
glTexSubImage2D, or use glReadPixels/glWritePixels to move
data in and out of GL.
The OpenGL specs do not include an LFB, and hacking one will almost
surely be slow to the point of being useless. On consumer hardware,
your best bet is implementing everything as textured triangles
(including 2D operations).
LFB and OpenGL are just not compatible, and low end boards/drivers
usually do not offer good support for pixel/imaging operations.
Does this mean I can mix 2D operations like blitting and calls to
OpenGL?
The OpenGL specs do not include an LFB, and hacking one will almost
surely be slow to the point of being useless. On consumer hardware,
your best bet is implementing everything as textured triangles
(including 2D operations).
Yes, I know, I meant whether this textured triangle support will be
included in SDL so I can e.g. draw a scene using OpenGL and then maybe
blit a surface using SDL onto that scene without me having to do that
boring texturesplitup and stuff (not using X11 for displaying but GL
instead).–
Daniel Vogel
