glSDL integration / future plans

SDL Development
1

Hi,

I have a few questions about glSDL and some related topics.

  1. According to other posts (and from downloading it and quickly
    trying it out), it seems that the backend now works pretty well,
    probably with a few little bugs. Is there any kind of plan or roadmap
    for integrating it into the main SDL distribution, or will it remain
    outside of it for a while / permanently?

  2. I’ve seen the help page here:
    http://icps.u-strasbg.fr/~marchesin/sdl/glsdl.html
    but I’m still not clear on how to specify that the hardware mode
    should be OpenGL rather than the standard 2D accelerated (ie no
    accelerated alpha) mode. Will it be possible to use both accelerated
    modes with the same DLL, or switch between them at runtime?

  3. Are there any thoughts of adding scaled/rotated blits to the SDL
    API now that they can be hardware-accelerated on more platforms? It
    seems like relying on things like SDL_gfx to add support for the
    OpenGL backend seems kind of optimistic, but who knows. I also have a
    feeling that adding this kind of functionality on in external
    libraries gets more complicated with multiple backends if you don’t
    want to do everything in software, but I could be wrong.

  4. It is becoming popular in the downloadable-games field to use
    Direct3D v.7 for 2D, since Windows XP doesn’t ship with any OpenGL
    drivers even for modern cards, but many/most pre-XP machines don’t
    have DirectX 8 installed. I know this has been discussed on this list
    before with some distaste, perhaps understandable, but if DirectDraw
    is supported, I don’t see the difference between supporting that and
    supporting D3D, especially since DirectDraw is now deprecated. A D3D7
    backend would be useful for (and used by) a large number of people, I
    think. I’m not qualified to implement such a thing myself, but I’d be
    perfectly happy to go out and get an old D3D7 book and slap together a
    really bad, barely-working one, if that would encourage a real
    programmer to step in and do it right. The thing is that would
    probably take me a year or so, so if anyone more competent is working
    on something like this, let me know. I would be very happy to help
    with testing or anything else I could do.

Or, maybe the best thing is just to wait until software rendering is
so fast that OpenGL/Direct3D are unnecessary anyway, like Macromedia
appears to be doing…

2

Peter Nicolai a ?crit :

Hi,

I have a few questions about glSDL and some related topics.

  1. According to other posts (and from downloading it and quickly
    trying it out), it seems that the backend now works pretty well,
    probably with a few little bugs. Is there any kind of plan or roadmap
    for integrating it into the main SDL distribution, or will it remain
    outside of it for a while / permanently?

It’s been outside SDL for about one year, and I think that’s enough.
Integration into SDL itself is not my call.
Actually, I find it a little sad that SDL development has almost
stopped, although I see many people are sending patches which end up
being lost.

  1. I’ve seen the help page here:
    http://icps.u-strasbg.fr/~marchesin/sdl/glsdl.html
    but I’m still not clear on how to specify that the hardware mode
    should be OpenGL rather than the standard 2D accelerated (ie no
    accelerated alpha) mode. Will it be possible to use both accelerated
    modes with the same DLL, or switch between them at runtime?

You can use the same library, you just have to set the env var
SDL_VIDEODRIVER to glSDL. I’ll add this to the page.

  1. Are there any thoughts of adding scaled/rotated blits to the SDL
    API now that they can be hardware-accelerated on more platforms? It
    seems like relying on things like SDL_gfx to add support for the
    OpenGL backend seems kind of optimistic, but who knows. I also have a
    feeling that adding this kind of functionality on in external
    libraries gets more complicated with multiple backends if you don’t
    want to do everything in software, but I could be wrong.

Well, I think accelerating scaled/rotated blits is getting a bit out of
the scope of SDL.

My opinion is that SDL should provide hooks to some internal
platform-dependent structures (X context, window handle…), and then
add-on libraries would be able to add the missing platform-dependent
hardware-accelerated code to do that. That way people would be able to
plug virtually anything they want into SDL.

  1. It is becoming popular in the downloadable-games field to use
    Direct3D v.7 for 2D, since Windows XP doesn’t ship with any OpenGL
    drivers even for modern cards, but many/most pre-XP machines don’t
    have DirectX 8 installed. I know this has been discussed on this list
    before with some distaste, perhaps understandable, but if DirectDraw
    is supported, I don’t see the difference between supporting that and
    supporting D3D, especially since DirectDraw is now deprecated. A D3D7
    backend would be useful for (and used by) a large number of people, I
    think. I’m not qualified to implement such a thing myself, but I’d be
    perfectly happy to go out and get an old D3D7 book and slap together a
    really bad, barely-working one, if that would encourage a real
    programmer to step in and do it right. The thing is that would
    probably take me a year or so, so if anyone more competent is working
    on something like this, let me know. I would be very happy to help
    with testing or anything else I could do.

I actually think it’s a good idea, it’s just that I don’t run windows
that much.
If you want to get started with that, you can probably build upon the
SDL12/src/video/wincommon/ stuff and add a new SDL12/src/video/windx7/
backend. I also think a lot of the glSDL code could be reused, since a
3D API is just a 3D API when it comes to immediate mode.

Btw, I wrote a little document about porting SDL to a new video backend
some time ago :
http://icps.u-strasbg.fr/~marchesin/sdl/sdl_port.txt
Probably not all of this applies, though, since you can build upon the
wincommon stuff.

Or, maybe the best thing is just to wait until software rendering is
so fast that OpenGL/Direct3D are unnecessary anyway, like Macromedia
appears to be doing…

Actually, I think that software rendering (with up-to-date CPUs) will be
getting slower over time compared with hardware rendering (with
up-to-date GPUs). So I don’t think that’s a safe path.

Stephane

3

[…]

Or, maybe the best thing is just to wait until software rendering
is so fast that OpenGL/Direct3D are unnecessary anyway, like
Macromedia appears to be doing…

Actually, I think that software rendering (with up-to-date CPUs)
will be getting slower over time compared with hardware rendering
(with up-to-date GPUs). So I don’t think that’s a safe path.

Well, one might argue that SIMD, array programmable logic sections or
other technologies could be taken so far that they’ll eventually beat
dedicated 3D accelerators - but that’s just a small part of the
problem.

Ever since the 486, the CPU/VRAM bottleneck has basically crippled the
CPU, allowing only a fraction of the frame rates that would otherwise
be possible, and so far, I have seen no sign whatsoever of that
problem going away.

Also, once you start getting close to the internal bandwiths of modern
video cards, the kind of bus widths and clocks suitable for "normal"
computing just won’t cut it. A GPU usually has a memory bus that is
several times wider and higher clocked than the corresponding bus on
the motherboard. Multicore CPUs and/or SMP won’t help either, unless
each CPU gets it’s own private memory bank, and/or at least a few
hundred MB of cache.

Then again, look at the audio field… Your average PC these days
beats most studio samplers in terms of raw performance (voice count
and/or processing quality), despite the latter being based on
specialized DSPs. This could happen with graphics as well, though the
insane bandwidth requirements might be a problem. It’s kinda’ hard to
motivate using several times faster buses and memory chips, when
normal applications are mostly CPU bound already.

But OTOH, I wouldn’t be using a 512 MB, 430 MHz GF 6800 Ultra video
card (basically just because I need the dual-link DVI port!) if the
gaming market didn’t cause a demand for such monsters - so anything
can happen, I guess… :slight_smile:

//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 01 August 2005 02.12, Stephane Marchesin wrote:

4

Actually, I find it a little sad that SDL development has almost
stopped, although I see many people are sending patches which end up
being lost.

I have a bunch of patches that are still sitting in my TODO queue that
need consideration, and will put out a call for patches that I might
have missed later on when I get through these.

Part of the problem is that there are patches in my queue that aren’t
really suitable for mainline SDL but no good way to tell people, other
than posting them here…several of them are things I sort of harvested
from the mailing list or other people’s collections but don’t know who
they belong to.

In short, SDL isn’t dead or anything, there’s just a bit of a mess in
the patch submission backlog that needs cleaning up.

–ryan.

5

Ryan C. Gordon a ?crit :

Actually, I find it a little sad that SDL development has almost
stopped, although I see many people are sending patches which end up
being lost.

I have a bunch of patches that are still sitting in my TODO queue that
need consideration, and will put out a call for patches that I might
have missed later on when I get through these.

Part of the problem is that there are patches in my queue that aren’t
really suitable for mainline SDL but no good way to tell people, other
than posting them here…several of them are things I sort of
harvested from the mailing list or other people’s collections but
don’t know who they belong to.

I have written all the patches I sent you.
That was in march, btw.

Stephane