[Bug 15636] New: Colin McRae Rally 2.0 draws no background during race
http://bugs.winehq.org/show_bug.cgi?id=15636 Summary: Colin McRae Rally 2.0 draws no background during race Product: Wine Version: 1.1.6 Platform: PC URL: http://cdn.gamezone.com/pub/gamezone/16/0/86/cmr2pcdemo. zip OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net Created an attachment (id=16677) --> (http://bugs.winehq.org/attachment.cgi?id=16677) screenshot. The black area in the lower right comes from the snapshot tool: This area was not redrawn. During race, Colin McRae Rally 2.0 draws neither road nor other background (see attached picture), i.e. the game is unplayable. This affects both the commercial and the demo version, available from http://downloads.gamezone.com/demosfiles/t1582.htm http://cdn.gamezone.com/pub/gamezone/16/0/86/cmr2pcdemo.zip This may be a driver issue. I'm using Ubuntu 8.04 with the Intel XOrg video driver. This could as well be a "Wine's DirectX6 not good enough" issue. The in-game graphics selection menu displays no other "choice" than "DirectDraw HAL", i.e. only DirectX6 is recognized. Indeed, during install, a requester says "your machine is not ... for DirectX7". The DirectX7a installer is distributed with the game. So this could be a DirectX7 detection issue. Alas, the game's configuration (Configuration/*.rcf) is a binary file, so I cannot change the graphics driver. Default trace output is attached. It contains a lot of fixme:d3d_surface:surface_convert_format Cannot find a conversion function from format WINED3DFMT_DXT5 to WINED3DFMT_A4R4G4B4 with XxYx16bit or fixme:d3d_surface:surface_convert_format Cannot find a conversion function from format WINED3DFMT_DXT5 to WINED3DFMT_A8R8G8B8 with a XxYx32bit resolution setting. Could that be related to the missing background? -- 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=15636 --- Comment #1 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2008-10-16 10:10:55 --- Created an attachment (id=16678) --> (http://bugs.winehq.org/attachment.cgi?id=16678) normal trace output no particular component was traced -- 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=15636 --- Comment #2 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2008-10-16 10:56:46 --- CMR2 is quite sensitive to some graphics settings: - With deactivated pixel shader in winecfg, the initial (intro/menu) screen remains black. (Vertex shader makes no difference). - Within the game, setting the car details from low to high causes the car not be drawn (only its shadow is visible), as Daniel Szollosi-Nagy reported in AppDB. -- 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=15636 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download -- 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=15636 --- Comment #3 from Lei Zhang <thestig(a)google.com> 2008-10-21 17:07:09 --- What video card / driver version are you using? Can you try on another computer with a nvidia / ati card and see if that makes a difference? -- 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=15636 --- Comment #4 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2008-10-26 03:36:34 --- The hardware is Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller X.Org X Server 1.4.0.90 Release Date: 5 September 2007 (prerelease, used by Ubuntu 8.04) I'm using the Intel Xorg driver on the laptop. (II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so (II) Module intel: vendor="X.Org Foundation" compiled for 1.4.0.90, module version = 2.2.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 2.0 Alas, I have no other computer to try on. I've observed that versions of Wine around 1.0..1.1.2 manage to display *some* background (i.e. grey rectangles) and will do regression testing. Also, with these versions, the cars are rendered correctly. -- 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=15636 --- Comment #5 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2008-11-14 04:41:40 ---
Can you try on another computer I still have no other HW, but I had hoped that an upgrade of the software from Ubuntu Hardy 8.04 to Ubuntu Intrepid 8.10 might make a difference. It does not (tested with 1.1.6), although XOrg & mesa is now much newer:
X.Org X Server 1.5.2 Release Date: 10 October 2008 -- 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=15636 --- Comment #6 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2008-12-10 12:52:12 ---
I've observed that versions of Wine around 1.0..1.1.2 manage to display *some* background (i.e. grey rectangles)
More precisely, the change between 1.1.2 and 1.1.3 14b24058d69d73ebf6b70bc36c8aa62993351079 is first bad commit commit 14b24058d69d73ebf6b70bc36c8aa62993351079 Author: Stefan Dösinger <stefan(a)codeweavers.com> Date: Mon Jul 28 11:41:02 2008 -0500 wined3d: GL_ARB_fragment_program ffp implementation. broke the rendering of grey building rectangles. Very old versions of wine, e.g. 0.9.57, behave much like 1.1.3-1.1.10: no background is drawn at all. Sadly, I cannot identify what commit enabled the greyscale rectangles, as I too often get crashes during regression testing. It happened somewhere between 0.9.57 and 1.0-rc1. I thought that the missing background might be some hardware driver issue. So I tried and switched to software rendering instead, using a recent enough version of XOrg/Mesa, as found in Ubuntu Intrepid (previous tests were with Ubuntu Hardy). LIBGL_ALWAYS_SOFTWARE=yes changes nothing to rendering (except it's dog slow) LIBGL_ALWAYS_INDIRECT=yes crashes the Xorg server (version 1.5.2, Ubuntu Intrepid) Do the identical results with LIBGL_ALWAYS_SOFTWARE eliminate the possibility of a bug in the Intel XOrg driver? Does *_ALWAYS_SOFTWARE act like a portable, hardware-independent display driver so one could "prove" bugs must be somewhere else? -- 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=15636 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- 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=15636 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID Summary|Colin McRae Rally 2.0 draws|Colin McRae Rally 2.0 draws |no background during race |no background during race - | |missing DXT/S3TC | |decompression --- Comment #7 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2009-04-20 03:35:53 ---
This may be a driver issue. Indeed it is: DXT/S3TC in HW is (partly) lacking in the Intel GPU.
Surprisingly, http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html says: "Currently, s3tc is supported on all graphic cards which use the radeon, r200, i830 and i915 driver". Alas, OpenGL does not announce the S3TC capability because the specification requires both decompression *and* compression. From what I understood, the i915 can only decompress in HW. Luckily, that is enough for many applications. Here's my ~/.drirc (or /etc/drirc) to force OpenGL to declare the S3TC capability. Then glxinfo reports it. The file produces immediate effect, there's no need to restart the X server. <driconf> <device screen="0" driver="i915"> <application name="Default"> <option name="force_s3tc_enable" value="true" /> </application> </device> </driconf> With that, Colin McRae 2.0 becomes playable, as everything is drawn correctly. The fixmes about DXT vanish (tested with wine-1.1.16 or -1.1.18 with Ubuntu Hardy and Intrepid). Sadly, like in TORCS, the image freezes from time to time during race, exactly like satellite TV on bad weather. Sound still plays but motion is stopped, then resumes after half a second. All objects are redrawn to their new position, as the application never stopped. Meanwhile, the car bumped into a fence as you lost visual control of it. But that's another issue. Changing resolution to 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=15636 Jeff Zaroyko <jeffz(a)jeffz.name> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #8 from Jeff Zaroyko <jeffz(a)jeffz.name> 2009-04-20 04:18:44 --- closing -- 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=15636 Ben Klein <shacklein(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |shacklein(a)gmail.com --- Comment #9 from Ben Klein <shacklein(a)gmail.com> 2009-04-20 21:34:26 --- (In reply to comment #7)
This may be a driver issue. Indeed it is: DXT/S3TC in HW is (partly) lacking in the Intel GPU.
Surprisingly, http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html says: "Currently, s3tc is supported on all graphic cards which use the radeon, r200, i830 and i915 driver".
Alas, OpenGL does not announce the S3TC capability because the specification requires both decompression *and* compression. From what I understood, the i915 can only decompress in HW. Luckily, that is enough for many applications.
Here's my ~/.drirc (or /etc/drirc) to force OpenGL to declare the S3TC capability. Then glxinfo reports it. The file produces immediate effect, there's no need to restart the X server. <driconf> <device screen="0" driver="i915"> <application name="Default"> <option name="force_s3tc_enable" value="true" /> </application> </device> </driconf>
Umm ... if you're forcing S3TC support on, and your hardware doesn't support it, it shouldn't change the behaviour of your app (you should still be missing textures).
With that, Colin McRae 2.0 becomes playable, as everything is drawn correctly. The fixmes about DXT vanish (tested with wine-1.1.16 or -1.1.18 with Ubuntu Hardy and Intrepid).
There's something else going on here. Possibly the application is asking the driver for S3TC, which is not supported by the driver (glxinfo | grep -i s3tc) and as a result, asking DirectX to decompress it into ARGB, which is supported by the drivers. Or possibly the application (or Wine) is querying the wrong GL extension when testing for S3TC support. I think your glxinfo would be interesting here. If they're different, once with the driconf hack above, and once without.
Sadly, like in TORCS, the image freezes from time to time during race, exactly like satellite TV on bad weather. Sound still plays but motion is stopped, then resumes after half a second. All objects are redrawn to their new position, as the application never stopped. Meanwhile, the car bumped into a fence as you lost visual control of it. But that's another issue.
Changing resolution to invalid.
I don't think this bug is resolved. The symptoms are the same as in bug 14939 (missing DXTC/ARGB conversion). The proposed solution in driconf is hacky and, if S3TC really is missing in the hardware, could cause breakages. It also only works on supported intel and radeon drivers, not on nvidia (and bug 14939 is reported with an nvidia card). -- 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=15636 --- Comment #10 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2009-04-21 03:56:53 ---
if you're forcing S3TC support on, and your hardware doesn't support it, it shouldn't change the behaviour of your app AFAIK, my hardware supports decompression, but not compression. The former is apparently all that's needed for this particular application. The referred URI further reads: "you will get errors if applications try to use online-compression (like QuakeIII does)".
BTW, somewhere I read that it could be that MS-Windows' D3D drivers would report the S3TC capability even on my hardware. That would make CMR2 run there. So the force_s3tc_enable option gets wine closer to MS-Windows' behaviour. It's not to be frowned upon. Material for wine-wiki?
I think your glxinfo would be interesting here. If they're different As I said, they are. A single additional capability is output, something xyz_s3tc (from memory, I cannot check right now). Must be ext_texture_compression_s3tc as it's this one wine checks in dlls/wined3d/directx.c.
There's something else going on here. Well, what's puzzled me is the following quote from http://dri.freedesktop.org/wiki/S3TC "force_s3tc_enable... This may be of use for some games which require S3TC or don't use the ARB_texture_compression extension correctly." So there would be some correct use of ARB_texture_compression (which wine should thus implement) that does not depend on this option?!? I could not find further information on this.
The two pages about S3TC are not clear enough, IMHO. It took me some time after initially reading them to combine that it would benefit CMR2.
bug 14939 is reported with an nvidia card Yes, much to my surprise. NVidia is probably supported by CMR2 (I will look up the package cover). Does the CMR2Demo (URL in top template) work for you with NVidia?
-- 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=15636 --- Comment #11 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2009-04-23 07:42:24 --- CMR2's package cover (published 2000 approx.) lists these supported HW devices: 3Dfx, Voodoo2, Voodoo Banshee, Voodoo3, Voodoo5, 3DLabs Permedia 3, ATI Rage Pro, Rage 128, Intel i740, Matrox G100, G200, G400, NVidia Riva 128, Riva TNT, Riva TNT2, GeForce 256, GeForce 2, S3 Savage 4, Savage 2000. 3D with 8MB RAM, 233MHz, D3DX7.0a. I don't know whether they all support(ed) S3TC or whether CMR2 may contain alternate code path not using DXT textures. Note that i740 is supported, an ancestor of i915. (Although I now have s3tc enabled in /etc/drirc, it's clear to me it's not a completely satisfying solution. E.g. from what Scheidegger writes, I would get into trouble if I wanted to use QuakeIII or DoomIII. But that's as far as one can currently go without too much hassle.) -- 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=15636 --- Comment #12 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2009-07-13 09:23:43 --- Chris Dragan's D3Dcaps database http://zp.amsnet.pl/cdragan/d3dcaps.html shows that among the cards supported (comment #11) by Colin Mac Rae 2.0, the following ones do not support DXT1 .. DXT5. Obviously, the app is able to take different code paths, but I don't know how to trigger it (will try PCI ID). - Voodoo3 - NVidia Riva TNT2 - ATI Rage Pro -- 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