http://bugs.winehq.org/show_bug.cgi?id=24009
Summary: Tomb Raider 4: Wrong camera position (Unnecessary Viewport Scaling transformation) Product: Wine Version: unspecified Platform: x86-64 URL: http://tombraider.ru/files/demos/pc/tr4_demo.rar OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: sudemon@gmail.com
Created an attachment (id=30158) --> (http://bugs.winehq.org/attachment.cgi?id=30158) Screenshot
Game start normal with "Wine Windows version" is win98.
But the camera is too close to the character, than his back can not see anything.
If I remove these lines in the code of Wine in the file "dlls/wined3d/device.c", in "process_vertices_strided" function, Viewport transformation part... :
3946,3948d3945 < x *= vp.Width / 2; < y *= vp.Height / 2; < z *= vp.MaxZ - vp.MinZ; 3950,3952d3946 < x += vp.Width / 2 + vp.X; < y += vp.Height / 2 + vp.Y; < z += vp.MinZ;
... and recompile(reinstall) wine, that CAMERA is WORKING PROPERLY, and the GAME becomes PLAYABLE!!
May be x,y,z values corrupted, or viewport scaling transformation makes by game itself.
May be wine did not recognize any special flag for the viewport transformation (maybe except the "scaling" is more modes of viewport transformation)
=============== You can download demo versions of game on one of these links: http://www.tombraiderchronicles.com/cgi-bin/dl03/dl.pl?dm_tlrdemo http://www.tombraiderchronicles.com/cgi-bin/dl03/dl.pl?dm_tlrtimesdemo or http://tombraider.ru/files/demos/pc/times_level.rar http://tombraider.ru/files/demos/pc/tr4_demo.rar =============== PS: Game used DirectX 6.1
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #1 from sudemon sudemon@gmail.com 2010-08-15 02:59:51 --- Created an attachment (id=30159) --> (http://bugs.winehq.org/attachment.cgi?id=30159) trace+d3d
WINEDEBUG=+d3d wine ./tomb4.exe &> trace-d3d.txt
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #2 from sudemon sudemon@gmail.com 2010-08-15 03:52:16 --- Created an attachment (id=30161) --> (http://bugs.winehq.org/attachment.cgi?id=30161) Screenshot (Without Viewport Scaling)
Screenshot (Without Viewport Scaling)
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #3 from Dmitry Timoshkov dmitry@codeweavers.com 2010-08-15 07:44:49 --- Please specify the Wine version you are using (in the Version field above).
http://bugs.winehq.org/show_bug.cgi?id=24009
sudemon sudemon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.3.0
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #4 from sudemon sudemon@gmail.com 2010-08-15 09:23:56 --- (In reply to comment #3)
Please specify the Wine version you are using (in the Version field above).
OK, wine version is 1.3.0. But this problem exists in previous versions too.
http://bugs.winehq.org/show_bug.cgi?id=24009
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #5 from Stanislav Larionov sudemon@gmail.com 2010-08-23 08:04:21 --- And yet I can not test the lighting, if the strings with viewport transformation is not cut. But at the cut, lihting not work.
http://bugs.winehq.org/show_bug.cgi?id=24009
Stanislav Larionov sudemon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hverbeet@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=24009
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |wylda@volny.cz Ever Confirmed|0 |1
--- Comment #6 from Wylda wylda@volny.cz 2010-08-28 09:39:51 CDT ---
Confirming. Same problem here. Tested under: * wine-1.0.1, wine-1.3.1-267-g7ab48e8 * nVidia GT240 v195.36.31
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #7 from Wylda wylda@volny.cz 2010-09-09 07:15:05 CDT ---
Still present in wine-1.3.2-115-gd822555.
http://bugs.winehq.org/show_bug.cgi?id=24009
Niels niels.emmersen@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |niels.emmersen@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=24009
Igor Tarasov tarasov.igor@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com, | |tarasov.igor@gmail.com
--- Comment #8 from Igor Tarasov tarasov.igor@gmail.com 2010-09-09 09:05:32 CDT --- This code appeared in wine in 2006. The commit:
http://source.winehq.org/git/wine.git/?a=commit;h=9abdac6aaa593bfd704a8222c2...
I think that it's author Stefan Dösinger, or other people who are into this code (such as Henri Verbeet) could help.
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #9 from Henri Verbeet hverbeet@gmail.com 2010-09-10 04:58:37 CDT --- Probably just needs some tests.
http://bugs.winehq.org/show_bug.cgi?id=24009
Maciej jagusek@wp.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jagusek@wp.pl
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #10 from Wylda wylda@volny.cz 2010-09-28 00:50:02 CDT ---
Still present in wine-1.3.3-282-g440cf08.
Stanislav, when Henri did not reject it on a first look, then your patch is probably correct ;) Don't you want to send it to wine-patches bundled with some small test?
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #11 from Henri Verbeet hverbeet@gmail.com 2010-09-28 05:21:45 CDT --- (In reply to comment #10)
Still present in wine-1.3.3-282-g440cf08.
Stanislav, when Henri did not reject it on a first look, then your patch is probably correct ;) Don't you want to send it to wine-patches bundled with some small test?
As it is, that patch will break the existing ProcessVerticesTest() test in dlls/ddraw/tests/d3d.c. But it doesn't seem unlikely to me that that transformation should be skipped under certain conditions. That's where writing tests comes in.
http://bugs.winehq.org/show_bug.cgi?id=24009
progger1986 anubis1@linux-ecke.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |anubis1@linux-ecke.de
--- Comment #12 from progger1986 anubis1@linux-ecke.de 2011-02-25 08:17:47 CST --- (In reply to comment #0)
Created an attachment (id=30158)
--> (http://bugs.winehq.org/attachment.cgi?id=30158) [details]
Screenshot
Game start normal with "Wine Windows version" is win98.
But the camera is too close to the character, than his back can not see anything.
If I remove these lines in the code of Wine in the file "dlls/wined3d/device.c", in "process_vertices_strided" function, Viewport transformation part... :
3946,3948d3945 < x *= vp.Width / 2; < y *= vp.Height / 2; < z *= vp.MaxZ - vp.MinZ; 3950,3952d3946 < x += vp.Width / 2 + vp.X; < y += vp.Height / 2 + vp.Y; < z += vp.MinZ;
... and recompile(reinstall) wine, that CAMERA is WORKING PROPERLY, and the GAME becomes PLAYABLE!!
May be x,y,z values corrupted, or viewport scaling transformation makes by game itself.
May be wine did not recognize any special flag for the viewport transformation (maybe except the "scaling" is more modes of viewport transformation)
=============== You can download demo versions of game on one of these links: http://www.tombraiderchronicles.com/cgi-bin/dl03/dl.pl?dm_tlrdemo http://www.tombraiderchronicles.com/cgi-bin/dl03/dl.pl?dm_tlrtimesdemo or http://tombraider.ru/files/demos/pc/times_level.rar http://tombraider.ru/files/demos/pc/tr4_demo.rar =============== PS: Game used DirectX 6.1
I build a small switch, that can "disable" theese 6 code-lines.
char* scale = getenv("noscale"); if (!scale || (scale[0] != '1')) { x *= vp.Width / 2; y *= vp.Height / 2; z *= vp.MaxZ - vp.MinZ;
x += vp.Width / 2 + vp.X; y += vp.Height / 2 + vp.Y; z += vp.MinZ; }
If you use that, you can play "Tomb Raider 4" without disturbing other games: export noscale=1 wine tomp4.exe
I know that this is a quick&dirty workaround, but it works :)
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #13 from thedoctor45 thedoctor45@portingteam.com 2011-04-04 11:52:58 CDT --- Created an attachment (id=33927) --> (http://bugs.winehq.org/attachment.cgi?id=33927) Screenshot (Gamma issues without viewport scaling)
I was able to get the game playable by applying the source modifications recommended by Stanislav, but strangely enough the games gamma correction is now completely out of alignment - it's far too bright. I have attached a screenshot of the problem
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #14 from progger1986 anubis1@linux-ecke.de 2011-04-04 12:10:00 CDT --- (In reply to comment #13)
Created an attachment (id=33927)
--> (http://bugs.winehq.org/attachment.cgi?id=33927) [details]
Screenshot (Gamma issues without viewport scaling)
I was able to get the game playable by applying the source modifications recommended by Stanislav, but strangely enough the games gamma correction is now completely out of alignment - it's far too bright. I have attached a screenshot of the problem
I think the brightnes problem ist not cause by the viewport source changes. But since we cannot see anything without theeses changes i can't know if its true. I played the game with theese source-changes adn got pretty far. Sometimes the missing lighting is very helpful and sometimes its an obstacle. For example the two room with the mirror, that tells you some useful information about the room.
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #15 from thedoctor45 thedoctor45@portingteam.com 2011-04-04 12:29:28 CDT --- Created an attachment (id=33929) --> (http://bugs.winehq.org/attachment.cgi?id=33929) Wine Error Log
I see you're experiencing the same problem - I have tried other TR games with the same Wine build and TR4 seems to be the only one that suffers from this problem- What confuses me is that Stanislav's previous screenshot does not display these particular characteristics.
I have attached my error log - the d3d7 errors seem very suspicious to me however I'm not sure how to interpret them - maybe someone else can help?
http://bugs.winehq.org/show_bug.cgi?id=24009
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
--- Comment #16 from Stefan Dösinger stefandoesinger@gmx.at 2011-04-04 13:50:36 CDT --- Yes, this needs some more test cases. Try to find out which API the app uses to call ProcessVertices(a +ddraw log will tell you). Most likely it is IDirect3DVertexBuffer::ProcessVertices (IDirect3DVertexBufferImpl_1_ProcessVertices), which forwards to IDirect3DVertexBuffer7::ProcessVertices (IDirect3DVertexBufferImpl_ProcessVertices). It is possible that those two functions are different in their behavior. The current tests test IDirect3DVertexBuffer7::ProcessVertices.
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #17 from thedoctor45 thedoctor45@portingteam.com 2011-06-15 21:18:59 CDT --- Created an attachment (id=35157) --> (http://bugs.winehq.org/attachment.cgi?id=35157) Wine +ddraw log for patched TR4 source
I have attached the +ddraw log of my patched TR4 specific build. it's huge and I'm not very good at interperting the various error messages so I'll leave it to you to judge them.
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #18 from Stanislav Larionov sudemon@gmail.com 2011-07-29 13:53:39 CDT --- Created an attachment (id=35741) --> (http://bugs.winehq.org/attachment.cgi?id=35741) fix Viewport Transformation Condition
Still present in wine-1.3.25-195-g5e941f8
I attached the diff-patch, which should not break the work of other games, I changed the operator "OR" to "AND" because "doClip" always set to "FALSE" and the second condition would not make any sense.
http://bugs.winehq.org/show_bug.cgi?id=24009
Stanislav Larionov sudemon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.3.0 |1.3.25
--- Comment #19 from Stanislav Larionov sudemon@gmail.com 2011-07-29 14:04:38 CDT --- It seems the game uses Clipping, but it is not implemented. I came to this idea because the incoming values x, y, z using the Viewport Scaling should not be greater than 1.0 or -1.0, but the game sends the values are much larger.
For example: x = 1221.000000 y =- 3174.625000 z =- 5940.500000 rhw = 1.000000
http://bugs.winehq.org/show_bug.cgi?id=24009
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.3.25 |1.3.0
--- Comment #20 from Wylda wylda@volny.cz 2011-07-29 14:19:48 CDT ---
Thanks for your good job, Stanislav. Hopefuly your patch will reach wine-patches mailing list sometime :) Please do not change originaly reported version. Saying here: "Still present in 1.3.25" is enough.
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #21 from Stefan Dösinger stefandoesinger@gmx.at 2011-07-30 07:41:01 CDT --- Clipping in ProcessVertices is indeed not fully implemented. Clipping when drawing is implemented because OpenGL always clips.
Clipping in ProcessVertices is trickier than the attached patch because clipping has to be done on full primitives(triangles, lines) rather than single vertices. ProcessVertices however doesn't know about the primitive assembly, it just operates on vertices.
According to the msdn[1], ProcessVertices stores a list of clipped triangles inside the vertex buffer, which is hidden from the application. When this vertex buffer is used for drawing, the draw function(which knows about the primitive assembly) uses this list to clip the primitives(which may mean that a triangle is split into two triangles).
Your patch is wrong in two ways: first, doClip is only false because it is forced to FALSE a couple of lines earlier in process_vertices_strided. The proper way is to disable the hack there. We also need a test for d3d8 and d3d9, those dll's ProcessVertices methods aren't tested yet.
With the hack disabled, a list of clipped vertices has to be added to the buffer. In case this list is non-empty, drawing has to go through drawStridedSlow. There won't be any vertex shaders involved because RHW vertices bypass the vertex pipeline. A clipping algorithm(look the details up in the CG book of your choice) has to be added to drawStridedSlow to emit properly clipped triangles(or lines). For POINTLIST draws nothing special has to be done I think.
1: http://msdn.microsoft.com/en-us/library/bb174424(v=vs.85).aspx
http://bugs.winehq.org/show_bug.cgi?id=24009
Sven sven.wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sven.wine@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=24009
--- Comment #22 from Wylda wylda@volny.cz 2011-12-17 14:19:54 CST ---
Hmmm :) Henri's not yet committed patch helps here too:
http://bugs.winehq.org/show_bug.cgi?id=22507#c18
http://bugs.winehq.org/show_bug.cgi?id=24009
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |4a30db74b1dbad885941970e7ca | |f9815abd7826d Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #23 from Wylda wylda@volny.cz 2011-12-26 15:07:19 CST ---
Works in wine-1.3.35-168-g5b93bb9 and fixed by Henri (particular commit 4a30db74b1dbad885941970e7caf9815abd7826d). BTW there are some visual differences (missing shadows/lightmap) compared to WinXP, maybe covered by some bug already. If not, i can fill one in.
http://bugs.winehq.org/show_bug.cgi?id=24009
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #24 from Alexandre Julliard julliard@winehq.org 2011-12-30 12:57:24 CST --- Closing bugs fixed in 1.3.36.