[SDL] DirectX 7?

Patrick McFarland unknown at panax.com
Thu Sep 26 07:54:01 PDT 2002


Hmm, yeah, I kinda wish sdl 2.0 had everything in software so in the long run
all of this wouldnt matter. Exploit what you can with hardware APIs, if you
cant, fall back to an internal software routine. 

On 26-Sep-2002, David Olofson wrote:
> On Thursday 26 September 2002 13:23, 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.
> 
> It might be better if it dropped back to DX3 - but then again, anyone 
> that actually cares could just contribute a backend for it, if it's that 
> important...
> 
> 
> > 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.
> 
> Good point. And we either have prefectly fine OpenGL support, or 
> basically no acceleration at all. Same situation, really; DX8 or GDI - 
> OpenGL or Xlib/fbdev/<whatever>.
> 
> 
> > 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. That's pure logic - and I'd love to see you back up your
> > claims.
> >
> > Basically, you should take advantage of current technology, not stick
> > to the old days because you know how to use DirectDraw. There's a good
> > reason for rendering to textures. It's fast on pretty much every piece
> > of graphics hardware since 1996.
> >
> > Get with the times. And for people not with the times, they have GDI.
> 
> Right. There's only one thing I'm worried about: How do you take 
> advantage of the power of OpenGL and DX8 while still maintaining the same 
> API for 2D APIs and software rendering?
> 
> The obvious way is the way of the current glSDL; just don't provide 
> anything new but raw speed. glSDL even deliberately "breaks" surface 
> alpha on RGBA textures the same way SDL does, just to be compatible.
> 
> The other way is to figure out a reasonable feature set for "advanced 
> 2D", and make sure that there's a software fallback for every feature 
> added. Some things (like sub-pixel accurate blitting) could simply be 
> ignored when there's no acceleration, but transformations and blending 
> effects aren't that easy to fake...
> 
> 
> //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 ---
> 
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl

-- 
Patrick "Diablo-D3" McFarland || unknown at panax.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989




More information about the SDL mailing list