[SDL] DirectX 7?

On Thursday 26 September 2002 17:35, Kylotan wrote:
> Neil Griffiths wrote:
> > I'd love to see where you get your numbers from. People who play
> > games will nearly always have fairly modern hardware. Those who don't
> > won't care that SDL will be dropping back to GDI which Sam has
> > already said SDL will be doing.
>> Let's not lose sight of the fact that SDL is used for more than games.
> And there are many simple games which will run too slowly on GDI. This
> is why I would prefer to see a DX5 fallback kept in addition to the
> latest DX47 or whatever version is around at the time for the more
> up-to-date programs. If 3 back-ends is too much work in terms of
> maintenance, personally I'd rather see the GDI option dropped than the
> DX5 one. But I know many others would disagree. :)
Well, I'm sure no one would complain about you maintaining a DX<whatever>
backend. ;-)
> > 2/5ths of the SDL userbase are not going to be using Windows '95.
> > Most of the SDL userbase will be made up of Linux users and
> > programmers. The majority of the rest will be made up of emulation
> > fans and games players. All of these will have reasonably up-to-date
> > hardware and software.
>> As word of mouth spreads, SDL should be reaching new audiences. Should
> it be designed to please the current userbase and stay in its niche, or
> perhaps to broaden the potential userbase by being more widely
> applicable? For example, with DirectDraw now effectively gone from
> DirectX, lots of us on GameDev.net are now promoting SDL as a more
> usable alternative for simple 2D games, increasing its popularity among
> Windows programmers and therefore users. So this choice is something to
> think about.
Yeah. And I maintain that SDL 2.x needs to cover the kind of stuff that
causes people to use OpenGL or D3D instead, or there isn't much of a
future in SDL's 2D API. I don't really think basic blitting with alpha
support will be enough motivation to use the API for much longer, even if
the *speed* is on par with native OpenGL and D3D when either of those is
present.
And where do we go if we don't want to code for *both* OpenGL and D3D?
There is a need here, and it seems reasonable to me to extend the SDL API
to fulfill this need - and I'm not talking about turning it into another
3D API.
Many typical 3D features don't belong in the SDL API at all, whereas some
features generally *not* found in OpenGL or D3D do. (Loading/saving
surfaces, blitting between surfaces, basic drawing primitives and that
sort of stuff. Maybe even tiling with sub-pixel accurate scrolling
belongs here. With 2D, I think that's related to subpixel accurate
coordinates...)
//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 ---