0.9.31 not suitable for gaming

[Pavel Troller]

Hi!
  I've tried 0.9.31 and it seems that there is a regression in at least two
games:
  - Fallout Tactics (BOS.exe): Shows a dialog stating
"C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**:
Could not create display buffers"
and then another one about abnormal termination of the program and quits.
  - Steam based games, mainly HL2: During game load, the screen goes black.
Moving the cursor causes sound effects as it hovers across the menus and
buttons, so the program runs, but nothing can be seen.
  Both those games are known to work with wine at about a half between .29
and .30. 
  I tried it with basic .31 as well as with today's git update.
  Are those regressions known and is it a work in progress, or should I make
a bisecting session to find the problem ?
            With regards, Pavel Troller

[H. Verbeet]

On 20/02/07, Pavel Troller <patrol(a)sinus.cz> wrote:
> Hi!
>   I've tried 0.9.31 and it seems that there is a regression in at least two
> games:
>   - Fallout Tactics (BOS.exe): Shows a dialog stating
> "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**:
> Could not create display buffers"
> and then another one about abnormal termination of the program and quits.
>   - Steam based games, mainly HL2: During game load, the screen goes black.
> Moving the cursor causes sound effects as it hovers across the menus and
> buttons, so the program runs, but nothing can be seen.
>   Both those games are known to work with wine at about a half between .29
> and .30.
>   I tried it with basic .31 as well as with today's git update.
>   Are those regressions known and is it a work in progress, or should I make
> a bisecting session to find the problem ?
>             With regards, Pavel Troller

It's a bit unfortunate that right before the release a couple of
regressions appear to have crept in. I think that at least the one in
HL2/CSS is supposed to be fixed in current git, so if it isn't it
probably makes sense to do a regression test.

[Stefan Dösinger]

Am Dienstag 20 Februar 2007 06:37 schrieb Pavel Troller:
> - Steam based games, mainly HL2: During game load, the screen goes black.
> Moving the cursor causes sound effects as it hovers across the menus and
> buttons, so the program runs, but nothing can be seen.
> This regression is known, and it should be fixed already. It was caused by my 
> patch which made wined3d return an error if an unsupported query is created, 
> like windows does. Wine does not support event queries, but many apps expect 
> them to be supported. I have sent another patch(committed already) that 
> re-enables the fake event queries.
> - Fallout Tactics (BOS.exe): Shows a dialog stating
> "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**:
> Could not create display buffers"
> and then another one about abnormal termination of the program and quits.
> I don't know about this regression. Can you do a bisect?

[Pavel Troller]

Hi!
> Am Dienstag 20 Februar 2007 06:37 schrieb Pavel Troller:
> > - Steam based games, mainly HL2: During game load, the screen goes black.
> > Moving the cursor causes sound effects as it hovers across the menus and
> > buttons, so the program runs, but nothing can be seen.
> > This regression is known, and it should be fixed already. It was caused by my 
> > patch which made wined3d return an error if an unsupported query is created, 
> > like windows does. Wine does not support event queries, but many apps expect 
> > them to be supported. I have sent another patch(committed already) that 
> > re-enables the fake event queries.
> > OK. This bug seems to be really fixed, but the game crashes later (during the
> > startup of the "real" game, after all the selections). It crashes in its own
> > code (called "Engine") but ntdll and kernel32 are visible in the backtrace.
> > I can send it exactly if it helps. I don't know how to bisect this crash
> > because the one initially mentioned is "masking" it.
> > - Fallout Tactics (BOS.exe): Shows a dialog stating
> > "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**:
> > Could not create display buffers"
> > and then another one about abnormal termination of the program and quits.
> > I don't know about this regression. Can you do a bisect?

Yes, done. It's the following commit:

commit 388499ff28616ef03bf8949a78e658e1bdb4e4fc
Author: Stefan DĂśsinger <stefan(a)codeweavers.com>
Date:   Wed Feb 14 17:59:08 2007 +0100

    wined3d: More fullscreen window fixes.
    
The game is run in a virtual desktop (i.e. it appears in the Linux window, not
in full screen).

                    With regards, Pavel Troller

[Stefan Dösinger]

Am Dienstag 20 Februar 2007 21:55 schrieb Pavel Troller:
> Hi!
> > Am Dienstag 20 Februar 2007 06:37 schrieb Pavel Troller:
> > > - Steam based games, mainly HL2: During game load, the screen goes
> > > black. Moving the cursor causes sound effects as it hovers across the
> > > menus and buttons, so the program runs, but nothing can be seen.
> >
> > This regression is known, and it should be fixed already. It was caused
> > by my patch which made wined3d return an error if an unsupported query is
> > created, like windows does. Wine does not support event queries, but many
> > apps expect them to be supported. I have sent another patch(committed
> > already) that re-enables the fake event queries.
>
> OK. This bug seems to be really fixed, but the game crashes later (during
> the startup of the "real" game, after all the selections). It crashes in
> its own code (called "Engine") but ntdll and kernel32 are visible in the
> backtrace. I can send it exactly if it helps. I don't know how to bisect
> this crash because the one initially mentioned is "masking" it.
> Yeah, I've introduced a new regression right after fixing the last one :-) 
> Today's patches should fix it(and maybe bring a new breakage)
> > > - Fallout Tactics (BOS.exe): Shows a dialog stating
> > > "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**:
> > > Could not create display buffers"
> > > and then another one about abnormal termination of the program and
> > > quits.
> >
> > I don't know about this regression. Can you do a bisect?
>
> Yes, done. It's the following commit:
>
> commit 388499ff28616ef03bf8949a78e658e1bdb4e4fc
> Author: Stefan DĂśsinger <stefan(a)codeweavers.com>
> Date:   Wed Feb 14 17:59:08 2007 +0100
>
> wined3d: More fullscreen window fixes.
>
> The game is run in a virtual desktop (i.e. it appears in the Linux window,
> not in full screen).
> That is strange. Can you send be a +ddraw,+d3d8,+d3d9,+d3d trace?

[Pavel Troller]

> > > I don't know about this regression. Can you do a bisect?
> >
> > Yes, done. It's the following commit:
> >
> > commit 388499ff28616ef03bf8949a78e658e1bdb4e4fc
> > Author: Stefan DĂśsinger <stefan(a)codeweavers.com>
> > Date:   Wed Feb 14 17:59:08 2007 +0100
> >
> > wined3d: More fullscreen window fixes.
> >
> > The game is run in a virtual desktop (i.e. it appears in the Linux window,
> > not in full screen).
> > That is strange. Can you send be a +ddraw,+d3d8,+d3d9,+d3d trace?
> > OK, did it. Sending two traces: A bad one, and a good one made by wine just 
> > before the above commit. 
> >                       With regards, Pavel Troller
>

[Stefan Dösinger]

> OK, did it. Sending two traces: A bad one, and a good one made by wine just
> before the above commit.
>                       With regards, Pavel Troller
> trace:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow Old style was
> 90000000,00000008, setting to 90080000,00000008
> trace:ddraw:IDirectDrawImpl_FlipToGDISurface (0x19daf8) 
> This here seems strange. If you compare that to the good log you'll see that 
> IWineD3DDeviceImpl_Init3D was left way to early. As there is no ERR about a 
> possible reason for the abortion I think that somewhere an exception is 
> thrown, caught by the game which terminates afterwards.

You can do the following:
-> Run the game in winedbg and see if it catches the execption and gives a 
backtrace and crash position
-> Add some extra traces(or ERRs) to Init3D and its subfunctions to catch the 
last line that is exectuted successfully.

[Pavel Troller]

> > trace:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow Old style was
> > 90000000,00000008, setting to 90080000,00000008
> > trace:ddraw:IDirectDrawImpl_FlipToGDISurface (0x19daf8) 
> > This here seems strange. If you compare that to the good log you'll see that 
> > IWineD3DDeviceImpl_Init3D was left way to early. As there is no ERR about a 
> > possible reason for the abortion I think that somewhere an exception is 
> > thrown, caught by the game which terminates afterwards.

Doesn't seem so. See below.
> You can do the following:
> -> Run the game in winedbg and see if it catches the execption and gives a 
> backtrace and crash position

There is no such exception, at least winedbg doesn't catch any. Is a special
action (command etc.)
> -> Add some extra traces(or ERRs) to Init3D and its subfunctions to catch the 
> last line that is exectuted successfully.
> Hmm... I added some traces to device.c. We know that last known trace from
> Init3D in the bad case is "Creating implicit swapchain."
> I added a new trace here:

/* Setup the implicit swapchain */
    TRACE("Creating implicit swapchain\n");
    if (D3D_OK != D3DCB_CreateAdditionalSwapChain((IUnknown *) This->parent, pPresentationParameters, (IWineD3DSwapChain **)&swapchain) || swapchain == NULL) {
        WARN("Failed to create implicit swapchain\n");
        return WINED3DERR_INVALIDCALL;
    }
    TRACE("1674\n");

(it's on line 1674) and this one was NOT reached.
I'm a bit confusd because I failed to find the code for
D3DCB_CreateAdditionalSwapChain(), I found only its call in device.c and its
definition in wined3d_interface.h.
  So, what to do next ?
                     With regards, Pavel Troller

[Pavel Troller]

> > You can do the following:
> > -> Run the game in winedbg and see if it catches the execption and gives a 
> > backtrace and crash position
> > There is no such exception, at least winedbg doesn't catch any. Is a special
> > action (command etc.) 
> > Oops. Unfinished mail sent. I meant:
> > Is a special action (command etc.) necessary to enable exception catching
> > in winedbg ?
> >         Pavel

[H. Verbeet]

On 21/02/07, Pavel Troller <patrol(a)sinus.cz> wrote:
> I'm a bit confusd because I failed to find the code for
> D3DCB_CreateAdditionalSwapChain(), I found only its call in device.c and its
> definition in wined3d_interface.h.
> That's D3D7CB_CreateAdditionalSwapChain() in dlls/ddraw/ddraw.c

[Pavel Troller]

> On 21/02/07, Pavel Troller <patrol(a)sinus.cz> wrote:
> > I'm a bit confusd because I failed to find the code for
> > D3DCB_CreateAdditionalSwapChain(), I found only its call in device.c and 
> > its
> > definition in wined3d_interface.h.
> > That's D3D7CB_CreateAdditionalSwapChain() in dlls/ddraw/ddraw.c

Hi!
  OK, thanks, found it now.
  I've modified its code by inserting many traces:

{
    ICOM_THIS_FROM(IDirectDrawImpl, IDirectDraw7, device);
    IParentImpl *object = NULL;
    HRESULT res = D3D_OK;
    IWineD3DSwapChain *swapchain;
    TRACE("(%p) call back\n", device);
    TRACE("$$$$ 2672\n");
    object = HeapAlloc(GetProcessHeap(),  HEAP_ZERO_MEMORY, sizeof(IParentImpl));
    TRACE("$$$$ 2674\n");
    if (NULL == object)
    {
        FIXME("Allocation of memory failed\n");
        *ppSwapChain = NULL;
        return DDERR_OUTOFVIDEOMEMORY;
    }
    TRACE("$$$$ 2681\n");
    ICOM_INIT_INTERFACE(object, IParent, IParent_Vtbl);
    TRACE("$$$$ 2683\n");
    object->ref = 1;

    res = IWineD3DDevice_CreateAdditionalSwapChain(This->wineD3DDevice,
                                                   pPresentationParameters,
                                                   &swapchain,
                                                   (IUnknown*) ICOM_INTERFACE(object, IParent),
                                                   D3D7CB_CreateRenderTarget,
                                                   D3D7CB_CreateDepthStencilSurface);
    TRACE("$$$$ 2692\n");
    if (res != D3D_OK)
    {
        FIXME("(%p) call to IWineD3DDevice_CreateAdditionalSwapChain failed\n", This);
        HeapFree(GetProcessHeap(), 0 , object);
        *ppSwapChain = NULL;
    }
    else
    {
        TRACE("2701\n");
        *ppSwapChain = swapchain;
        object->child = (IUnknown *) swapchain;
    }
    TRACE("$$$$ Returning\n");
    return res;
}

  The last trace which appeared in the log is 2683, so
IWineD3DDevice_CreateAdditionalSwapChain() didn't return. I'm going bananas
from those names; where the hell this one grows :-) ? grep, as obvious, shows
its calls only.
                  With regards, Pavel Troller

[H. Verbeet]

On 21/02/07, Pavel Troller <patrol(a)sinus.cz> wrote:
> The last trace which appeared in the log is 2683, so
> IWineD3DDevice_CreateAdditionalSwapChain() didn't return. I'm going bananas
> from those names; where the hell this one grows :-) ? grep, as obvious, shows
> its calls only.
> IWineD3DDeviceImpl_CreateAdditionalSwapChain() in dlls/wined3d/device.c.
> IWineD3DDevice_CreateAdditionalSwapChain is actually a macro defined
> in include/wine/wined3d_interface.h.

[Pavel Troller]

> On 21/02/07, Pavel Troller <patrol(a)sinus.cz> wrote:
> > The last trace which appeared in the log is 2683, so
> > IWineD3DDevice_CreateAdditionalSwapChain() didn't return. I'm going bananas
> > from those names; where the hell this one grows :-) ? grep, as obvious, 
> > shows
> > its calls only.
> > IWineD3DDeviceImpl_CreateAdditionalSwapChain() in dlls/wined3d/device.c.
> > IWineD3DDevice_CreateAdditionalSwapChain is actually a macro defined
> > in include/wine/wined3d_interface.h.

Thanks,
  traced a few calls deeper. Now I'm standing at

static void WINAPI IWineD3DDeviceImpl_SetupFullscreenWindow(IWineD3DDevice *iface, HWND window) {
    IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;

    LONG style, exStyle;
    /* Don't do anything if an original style is stored.
     * That shouldn't happen
     */
    TRACE("(%p): Setting up window %p for exclusive mode\n", This, window);
    if (This->style || This->exStyle) {
        ERR("(%p): Want to change the window parameters of HWND %p, but "
            "another style is stored for restoration afterwards\n", This, window);
    }

    /* Get the parameters and save them */
    style = GetWindowLongW(window, GWL_STYLE);
    exStyle = GetWindowLongW(window, GWL_EXSTYLE);
    This->style = style;
    This->exStyle = exStyle;

    /* Filter out window decorations */
    style &= ~WS_CAPTION;
    style &= ~WS_THICKFRAME;
    exStyle &= ~WS_EX_WINDOWEDGE;
    exStyle &= ~WS_EX_CLIENTEDGE;

    /* Make sure the window is managed, otherwise we won't get keyboard input */
    style |= WS_POPUP | WS_SYSMENU;

    TRACE("Old style was %08x,%08x, setting to %08x,%08x\n",
          This->style, This->exStyle, style, exStyle);
TRACE("1184\n");
    SetWindowLongW(window, GWL_STYLE, style);
    SetWindowLongW(window, GWL_EXSTYLE, exStyle);
TRACE("1187\n");
    /* Inform the window about the update. */
    SetWindowPos(window, HWND_TOP, 0, 0,
            This->ddraw_width, This->ddraw_height, SWP_FRAMECHANGED);
TRACE("1191\n");
    ShowWindow(window, TRUE);
TRACE("1193\n");
}

The last trace executed is 1187, which looks that SetWindowPos doesn't return.
Should I trace even more deep, or is anybody getting an idea, what can be wrong
here ?
  Where is SetWindowPos located ?

                  With regards, Pavel Troller

[Pavel Troller]

> > On 21/02/07, Pavel Troller <patrol(a)sinus.cz> wrote:
> > > The last trace which appeared in the log is 2683, so
> > > IWineD3DDevice_CreateAdditionalSwapChain() didn't return. I'm going bananas
> > > from those names; where the hell this one grows :-) ? grep, as obvious, 
> > > shows
> > > its calls only.
> > > IWineD3DDeviceImpl_CreateAdditionalSwapChain() in dlls/wined3d/device.c.
> > > IWineD3DDevice_CreateAdditionalSwapChain is actually a macro defined
> > > in include/wine/wined3d_interface.h.
>
> Thanks,
>   traced a few calls deeper. Now I'm standing at
>
> static void WINAPI IWineD3DDeviceImpl_SetupFullscreenWindow(IWineD3DDevice *iface, HWND window) {
>     IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;
>
> LONG style, exStyle;
>     /* Don't do anything if an original style is stored.
>      * That shouldn't happen
>      */
>     TRACE("(%p): Setting up window %p for exclusive mode\n", This, window);
>     if (This->style || This->exStyle) {
>         ERR("(%p): Want to change the window parameters of HWND %p, but "
>             "another style is stored for restoration afterwards\n", This, window);
>     }
>
> /* Get the parameters and save them */
>     style = GetWindowLongW(window, GWL_STYLE);
>     exStyle = GetWindowLongW(window, GWL_EXSTYLE);
>     This->style = style;
>     This->exStyle = exStyle;
>
> /* Filter out window decorations */
>     style &= ~WS_CAPTION;
>     style &= ~WS_THICKFRAME;
>     exStyle &= ~WS_EX_WINDOWEDGE;
>     exStyle &= ~WS_EX_CLIENTEDGE;
>
> /* Make sure the window is managed, otherwise we won't get keyboard input */
>     style |= WS_POPUP | WS_SYSMENU;
>
> TRACE("Old style was %08x,%08x, setting to %08x,%08x\n",
>           This->style, This->exStyle, style, exStyle);
> TRACE("1184\n");
>     SetWindowLongW(window, GWL_STYLE, style);
>     SetWindowLongW(window, GWL_EXSTYLE, exStyle);
> TRACE("1187\n");
>     /* Inform the window about the update. */
>     SetWindowPos(window, HWND_TOP, 0, 0,
>             This->ddraw_width, This->ddraw_height, SWP_FRAMECHANGED);
> TRACE("1191\n");
>     ShowWindow(window, TRUE);
> TRACE("1193\n");
> }
>
> The last trace executed is 1187, which looks that SetWindowPos doesn't return.
> Should I trace even more deep, or is anybody getting an idea, what can be wrong
> here ?
>   Where is SetWindowPos located ?
>
> With regards, Pavel Troller

Hi!
  Because I had to restore working wine, I did the following:
  1) Restored original files
  2) Pulled today's version
  3) Compiled and verified
  ... Fallout tactics still didn't start with the obvious symptoms.
  So I commented out the SetWindowPos() call in ..._SetupFullscreenWindow (on
lines 1251&2 of the today's source) and... voilla, the game starts and runs
perfectly. My son has verified it and didn't find any problems.
  Then he tried HL2 and it seems also fully functional.
  So... The bug is still there, but my workaround fixes it for me and I didn't
find any drawbacks (trying a lot of programs I'm using like IDA and some
special telco programs).
  Because I didn't read anything from Stefan for a while, I'll wait a bit more
and then I'll create a bugzilla record for it.
  Is it ok ?
 
                           With regards, Pavel Troller

[Stefan Dösinger]

Am Donnerstag 22 Februar 2007 15:04 schrieb Pavel Troller:
> So I commented out the SetWindowPos() call in ..._SetupFullscreenWindow
> (on lines 1251&2 of the today's source) and... voilla, the game starts and
> runs perfectly. My son has verified it and didn't find any problems.
> Yeah, the SetWindowPos isn't required for all games. One game that needs it is 
> Gothic 2.

It is strange that SetWindowPos crashed. Can you check that window is 
valid(i.e. not NULL)?

TRACE("window is %p\n", window);
> Because I didn't read anything from Stefan for a while, I'll wait a bit
> more and then I'll create a bugzilla record for it.
>   Is it ok ?
> I was away the last day on a small LAN party with friends, thats why I didn't 
> reply.

[Pavel Troller]

Hi!
> Am Donnerstag 22 Februar 2007 15:04 schrieb Pavel Troller:
> > So I commented out the SetWindowPos() call in ..._SetupFullscreenWindow
> > (on lines 1251&2 of the today's source) and... voilla, the game starts and
> > runs perfectly. My son has verified it and didn't find any problems.
> > Yeah, the SetWindowPos isn't required for all games. One game that needs it is 
> > Gothic 2.
>
> It is strange that SetWindowPos crashed. Can you check that window is 
> valid(i.e. not NULL)?
> And would it be possible that the immediately following ShowWindow(window, TRUE)
> wouldn't fail too ?
>
> TRACE("window is %p\n", window);
> > Because I didn't read anything from Stefan for a while, I'll wait a bit
> > more and then I'll create a bugzilla record for it.
> >   Is it ok ?
> > I was away the last day on a small LAN party with friends, thats why I didn't 
> > reply.
> > OK, never mind. I can continue debugging tonight, just now the machine is
> > occupied by my son and his friend :-). I will look at SetWindowPos(). Could you
> > tell me in which file its source is ?
> >                            With regards, Pavel Troller

[H. Verbeet]

On 22/02/07, Pavel Troller <patrol(a)sinus.cz> wrote:
> OK, never mind. I can continue debugging tonight, just now the machine is
> occupied by my son and his friend :-). I will look at SetWindowPos(). Could you
> tell me in which file its source is ?
> That's in dlls/user32/winpos.c, but I'm not sure how likely it is for
> the problem to be in there.

[Stefan Dösinger]

Am Donnerstag 22 Februar 2007 16:15 schrieb H. Verbeet:
> On 22/02/07, Pavel Troller <patrol(a)sinus.cz> wrote:
> > OK, never mind. I can continue debugging tonight, just now the machine is
> > occupied by my son and his friend :-). I will look at SetWindowPos().
> > Could you tell me in which file its source is ?
>
> That's in dlls/user32/winpos.c, but I'm not sure how likely it is for
> the problem to be in there.
> I do not think that the problem is in SetWindowPos. I think the problem is in 
> wined3d, either some bad parameter to SetWindowPos or maybe SetWindowPos 
> causes signals to be sent that native d3d does not send.

That said, this is a Direct3D7 application, where the window setup is done 
BEFORE creating the Direct3D device(which calls Init3D in wined3d). So I 
gather that SetupFullscreenWindow should not be called during Init3D in the 
d3d7 case because the window and fullscreen setting are not changed. Setting 
window parameters there may cause signals to be sent to the application that 
cause crashes in the app. So I think the question is why 
SetupFullscreenWindow is called at all.

[Stefan Dösinger]

Am Donnerstag 22 Februar 2007 16:46 schrieb Stefan Dösinger:
> That said, this is a Direct3D7 application, where the window setup is done
> BEFORE creating the Direct3D device(which calls Init3D in wined3d). So I
> gather that SetupFullscreenWindow should not be called during Init3D in the
> d3d7 case because the window and fullscreen setting are not changed.
> Setting window parameters there may cause signals to be sent to the
> application that cause crashes in the app. So I think the question is why
> SetupFullscreenWindow is called at all.
> I have to correct myself, Init3D is not called when the application creates 
> the Direct3DDevice7, it is called when a primary surface with 3D 
> capatiblities is created(or any caps when the opengl ddraw renderer is 
> selected).

[Detlef Riekenberg]

On Mi, 2007-02-21 at 20:31 +0100, Pavel Troller wrote:
> Where is SetWindowPos located ?

You can find a function with "findfunc"

detlef(a)p4:~/wine.cvs/src$ tools/findfunc SetWindowPos

dlls/user32/winpos.c:BOOL WINAPI SetWindowPos(
and also 
dlls/winex11.drv/winpos.c:BOOL X11DRV_SetWindowPos




-- 
 
By by ... Detlef