[SDL] DirectX 7?

David Olofson david.olofson at reologica.se
Thu Sep 26 05:23:01 PDT 2002


On Thursday 26 September 2002 13:43, Matthijs Hollemans wrote:
> [DirectX 8 not suitable for SDL 2.0]
>
> So what's the big deal? If you want to write a (2D) game that runs
> on low-end and older machines, use the SDL 1.x branch. No one is
> forcing you to use SDL 2.x.

That sounds like a bad idea to me. As soon as the new version is 
reasonably stable, we should use that. Keeping an old tree alive is 
basically the same thing as forking the project, and the community does 
not have unlimited resources.

I think the time would be *much* better spent implementing support for 
more than one DX version, if there's actually a need.


> (Unless, of course, having 2.x means
> that the 1.x branch is no longer maintained with bug fixes and
> such.)

Well, that level of maintenace *might* be realistic, but what happens 
when people start asking for 2.x to be backported into in 1.x, since they 
don't want to use 2.x? *heh*


> Now, I know next to nothing about SDL 2.0, but I was under the
> impression that it was going to be a total rewrite. A kick-ass game
> toolkit that takes advantage of the latest and greatest features
> available.

The latest and greatest *portable* features, unless the design goals 
differ from those of 1.x.


> If that is truly the case, then obviously it should use
> DirectX 8. But I am not Sam, so I may be mistaken about this.

The way I see it, a DirectX 8 backend should be seen as Win32-only 
alternative to glSDL, not an alternative to the GDI and DX3 backends. DX8 
"2D" is 2D-on-3D using DirectGraphics instead of OpenGL. These backends 
(glSDL and "D3DSDL") are in no way alternatives to DirectDraw and other 
pure 2D backends, until *everyone* has working 3D acceleration. The 
features one would reasonably expect from a DX8/OpenGL wrapper cannot be 
emulated in s/w with seriously usable performance, especially not without 
insane amounts of work.

IMHO, having SDL 2.x *require* DX8 is not very different from coding 
applications directly for, and only for OpenGL. Even if SDL 2.x provided 
software emulation of any featuers that normally require 3D acceleration, 
it wouldn't be much better than just using OpenGL and some s/w OpenGL 
implementation when there's no h/w acceleration. Then why bother with a 
new graphics API in the first place, rather than just making SDL 2.x a 
glorified portable OpenGL utility library?

I'd certainly prefer to have the extremely portable "real" 2D support 
left around for applications where it's sufficient, and just have DX8 and 
OpenGL support through backends similar to glSDL as a transparent option 
for users that have DX8 and/or OpenGL.

As soon as we start thinking about advanced transformation and blending 
features and other stuff that require 3D acceleration for usable 
performance, we're bound to end up with something that's too limited for 
serious use, or complex enough that trying to implement a good 
OpenGL-over-DX8 wrapper seems like a better idea.

Maybe we'll just never get around this "need to support both D3D and 
OpenGL" obstacle until one of the APIs is dead and forgotten. I don't 
think SDL 2.x can solve that, but then again, I might be mistaken on what 
kind of level the API will be on. (If it's aware of "tiled layers", 
sub-pixel accuracy and that kind of stuff, then *maybe* it could handle 
serious 2D-on-3D gaming...)


//David Olofson - Programmer, Composer, Open Source Advocate

.- Coming soon from VaporWare Inc...------------------------.
| The Return of Audiality! Real, working software. Really!  |
| Real time and off-line synthesis, scripting, MIDI, LGPL...|
`-----------------------------------> (Public Release RSN) -'
.- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---




More information about the SDL mailing list