Is the assumption ok that a user which has DirectX8 installed probably has
hardware which can do this fast?
That sounds reasonable. The problem is that if you’ve got someone with
Win95 on an ancient machine where DirectDraw would be a better choice,
we still default to GDI first, and that is less nice. I guess a
“maybedirectx” driver could be put in front of the GDI one, which
would try to figure out if DirectX is a good or a bad idea (query for
DirectX 8, if you get it, then skip DirectX, for example). That said,
this is becoming less and less relevant, I think…
What other problems are there with the DirectX backend on Windows Vista?
(Just failing wouldn’t be a problem as we have the fallback then to just use
the SDL default.)
I’m not entirely aware of the details there, as I don’t use it myself,
it’s just been reported. I saw the DirectDraw slowdowns on DirectX 8
and up, though, pretty visible (test programs that used to have 50 fps
and up down to below 10 fps, but they also sucked on Linux, so…).
I wonder if we perhaps should change the behaviour in our game. Whereby up
to now we got a lot of reports that our game is running faster since we have
it. But it could be that I am not up-to-date anymore (I only get this
reports indirectly from our Windows developer).
You could still have a bit of Windows-specific code to use SDL_setenv
to set the video driver to DirectX in your game before initializing
SDL, checking on some conditions that work for your users. No
modification to SDL required, just more hacking. 
and SDL games are often “used to” software rendering, often
being used on Linux, where it’s all software, all the time.
Is that also true for OpenGL & SDL_HWSURFACE?
OpenGL is its own deal, separate from SDL (the latter only gives you a
portable access to the platform OpenGL), so if OpenGL is hardware
accelerated, then it will be for a program using OpenGL through the
SDL binding (but any SDL calls that aren’t using OpenGL won’t be
accelerated). That’s one of the reasons that the OpenGL rendering in
SDL 1.3 is so nice, SDL will use OpenGL itself if available, so we
finally have access to hardware acceleration on Linux! If your OpenGL
isn’t hardware accelerated, though, software is still the word. I
curse the lack of (useful) access to the 2D accelerators on Linux all
the time, there’s very little you can do even using Xlib directly
(solid fills, non-colorkeyed, non-alpha blits, that’s more or less
it)…
SDL_HWSURFACE is just a “nice request”, if it’s not available, you
still get a surface that won’t be on hardware, and/or won’t be
accelerated.
The general situation on Linux is that either your game should be
simple enough to be doable in software (which is still fairly nice on
a modern machine, but on an old geezer, it gets unimpressive real
quick), or you can do 2D effects with OpenGL, basically requiring 3D
hardware acceleration, but guaranteeing solid performance everywhere
(even a crappy Intel GMA can do a whole bunch of 2D effects without
sweat).On Wed, Mar 25, 2009 at 3:49 PM, Albert Zeyer <albert.zeyer at rwth-aachen.de> wrote:
–
