Scribd
Upload
5 views

pr_obj_reference

The document details the structure and contents of character files used in the Guilty Gear XX Accent Core Plus R game. It outlines the organization of data, including player objects, cells, sprites, scripts, and palettes, along with their respective pointers and padding. Additionally, it explains the formats for uncompressed and compressed sprites, as well as the specifics of palette data used in the game.

Uploaded by

brenosdpereira
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
5 views

pr_obj_reference

The document details the structure and contents of character files used in the Guilty Gear XX Accent Core Plus R game. It outlines the organization of data, including player objects, cells, sprites, scripts, and palettes, along with their respective pointers and padding. Additionally, it explains the formats for uncompressed and compressed sprites, as well as the specifics of palette data used in the game.

Uploaded by

brenosdpereira
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 3

..

\Guilty Gear XX Accent Core Plus R\Resource\pr\ver_100\obj:

- Contains every character file used by the game in AC+R mode.


- Files starting with "e" correspond to the EX versions of characters.
- Names correspond to the following:
sl.bin = Sol
ky.bin = Ky
my.bin = May
ml.bin = Millia
ax.bin = Axl
po.bin = Potemkin
ch.bin = Chipp
zt.bin = Eddie
bk.bin = Baiken
fa.bin = Faust
ts.bin = Testament
jm.bin = Jam
an.bin = Anji
jy.bin = Johnny
ve.bin = Venom
dz.bin = Dizzy
sy.bin = Slayer
in.bin = I-No
zp.bin = Zappa
yy.bin = Bridget
rk.bin = Robo-Ky
ab.bin = A.B.A
fr.bin = Order-Sol
kr.bin = Kliff
js.bin = Justice

- While in decompressed form, the binary begins with a variable amount of


relative pointers. The first
points to the player object, the last one points to the unused audio array,
and between them there are
all the extra objects owned by the character. For Slayer, however, the two
last pointers are to unused
audio arrays. These pointers are followed by 0xFF padding bytes, being either
the amount of missing
bytes in the last 16-byte row of the section, or 16 bytes if the data is
already aligned.

- The player object consists of four relative pointers, with them being
respectively for the Cells,
Sprites, Scripts and Palettes sections. Also has padding.

- Every other object follows the default object structure, being three
relative pointers to respectively,
the Cells, Sprites and Scripts sections. Ultimately they only don't have the
palettes section. Also has
padding.

- The Cells section consists of multiple relative pointers as well, each one
pointing to an individual
cell. Also has padding.

- Each cell then have the following structure:


Offset 0x0: Box Count (int)
Offset 0x4: Boxes Data { - repeats for every box
Suboffset 0x0: X Offset (short)
Suboffset 0x2: Y Offset (short)
Suboffset 0x4: Width (ushort)
Suboffset 0x6: Height (ushort)
Suboffset 0x8: Type (ushort)
Suboffset 0xA: Args (word)
}
Offset 0x4 + (Box Count * 12): Sprite X Offset (short)
Offset 0x6 + (Box Count * 12): Sprite Y Offset (short)
Offset 0x8 + (Box Count * 12): Unk (dword)
Offset 0xC + (Box Count * 12): Sprite Index (ushort)
- After every cell there is also padding bytes.

- Just like the Cells section, the Sprites section consists of multiple
relative pointers, each one
pointing to an individual sprite. Also has padding.

- Each sprite begins with a short 16-bytes long header that translated to the
following:
Offset 0x0: Mode (ushort)
Offset 0x2: clut (ushort)
Offset 0x4: Bit Depth (ushort)
Offset 0x6: Width (ushort)
Offset 0x8: Height (ushort)
Offset 0xA: tw (ushort)
Offset 0xC: th (ushort)
Offset 0xE: hash (ushort)

- After that, if clut is equal to 0x20, there will be an appended palette,


more about these in the
Palettes section.

- Then if mode is 0, the sprite will be uncompressed, so each byte (or half
for 4 bpp) corresponds to
a pixel, with their value being the index of the color they should use from
the provided palette.

- If mode is 1, the sprite will be in compressed format using LZSS. Keep in


mind, however, that the
bitstream is not correctly ordered because of endianess, every 16-bits chunk
must have the bytes swapped
in place first. Then to figure out literals and tokens, the structure is the
following:
- Reading 17 bits at a time
1 bit: flag (0: token, 1: literal)

when a literal:
8 bits: pixel 1
8 bits: pixel 2
when a token
9 bits: token offset
7 bits: token length

- Regardless of the parameters, a sprite will only have padding


bytes/separators if it is not aligned by
16-bytes, otherwise the next sprite will begin right after the previous one.

- For the Scripts section, things get slightly more complex, refer to the
scripts documentation for
proper info on that.

- For the Palettes section, there will be also multiple relative pointers,
each one pointing to an
individual palette, which all also have the same header as sprites, but
currently only the mode, clut and
bit depth field seems to be used, with mode always being "3", clut always
being "0x20", and the bit depth
telling the game in which order to read the palette and how many colors.

- After that, there will be 256 Big-Endian RGBA (with half alpha) colors.
- For embedded palettes, if a sprite is in 4 bpp, there will only be 16
colors.

You might also like