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(a)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 -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
Hi, --- Roderick Colenbrander <thunderbird2k(a)gmx.net> 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(a)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
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(a)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
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
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
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 -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart
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 ?
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?
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
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...
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
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
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
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....
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...
participants (8)
-
Evil -
Fabian Bieler -
Ivan Gyurdiev -
Michael Stefaniuc -
Oliver Stieber -
Roderick Colenbrander -
Stefan Dösinger -
Vitaliy Margolen