[SDL] DirectX 7?
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
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
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