[Bug 32092] Star Wars: The Old Republic - Game Crashes when Using Map

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=32092

Paul Gofman <gofmanp at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gofmanp at gmail.com

--- Comment #68 from Paul Gofman <gofmanp at gmail.com> ---
Created attachment 54073
  --> https://bugs.winehq.org/attachment.cgi?id=54073
Fix for testing

I've played around with it a little, and think I found what is this problem
about, though the patch fixing this game for me does not look yet like a
correct solution (at least fully correct).

Could someone interested please test if the patch fixes the issue (including
minimap)? I tested with crash on in-game settings change (the patch fixes the
crash). I do not know how to play the game and could not test this for minimap
crash, so I do not know if this is actually the same issue or not.

Besides, patch modifies a test in d3d9 (adds a sort of test with debug output
in respect to this problem, and removes all but added test to speed up its
run). I've tested it under Windows 7 with Intel and Nvidia discrete card. It
would be great if someone can run the test on other Windows version and/or
video cards. To compile the test, run 'make crosstest' in dlls/d3d9/tests. This
should build d3d9_crosstest.exe if build environment is set up correctly. In
the next message I will attach prebuilt test executable. To run the test on
Windows, please run 'd3d9_crosstest.exe visual' in the command prompt, and
attach the output here or send to me by email.

So, what is likely happening there. Somehow after changing settings and
resetting the device the game wants to create a texture of D3D9 format
D3DFMT_A8B8G8R8 (0x20) (seemingly similar textures are successfully created
previously with D3DFMT_X8R8G8B8 format, 0x15). Somehow it decides that it likes
this 0x20 format, but it looks like not really supported inside the game, and
it ends up in unknown internal texture format, which leads to to D3DFMT_UNKNOWN
in actual texture creation and in something like stride or alignment which it
decides from format code being 0 (this is the division by zero).

Simply disabling the support for texture format D3DFMT_A8B8G8R8 in wined3d
solves the issue (surely for ingame settings change, minimap yet to be tested,
see above). This is essentially what the patch does. Initially I thought of it
as just a tweak which can maybe help to find out a right difference between
Wine and native D3D, but my test on Windows 7 (unlike that on Wine test bot)
showed that CheckDeviceFormat fails on Windows for this format either. So for
now I am not sure if refusing this format is a correct behaviour, or rather
there are some conditions or Windows versions/hardware types when it is
refused, more testing is needed.

-- 
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.