ddraw / wined3d fighting over the resolution!

[Peter Dons Tychsen]

Hi Stefan/Devs.

The funny old game "Insane" has a resolution bug when it exits.
I am not sure exactly how to fix this.

1) It call SetDisplayMode() - switches from 1280 x 1024 -> 640 x 480.
OK.
2) It creates a 3D surface which starts the SwapChain - swapchain saves
current resolution.
3) Exit. It calls RestoreDisplayMode() - switches back to 1280 x 1024.
OK.
4) SwapChain is destroyed. Switches "back" to 640 x 480 ! BAD!

I presume the code guesses that the caller does this in another sequence
(and it does work fine in other sequences).

Why does the SwapChain-destroy function play around with the resolution
at all. Is that really necessary? I think it should not do it if the
caller is ddraw at least.

How do i fix this?

Thanks,

/pedro

[Stefan Dösinger]

Am Donnerstag, 14. Februar 2008 04:22:16 schrieb Peter Dons Tychsen:
> Why does the SwapChain-destroy function play around with the resolution
> at all. Is that really necessary? I think it should not do it if the
> caller is ddraw at least.
> I thought I'm filtering this out in the case of ddraw, but maybe that got 
> lost. The reason why the swapchain restores the resolution is the different 
> way ddraw/d3d8 and d3d8/d3d9 set up the screen.

In ddraw the app calls IDirectDraw7::SetDisplayMode. This sets the mode. Then 
it creates a DDSCAPS_PRIMARYSURFACE surface, which creates the swapchain.

In d3d8/d3d9 the swapchain controls the video mode

I think the problem is that RestoreDisplayMode is called before the primary 
surface is destroyed. The question is why this happens. I can think of the 
following reasons:

-> Refcounting problem, or the app just doesn't release the surfaces. Then 
ddraw.dll destroys the objects on DLL_PROCESS_DETACH

-> The app calls it that way. This needs a test, but I think it is not allowed 
to call SetDisplayMode / RestoreDisplayMode while a primary surface is around