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@winehq.org ReportedBy: gyebro69@gmail.com CC: hverbeet@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@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
http://bugs.winehq.org/show_bug.cgi?id=28945
--- Comment #1 from Henri Verbeet hverbeet@gmail.com 2011-10-30 15:15:49 CDT --- This doesn't seem to be happening for me with the demo.
http://bugs.winehq.org/show_bug.cgi?id=28945
--- Comment #2 from GyB gyebro69@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.
http://bugs.winehq.org/show_bug.cgi?id=28945
--- Comment #3 from Henri Verbeet hverbeet@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.
http://bugs.winehq.org/show_bug.cgi?id=28945
--- Comment #4 from Henri Verbeet hverbeet@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.
http://bugs.winehq.org/show_bug.cgi?id=28945
GyB gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Status|NEW |RESOLVED Resolution| |INVALID
--- Comment #5 from GyB gyebro69@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.
http://bugs.winehq.org/show_bug.cgi?id=28945
GyB gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from GyB gyebro69@gmail.com 2011-11-01 06:26:15 CDT --- Closing...INVALID
http://bugs.winehq.org/show_bug.cgi?id=28945
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED Resolution|INVALID |FIXED
--- Comment #7 from Austin English austinenglish@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...
http://bugs.winehq.org/show_bug.cgi?id=28945
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |1c91b082203bb62e7a28c63fd9b | |efc391d29ad7f
http://bugs.winehq.org/show_bug.cgi?id=28945
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2011-11-04 14:15:00 CDT --- Closing bugs fixed in 1.3.32.
-
wine-bugs＠winehq.org