http://bugs.winehq.org/show_bug.cgi?id=29184
Bug #: 29184 Summary: Hogs of War: ground is missing somewhere Product: Wine Version: 1.3.15 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: ianstroud@btinternet.com CC: kukuninse@gmail.com Classification: Unclassified
+++ This bug was initially created as a clone of Bug #15913 +++ When I run this all the fault as reported on the App database are still present. The most problematic being the incorrectly drawn landscapes. When running repeated errors get logged to the console:
fixme:d3d_surface:IWineD3DBaseSurfaceImpl_Blt Filter WINED3DTEXF_LINEAR not supported in software blit.
The machine I'm running is an AMD Phenon Quad Core running 64-bit Ubuntu 11.04 on Linux 2.6.38-12-generic and Wine 1.3.15. The Graphics card is a Zotac with NVIDIA GT 430. (I've just upgraded the graphics driver to NVIDIA-Linux-x86_64-290.10.
I can't believe a game of this vintage is particularly demanding on graphics so it should run. If I had to guess I'd that either
i) It is trying to use something in the Wine's DirectX implementation that hasn't been implemented and so the game is spending excessive time drawing in software. OR ii) There is an issue about how this graphics card/driver reports itself to the game via DirectX and so the game fails to try use the hardware accelerators and ends up trying to do too much in software. OR iii) This is a multiprocessor issue as the game was never written for multi-core machines. I can almost imagine the drawing process being run on multiple cores which then fight over access to the hardware resulting in the display being partially rendered in stripes.
Original report The game run fine, but some chunks of land aren't drawn texture. Its like a stripes of drawned/undrawned chunks of land. It making the game very difficult to play. Game use DirectDraw HAL. I ran on different settings - nothing difference.
http://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #1 from Ian Stroud ianstroud@btinternet.com 2011-11-26 18:17:55 CST --- I've just tried running the app on one CPU using
schedtool -a 0x01 -e wine .wine/drive_c/Program\ Files/Infogrames/Hogs\ Of\ War/warhogs.exe
This made absolutely no difference so that rulles out my multi-core theory.
http://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #2 from Vitaliy Margolen vitaliy-bugzilla@kievinfo.com 2011-11-26 21:14:18 CST --- Please upgrade to wine-1.3.33 and retest.
http://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #3 from Ian Stroud ianstroud@btinternet.com 2011-11-27 11:54:38 CST --- Downloaded and built wine 1.3.33.
I re-ran the game (without re-installing it) and the problems persist as before. The only thing that has changed is the error message that fills the terminal window. It now says:
fixme:d3d_surface:surface_cpu_blt Filter WINED3DTEXF_LINEAR not supported in software blit.
http://bugs.winehq.org/show_bug.cgi?id=29184
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #4 from joaopa jeremielapuree@yahoo.fr 2011-11-27 12:01:45 CST --- Attaching a backtrace could be a good start to fix this bug.
http://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #5 from Ian Stroud ianstroud@btinternet.com 2011-11-27 12:37:32 CST --- Given that the program doesn't crash or hang how can I get a back trace that contains any useful information?
I can attach the wine debugger and stop the code at some random point and then issue the bt command but that info could be totally irrelevant.
http://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #6 from Vitaliy Margolen vitaliy-bugzilla@kievinfo.com 2011-11-27 12:47:07 CST --- Complete terminal output as a file would be a good start.
http://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #7 from Ian Stroud ianstroud@btinternet.com 2011-11-27 13:03:44 CST --- Created attachment 37670 --> http://bugs.winehq.org/attachment.cgi?id=37670 Console Error output redirected to file
I ran the application for long enough (1-2 minutes) to get past menus and into game where the rendering problems becomes evident.
When navigating the menus it becomes apparent that they get progressively slower. Could this be as a result of the game continually spamming the console with the same fixme message?
http://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #8 from Ian Stroud ianstroud@btinternet.com 2011-11-28 15:12:10 CST --- I've done some more digging into this problem by adding some more FIXMEs into the source.
I believe the problem may be associated with dlls/wine3d/surface.c, function wined3d_surface_blt.
When the game starts running (i.e.gets beyond the menus) calls into this function fail with error code WINEDDERR_INVALIDRECT, when warning "The application gave us a bad destination rectangle without a clipper set.\n" is triggered.
I've not yet looked at the various rectangle bounds checks to see what exactly is causing the problem.
http://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #9 from Ian Stroud ianstroud@btinternet.com 2011-11-28 15:42:32 CST --- Further to my last comment: dst_rect (left,right,top,bottom) is 639,1196,479,1136 dst_surface->resource (width,height) is 640,480
Back tracking the code any further is proving difficult: wined3d_surface_blt is being called from ddraw/surface.c ddraw_surface7_Blt() which is turned called from many other places within this file. I'd need to set a proper debugger with a decent call stack display to back track any further.
Are there any app notes on how to do that?
http://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #10 from Ian Stroud ianstroud@btinternet.com 2011-12-04 10:52:00 CST --- I'm not making any much progress with this. It appears that a call to IDirectDrawSurface7->Blt is sometimes failing with WINEDDERR_INVALIDRECT. There are a number of TODOs and FIXMEs scattered through the code which may or may not be relevant. This issue really needs help from someone with an in depth knowledge of opengl / directx to pinpoint the exact problem. I'm happy to help/test potential fixes where I can but at the moment I'm just working blind.
http://bugs.winehq.org/show_bug.cgi?id=29184
Ian Stroud ianstroud@btinternet.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.3.15 |1.4-rc1
--- Comment #11 from Ian Stroud ianstroud@btinternet.com 2012-01-31 15:53:44 CST --- Problem still present with Wine 1.4-rc1. Landscape rendering still only occurs in alternate strips. However some of the earlier menus are more responsive so something has improved.
http://bugs.winehq.org/show_bug.cgi?id=29184
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com Version|1.4-rc1 |1.3.15
--- Comment #12 from Dan Kegel dank@kegel.com 2012-01-31 23:42:32 CST --- Please don't change the reported version - it should be the earliest version where the bug is observed. If this really is a clone of bug 15913, perhaps the version should be 1.1.7.
http://bugs.winehq.org/show_bug.cgi?id=29184
Jarkko K jarkko_korpi@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jarkko_korpi@hotmail.com
--- Comment #13 from Jarkko K jarkko_korpi@hotmail.com --- There is a demo of this game, but isn't so easy to get. Meanwhile can anybody update the status?
https://bugs.winehq.org/show_bug.cgi?id=29184
rachus@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rachus@web.de
--- Comment #14 from rachus@web.de --- @Jarkko K: Tested it today with wine 1.7.17. The bug still exists.
https://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #15 from Jarkko K jarkko_korpi@hotmail.com --- Can you send debug?
Also if you find the demo, post the link here.
https://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #16 from rs rachus@web.de --- Unfortunately I do not know where to find a demo version of this game. Mine is from a games collection.
To create debug information, I used this call: $ WINEPREFIX=~/.wine32 WINEDEBUG=+relay wine /media/cdrom/FEProg.exe > ~/sout 2> ~/serr But ~/serr is now 2.3 GB. I don't think this will be helpful, right?
Nonetheless I created another debug file without WINEDEBUG=+relay. However, this log is very similiar to Ian Stroud's log.
Please let me know, if I can do anything else.
https://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #17 from rs rachus@web.de --- Created attachment 48199 --> https://bugs.winehq.org/attachment.cgi?id=48199 Redirected console output without further debugging enabled (wine 1.7.17)
http://bugs.winehq.org/show_bug.cgi?id=29184
hanska2@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hanska2@luukku.com
--- Comment #18 from hanska2@luukku.com --- I am afraid that the bug is this
fixme:d3d_surface:surface_cpu_blt Filter WINED3D_TEXF_LINEAR not supported in software blit.
Some dev would know better...
https://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #19 from rs rachus@web.de --- The message "fixme:d3d_surface:surface_cpu_blt Filter WINED3D_TEXF_LINEAR not supported in software blit." does not seem to belong to the cause of the missing terrain.
When playing the game this message is only triggered when displaying the main menu or when a pipe containing (wrongly scaled) text is shown (e.g. after collecting boxes containing weapons).
During a paused game, the camera moves around the whole map with lots of occurrences of the bug but without producing any of these messages.
https://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #20 from joaopa jeremielapuree@yahoo.fr --- No news from the reporter since 3 years. No free download available. This bug can be closed as ABANDONNED.
https://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #21 from rs rachus@web.de --- Just tried it again with wine 3.10. The issue persists without any changes.
https://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #22 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-4.3?
https://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #23 from rs rachus@web.de --- Just compiled wine 4.3 and tried it again. Unfortunately, the same issue occurred like the last time.
However, a new fixme gets sometimes printed in the terminal:
004b:fixme:mcicda:MCICDA_GetError Unknown mode 87
Yet, I do not think that it has anything to do with the missing ground.
https://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #24 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-4.20?
https://bugs.winehq.org/show_bug.cgi?id=29184
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #25 from Paul Gofman gofmanp@gmail.com --- Created attachment 65744 --> https://bugs.winehq.org/attachment.cgi?id=65744 Proof of concept hack
I've tested the game. The problem is reproducible.
The game works fine if run in 16 bit colour depth display (with X session started, e. g., like this from console: 'xinit /usr/bin/lxsession -- :9 -ac -depth 16'; of course something else can be chosen instead of lxsession or :9).
It looks like there is a bug in the game which makes the display depth influence unrelated things. It draws all the 3D objects using transformed positions with _DrawPrimitive(). The contents of the vertex position data which game prepares happen to depend on the display depth (while has nothing to do with that in principle), more exactly, on the value returned by gdi32.GetDeviceCaps(..., BITSPIXEL). Forcing it to 16 (as the attached hack does) is enough to make the game happy on 32 bit display and fixes the rendering.
https://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #26 from Henri Verbeet hverbeet@gmail.com --- (In reply to Paul Gofman from comment #25)
It looks like there is a bug in the game which makes the display depth influence unrelated things. It draws all the 3D objects using transformed positions with _DrawPrimitive(). The contents of the vertex position data which game prepares happen to depend on the display depth (while has nothing to do with that in principle), more exactly, on the value returned by gdi32.GetDeviceCaps(..., BITSPIXEL). Forcing it to 16 (as the attached hack does) is enough to make the game happy on 32 bit display and fixes the rendering.
That sounds similar to bug 42215.
https://bugs.winehq.org/show_bug.cgi?id=29184
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=29184
--- Comment #27 from Paul Gofman gofmanp@gmail.com --- Yes, looks the same. There are also games which explicitly complain about incompatible screen depth. While emulating 16 bit visual in terms of reporting compatibility mode values looks easy to do, those old games often mix ddraw rendering with working on surfaces' DC through gdi, so probably a proper emulation of that would require rather lot from display driver side. Or maybe it would be even easier to introduce a separate compatibility display driver for that?
https://bugs.winehq.org/show_bug.cgi?id=29184
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #28 from winetest@luukku.com --- hopefully this is the correct way to fix this bug.
https://source.winehq.org/patches/data/205834
https://bugs.winehq.org/show_bug.cgi?id=29184
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |zzhang@codeweavers.com Fixed by SHA1| |d171d1116764260f4ae272c69b5 | |4e5dfd13c6835 Resolution|--- |FIXED
--- Comment #29 from Zhiyi Zhang zzhang@codeweavers.com --- Fixed by d171d1116764260f4ae272c69b54e5dfd13c6835
https://bugs.winehq.org/show_bug.cgi?id=29184
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #30 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.11.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla