Which directx version is required?

i’m trying to determine exactly which version of directx is required
for SDL on windows? (well, at least for the ‘directx’ driver)

i thought (and others in #sdl) that directx5 was all that was required.
in the latest cvs headers are the following lines…

#define DIRECTDRAW_VERSION 0x0700
#define DIRECTSOUND_VERSION 0x0700
#define DIRECTINPUT_VERSION 0x0700

this would seem to imply directx7 is needed to run directx.
have there been changes to SDL that now require v7 over v5?

if SDL can run with directx5 and just switching these to 0x0500
would allow it to run with directx5 then that seems like a worthwhile
adjustment?

anyways, in the long run i don’t really care which version is needed,
i’m just trying to figure out for sure what the requirement is.
although if directx5 is already supported, it would seem prudent to
actually support it :]

just another slightly-puzzled, satisfied customer.
thanks for insight :]

i’m trying to determine exactly which version of directx is required
for SDL on windows? (well, at least for the ‘directx’ driver)

i thought (and others in #sdl) that directx5 was all that was required.
in the latest cvs headers are the following lines…

#define DIRECTDRAW_VERSION 0x0700
#define DIRECTSOUND_VERSION 0x0700
#define DIRECTINPUT_VERSION 0x0700

this would seem to imply directx7 is needed to run directx.
have there been changes to SDL that now require v7 over v5?

The gamma ramp code is only supported in DirectX 6 or newer.
Since DirectX 6 was an intermediate version immediately followed by
the more stable DirectX 7, I decided to use that define instead.
SDL compiles with the DirectX 6 SDK with the above defines,
but no longer compiles with the DirectX 3 SDK. Hum.

For 1.3, I’ll probably rewrite the SDL video code for the DirectX 8 SDK,
which no longer separates DirectDraw and Direct3D. The reason for this
is that driver writers will be maintaining code for the new API, and
their backwards compatibility will probably slowly break. SDL 1.3 is
far enough in the future for a usable version, that I think this is okay.

if SDL can run with directx5 and just switching these to 0x0500
would allow it to run with directx5 then that seems like a worthwhile
adjustment?

Yes, but then DirectX gamma control is no longer possible.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

“Sam Lantinga” wrote

For 1.3, I’ll probably rewrite the SDL video code for the DirectX 8 SDK,
which no longer separates DirectDraw and Direct3D. The reason for this
is that driver writers will be maintaining code for the new API, and
their backwards compatibility will probably slowly break. SDL 1.3 is
far enough in the future for a usable version, that I think this is okay.

if SDL can run with directx5 and just switching these to 0x0500
would allow it to run with directx5 then that seems like a worthwhile
adjustment?

Yes, but then DirectX gamma control is no longer possible.

ok sam, thats good to know. btw, i heard directx 8 no longer supports
colorkeys (only alpha). that could likely be for textures not straight
blitting.

Sam Lantinga wrote:

i’m trying to determine exactly which version of directx is required
for SDL on windows? (well, at least for the ‘directx’ driver)

i thought (and others in #sdl) that directx5 was all that was required.
in the latest cvs headers are the following lines…

#define DIRECTDRAW_VERSION 0x0700
#define DIRECTSOUND_VERSION 0x0700
#define DIRECTINPUT_VERSION 0x0700

this would seem to imply directx7 is needed to run directx.
have there been changes to SDL that now require v7 over v5?

The gamma ramp code is only supported in DirectX 6 or newer.
Since DirectX 6 was an intermediate version immediately followed by
the more stable DirectX 7, I decided to use that define instead.
SDL compiles with the DirectX 6 SDK with the above defines,
but no longer compiles with the DirectX 3 SDK. Hum.

For 1.3, I’ll probably rewrite the SDL video code for the DirectX 8 SDK,
which no longer separates DirectDraw and Direct3D. The reason for this
is that driver writers will be maintaining code for the new API, and
their backwards compatibility will probably slowly break. SDL 1.3 is
far enough in the future for a usable version, that I think this is okay.

Windows NT only has DirectX 5 IIRC.

if SDL can run with directx5 and just switching these to 0x0500
would allow it to run with directx5 then that seems like a worthwhile
adjustment?

Yes, but then DirectX gamma control is no longer possible.

You don’t have to use DirectX to set the gamma ramp. You can use
SetDeviceGammaRamp to do that though the DirectX version should work in
more cases (at least that’s what the docs say).

                        Daniel Vogel, Programmer, Loki Software Inc.

hmm, ok here is the current dilemma. this might be all cleaned
up when moving to SDL-1.1.7?

i’ve got my SDL.dll compiled against the directx7 sdk. the problem
is then when a user runs that dll on a machine with only directx5
SDL will bail out with an error saying directx needs to be upgraded.

this is certainly a good error message and all, but i think it
would be a lot better for the DX5_Available to be changed to
detect if directx will work at all, and if not report no so we
can automatically drop down to the windib driver.
the only case where sdl will not run (yet report a good error)
is when SDL is compiled with directx7 but run with directx5.
(there might be others, but this is the one my users are finding)

the workaround for this isn’t too hard. i’m telling users to either
upgrade directx, or set the SDL_VIDEODRIVER to “windib”. Both these
solutions get things running easy enough, but again it would seem
best to automatically fallback to windib (like NT does so well)

the solution would be to change the DX5_Available to check that
the directx version installed is at least as high as the directx
version SDL was compiled with.

after looking at the code i feel i could write this easily
enough and get the patch in tonight if it would help. does this
sound like the correct solution?

hmm, after more thought, i think an even better solution would
be to change the directinput and directsound to only request
directx version 5. i’m sure we’re not using sound and input
routines that are locked to directx7. this would mean just
changing the directx api defines in video/windx5/directx.h:72
#define DIRECTDRAW_VERSION 0x0700
#define DIRECTSOUND_VERSION 0x0500
#define DIRECTINPUT_VERSION 0x0500

(this assumes directx allows you to mix and match interfaces
like this, which would seem possible, but you never know with directx)