Dead or Alive series formats and tools

[gjinka]

Uh, so
1) XPR files are basically split into two parts,
2) first part contains model and texture entries, second part contains vertex data and texture data,
3) second part's offset is the 3rd integer in the file,
correct?

Seems from browsing the sourcecodes that there are 10 types of vertex buffers.
I tried the "position+normal+uv" type on a stage and got this:


I see shapes that couldn't have been caused by random vertex placements, so I have something right, lol.

May I know why you guys just won't make a wiki page for the formats in the Xentax wiki? That's the point of it you know, plus we got used to the style. Spreedsheet is fine don't get me wrong, but lets put stuff where they are meant to be. Even though Google will probably keep the doc unlike rapidshit or megaupload, it is still harder to find.

To be honest don't understand the docs in their current state, I see blocks of data but don't see how they relate, where they are located and how they should be parsed. Still good job on that, but I'm afraid it's like notes for hexers right now and I'm no hexer.

So who's for making a wiki style doc for me?

[b0ny]

2mariokart64n
install on your "doa online" client the latest update http://rghost.ru/25644601

this patch will save your time experimenting with the game files, here's a quick start guide:



- Download and unpack the update in the doao root directory.
- Run the launcher from the "Final" directory and set these options. (Select The Russian Lang To See The Skins "FileName" In the tool-tip when you select a skin)
- Type your nikname, select "localhost" and press "OK"
- Press simultaneously the <Alt> and the <C> buttons on your keyboard to select a different stage or character. For more stages talk to the girl with a gift-box, and for different hairstyles for kasumi and lei-fang talk to the girl with scissors. (To listen to a random song from the game talk to the girl with a notebook)
- and, only in the last update, this thing will save your time experimenting on how your changes in the skin files will affect the game. you can modify the files while the game is running, and press the "outgame" button, and then the [E] button, to reload the files with your modifications. you can immediately see the changes

[finale00]

Uh, so
To be honest don't understand the docs in their current state, I see blocks of data but don't see how they relate, where they are located and how they should be parsed. Still good job on that, but I'm afraid it's like notes for hexers right now and I'm no hexer.

So who's for making a wiki style doc for me?

I think it's mainly people not knowing mediawiki syntax.

I don't know if there's a rich-text editor installed here but it is definitely not intuitive for anyone that's never edited a wiki before.

But you can create a page and provide a link to it. Maybe I will write something on it.

[gjinka]

Sure thing. Here: http://wiki.xentax.com/index.php/Dead_Or_Alive_Ultimate

You can use other pages, like DOA1 page as reference: http://wiki.xentax.com/index.php/Dead_Or_Alive

Otherwise, you can always make a txt version and ask someone to port it for you (like me?). Maybe you can even post the simple text version in the wiki page and hope others will add all the markup later. I don't think it will be deleted. I'm not sure though

Also there are some WYSIWYG editors out there: http://www.mediawiki.org/wiki/Extension:WYSIWYG
Maybe we could ask to add one to the xentax wiki. There might even be an offline version which you can use on any wiki, by copy-pasting the results or something.

[finale00]

I've done wiki editing for a couple years.
Only problem is how to take all of that information and present it nicely lol

[gjinka]

Anything's a start. I'm kind of stuck so I'm really lookign forward to any more info.

[finale00]

I've organized the layout and removed some unnecessary code.
A table would probably be the easiest way to present it.

Since I don't have files I can't verify whatever I'm writing is correct so I didn't write anything.

[gjinka]

Yeah, wikitables are great for this, I just thought we could make it consistent with the other wiki pages.

Since I don't have files I can't verify whatever I'm writing is correct so I didn't write anything.

Check your pm inbox.

[finale00]

Only a couple people work on the wiki so it's pretty much personal preference.
I think we should just throw up some different formats and maybe people can see which one they like better.

The spreadsheet is hard to follow cause it mixes the data with cases.
But it looks like you've gotten the vertex data out.

EDIT: ok, I'm looking at ayaA0.xpr and trying to follow the OBJ subblock, but there seems to bytes that aren't accounted for. Actually, many bytes. I see the word "HB" everywhere. Is this the same game?

[gjinka]

But it looks like you've gotten the vertex data out.

All I did was:
1) get the 3rd integer from the file, which tells the offset of the 2nd part of the file, which contains vertex buffers and texture data.

2) moved the file cursor there

3) assuming that the map I was testing only used one type of vertexbuffer format, I just looped till the end of the file, which of course means I also read the texture data with it, which is bad, I got lots of junk vertices.

I just did this test to make sure I have the vertexbuffer part right.

The vertex buffer type is the one from the spreedsheet. it's called "vertex definition":

Code: Select all

typedef struct {  // D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_TEX1
	FLOAT	vx, vy, vz;
	FLOAT	nx, ny, nz;
	FLOAT	u, v;
} ST_VERTEXFORMAT0_0;

I basically keeped reading chunks like this until I reached the end of file (reading 32 bytes and getting position values from the first 12 bytes).

The "type" of the vertexbuffer(s) is actually specified in the first part of the file.

Then presumably I start looping, reading two int16 for the main and sub ID's.

I didn't get even that, thank.
Any ideas why there are two ids?

I look ahead and see a lot of vertBuff chunks and their offsets are increasing, but I don't know what to do with that offset.

I think each OBJect has it's own "part" (slice might be a better word) in the vertexbuffer, so the offsets are probably relative to the beginning of the vertex buffer, or which is probably the same as the start of the 2nd part of the file (which we are given in the header).

Even if all my assumptions are true, still no idea where "MDL Block", "OBJ SubBlock" and "Material SubSubBlock" are and how to read them.

EDIT: I may have send you some files from DOAX2. I'm not really sure, so I'm pm'ing new ones just in case.

[finale00]

Ok I see the problem I had now.
The files that you initially sent had some differences.

The aya file you gave me was different from the stage_AG1N.xpr file.
The kasumi file looks encrypted.

In the recent batch that was sent, the kas20 file was still encrypted. Same with lei.
How do I decrypt it?

Also, the aya file doesn't follow what is written in the specs, so maybe that was the different game issue lol
I don't know how the indices are assigned for the aya model though (I plotted the vertices already)

stage_AG1N looks like it follows it, so I'll try it with that.

The MDL chunk is at the very top. You should see MDL easily.
The OBJ chunks follow afterwards.

Are there quads? Cause stage_AG1N has meshes with 4 indices and 4 vertices.
I don't know what a tri-strip is so I'm not sure how to draw that. Is it just, for example

indices: 0 1 2 3

face1 = 0 1 2
face2 = 1 2 3

There are some differences in each mesh chunk as well. Some of them follow the ones on the spec

Code: Select all

char[4] OBJ
int32 vertType
int32 "4"?
int32 numIdx
float[4] stuff
int32 numVerts
int32 vertOfs
int32 numIdx
int32 intOfs

But then some of them have 16 null bytes after the 4 floats.

[mariokart64n]

are you guys just stuck on how to read the OBJ blocs?

[gjinka]

@finale: so MDL chunk is always right after those? Cool, thanks.

I dont think any file is encrypted, are you sure the header is not just swapped with a hash?

I think only tristrips are used.

[finale00]

From the two samples that I could read, that was the case (just open it in hex editor you'll see the MDL string)



Compressed? Encrypted?

are you guys just stuck on how to read the OBJ blocs?

I'm stuck with the indices lol
How are they assigned.

Here's a set of indices I printed out in groups of 3:

60 71 70
81 80 91
90 101 100
111 110 110
20 20 19
30 29 40
39 50 49

Those will cause problems for me if I just treat them as triangles, and my idea of a tri-strip doesn't work for that either.

[mariokart64n]

the faces are triStrip,

so your read 3, then just read one for each loop

1,2,3
2,3,4
3,4,5
4,5,6

etc


but you can just read the face buffer, there are index by material.

also you've posted encrypted files, I posted the source code for XPRbreaker around pages 5-7? compile that, it'll allow you to decrypt the files.
but otherwise use GreedXplorer to export your files, it decrypts for you.

And I should reclassify the XPR spec, since it seems you both have it incorrect

DWORD - BlocID
DWORD - FileSize
DWORD - BufferOffset

now you loop until a DWORD, and if its a certain ID, you have to preform a certain action

the chunkID and what they do are recorded in my google doc.

but for example the ID 0x00000080
DWORD - BlocID 0x00000080 = User inputed binary
DWORD - DataSize

now you would store that user binary into memory.. yes there can be multiple IDs of 0x00000080

as you can see in the NinjaGaiden XPRs this is true

so after parsing the XPR, reading all the IDs and evaluating all the given IDs.. then you get the MDL bloc as apart of the XPR's User Inputed Binaries