[SDL] DirectX 7?
david.olofson at reologica.se
Mon Sep 30 07:35:01 PDT 2002
On Friday 27 September 2002 11:46, Neil Griffiths wrote:
> 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