http://bugs.winehq.org/show_bug.cgi?id=28444
Summary: zenilib 0.4.1.0 applications: crash when attempting to use d3dx9 for rendering Product: Wine Version: 1.3.28 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3dx9 AssignedTo: wine-bugs@winehq.org ReportedBy: bazald@gmail.com CC: wine-bugs@winehq.org
Created an attachment (id=36469) --> (http://bugs.winehq.org/attachment.cgi?id=36469) Output log
I'm responsible for the development of a "simple" game engine, zenilib. It compiles and runs natively under Linux, so most code isn't doing anything too platform specific. The Windows build runs magnificently in Linux when using OpenGL for rendering, but something is preventing applications from starting at all when attempting to use Direct3D9.
You can download the engine and supporting files here: http://zenilib.com/download/#vs
To reproduce: 1. unzip zenilib_0.4.1.0.zip 2. unzip zenilib_0.4.1.0_support.zip 3. cd zenilib/config 4. cat zenilib.xml | sed 's/OpenGL/DX9/' > temp && mv temp zenilib.xml 3. cd ../bin 4. wine Application.exe
http://bugs.winehq.org/show_bug.cgi?id=28444
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://zenilib.com/download | |/#vs Component|directx-d3dx9 |directx-d3d
http://bugs.winehq.org/show_bug.cgi?id=28444
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |xerox_xerox2000@yahoo.co.uk Component|directx-d3d |directx-d3dx9 Ever Confirmed|0 |1
--- Comment #1 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2011-10-22 13:25:58 CDT --- confirming
With the hack below i was able to get into the menu
From a debuglog it looks as if D3DXFilterTexture doesn't return success, and
then trouble start. Mitchell, could you try if the hack let's you get further in the game up to the menu too? Then we know at least the problem is in d3dx9_36.
diff --git a/dlls/d3dx9_36/texture.c b/dlls/d3dx9_36/texture.c index 20d8880..c8e6f08 100644 --- a/dlls/d3dx9_36/texture.c +++ b/dlls/d3dx9_36/texture.c @@ -69,7 +69,7 @@ HRESULT WINAPI D3DXFilterTexture(LPDIRECT3DBASETEXTURE9 textur UINT level; HRESULT hr; D3DRESOURCETYPE type; - +return 0; TRACE("(%p, %p, %d, %d)\n", texture, palette, srclevel, filter);
if (!texture)
http://bugs.winehq.org/show_bug.cgi?id=28444
Mitchell Keith Bloch bazald@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.3.28 |1.3.31
--- Comment #2 from Mitchell Keith Bloch bazald@gmail.com 2011-10-22 15:04:30 CDT --- Interesting. That does explain why the stderr.txt log complained about being unable to load textures. It seems that your hack prevents the immediate detection of a problem loading textures, so I can report that it's partially successful. The window loads and allows me to quit by sending a quit event. However, rendering seems to be utterly broken. All I'm seeing is an undrawn frame which occasionally refreshes to just a black screen. OpenGL still works.
In some earlier experimentation, it seemed that dropping official Windows d3d9.dll and d3dx9_*.dll into the zenilib/bin/ directory allowed everything to work, but that seems to be broken now. I can't get it to work again, with or without your hack, so I might be encountering a driver issue. I'll try it again on another computer as soon as I'm able to.
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #3 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2011-10-22 15:26:42 CDT ---
In some earlier experimentation, it seemed that dropping official Windows d3d9.dll and d3dx9_*.dll into the zenilib/bin/ directory allowed everything to work, but that seems to be broken now. I can't get it to work again,
I see the same problem after installing a native d3dx9_36. Si there has been probably a regression wine. If you could pinpoint the patch that broke wine,that would be great
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #4 from Mitchell Keith Bloch bazald@gmail.com 2011-10-22 20:55:23 CDT --- Your fix seems to work better with 1.3.30, as do the native DLLs. It's definitely a regression going from 1.3.30 to 1.3.31. Finding the exact commit to blame will be a bit of a pain. I'm not on my fastest build machine right now.
Anyway, in 1.3.30, using your fix, the menu is indeed working perfectly. Textures generated from files are obviously(?) garbage, but everything else seems great, which is good news.
http://bugs.winehq.org/show_bug.cgi?id=28444
Vitaliy Margolen vitaliy-bugzilla@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.3.31 |1.3.28
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #5 from Rico kgbricola@web.de 2011-10-23 03:23:39 CDT --- Regression test gave here:
25b1130b44c2d64effbf259ba174fc5a32d33c4d is the first bad commit commit 25b1130b44c2d64effbf259ba174fc5a32d33c4d Author: Henri Verbeet hverbeet@codeweavers.com Date: Sun Oct 16 21:55:31 2011 +0200
wined3d: Also restore the pixel format in context_restore_gl_context().
:040000 040000 813b85a7330694aa490d4509332af63f73d71433 e54ef8126bd61629d76b94cb5d27e2c500c97249 M dlls
Well the regression should be a separate bug, shouldn't it? Could you please confirm/deny if this is the patch which broke the usage of native d3dx9_36.dll?
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #6 from Mitchell Keith Bloch bazald@gmail.com 2011-10-23 12:22:27 CDT --- (In reply to comment #5)
25b1130b44c2d64effbf259ba174fc5a32d33c4d is the first bad commit
Confirmed. It seems reverting 25b1130b44c2d64effbf259ba174fc5a32d33c4d from HEAD doesn't break the build, and allows things to start up successfully with the native DLLs or with the hack described above.
http://bugs.winehq.org/show_bug.cgi?id=28444
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Regression SHA1| |25b1130b44c2d64effbf259ba17 | |4fc5a32d33c4d
http://bugs.winehq.org/show_bug.cgi?id=28444
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression | Regression SHA1|25b1130b44c2d64effbf259ba17 | |4fc5a32d33c4d |
http://bugs.winehq.org/show_bug.cgi?id=28444
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #7 from Dan Kegel dank@kegel.com 2012-07-16 15:27:06 CDT --- Is this still an issue? The app seems to start ok here with zenilib 4.2 and wine 1.5.8, and looks the same as in XP: it just shows a single window the the Zenilib logo.
If it's still a problem, please attach a screenshot of how it's supposed to look, and how it looks in wine.
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #8 from Mitchell Keith Bloch bazald@gmail.com 2012-07-16 20:31:04 CDT --- Dan, I imagine you missed step 4 in the original post or tried step 6 (er... the second step 4) first. My console reports:
X Error of failed request: GLXBadCurrentWindow Major opcode of failed request: 154 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 931 Current serial number in output stream: 931
This is in wine-1.5.8. It *does* work when the OpenGL renderer is in use, but if you are successful in forcing the Direct3D renderer, it will fail.
One way to ensure failure is as follows:
1. rm ~/.wine/drive_c/users/bazald/Application\ Data/zenilib/config/zenilib.xml 2. cd zenilib/config 3. cat zenilib.xml | sed 's/OpenGL/DX9/' > temp && mv temp zenilib.xml 4. cd ../bin 5. wine Application.exe
Alternatively, use the in-game configurator to switch to Direct3D and hit Apply. It will fail immediately in the same way.
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #9 from Dan Kegel dank@kegel.com 2012-07-16 22:49:24 CDT --- I didn't miss that step, but maybe I muffed it, sorry. I am able to reproduce the failure now (using the gui to select d3d).
Reverting 25b1130b44c2d64effbf259ba174fc5a32d33c4d still lets you use 'winetricks d3dx9' to get past this problem.
(I tested this because I saw Józef Kucia was working on D3DXFilterTexture, see ffe36a3894356f6e23107eb7f0fd1c87d0d71f14 )
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #10 from Mitchell Keith Bloch bazald@gmail.com 2012-07-16 23:07:29 CDT --- No problem. It's nice to know that this bug report hasn't been forgotten.
It looks like Józef Kucia's ffe36a3894356f6e23107eb7f0fd1c87d0d71f14 implements D3DRTYPE_VOLUMETEXTURE and changes virtually nothing else. Unfortunately, fixing this depends on a change to how D3DRTYPE_TEXTURE is handled. I can't offer any more insight than that at the moment, I'm afraid.
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #11 from Józef Kucia joseph.kucia@gmail.com 2012-07-21 12:37:27 CDT --- Created attachment 41090 --> http://bugs.winehq.org/attachment.cgi?id=41090 Patch
This patch should help.
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #12 from Mitchell Keith Bloch bazald@gmail.com 2012-07-21 15:19:42 CDT --- Well this is just odd. Thanks for the patch, but I might have to wait to test it until I can use a native Linux installation. It has occurred to me that since I'm now doing most of my Linux development in VirtualBox, I'm probably running into a different error in Direct3D 9 initialization. If I recall correctly, before, my code was exiting gracefully in response to the error it was encountering. Now it's generating this GLXBadCurrentWindow weirdness, even with the patch from Comment 1.
If the patch in attachment 41090 helps on a native installation, it looks like I might have to create a separate bug report for this other issue. I'll get back to you. Thanks again to all of you.
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #13 from Mitchell Keith Bloch bazald@gmail.com 2012-07-23 15:08:24 CDT --- It appears that the patch in attachment 41090 is sufficient to prevent instant crashing when attempting to switch to the "DX9" renderer. Now it consistently results in a number of lines identical to:
fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5.
This seems to be non-fatal. However, the screen turns black while it waits for the user to confirm that the settings are alright. When the user fails to confirm because the screen is completely black, within ~15 seconds the settings revert to the OpenGL renderer.
Unfortunately, some of the time, reverting results in the following hang of the program:
X Error of failed request: GLXBadDrawable Major opcode of failed request: 135 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 5302 Current serial number in output stream: 5302
http://bugs.winehq.org/show_bug.cgi?id=28444
Christian Costa titan.costa@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |titan.costa@gmail.com
--- Comment #14 from Christian Costa titan.costa@gmail.com 2013-06-07 09:48:27 CDT --- What is the status with latest wine?
http://bugs.winehq.org/show_bug.cgi?id=28444
Mitchell Keith Bloch bazald@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #36469|0 |1 is obsolete| |
--- Comment #15 from Mitchell Keith Bloch bazald@gmail.com 2013-06-10 14:51:17 CDT --- Created attachment 44741 --> http://bugs.winehq.org/attachment.cgi?id=44741 Current output from wine64 when running zenilib
I'm now using the files from zenilib_0.5.1.0.7z, and testing `wine64 Play\ game\ x64.exe` using revision eeca784b708ce44257b78bf1e8c291eeccf5d8c2 in a fresh WINEPREFIX.
With OpenGL, everything still works fine. Direct3D9 gets much further than before. The rendering looks fine, but it's doing something nasty to my system. It's unresponsive to the extent that it is difficult to exit my program / wine, or do anything else with my system. I was eventually able to quit, and my system returned to normal afterward, but it took ages.
This is bad behavior is the same regardless of whether you manually specify that it should use DX9 as in the original instructions I provided, or whether you switch to it using the configurator built into my program.
Lines 8 through 47 of the log I'm providing are absent when running with OpenGL. The short version:
fixme:win:EnumDisplayDevicesW ((null),0,0x23f4a0,0x00000000), stub! fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5. fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #16 from Dan Kegel dank@kegel.com 2013-06-10 15:33:19 CDT --- Is the problem reproducible using the source version of zenilib?
If so, can you attach a download/build/run-and-explode script here? Thanks!
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #17 from Mitchell Keith Bloch bazald@gmail.com 2013-06-10 18:10:25 CDT --- The full source tree is available as a .7z from the original download link, and it's also available through svn: svn://svn.code.sf.net/p/zenilib/code/trunk/zenilib
Forgive me for my ignorance, but if the Windows version needs to be built with with Visual Studio 2010 or later (I haven't tested against 2008 or earlier in a while), how would I go about putting together a download/build/run-and-explode script? Do you want a batch script to do a compile+zip job on Windows, and a separate shell script to unzip+run-and-explode on the Linux side?
If you could point me to a working example of the kind of script you'd like me to build, I'm willing to try to put it together when I have time. However, none of this seems to work in VirtualBox, so I can only test when I'm at a native Linux workstation.
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #18 from Dan Kegel dank@kegel.com 2013-06-10 18:13:30 CDT --- Just give me any old instructions (e.g. "fire up visual studio 2010 on foo.sln, build this target, and run the resulting .exe in wine, then click on the clown's nose; you should see a crash"). Thanks!
http://bugs.winehq.org/show_bug.cgi?id=28444
--- Comment #19 from Mitchell Keith Bloch bazald@gmail.com 2013-06-10 18:34:23 CDT --- Windows-side:
1. Download http://sourceforge.net/projects/zenilib/files/zenilib/0.5.1.0/zenilib_0.5.1.... 2. Extract zenilib_0.5.1.0_only-src.7z 3. In a shell, `cd zenilib` and then `multi-premake_sh.bat --build=all` 4. Open zenilib\build\vs2010\zenilib.sln 5. Pick your build target (The one I just reported on was Release x64) and build all. 6. You can then optionally delete the zenilib\build\ directory, or the extra files built by Visual Studio and zip up the zenilib\ directory.
Linux-side:
1. unzip zenilib.zip 2. cd zenilib/ 3. `wine32 Play\ game\ x32.exe` or `wine64 Play\ game\ x64.exe` assuming you built for Release, `wine32 Play\ game\ d32.exe` or `wine64 Play\ game\ d64.exe` otherwise. 4a. In the window that pops up, click on "Configure Video", then "OpenGL", then "Direct3D 9", then Apply. It will start to chug. To make it permanent, try to click on "Apply" in the lower-right corner when the option appears. 4b. To start in Direct3D9 instead, change "OpenGL" to "DX9" in zenilib/assets/config/zenilib.xml before running it for the first time.
Like I said, things seem to work on some level. Performance just goes bad when using Direct3D 9.
http://bugs.winehq.org/show_bug.cgi?id=28444
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source
--- Comment #20 from Dan Kegel dank@kegel.com 2013-06-10 18:44:32 CDT --- Adding the 'source' keyword.
https://bugs.winehq.org/show_bug.cgi?id=28444
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |2c1968aef99fd51e715c8ed89e2 | |3fc25e249416a Status|NEW |RESOLVED CC| |leslie_alistair@hotmail.com Resolution|--- |FIXED
--- Comment #21 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- This appears fixed.
Based off patch attached patch commit 2c1968aef99fd51e715c8ed89e23fc25e249416a is the fix.
d3dx9: Allow D3DX_DEFAULT to be passed as srclevel to D3DXFilterTexture
https://bugs.winehq.org/show_bug.cgi?id=28444
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #22 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.50.