http://bugs.winehq.org/show_bug.cgi?id=10992
Summary: Sacred: Crashes on enter in wine 0.9.52 Product: Wine Version: 0.9.52. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: legine@gmx.net
Created an attachment (id=9956) --> (http://bugs.winehq.org/attachment.cgi?id=9956) Error output on cli
With update to Wine 0.9.52 Sacred is crashing when starting the game.It works with wine 0.9.49 at least, have not checked later ones... (will do when time)
I would supply all data needed if someone can tell what to do.
atached snipplet from default output.
http://bugs.winehq.org/show_bug.cgi?id=10992
Vijay Kamuju infyquest@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal
--- Comment #1 from Vijay Kamuju infyquest@gmail.com 2008-01-01 13:53:01 --- please do regression test, to find which patch broke the game
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #2 from Peter Kovacs legine@gmx.net 2008-01-02 04:40:58 --- I checked now wine version 0.9.51 And there the game starts. So something in 0.9.52 breaks Sacred.
Anything more I can provide
http://bugs.winehq.org/show_bug.cgi?id=10992
Rico kgbricola@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kgbricola@web.de
--- Comment #3 from Rico kgbricola@web.de 2008-01-02 11:16:21 --- Yes, please do a full regression test. It's described here: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=10992
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
--- Comment #4 from Lei Zhang thestig@google.com 2008-01-02 15:31:22 --- Does the demo have the same problem?
http://www.download.com/Sacred-Demo/3000-7537_4-10264157.html
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #5 from Peter Kovacs legine@gmx.net 2008-01-02 16:01:17 --- I dont know. But I would guess so. It looks like a d3d Problem. As you can see from the Error Message. By the way which is always the same.
You will be able to start the game but as soon as you enter the gameworld with a Character the game crashes hard.
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #6 from Peter Kovacs legine@gmx.net 2008-01-02 17:24:30 --- Okay I did a regression test. Thought The Howto is a bit rough so I hope you can use the following info:
command used: git bisect log git-bisect start 'dlls/wined3d' # good: [0e7ca5863c4b4fd4df1275bde3809fae31cd39f6] Release 0.9.51. git-bisect good 0e7ca5863c4b4fd4df1275bde3809fae31cd39f6 # bad: [c03617509409fb5a1f8528c6f927c0bc7ed9d2ae] Release 0.9.52. git-bisect bad c03617509409fb5a1f8528c6f927c0bc7ed9d2ae # bad: [b83dc6bbf635f96f8afba19fa9713d15d833d942] wined3d: Move the GL info structure into the adapter. git-bisect bad b83dc6bbf635f96f8afba19fa9713d15d833d942 # bad: [7a1d35e513d75ec0f86b48418d8b4e6235e8dc19] wined3d: Emulate half float vertices if GL_NV_half_float is not there. git-bisect bad 7a1d35e513d75ec0f86b48418d8b4e6235e8dc19
command used: git bisect good Bisecting: 1 revisions left to test after this [83c0b13c5b2bf710542f365b6aa876b103a46147] wined3d: Split up the render target -> render target blit.
I hope that helps. Tell me if you need more Infos.
If I find time I check if that bug applies to the Demo too
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #7 from Austin English austinenglish@gmail.com 2008-01-02 17:42:45 --- (In reply to comment #6)
Okay I did a regression test. Thought The Howto is a bit rough so I hope you can use the following info:
It's a wiki, so feel free to improve it. I wrote that one to improve the old developer oriented one, but if you have any ideas on how to make it better, please do so.
command used: git bisect good Bisecting: 1 revisions left to test after this [83c0b13c5b2bf710542f365b6aa876b103a46147] wined3d: Split up the render target -> render target blit.
You haven't finished the test. When you reach the bad patch, it'll say 'blank is the first bad patch.' Should just be one or two more compiles.
If I find time I check if that bug applies to the Demo too
Please do, that'll make it much easier for others to debug/verify.
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #8 from Peter Kovacs legine@gmx.net 2008-01-03 11:19:50 ---
It's a wiki, so feel free to improve it. I wrote that one to improve the old developer oriented one, but if you have any ideas on how to make it better, please do so.
I will do when I know more what I am doing.
You haven't finished the test. When you reach the bad patch, it'll say 'blank is the first bad patch.' Should just be one or two more compiles.
Hmm, yes you are right. It was quite late yesterday and lost a bit focus...
Hmpf, I did something wrong and did not called the git wine for testing. Is there a way to go back one step. Or do I have to start all over again :/ ?
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #9 from Austin English austinenglish@gmail.com 2008-01-03 12:03:38 --- (In reply to comment #8)
It's a wiki, so feel free to improve it. I wrote that one to improve the old developer oriented one, but if you have any ideas on how to make it better, please do so.
I will do when I know more what I am doing.
You haven't finished the test. When you reach the bad patch, it'll say 'blank is the first bad patch.' Should just be one or two more compiles.
Hmm, yes you are right. It was quite late yesterday and lost a bit focus...
Hmpf, I did something wrong and did not called the git wine for testing. Is there a way to go back one step. Or do I have to start all over again :/ ?
You can use $ git bisect log
to see what you did. Copy that to another file, then reissue those bisects in the same order, up to the point where you messed up.
http://bugs.winehq.org/show_bug.cgi?id=10992
Peter Kovacs legine@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #10 from Peter Kovacs legine@gmx.net 2008-01-05 08:39:33 --- So finished the Regression Test. :D
88f746ab0e7a10d33f67b36744dfb6d8b8281748 is first bad commit commit 88f746ab0e7a10d33f67b36744dfb6d8b8281748 Author: Stefan Dösinger stefan@codeweavers.com Date: Sat Dec 15 11:43:51 2007 +0100
wined3d: Filter out some shader compilation spam.
:040000 040000 5058c32fd5de64984eac7cfbcf4d9525472ac2a7 6c34b9fbc1dd729c9fee5766774728b6293e5fa3 Mdlls
I added Stefan Dösinger to the List.
I test next the Demo if the Bug appears there too.
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #11 from Peter Kovacs legine@gmx.net 2008-01-13 12:47:20 --- Okay the Demo Crashes too in version 0.9.52. (Just tried to run the Demo...)
I had trouble obtaining the Demo. (finding it ;) )
I am atm compiling wine 0.9.53 And I will do a retest.
Have Fun!
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #12 from Peter Kovacs legine@gmx.net 2008-01-13 17:15:38 --- Hello,
I tested the demo on version 0.9.53. Error seems to stay. Please confirm this or not so I can check.
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #13 from Rico kgbricola@web.de 2008-01-14 15:38:01 --- I've also done a regression test width the demo but width this result:
2d904495003f65a9fefb96eacf828617f3bb9c30 is first bad commit commit 2d904495003f65a9fefb96eacf828617f3bb9c30 Author: Stefan Dösinger stefan@codeweavers.com Date: Wed Dec 19 17:10:02 2007 +0100
wined3d: Fixed function vertex attribute types are flexible.
:040000 040000 7f3651a64e747332b2d23ed33d39506654278b22 8223ad7802700fdbf6f6c15e735825023a03f0bf M dlls
Could you try another regression test (at least try this one a3c2fb9e641158dc404ea1dbc32fd8b7cbb06ca6 if it works for you)?
I've a Geforce 8800GTS. What GPU do you have?
Could anyone confirm this?
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #14 from Peter Kovacs legine@gmx.net 2008-01-15 05:26:12 --- I'll repeat the regression test.
GPU is Nvidia 7600 GO or 7800 GO. (currently at work so not sure).
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #15 from Peter Kovacs legine@gmx.net 2008-01-16 16:10:50 ---
GPU is Nvidia 7600 GO or 7800 GO. (currently at work so not sure).
hmm it is a 7600 Go...
(In reply to comment #13)
I've also done a regression test width the demo but width this result:
2d904495003f65a9fefb96eacf828617f3bb9c30 is first bad commit commit 2d904495003f65a9fefb96eacf828617f3bb9c30 Author: Stefan Dösinger stefan@codeweavers.com Date: Wed Dec 19 17:10:02 2007 +0100
wined3d: Fixed function vertex attribute types are flexible.:040000 040000 7f3651a64e747332b2d23ed33d39506654278b22 8223ad7802700fdbf6f6c15e735825023a03f0bf M dlls
Could you try another regression test (at least try this one a3c2fb9e641158dc404ea1dbc32fd8b7cbb06ca6 if it works for you)?
I've a Geforce 8800GTS. What GPU do you have?
Could anyone confirm this?
I repeated the regression Test. And I did a mistake I found out... :P and the correct patch that caused this is what you found here. I tested on the Demo and on Sacred underworld v 2.28 same results.
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #16 from Rico kgbricola@web.de 2008-01-19 13:44:36 --- Created an attachment (id=10367) --> (http://bugs.winehq.org/attachment.cgi?id=10367) workaround
Here is a workaround for the crash in sacred. Could you try it?
This isn't a good patch, because I just tried a function and this works. Could anyone with more knowledge take a look at this? It shouldn't take so much time.
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #17 from Rico kgbricola@web.de 2008-02-10 04:11:44 --- @Peter Kovacs Could you try the workaround?
@Stefan Dösinger Is there a reason why some function have the invalid_func or is this just a missing implementation or isn't there a equivalent which does the same in OpenGL as DX need it? Here is the workaround to the question http://bugs.winehq.org/attachment.cgi?id=10367 which contains some of the invalid_func.
http://bugs.winehq.org/show_bug.cgi?id=10992
Rico kgbricola@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #10367|0 |1 is obsolete| |
--- Comment #18 from Rico kgbricola@web.de 2008-02-10 09:05:32 --- Created an attachment (id=10703) --> (http://bugs.winehq.org/attachment.cgi?id=10703) a better workaround for the invalid_func call
This patch should be better because the old one misinterpreted the colors.
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #19 from Peter Kovacs legine@gmx.net 2008-02-24 17:06:24 --- I am sorry that it took so long. But other more important things bugged me.
I checked now wine version 0.9.56 and the patch supplied on the git version 0.9.55.
1) 0.9.56 The bug still exist
2) 0.9.55 + patch That did work on the demo very well. It works for me ;) would be great if this patch finds its way into wine :)
http://bugs.winehq.org/show_bug.cgi?id=10992
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |stefandoesinger@gmx.at
--- Comment #20 from Stefan Dösinger stefandoesinger@gmx.at 2008-03-01 04:29:38 --- Using diffuse_d3dcolor for SHORT4 type formats is not correct. You should add a new function using glColor4sv or glColor4usv. If the patch produces the expected results, please write a test showing that WINED3DDECLTYPE_SHORT4 is treated as WINED3DDECLTYPE_D3DCOLOR in the fixed function pipeline(see dlls/d3d9/tests/visual.c)
Sorry for the late reply, I'm usually using stefandoesinger@gmx.at in bugzilla. The @codeweavers.com account was created for some testing and *should* be disabled.
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #21 from Peter Kovacs legine@gmx.net 2008-03-01 05:09:34 --- The email adress has been shown by git.
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #22 from Rico kgbricola@web.de 2008-03-04 12:51:23 --- Created an attachment (id=11114) --> (http://bugs.winehq.org/attachment.cgi?id=11114) try to write a test
Hi Stefan, i have tried to write a test, but I couldn't get it working correctly in windows. If I use D3DDECLTYPE_D3DCOLOR all is fine on both systems (wine and windows). If I use D3DDECLTYPE_SHORT4N (just a try because WINED3DDECLTYPE_SHORT4 didn't work) (the one which isn't commented out) the triangle is always black in wine. In windows it isn't shown!
Do you have any suggestions what went wrong?
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #23 from Rico kgbricola@web.de 2008-03-04 12:58:05 --- Created an attachment (id=11115) --> (http://bugs.winehq.org/attachment.cgi?id=11115) the executable compiled from my source
I attach this so that you easily can check what happen. The command is simply "d3d9_crosstest.exe virtual". I forgot to say ... I just want to find out which are the correct colors in windows (but the colors aren't shown).
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #24 from Rico kgbricola@web.de 2008-03-04 13:50:59 ---
The command is simply "d3d9_crosstest.exe virtual".
Sorry, this is wrong, it must be "d3d9_crosstest.exe visual"
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #25 from Stefan Dösinger stefandoesinger@gmx.at 2008-03-04 13:56:54 --- Check the return values the d3d calls. If e.g. drawPrimitiveUP returns an error that explains that the triangle isn't shown. If Windows returns an error we can return an error as well
As far as I could see, ATI cards return errors on most, but not all types, and Nvidia cards accept all types. If you can get a decent color on nvidia cards on Windows, then we're fine with implementing D3DDECLTYPE_SHORT4N fixed function colors. If both Nvidia and ATI return an error we have to return an error as well, but we don't have the infrastructure for passing an error out of state setters yet.
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #26 from Rico kgbricola@web.de 2008-03-04 14:53:41 ---
IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 1, tri1, sizeof(tri1[0]))
The return value in windows (SP2) is -2005530516 (0x0x8876086c) for D3DDECLTYPE_SHORT4N
The same return value (0x8876086c) is for the problematic on D3DDECLTYPE_SHORT4 (the one I try to fix)
I'll try it with d3d8 as soon as possible ... properly then windows return another value ... because I couldn't see the models in sacred anymore, when I just disabled the line in directx.c like this diffuse_funcs[WINED3DDECLTYPE_SHORT4] = (void *) nothing;
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #27 from Stefan Dösinger stefandoesinger@gmx.at 2008-03-04 16:06:36 --- This return value is D3DERR_INVALIDCALL. It's the general return value if something is wrong.
Does the game use ddraw.dll, d3d8.dll or d3d9.dll?
It might be possible as well that our d3d8.dll converts the d3d8 declaration incorrectly to the wined3d decl, or that there is some undocumented stuff when using them with the fixed function pipeline. In d3d8 there are no FVFs or Vertex Declarations like in d3d9. There are only vertex shaders, which in this case are 32 bit integers(HANDLEs). Shader handles smaller than the biggest possible FVF code are treated as an FVF code. Other shaders can be created using CreateVertexShaders. Shaders have a function and a declaration. If the function pointer is NULL, then the shader serves just as a declaration, similarly to a Direct3D9 vertex declaration.
My quick guess is that if there's a d3d8 shader without a function, then custom attribute types are ignored and d3d8 always uses the standard type for each usage type.(e.g. DCLUSAGE_COLOR -> D3DVSDT_D3DCOLOR, DCLUSAGE_POSITION -> FLOAT3, POSITIONT -> FLOAT4, etc)
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #28 from Rico kgbricola@web.de 2008-03-05 10:03:30 ---
Does the game use ddraw.dll, d3d8.dll or d3d9.dll?
Looks like it is using ddraw.dll. (just tried WINEDEBUG=+d3d7) -> d3d8/9 didn't produce any additional output.
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #29 from Stefan Dösinger stefandoesinger@gmx.at 2008-03-05 10:05:57 --- In that case the bug must be somewhere in ddraw's/wined3d's FVF->vertex declaration conversion, as D3D7 only supports D3DCOLOR colors. It doesn't offer any way to use SHORT4 attribs or similar.
See IDirect3DDevice7::SetFVF in dlls/ddraw/device.c. It calls a WineD3D helper function to create a wined3d vertex declaration that matches the FVF
http://bugs.winehq.org/show_bug.cgi?id=10992
Rico kgbricola@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #10703|0 |1 is obsolete| |
--- Comment #30 from Rico kgbricola@web.de 2008-03-05 11:27:32 --- Created an attachment (id=11127) --> (http://bugs.winehq.org/attachment.cgi?id=11127) try to solve the right thing ;-)
I think I've found the problem ... could you have a look here. I fixed both functions (not only the one which lets sacred crash - IDirect3DDeviceImpl_7_DrawIndexedPrimitiveStrided). In these functions there is short after the patched lines a line which looks similar to the problem but for specular. How to handle this? Because there isn't a function which could be called (invalid_func)!
if(VertexType & D3DFVF_SPECULAR) { WineD3DStrided.u.s.specular.lpData = D3DDrawPrimStrideData->specular.lpvData; WineD3DStrided.u.s.specular.dwStride = D3DDrawPrimStrideData->specular.dwStride; WineD3DStrided.u.s.specular.dwType = WINED3DDECLTYPE_SHORT4; }
I try to write a test for the original problem and for the other case (specular) and check what happens on windows if these are set.
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #31 from Stefan Dösinger stefandoesinger@gmx.at 2008-03-05 12:04:12 --- Your patch(changing the SHORT4 to D3DCOLOR) does the right thing I think. There is no SHORT4 data type in d3d7, specular and diffuse colors are D3DCOLORs. Feel free send it to wine-patches@winehq.org to get it applied.
If you have time to write tests they are welcome as well, we can never have enough tests
Good work with the debugging!
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #32 from Rico kgbricola@web.de 2008-03-05 12:33:15 --- My patch fixes only line 3711 and 3860 (in current git) (http://source.winehq.org/git/wine.git/?a=blob;f=dlls/ddraw/device.c;h=eed378...) so specular isn't fixed with this patch.
I'll add these for specular (3867 and 3718), too. I missed this because I haven't found the specular_funcs[WINED3DDECLTYPE_D3DCOLOR] (by looking there) in http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/directx.c;h=3d8... , I've simply overseen it ;-), but it is there and there is properbly a copy and paste mistake (line 3236)? specular_funcs[WINED3DDECLTYPE_FLOAT3] = (void *) warn_no_specular_func; have to be specular_funcs[WINED3DDECLTYPE_D3DCOLOR] = (void *) warn_no_specular_func;?
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #33 from Rico kgbricola@web.de 2008-03-05 15:48:14 --- Both patches were send to wine-patches.
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #34 from Stefan Dösinger stefandoesinger@gmx.at 2008-03-05 15:50:52 --- I didn't get them yet. Are you subscribed to the list?
http://bugs.winehq.org/show_bug.cgi?id=10992
--- Comment #35 from Rico kgbricola@web.de 2008-03-06 12:59:00 --- @Peter Kovacs Could you try with current git? If it is fixed for you please close the bug.
I didn't get them yet. Are you subscribed to the list?
Yes, I am. Looks like my e-mail provider is a little bit slow ...
http://bugs.winehq.org/show_bug.cgi?id=10992
Peter Kovacs legine@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #36 from Peter Kovacs legine@gmx.net 2008-03-23 13:50:57 --- Hi,
sry it took so long. I checked wine 0.9.58. And the bug is fixed. Great work! thx a lot.
Bug is closed
http://bugs.winehq.org/show_bug.cgi?id=10992
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #37 from Alexandre Julliard julliard@winehq.org 2008-04-04 10:06:50 --- Closing bugs fixed in 0.9.59.
-
wine-bugs＠winehq.org