Hello S.
I have studied this a bit more. The app seems to do this purposely.
In any case wined3d should not change the mode in this case. Either wined3d must detect this, or the code should be moved into d3d8/d3d9.
On a similar note, i found i found a funny "RestoreDisplayMode()" call in "SetCooperateLevel()", when switching from full-screen. I tested with win-xp, and here this does not happen. This causes additional mode-switch flicker.
I think i will chew on some nice German wine-gums (Haribo), and then send some patches :-). mmmmmm.... wine-gums.... they should sell them on wine.org... would be appropriate... :-)
/p
On Thu, 2008-02-14 at 09:18 +0100, Stefan Dösinger wrote:
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