Hi there, I'm using SlimDX on Vista in conjunction with multiple swap chains to render to different Windows Form controls. That works really nice :) The problem is that after a LostDevice (like when pressing CTRL+ALT+DEL) I'm unable to recover from the lost device. What I do is:

        try
        {
          Data.SwapChain.Present(Present.None);
        }
        catch (Direct3D9Exception)
        {
          _DeviceLost = true;
        }

The problem is that it dies somewhere in ntdll.dll, when calling Present(), so it doesn't even come to the exception handler. The debug runtime says: Direct3D9: (INFO) :Failed to create driver indexbuffer Direct3D9: (ERROR) :Lost due to display uniqueness change (Thats the last before it crashes) And on a second try I got this instead of the first one (no code change): Direct3D9: (INFO) :Failed to create driver indexbuffer Direct3D9: (ERROR) :BitBlt or StretchBlt failed in Present One note: There is a second D3D device at that time active (but not controlled by me, rendering to a seperate window in the same application) I hope someone has an idea, my searches didn't turn out lucky :) Thanks, Marc

Yes I found that thread, but I couldn't find a solution from it,
I didn't find a way to create a device in SlimDX via IDirect3DDevice9Ex.
(Or simply a flag stating to create a device using the Direct3D 9 Extensions for Vista)

Marc

Unless somebody added it without my noticing (which is entirely possible), we don't have D3D9Ex support in SlimDX yet.

I just checked out the svn version of SlimDX and hacked the creation
of the Ex D3D in, and now it doesn't crash in Present and I can continue
with my LostDevice handling.

(Now all swap chains are NULL on creation, but I try to sort that out.)

I'm not that involved with D3D9Ex stuff and Vista but if there is no other
difference than Direct3DCreate9Ex( D3D_SDK_VERSION, &direct3D ); instead of the
previous one, it may be viable to choose that depending on a #if on
the WINVER ?


Marc

No, that would be a compile-time decision and then we'd need to ship different .dlls for different platforms, which is a non-starter.

D3D9Ex only runs on Vista, so your program is now Vista-only.

Oops, I forgot something:

I meant more in the direction with the compile time check
in combination with a flag for the initialization, so you could choose
to use D3D9Ex, but only on Vista. (And on XP the flag has no effect)

Something like that would be nice because not having that is unfortunately a
real show stopper on Vista.

Marc

The way we would likely implement the Ex functionality is via a new device type, so that you obtain a DeviceEx or suitable (ideally with a better name) rather than a Device.

The action of creating a new D3D9Ex device should fail on XP, with an exception. It shouldn't silently do nothing.

As Promit said, D3D9Ex support isn't that hard for us to add so we can probably do it pretty quickly. However, I agree with Promit that the solution you've chosen and the solution presented in that linked thread seem horribly sub-optimal. I'm not convinced that using D3D9Ex is required here, to fix this issue. As you can see, D3D9Ex doesn't bring a whole lot to the table... I would be hesitant to call it a showstopper.