http://bugs.winehq.org/show_bug.cgi?id=8357
Julio Fernandez ucldb@wanadoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ucldb@wanadoo.es
--- Comment #8 from Julio Fernandez ucldb@wanadoo.es 2008-01-25 13:49:44 --- Not sure if I should keep posting here or at some other thread, please direct me to the right one.
I tried to further track into code at dll/wined3d/vertexdeclaration.c
At IWineD3DVertexDeclarationImpl_SetDeclaration() patched for 0.9.52 with
wined3d: Vertex atributes are 4 byte aligned by Stefan Dösinger 12/20/2007 20:48:03
adding
if(This->pDeclarationWine[i].Offset & 0x3) {
WARN("Declaration element %d is not 4 byte aligned(%d), returning E_FAIL\n", i, This->pDeclarationWine[i].Offset);
HeapFree(GetProcessHeap(), 0, This->pDeclarationWine);
return E_FAIL;
making Everquest to crash on page fault
this function is receiving a vertex buffer with multiple WINED3DVERTEXELEMENT where one of elements is Type 0xfe, and making next element offset to increase by a size of 177, so all next elements on that vertex fail the 4 byte alignment check
An example of typical check failing vertex would be
WINED3DVERTEXELEMENT:
Elemento 0: Stream 0 Offset 0 Type 2 Method 0 Usage 0 UsageIndex 0 Reg -1 Elemento 1: Stream 0 Offset 12 Type 0xfe Method 0 Usage 1 UsageIndex 0 Reg -1 Elemento 2: Stream 0 Offset 189 Type 4 Method 0 Usage 2 UsageIndex 0 Reg -1 Elemento 3: Stream 0 Offset 193 Type 2 Method 0 Usage 3 UsageIndex 0 Reg -1 Elemento 4: Stream 0 Offset 205 Type 1 Method 0 Usage 5 UsageIndex 0 Reg -1
The 2nd element 'missaligns' all next ones
I haven't found any documentation of a type 0xfe element so either the game is making some obscure use of vertex elements or there's some 'undocumented' use by D3D of type 254 (0xfe) vertex elements or the type is getting messed in some place on way from the game to wine