yeah when hit 0x00000080 read the next DWORD, that is the size of the binary.gjinka wrote:OK, gotcha
But the offset which you say comes after seems to be too large.
Also, did you mean I should store the offset so I can return later to parse the MDL? Question,why not parse (read) it then, instead of storing the offset and returning later?
MDL seems to contain info which you really need.
And can I ask again why you don't treat the MDL chunk like the rest of the chunks? (resData, resEntries, etc).
if you want to jump to the end of that binary, offset your cursor from its current position.
Don't offset from the start of the file, because its a size, not a offset. the size is relative to after you read in the binary size.
but even though, you jumped from the start of the file, your cursor was only off like 12bytes?
and you can see now your at the texture tables.. see in the text viewer side theres a repeating pattern.
those are the final entries then the file ends with -1
your correct in that you can treat the MDL as just another chunk. you don't have to follow what i did. I did it this way to conform to NG.
NG does not contain MDL blocks, but does contain the XPR ID 0x00000080
thats why I read them all and log them, because in other games that ID pops up XX amount of times
the XPR is just pointing us to resources, so I read or evaluate the MDL separate from the XPR structure.. but again since your just working within DOA, and the MDL is always at the same location.
it may be easier just to read it as a normal chunk as apart of the header.
EDIT
Can anyone explain the DOA3 Material Block?
I'm going off this information, but I do not understand how to parse the tables at the end of that materials.
in this doc, it explains that there subset headers?
aman wrote:MATERIAL BLOCK OVERVIEW:Code: Select all
typedef struct _D3DMATERIAL { float Diffuse[4]; float Ambient[4]; float Specular[4]; float Emissive[4]; float Power; } D3DMATERIAL; typedef struct DOA3MATERIALBLOCK { dword dwheader; dword dwSize; //dwSize * 4 == materialblock size dword pad0; //usually 00 dword pad1; //usually 00 float x; float y; float z; float radius; dword renderFg; //usually 00,02,04,06 D3DMATERIAL material; //direct3d material dword NumTexInfos; } doa3materialblock; typedef struct DOA3MATTEXINFO { dword tex_num; //texture index; dword transFg; //(==01)?[alpha blend (256-bit)]:[] //check later dword renderFg; //(RenderFg & 01)?[1-bit alpha test]:[] //check later word typeFg; //0400h:Texture; 0000h:NonTexture word renderFg2; //0100,0000 } doa3MatTexInfo; typedef struct DOA3SUBSETHEADER { dword NumSubsets; dword vbufno; } doa3subsetheader; type struct DOA3MESHSUBSET { word group_num; //?? word flag0; //usually 00 dword indexoffset; //same as doax dword numFace; //?? to be checked word flag1; //usually 00 word flag2; //usually 00 } doa3MeshSubset;
Material block was separated into two part. the first part (DOA3MATERIALBLOCK) is similar to the source of xpression, except the variable name "mat_color0" and "dwNumSubsets", it had been changed to "x,y,z,radius" and "NumTexInfos" respectively. "x,y,z" are the center of Material block(submesh) but the pivot.
the second part start with 0 to 3 Material Texture Info Records, followed by NumSubsets, vBufNo and lots of mesh subsets.
Number or Material Texture Info Records(NumTexInfos) could be zero or greater than one. it means no or more than one texture associated. And if there are more than 1 material Textrue info record, the last record may not be texture. especially when the tex_num is equal to 0x0888, it maybe procedural texture, environment or auto-reflation...
MESHSUBSET:
i think i have something wrong in mesh subset and wish to correct it later.
there is only one subset in doax. however, there are so many subsets in doa3. it cause slower rendering. another problem is missing face during rendering. however, when add each numFace by 2 it will get better result.
group_num have relative value to numFace. if value of group_num are same, the value of numFace also same in materialblock.
MESHSUBSET DATA:Code: Select all
--------[group_num][ offset ][numFace ][ pad ] 00000000 8000 0000 0000 0000 0200 0000 0000 0000 ................ 00000010 8000 0000 0400 0000 0200 0000 0000 0000 ................ 00000020 A000 0000 0A00 0000 0300 0000 0000 0000 ................ 00000030 A000 0000 1100 0000 0300 0000 0000 0000 ................ 00000040 C000 0000 1800 0000 0400 0000 0000 0000 ................ 00000050 E000 0000 2000 0000 0500 0000 0000 0000 .... ........... 00000060 E000 0000 2900 0000 0500 0000 0000 0000 ....)........... 00000070 0001 0000 3200 0000 0600 0000 0000 0000 ....2........... 00000080 2001 0000 3C00 0000 0700 0000 0000 0000 ...<........... 00000090 6001 0000 4700 0000 0900 0000 0000 0000 `...G........... 000000A0 E001 0000 5400 0000 0D00 0000 0000 0000 ....T........... 000000B0 0002 0000 6500 0000 0E00 0000 0000 0000 ....e........... 000000C0 2002 0000 7700 0000 0F00 0000 0000 0000 ...w........... 000000D0 4002 0000 8A00 0000 1000 0000 0000 0000 @............... 000000E0 6002 0000 9E00 0000 1100 0000 0000 0000 `............... 000000F0 E003 0000 B300 0000 1D00 0000 0000 0000 ................ 00000100 8005 0000 D400 0000 2A00 0000 0000 0000 ........*....... 00000110 6006 0000 0201 0000 3100 0000 0000 0000 `.......1....... 00000120 6000 0000 3701 0000 0100 0000 0000 0000 `...7........... 00000130 6000 0000 3C01 0000 0100 0000 0000 0000 `...<........... 00000140 6000 0000 4101 0000 0100 0000 0000 0000 `...A........... 00000150 6000 0000 4601 0000 0100 0000 0000 0000 `...F........... 00000160 6000 0000 4B01 0000 0100 0000 0000 0000 `...K........... 00000170 C001 0000 5001 0000 0C00 0000 0000 0000 ....P........... 00000180 0002 0000 6001 0000 0E00 0000 0000 0000 ....`........... 00000190 0002 0000 7201 0000 0E00 0000 0000 0000 ....r........... 000001A0 8003 0000 8401 0000 1A00 0000 0000 0000 ................ 000001B0 8003 0000 A201 0000 1A00 0000 0000 0000 ................ 000001C0 C006 0000 C001 0000 3400 0000 0000 0000 ........4.......