[SDL] DirectX 7?

David Olofson david.olofson at reologica.se
Mon Sep 30 07:35:01 PDT 2002

On Friday 27 September 2002 11:46, Neil Griffiths wrote:
> Hi,
> PM> No, Im not. The zsnes development team (which I am apart of) have
> gotten PM> several "bug reports" about zsnes not working on early
> pentium systems PM> because microsoft will not allow dx8 to be
> installed on a system that old. PM> This has also been confirmed by
> several of the windows port developers.
> Well, I've just used google and searched for "directx8 pentium
> problem". Guess what? I found no problems at all. I went through 50
> results with not one match for what you're saying. I doubt it a lot.
> Besides which, it's immaterial anyway if there's DirectX7 (or
> whatever) to fall back on.
> I will fix up my old P-90 in a bit and test it for myself BTW, because
> I quite simply don't believe you.
> PM> As I said before, its a completely bad idea to display a surface as
> a texture. PM> Its slow, and its dumb. If you wanna make a complete
> opengl rendering pipeline PM> that uses a texture per sprite and per
> background, then yeah, you can do that. PM> But that takes alot of
> recoding, and still, mesa sucks in software mode, and PM> microsoft's
> opengl32.dll (which I heard uses d3d as the rendering backend, PM>
> which means software mode in D3D, which also means (iirc) no software
> mode PM> in DX8.)
> Slow? Sure, if if a 4x+ speed-up is what you call slow.

Actually, it *is* slow - unless you have the AGP aperture and/or 
busmaster DMA working properly. On some drivers, textures *must* be 
uploaded to the card before they can be used, and that's done with the 
CPU, and consequently is just as slow as normal s/w rendering.

The only situation where it virtually always pays off is when you want to 
scale a super low res emulator screen to fit a 640x480+ screen. In such 
cases, the texture uploading bandwidth requirement is low enough that 
it's not an issue if it's limited to "software speed".

> Of course it's
> better to keep everything as seperate textures - which isn't a problem
> at all if you place the texture on a poly and move it to the place
> it's being blitted too. That would be much faster.
> BTW, I can claim a 4x speed-up because this is how glSDL works - at
> least this is how I'm sure it works from when I looked at the code.
> I'm sure David will tell me if I'm wrong!

glSDL uploads individual surfaces to OpenGL as textures, which generally 
means that it goes directly to texture RAM - through DMA, if you're lucky.

Textures are also kept in system RAM (ie they don't "go away" when 
uploaded) as normal SDL s/w surfaces, so you can lock them, modify them, 
and unlock them. As you unlock a surface, glSDL automatically updates 
it's corresponding texture area. (This is why I want an optional rect 
argument for SDL_LockSurface(). Without it, glSDL will always have to 
update the whole surface, even if you only changed a single pixel.)

> And of course it takes a lot of recoding. But that's the whole point
> anyway! SDL 2.0 is going to be a rewrite...

OTOH, we're talking about major recoding of *SDL* - not SDL applications. 
Sure, there probably have to be some API changes that will break SDL 1.2 
apps, but considering what glSDL can do already, and what it *could* do 
with only major API tweaks, it's not like anyone will have to rewrite any 
SDL graphics code to work with it.

//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