Take this struct for example:
In katai, it becomes:
The useless steps being:
vs the lines and each field's declaration is less concise
As for the overhead, it generates a 80 line header and a c++ file that needs to be compiled (as well as depending on the katai library to build) for a struct that could've been read in one pointer dereference with the definition above just put in a header
Katai could be useful for other languages, but considering most coding done for the game above asm is in C++ (or even pure C, which katai doesn't support), it's not ideal here imo
Code:
typedef struct {
uint8_t unknkown_0x0;
uint8_t unknkown_0x1;
uint8_t padding[2]; // Ignored when copying to array
uint32_t objectId; // see http://wiki.tockdom.com/wiki/List_of_Identifiers#Items
uint32_t numberOfItems;
uint32_t unknown_0xc;
uint8_t unknown_0x10;
uint8_t padding2[3]; // Ignored when copying to array
ItemUseType useType;
void * useFunction; // Item is draggable if this is null
} ItemBehaviour; // Total size 0x1c
Code:
meta:
id: itembehaviour
endian: be
seq:
- id: body
type: body
types:
body:
seq:
- id: unknown_0x0
type: u1
- id: unknown_0x1
type: u1
- id: padding_0x2
size: 2
- id: objectid
type: u4
- id: numberofitems
type: u4
- id: unknown_0xc
type: u4
- id: unknown_0x10
type: u1
- id: padding_0x11
size: 3
- id: usetype
type: u4
- id: usefunction
type: u4
Code:
meta:
id: itembehaviour
endian: be
seq:
- id: body
type: body
types:
Code:
typedef struct {
} ItemBehaviour; // Total size 0x1c
As for the overhead, it generates a 80 line header and a c++ file that needs to be compiled (as well as depending on the katai library to build) for a struct that could've been read in one pointer dereference with the definition above just put in a header
Katai could be useful for other languages, but considering most coding done for the game above asm is in C++ (or even pure C, which katai doesn't support), it's not ideal here imo