[Bug 28945] New: Armored Fist 3 shows only black screen after starting
http://bugs.winehq.org/show_bug.cgi?id=28945 Bug #: 28945 Summary: Armored Fist 3 shows only black screen after starting Product: Wine Version: 1.3.31 Platform: x86 URL: http://www.fileplanet.com/29182/20000/fileinfo/Armored -Fist-3-Demo OS/Version: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: gyebro69(a)gmail.com CC: hverbeet(a)gmail.com Classification: Unclassified Regression SHA1: 2da4f87a7e7551f17cd650ef6d8596f595efc13b The screen stays black after game launch, although the game is apparently running (mouse and keyboard work in the menus and I can hear the menu music in the full version of the game), but I can't see anything. The demo can be used to test the issue. You can exit the demo by pressing 'q' three times. In the terminal only fixme:win:EnumDisplayDevicesW ((null),0,0x32f6d8,0x00000000), stub! This was caused by 2da4f87a7e7551f17cd650ef6d8596f595efc13b is the first bad commit commit 2da4f87a7e7551f17cd650ef6d8596f595efc13b Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Mon Oct 24 20:45:42 2011 +0200 wined3d: Upload directly from the source surface in wined3d_surface_blt(), if possible. This avoids either loading sysmem surfaces into video memory (wasting GPU memory) and then doing a blit on the GPU, or downloading GPU surfaces to sysmem, doing a blit on the CPU, and likely uploading it again. This mostly matters for ddraw and d3d8 applications, d3d9 already has to go through wined3d_device_update_surface() to transfer data from sysmem surfaces to GPU surfaces. :040000 040000 de2e083e774b6605b4330430830583b12fb510f4 16fd239dcdf7e70872e0ff77f91e66b135638d2b M dlls The patch cannot be reverted on the current git version (wine-1.3.31-172-g7df0245), but git checkout 2da4f87a7e7551f17cd650ef6d8596f595efc13b >> black screen git reset --hard HEAD^ >> the game starts normally Bug #28899 was also affected by this commit. Commit 61550ff fixed the problem in that case, but apparently it has no effect on this bug. Fedora 15 x86 X.Org X Server 1.10.4 Nvidia 250 / driver 280.13 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28945 --- Comment #1 from Henri Verbeet <hverbeet(a)gmail.com> 2011-10-30 15:15:49 CDT --- This doesn't seem to be happening for me with the demo. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28945 --- Comment #2 from GyB <gyebro69(a)gmail.com> 2011-10-30 16:07:32 CDT --- Okay, now I got it...the problem only exists when Wine was compiled with CFLAGS=-O0 (that's how I compile the git versions). With -O2 the problem is non-existent. Isn't that interesting that until 2da4f87a7e7551f17cd650ef6d8596f595efc13b the game ran correctly whether -O0 or -O2 was used? btw., gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC) here. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28945 --- Comment #3 from Henri Verbeet <hverbeet(a)gmail.com> 2011-10-31 08:08:11 CDT --- Yeah, I can reproduce this with -O0. I actually only need to switch gdi32 to -O0. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28945 --- Comment #4 from Henri Verbeet <hverbeet(a)gmail.com> 2011-11-01 06:05:08 CDT --- Created attachment 37236 --> http://bugs.winehq.org/attachment.cgi?id=37236 patch This is probably invalid. What seems to happen is that the application pushes crap (including -nan) onto the FPU stack, which then results in FPU stack overflows in the implicit matrix multiplication in glOrtho(). The end result is a projection matrix with -nan's in it. When compiled with -O2, the matrix multiplication in (gdi32) CombineTransform() ends up clearing enough of the FPU stack for glOrtho() to work. This does result in transformation matrices with -nan in them, but apparently this has no negative effects. The attached patch avoids the matrix multiplication in set_blit_dimension(), but doesn't change the fact that the application is essentially broken. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28945 GyB <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Status|NEW |RESOLVED Resolution| |INVALID --- Comment #5 from GyB <gyebro69(a)gmail.com> 2011-11-01 06:24:47 CDT --- (In reply to comment #4)
Created attachment 37236 [details] patch
This is probably invalid. What seems to happen is that the application pushes crap (including -nan) onto the FPU stack, which then results in FPU stack overflows in the implicit matrix multiplication in glOrtho(). The end result is a projection matrix with -nan's in it. When compiled with -O2, the matrix multiplication in (gdi32) CombineTransform() ends up clearing enough of the FPU stack for glOrtho() to work. This does result in transformation matrices with -nan in them, but apparently this has no negative effects. The attached patch avoids the matrix multiplication in set_blit_dimension(), but doesn't change the fact that the application is essentially broken.
Resolving as INVALID (application bug), as there is no need to investigate further such an ambiguous case. Thank you for taking time to investigate this and keep up the good work! btw. the patch worked here as well. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28945 GyB <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from GyB <gyebro69(a)gmail.com> 2011-11-01 06:26:15 CDT --- Closing...INVALID -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28945 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED Resolution|INVALID |FIXED --- Comment #7 from Austin English <austinenglish(a)gmail.com> 2011-11-02 16:07:21 CDT --- (In reply to comment #4)
Created attachment 37236 [details] patch
This is probably invalid. What seems to happen is that the application pushes crap (including -nan) onto the FPU stack, which then results in FPU stack overflows in the implicit matrix multiplication in glOrtho(). The end result is a projection matrix with -nan's in it. When compiled with -O2, the matrix multiplication in (gdi32) CombineTransform() ends up clearing enough of the FPU stack for glOrtho() to work. This does result in transformation matrices with -nan in them, but apparently this has no negative effects. The attached patch avoids the matrix multiplication in set_blit_dimension(), but doesn't change the fact that the application is essentially broken.
http://source.winehq.org/git/wine.git/commitdiff/1c91b082203bb62e7a28c63fd9b... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28945 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |1c91b082203bb62e7a28c63fd9b | |efc391d29ad7f -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28945 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #8 from Alexandre Julliard <julliard(a)winehq.org> 2011-11-04 14:15:00 CDT --- Closing bugs fixed in 1.3.32. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org