Jump to content

PST CRE file, offsets 2e1, and 2b8-2bb


Qwinn

Recommended Posts

Bit of an update, depending on a compare between the byte at 0x2F4 and the byte at 0x2F6, the byte at 0x2F4 overwrites the byte at 0x2F6. Here's the relevant code:

 

.text:00766CEF                 mov     cl, [eax+7DCh]     ;0x2F6 in cre file
.text:00766CF5                 mov     edx, [ebp+var_1C]
.text:00766CF8                 xor     eax, eax
.text:00766CFA                 mov     al, [edx+7DAh]     ;0x2F4 in cre file
.text:00766D00                 cmp     ecx, eax
.text:00766D02                 jge     short loc_766D16
.text:00766D04                 mov     ecx, [ebp+var_1C]
.text:00766D07                 mov     edx, [ebp+var_1C]
.text:00766D0A                 mov     al, [edx+7DAh]     ;0x2F4 in cre file
.text:00766D10                 mov     [ecx+7DCh], al     ;0x2F6 in cre file

Link to comment

Well whatever it does I can help confirm it isn't a clownclr slot: if you look at the related IDS file for color placement you'll see that it only has 7 options, so an eighth wouldn't do a whole lot.

 

As for 2F2-2F4...these are odd. In the CRE they're usually set up as:

In clown colored character: 20 00 20

In true color character (i.e. Black Abashai) 0c 00 80

Deionarra, ROYALGD: 0c 00 0c

 

Hope that narrows it down some.

Link to comment

Are we sure color placement 1 doesn't have more to it? There's a sub that's doing a whole lot of logical operations on that entry, AND's, OR's shifts, etc. (and yes I'm sure this time, I fixed my offsets :hm:)

 

EDIT: Looks like all color placement values are ran through these operations in a loop, not just the first one.

Link to comment

Got some info on the color placement values. A struct is built out of these values in memory, I don't know how the struct is used in the game, but here's some info, note this is the struct as its in memory:

 

0x00 Byte from 0x2F2

0x04 Byte from 0x2F4

0x08 Byte from 0x2F3

0x0C - 0x12? Data from the color placement values, each byte position possibly is where the color goes (hair, skin, etc.)

 

The first thing that happens when processing the value in a color placement slot is the high bit is checked. If it is not set then it is not processed further. If it is set bits 4, 5, and 6 are stripped off and they are used for a number between 0 and 7 (or possible 1 - 7, not sure yet) which is used as an offset in the above struct at 0x0C to store data from this number (e.g. if the number stripped off is 4, then data would be stored at 0x0C + 4) Several bits are then checked in the color placement value and these are acted on. Finally the loop goes on to the next color placement slot.

 

Just a guess but bit 8 I assume is a flag for a valid color placement value. The number built from bits 4 - 6 are where the color is used (i.e. hair, skin) and is a offset from 0x0C in the struct, and the rest are flags for something, not sure what though.

Link to comment

Ok, just to recap and to get it straight in my own head as NI knows what these values means, the value in a color placement is composed of the following:

 

Upper nibble is a flag and the actual placement. The high bit is set if its a valid placement value, and the remaining value is the actual placement (skin, hair etc.) The lower nibble is a set of flags, bit 0 is a hologram flag, and bit 1 is a pulsate flag (according to NI). Bit 2 is not used and bit 3 is always set manually by the engine regardless of what the value actually is.

 

So now the question is what are the other 3 bytes used for (0x2F2 - 0x2F4)? They are going into this color struct so they have something to do with the colors.

Link to comment

I've added most of this info to my IESDP local copy, but I'm a little confused by this:

0x29:

bit 0 - True color yes/no

bit 1 - Unknown

bit 2 - Unknown

bit 3 - Unknown

bit 4 - Unknown

bit 5 - Per pixel blending

 

0x28 is currently defined as a dword representing animation. If the values listed above are corrected, it this a subset of 0x28 (i.e. the 0x28 dword still represents animation, but with some of the flags inside the dword altering the animation type) or is 0x28 split into multiple fields?

 

Note to self: Integreate "Posted Aug 2 2009, 09:23 PM"

Link to comment

I believe only the initial WORD is used. I think they're hinting at how the BIS animation IDs are constructed (e.g., 0xE010 isn't just some made up number for the fun of it).

 

I'd not document it for now until we understand more of it.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...