Is wine reporting the right value for MaxVertexBlendMatrices ?
Julio Fernandez
ucldb at wanadoo.es
Sat Feb 9 09:42:04 CST 2008
Hi, I don't know if this is the right place to post this, but sorry if
not, and I'd like to be pointed to the right one
I have been working last weeks on making the game Everquest to work
under wine, since 0.9.49 it was working flawlesly, but most models were
not shown properly. This corresponds with bug
http://bugs.winehq.org/show_bug.cgi?id=8357.
These are my findings:
The main executable is eqgame.exe, it typically accesses D3D through a
custom dll eqgraphicsdx9 which interacts with D3D itself or through
d3dx9_30.dll
Using channels and adding some extra messages into certain source files
I got to track a possible reason:
The game was declaring vertex lists with vertex of type '0xfe' and +189
offset
Sadly, I could not get any extra information tracking just from source
code, so I had to run the game under Windows on a computer and using
windbg to debug it, while running at the same time on another computer
the game under Debian etch using winedbg to debug, and so tracing both
programs in assembler (I've burnt my eyelashes there!), the fact that I
could have d3d dll symbols availables on the windows box was the key
here, I really missed winedbg was able to read pdb files :(
After many hours I was able to track down the reason, and to my surprise
it seems it's not wine's fault (for the most of it)
The 'troublesome' vertex are apparently Blended ones on a Mesh setup.
When d3dx9_30 calls ConvertToIndexedBlendedMesh, it calls GetDeviceInfo
to get the device capabilites, in the end wine returns the capabilites
through IWineD3DImpl_GetDeviceCaps in wine/dlls/wined3d/directx.c
Here comes the fun thing, for the attribute MaxVertexBlendMatrices in
D3DCAPS9, from (MSDN):
"Maximum number of matrices that this device can apply when performing
multimatrix vertex blending. For a given physical device, this
capability may vary across Direct3D devices depending on the parameters
supplied to IDirect3D9::CreateDevice."
At the moment is set in wine as *pCaps->MaxVertexBlendMatrices =
GL_LIMITS(blends) which results in a value of 0 (at least in my Linux
computer/build), while under Windows (XPSP2 DX9c) results in a value of 4
d3dx9_30 has a check right after capabilites are returned comparing that
value with 2, resulting in different code paths for the remaining of
MaxVertexBlendMatrices function, when the value was 0 both Linux and
Windows (hacking the returned value to be 0) make those odd '0xfe'
vertexes to be inserted (in Linux that makes the models not to be shown,
in Windows it makes eqgame.exe to crash)
I proceeded then to try to 'hack' wine to return a value of 4, adding
the line
pCaps->MaxVertexBlendMatrices=0x4;
Before returning from function
IDirect3DDevice9Impl_GetDeviceCaps(LPDIRECT3DDEVICE9 iface, D3DCAPS9*
pCaps) at wine/dlls/d3d9/directx.c
The result: MaxVertexBlendMatrices runs the same path as Windows does,
the odd '0xfe' vertexes are not generated and the models are now shown
as expected
My apologies for the long post, but I thought it would be handy to tell
the full story to justify calling your atention on this
- d3dx9_30 ConvertToIndexedBlendedMesh shows an 'odd' behavior when
MaxVertexBlendMatrices capabilites in D3DCAPS9 is 0
- Is wine reporting the right value for MaxVertexBlendMatrices ??? As it
seems the game works flawlesly in wine when it's hacked to be 4 (I don't
know if this 'hack' would affect other programs in any other way
More information about the wine-devel
mailing list