DirectX9 and Halflife2

[Roderick Colenbrander]

Hi all,

Today I have been doing some experiments with halflife2 and the game works
(atleast if launched through steam in my case) but there are some issues
which I tried to address.

The game uses the D3D9 Query mechanism (CreateQuery/Issue/GetData) to
retrieve status information. HL2 uses this all the time and because the
implementation is stubbed for the biggest part (and perhaps impossible to
fully implement) you see thousands of FIXMEs which reduce the performance
from a playable framerate to less than 1 fps. While looking into this issue
I (perhaps) found one or more bugs and second I need some assistance.

According to MSDN CreateQuery should be called with a NULL pointer to see if
the 'Type' in question is available. Halflife2 doesn't do this NULL pointer
check and passes a pointer. Further wine returns D3D_OK for unsupported
types which should be D3DERR_NOTAVAILABLE (wined3d's CreateQuery does this).
I expect this is wrong and can supply a patch for this yet. The reason you
see below.

When the Query mechanism isn't available halflife2 moves over to a different
backend (I think). Suddenly the screen becomes black and you see hundreds of
lines like this:
fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking to
surface surf@0x7fe1d810 usage(512)

I looked up the error and it seems UnlockRect isn't handling
D3DUSAGE_DYNAMIC but I don't have enough d3d/opengl knowledge to fix this
issue. I hope that someone can assist me with the UnlockRect (if it doesn't
take that much time) so that halflife2 works fine out of the box.

Regards,
Roderick

[Oliver Stieber]

Hi,
--- Roderick Colenbrander  wrote:
> Hi all,
>
> Today I have been doing some experiments with halflife2 and the game works
> (atleast if launched through steam in my case) but there are some issues
> which I tried to address.
>
> The game uses the D3D9 Query mechanism (CreateQuery/Issue/GetData) to
> retrieve status information. HL2 uses this all the time and because the
> implementation is stubbed for the biggest part (and perhaps impossible to
> fully implement) you see thousands of FIXMEs which reduce the performance
> from a playable framerate to less than 1 fps. While looking into this issue
> I (perhaps) found one or more bugs and second I need some assistance.

This patch should fix the problem with Queries 
http://www.winehq.org/pipermail/wine-devel/2005-October/041237.html
> When the Query mechanism isn't available halflife2 moves over to a different
> backend (I think). Suddenly the screen becomes black and you see hundreds of
> lines like this:
> fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking to
> surface surf@0x7fe1d810 usage(512)
>
> I looked up the error and it seems UnlockRect isn't handling
> D3DUSAGE_DYNAMIC but I don't have enough d3d/opengl knowledge to fix this
> issue. I hope that someone can assist me with the UnlockRect (if it doesn't
> take that much time) so that halflife2 works fine out of the box.

UnlockRect only manages Back/Front buffers. Texture updates are handled by
IWineD3DSurface_UpdateTexture. The FIXME's can be safely ignored.

Other people seem to have the game working OK 
e.g. http://bugs.winehq.org/show_bug.cgi?id=3253 show the game working a lot better.

If you report any problems you are having in the wines Bugzilla http://bugs.winehq.org I can take
a propper look at them for you.

Oliver.
> Regards,
> Roderick
>
> -- 
> Telefonieren Sie schon oder sparen Sie noch?
> NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie

___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

[Roderick Colenbrander]

> This patch should fix the problem with Queries
> http://www.winehq.org/pipermail/wine-devel/2005-October/041237.html

This patch is not the same as the problem for halflife2. In case ppQuery is 
NULL applications can detect if a certain query Type is supported. This 
should indeed fail for unsupported types. In case of halflife2 ppQuery isn't 
NULL and right D3D_OK is returned while it are unsupported types. Returning 
D3DERR_NOTAVAILABLE seems to be right to me. (the attached patch implements 
what I mean; the patch is on top of the other patch you showed me)

Second I believe CreateQuery of d3d9 isn't correct. MSDN states that ppQuery 
can be NULL as explained above. Right now d3d9's CreateQuery returns 
D3DERR_INVALIDCALL when ppQuery is NULL. Further I'm not sure if wined3d's 
CreateQuery is correctly called from d3d9 as ppQuery isn't passed to it but 
some other object which isn't NULL if I'm right.
> > When the Query mechanism isn't available halflife2 moves over to a
> > different backend (I think). Suddenly the screen becomes black and you
> > see hundreds of lines like this:
> > fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking to
> > surface surf@0x7fe1d810 usage(512)

When I let CreateQuery 'fail' as it should in my opinion for unsupported query 
types then halflife2 stops working. It prints those unlockrect lines and it 
seems to get out of video memory. I think the d3d bug stuff should be handled 
here and if it is correct, the hl2 breaking caused by patches like this 
should be handled in bugzilla.

Roderick

[Roderick Colenbrander]

> Second I believe CreateQuery of d3d9 isn't correct. MSDN states that
> ppQuery can be NULL as explained above. Right now d3d9's CreateQuery
> returns D3DERR_INVALIDCALL when ppQuery is NULL. Further I'm not sure if
> wined3d's CreateQuery is correctly called from d3d9 as ppQuery isn't passed
> to it but some other object which isn't NULL if I'm right.

The call to wined3d from d3d9 is correct, didn't look well for all different 
datatypes and pointer tricks. Then only the 'NULL=ppQuery' line is wrong in 
d3d9's CreateQuery.

Roderick

[Roderick Colenbrander]

Ignore my black screen comment aswell. The cause for it is likely some memory 
corruption caused by my D3DERR_NOTAVAILABLE which isn't correct. Will submit 
a small patch for the d3d9 CreateQuery bug and will look at other parts.

The reason I was looking into all this is that the performance of hl2 (atleast 
in the menus) is greatly reduced by all the FIXME's printed by GetData / 
Issue. As this makes the game unusable is it perhaps an option to turn it 
into a TRACE? Normally I don't like covering bugs like this but I think it is 
a different case when an application because unusable because of FIXMEs. Most 
users don't know anything about this. The same is the case for 
drawStridedSlow which is used in lots of cases aswell.

Roderick

[Michael Stefaniuc]

Roderick Colenbrander wrote:
> Ignore my black screen comment aswell. The cause for it is likely some memory 
> corruption caused by my D3DERR_NOTAVAILABLE which isn't correct. Will submit 
> a small patch for the d3d9 CreateQuery bug and will look at other parts.
>
> The reason I was looking into all this is that the performance of hl2 (atleast 
> in the menus) is greatly reduced by all the FIXME's printed by GetData / 
> Issue. As this makes the game unusable is it perhaps an option to turn it 
> into a TRACE? Normally I don't like covering bugs like this but I think it is 
> a different case when an application because unusable because of FIXMEs. Most

You can implement a counter and print only the first 10 times the FIXMEs 
  and then you ignore them. It was done already in a couple of places in 
Wine.
> users don't know anything about this. The same is the case for 
> drawStridedSlow which is used in lots of cases aswell.

bye
    michael

[Stefan Dösinger]

Hello,
> The reason I was looking into all this is that the performance of hl2
> (atleast in the menus) is greatly reduced by all the FIXME's printed by
> GetData / Issue. As this makes the game unusable is it perhaps an option to
> turn it into a TRACE? Normally I don't like covering bugs like this but I
> think it is a different case when an application because unusable because
> of FIXMEs. Most users don't know anything about this. The same is the case
> for
> drawStridedSlow which is used in lots of cases aswell.

What happens if you use WINEDEBUG=-all wine ... or wine something.exe 
2> /dev/null ?

[Ivan Gyurdiev]

Roderick Colenbrander wrote:
> Hi all,
>
> Today I have been doing some experiments with halflife2 and the game works
> (atleast if launched through steam in my case) but there are some issues
> which I tried to address.

How is it that you are able to get Steam to work?

You don't run into:
http://bugs.winehq.org/show_bug.cgi?id=3293

Do you use any native dlls?

[Roderick Colenbrander]

> How is it that you are able to get Steam to work?
>
> You don't run into:
> http://bugs.winehq.org/show_bug.cgi?id=3293
>
> Do you use any native dlls?

Regarding steam I'm using a native shlwapi and shdocvw for the rest all 
native.

Roderick

[Ivan Gyurdiev]

Roderick Colenbrander wrote:
> > How is it that you are able to get Steam to work?
> >
> > You don't run into:
> > http://bugs.winehq.org/show_bug.cgi?id=3293
> >
> > Do you use any native dlls?
>
> Regarding steam I'm using a native shlwapi and shdocvw for the rest all 
> native.

Strange... I can't get it to work even w/ native shlwapi/shdocvw - it 
runs into the exact same bug...

[Vitaliy Margolen]

Monday, October 24, 2005, 5:19:43 PM, Ivan Gyurdiev wrote:
> Roderick Colenbrander wrote:
> > > How is it that you are able to get Steam to work?
> > >
> > > You don't run into:
> > > http://bugs.winehq.org/show_bug.cgi?id=3293
> > >
> > > Do you use any native dlls?
> >
> > Regarding steam I'm using a native shlwapi and shdocvw for the rest all 
> > native.
>
> Strange... I can't get it to work even w/ native shlwapi/shdocvw - it 
> runs into the exact same bug...

If it stops for you while it upgrades itself (on 26%-27%). Then just kill wine
and restart steam. Eventually it will restart itself and continue from point
where it crashed.

Vitaliy

[Ivan Gyurdiev]

> If it stops for you while it upgrades itself (on 26%-27%). Then just kill wine
> and restart steam. Eventually it will restart itself and continue from point
> where it crashed.

That's a different bug...which, by the way was closed FIXED, and now I 
don't think it was FIXED anymore - I ran into the same problem recently. 
I am considering reopening it, but I will not do so, until it's 
consistently reproducible:
http://bugs.winehq.org/show_bug.cgi?id=3084

The bug I am referring to, that prevents steam from running is:
http://bugs.winehq.org/show_bug.cgi?id=3293

[Evil]

I gave Counter-Strike: Source a try under WINE tonight to see what kind
of results I get on my system (ATI9600XT w8.18 drivers, AMD2000+).  It
was a pre-existing install that I had set up to run under both Windows
98 and Cedega.

After overriding the necessary DLLs, Steam gets past the logon...  I'm
not seeing the HTML in the news tab for some reason, even though I have
IE6 working, but it's not a big deal.

I next had to update the DirectX version in my registry, to stop the
"You must have the latest version of Microsoft DirectX(r) installed to
run ..." message.

At first, I got no sound, but that was fixed by changing audio to
"Emulated" in WineCfg.  Setting it to "No Sound" appears to cause the
games to dump at startup.

Now, my problem is that the video test is running about 1 frame every
two seconds.  I was getting 24fps under Cedega, so I know WINE can
probably do a lot better than it is with some tweaking.  I've tried
changing all kinds of parameters in WINE tonight, and in the game
options but saw no significant speed increase.  I see no real
performance difference when running fullscreen vs. windowed.

Frankly, I was just amazed to see the game start and look as good as it
does - even if it's not at a playable speed yet.  Kudos to the guys
working on the DX emulation!

-Jesse

Ivan Gyurdiev wrote:
> The bug I am referring to, that prevents steam from running is:
> http://bugs.winehq.org/show_bug.cgi?id=3293

[Ivan Gyurdiev]

> > The bug I am referring to, that prevents steam from running is:
> > http://bugs.winehq.org/show_bug.cgi?id=3293

Hmm..... it looks like

---> CALL

0011:Call kernel32.VirtualAlloc(00800000,00002000,00001000,00000004) 
ret=20d13a13
0011:Call 
ntdll.NtAllocateVirtualMemory(ffffffff,7fcae0fc,00000000,7fcae114,00001000,00000004) 
ret=201ce723
0011:Ret  ntdll.NtAllocateVirtualMemory() retval=c0000019 ret=201ce723
0011:Call ntdll.RtlNtStatusToDosError(c0000019) ret=201ce72d
0011:Ret  ntdll.RtlNtStatusToDosError() retval=000001e7 ret=201ce72d
0011:Ret  kernel32.VirtualAlloc() retval=00000000 ret=20d13a13

returns: STATUS_NOT_MAPPED_VIEW

Then an exception is thrown, dbghelp is loaded, and things get bad from 
there....

[Fabian Bieler]

For me steam works if I use transgaming's mozcontrol with wine:
http://downloads.transgaming.com/mozilla_control_downloads/
(freely available under the MPL)
However it is somewhat unstable.

Fabian

On Tuesday 25 October 2005 01:19, Ivan Gyurdiev wrote:
> Roderick Colenbrander wrote:
> > > How is it that you are able to get Steam to work?
> > >
> > > You don't run into:
> > > http://bugs.winehq.org/show_bug.cgi?id=3293
> > >
> > > Do you use any native dlls?
> >
> > Regarding steam I'm using a native shlwapi and shdocvw for the rest all
> > native.
>
> Strange... I can't get it to work even w/ native shlwapi/shdocvw - it
> runs into the exact same bug...