http://bugs.winehq.org/show_bug.cgi?id=28343
Summary: UFO: Extraterrestrials Gold - crash at start unless native d3dx9_26 (or d3dx_36) is used Product: Wine Version: 1.3.24 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3dx9 AssignedTo: wine-bugs@winehq.org ReportedBy: mooroon2@mail.ru CC: wine-bugs@winehq.org
Created an attachment (id=36322) --> (http://bugs.winehq.org/attachment.cgi?id=36322) WINEDEBUG="+tid,+all,err+all,warn+all,trace-all" output
UFO:ET not only require native dsound/dmusic as reported in bug #25728, but also crashes unless native MS d3dx9_26 or d3dx9_36 are used. I had first ran into this bug with Wine 1.3.11, and it pertained till version 1.3.24. Can't test with later version due-to dsound/dmusic override workaround is no longer working as reported in bug #28340.
What's interesting is that is is sufficient to install native dsound/dmusic and only one of native d3dx_26/d3dx_36 to get the game working. With native d3dx_26 and wine's built-in d3dx_36 the game seems to start up faster than with wine's built-in d3dx_26 and native d3dx_36.
I attach essential WINEDEBUG logs recorded with Wine 1.3.24 + MS native dsound/dmusic + wine's built-in d3dx_26/d3dx_36.
Most "promising" line are:
fixme:d3dx:D3DXGetImageInfoFromFileInMemory (0x8a00c0, 49280, 0x34f8a0): partially implemented fixme:d3dx:D3DXGetImageInfoFromFileInMemory Invalid or unsupported image file fixme:d3dx:D3DXCreateEffectEx (0x14a2a8, 0x8c44a0, 1192, (nil), 0x8c4958, (nil), 0, (nil), 0x8c1770, 0x8c1764): semi-stub fixme:d3dx:d3dx9_base_effect_init HLSL ascii effects not supported, yet fixme:d3dx:get_format_info Unknown format 0x35545844
From relay trace it looks like that the last d3d function called prior to the
crash is d3dx9_36.D3DXCreateTextureFromFileInMemoryEx().
http://bugs.winehq.org/show_bug.cgi?id=28343
--- Comment #1 from Alexey Loukianov mooroon2@mail.ru 2011-09-11 00:51:29 CDT --- WINEDEBUG="-all,+tid,err+all,warn+all,fixme+all,+relay" output, bziped, download URL: http://lexa2.ru/lx2/Wine/2011-09-11-wine-errors-1.3.24-UFOET-relay.tar.bz2
There are two files in tarball - one is raw logs output starting from the call create UFO_ET.exe process, and second one is filtered with the only output from threads belonging to UFO_ET.exe included.
http://bugs.winehq.org/show_bug.cgi?id=28343
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|wine-bugs@winehq.org | Severity|normal |minor
http://bugs.winehq.org/show_bug.cgi?id=28343
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #2 from Jörg Höhle hoehle@users.sourceforge.net 2011-09-20 02:06:23 CDT --- 35545844 is DXT5, aka. the dreaded patented S3TC texture compression. The D3D guys will be able to tell you whether there's any hope that D3DXCreateTextureFromFileInMemoryEx supports that.
Many apps appear to use d3dx_36.dll when in fact they do not, because Wine redirects everything to _36, the others are stubs. Use WINEDEBUG=+loaddll to see which .dll is looked for initially. Then use only this one natively (presumably _26 here), not the _36 fallback. Then +loaddll will change and show that once native _26 is found and loaded, _36 is not sought anymore. Sometimes it's a little less obvious when the app is split across 2 .exe files, each of which linked against another d3dx_XY.dll SDK.
http://bugs.winehq.org/show_bug.cgi?id=28343
--- Comment #3 from Alexey Loukianov mooroon2@mail.ru 2011-09-20 07:13:23 CDT --- (In reply to comment #2)
35545844 is DXT5, aka. the dreaded patented S3TC texture compression. The D3D guys will be able to tell you whether there's any hope that D3DXCreateTextureFromFileInMemoryEx supports that.
Oh, it makes sense. But isn't this compression format supposed to be supported by libGL in both prop. driver binary blobs from major vendors and by MesaGL implementation with help of additional dloaded lib? As far as I remember correctly, Driver is an OpenGL game that supports DDS textures format loading, here is link to a tech page about it (with C/C++ sources): http://www.racer.nl/tech/dds.htm
Many apps appear to use d3dx_36.dll when in fact they do not, because Wine redirects everything to _36, the others are stubs.
Good catch. I suppose it's just what happens here with UFO:ET. I would check it with +loaddll "just in case" and post results here.
http://bugs.winehq.org/show_bug.cgi?id=28343
--- Comment #4 from Alexey Loukianov mooroon2@mail.ru 2011-09-20 09:49:01 CDT --- (In reply to comment #3)
I would check it with +loaddll "just in case" and post results here.
OK, checked and confirmed that the game itself require native d3dx9_26.dll as it's the first one it tries to load at start and it doesn't try to load d3dx9_36.dll in case native d3dx9_26.dll is installed and being used.
As for D3DXCreateTextureFromFileInMemoryEx() vs D3DFMT_DXT5 I took a quick look into Wine d3dx9_36 sources and it seems that the problem is not only lack of support for D3DFMT_DXT5, but also lack of support for DDS format.
D3DXGetImageInfoFromFileInMemory() which is called by D3DXCreateTextureFromFileInMemoryEx() to get image properties use WIC (Windows Imaging Components COM API) as an info provider. As far as I know native WIC lacks built-in decoders for common DirectX texture formats like DDS and same apply to Wine's built-in windowscodecs.dll. I suspect that the game uses DDS as texture on-disk storage format which apparently fails under current Wine's implementation. Unfortunately I hadn't been able to trace it more in-depth under debugger (OllyDbg which I prefer to use when dealing with Windows apps) as Steam's DRM makes it to be pretty hard task.
IMO best bet would be to try to implement homebrew DDS decoder in Wine's windowscodecs.dll and then continue with debugging the issue. Maybe I'd find some time to do it. Then again, maybe not - it depends on the amount of workload at my primary job.
http://bugs.winehq.org/show_bug.cgi?id=28343
--- Comment #5 from Vincent Povirk madewokherd@gmail.com 2011-09-20 10:34:11 CDT --- WIC isn't expressive enough to support the DDS format. It needs to be implemented somewhere else.
http://bugs.winehq.org/show_bug.cgi?id=28343
--- Comment #6 from Alexey Loukianov mooroon2@mail.ru 2011-09-20 10:45:36 CDT --- (In reply to comment #5)
WIC isn't expressive enough to support the DDS format...
Maybe, hadn't digged deep into MSDN on this topic. In any case final decision about where and how to implement DDS support for wined3d should and would be held by Wine's d3d team. My intension is just to quickly hack-in quick-n-dirty DDS implementation in a personal separate git branch (if I would have enough free time for it) to check if this is really what blocks the game from running properly.
http://bugs.winehq.org/show_bug.cgi?id=28343
Alexey Loukianov mooroon2@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #36322|0 |1 is obsolete| |
--- Comment #7 from Alexey Loukianov mooroon2@mail.ru 2012-05-27 22:38:17 CDT --- Created attachment 40311 --> http://bugs.winehq.org/attachment.cgi?id=40311 WINEDEBUG="-all,err+all,fixme+all,fixme-ntdll,fixme-class,fixme-msg,+d3dx,+tid,+loaddll,+fps"
OK, as Andrew had fixed another bug so with recent Wine versions UFO:ET no longer chokes on buggy dmusic implementation and recently DDS support had been hacked into d3dx9 I had tried to revisit this bug and check if it had been fixed or not.
Unfortunately crash still happen and installing native d3dx9_36 or d3dx9_26 workarounds the problem. The only suspicious fixmes left in logs that are related to d3dx9 are ones from "D3DXCreateEffectEx and Co family", so now this one looks like a dupe of bug #11675.
I had captured relevant logs with d3dx9 debug channel turned on, attaching them to this comment. I'm not sure if this bug should be marked as dupe or not so I left this decision to be carried by more competent people.
http://bugs.winehq.org/show_bug.cgi?id=28343
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|hoehle@users.sourceforge.ne | |t |
http://bugs.winehq.org/show_bug.cgi?id=28343
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #8 from joaopa jeremielapuree@yahoo.fr 2012-11-03 00:07:40 CDT --- Original bug was fixed. Please, open a new bug report for the other problem.
This bug can be closed as FIXED.
http://bugs.winehq.org/show_bug.cgi?id=28343
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #9 from Austin English austinenglish@gmail.com 2013-01-22 01:49:33 CST --- (In reply to comment #8)
Original bug was fixed. Please, open a new bug report for the other problem.
This bug can be closed as FIXED.
Fixed.
http://bugs.winehq.org/show_bug.cgi?id=28343
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Alexandre Julliard julliard@winehq.org 2013-02-01 04:55:06 CST --- Closing bugs fixed in 1.5.23.