User talk:Ssg

Answers are in red.

Mine are in small print.

Let's see what we have:

file id = res_id

level id = lev_id

unsigned integer = uint + lenght in bits

signed integer = int + lenght in bits

high bit = hb

float = float

link = link

raw offset = offset

string = char[lenght in bytes]

boolean = bool

color = color

bitset = bitset (In my interpretation a bitset has a lenght of one byte. "Bool" for bitsets is a bit confusing in my opinion. If I recall correctly Oni uses only "bitset collections", which are 4 bitsets in a row (so always 4 bytes are used, even if there's no need for 4 bytes).

ssg

It's "length". Oooohh... ummmm... that's somehow stored wrong in my head.

To your text below:

I. DO. NOT. AGREE.

SE2 uses COLOR (capitals) as the RGBA type. "color" is mostly OK.

"link" (or "link32") is essentially the same type as "res_id", right?

Both "link" and "offset" are a bit vague and too weakly typed IMO.

See below for the strong typing (WAHA*, VOID*, WAHA0*, etc...)

You may be right about bitfields usually spanning 32 bits.

(even though there might be a 16-bit bitfield in WMDD)

It's OK to split bitfields in 8-bit or 16-bit groups

(but only when it means some actual thematic grouping)

The bool32, bool16 and bool8 notation doesn't shock me

(also, I can't see what a "bool" is... any example?)

As for the high bit, I still think int31bool1 (or int31int1) is better.

I also suggest int12int20, int8int24 and int9int9int9int5 for OTLF.

geyser 01:30, 5 September 2007 (CEST)

---

---

I'd strongly suggest vectors, quaternions, planes and matrices.

geyser 01:30, 5 September 2007 (CEST)

---

IMO that's not a good idea. It turns "type" more into a "description". F.e. a vector is stored as a float (column "type"). The information that this float is a vector should be placed in the column "description".

Ssg 23:04, 4 September 2007 (CEST)

---

Well, types are always descriptive: more or less so depending on how "strongly typed" the system is.

IMO it's better to have the OBD pages as strongly typed as possible; so, very descriptive types.

It's not always justified, but in the case of matrices, vectors, etc, it almost certainly is.

geyser 01:30, 5 September 2007 (CEST)

For instance, a vector is not a float but a group (struct) of three consistent floats.

None of the three floats makes any sense without its two buddies, hence the vector type. Again. A float is a float. If the float is a part of a vector, then it should be mentioned in the "description" column. That's the function of this column. Plus if you write "vector" into the "type" column, nobody knows really the type. Vector could be anything. A bunch of floats or integers or doubles or whatever.

Also, treating it as 3 floats leads to redundant entries in the "description" column

("x-component of ...", "y-component of ...", "z-component of ..." ... every time) That's a really a real problem. *hmpf*

Whereas having a vector type makes the description much lighter and more to the point

(e.g., "translation in parent space / world space / whatever") If you're refering to the creepy OBAN tables, forget it.

In the case of the vector, at least, I'm sure that I'm right (it's that way in Oni) ^^

geyser 01:30, 5 September 2007 (CEST)

I.e. in Oni's source you'd have something like this:

typedef struct Vector {
    float x, y, z;
};
typedef struct Quaternion {
    float x, y, z, w;
};
typedef struct Matrix {
    float x1, y1, z1;
    float x2, y2, z2;
    float x3, y3, z2;
    float x4, y4, z4;
};

And then, in the definition of the file type OBAN:

typedef struct ObjectAnimationKeyframe {
    Quaternion rotation;
    Vector position;
    short time;
};
typedef struct OBAN {
    char blank_space[16];
    Matrix transform_initial;
    Matrix transform_fixed;
    short shpadoinkle1;
    short frames;
    short shpadoinkle2;
    short n_keyframes;
    ObjectAnimationKeyframe keyframes[n_keyframes];
}

I don't mean that's exactly how Oni's source looks like,

but it makes much more sense to me as a coder than this:

typedef struct ObjectAnimationKeyframe {
    float rotation_x;
    float rotation_y;
    float rotation_z;
    float rotation_w;
    float position_x;
    float position_y;
    float position_z;
    short time;
};
typedef struct OBAN {
    char blank_space[16];
    float transform_initial_x1;
    float transform_initial_y1;
    float transform_initial_z1;
    float transform_initial_x2;
    float transform_initial_y2;
    float transform_initial_z2;
    float transform_initial_x3;
    float transform_initial_y3;
    float transform_initial_z3;
    float transform_initial_x4;
    float transform_initial_y4;
    float transform_initial_z4;
    float transform_fixed_x1;
    float transform_fixed_y1;
    float transform_fixed_z1;
    float transform_fixed_x2;
    float transform_fixed_y2;
    float transform_fixed_z2;
    float transform_fixed_x3;
    float transform_fixed_y3;
    float transform_fixed_z3;
    float transform_fixed_x4;
    float transform_fixed_y4;
    float transform_fixed_z4;
    short shpadoinkle1;
    short frames;
    short shpadoinkle2;
    short n_keyframes;
    ObjectAnimationKeyframe keyframes[n_keyframes];
}

Do I have to explain why I like the first OBAN better? An overwiev table is not the same as a code snippet.

geyser 01:30, 5 September 2007 (CEST)

---

---

Maybe we should add a help page for the file types. This page explains the different types (float, integer, lev_id, links, ...) and how to read them (right to left, if a link ignore the 01, ...).

ssg

"File" types??? Do you mean something like this? OBD:Data_types No, I don't. Sorry. My mistake. Please delete the word file in the previous sentence.

(I had invited you to have a look at it several times AFAIR)

Note that since you're explaining the types anyway,

it shouldn't hurt to have a few "complex" types (structs).

Feel free to edit types out, but keep a copy in "discussion". ??? Why ??? I only try to change the design. Plus wiki saves the original wiki code.

geyser 01:30, 5 September 2007 (CEST)

---

---

---

From the bottom:

Please have a look at OBD:Data_types. It is very much like the "help page for the types" you suggest.

It needs some general remarks about Little Endian, as well as specific notes about the IEEE floats etc.

That's also where you'd have remarks on the level and resource ID format (low-byte 01, name hash, etc).

(for example, note that the level ID in level0_Tools.dat is DD 01 00 00 instead of 01 00 00 00)

If you object to aggregate types (or rather, since you object to aggregate types), feel free to remove them.

(I meant trimming the complete list in OBD:Data_types; nothing to do with your update of file type pages)

However, please back up the full collection of types in OBD_talk:Data_types, for convenient reference.

geyser 00:59, 6 September 2007 (CEST)

About aggregate types:

Since you are going to explain basic types in detail on a "help page", why not explain aggregate types, too?

Vectors, matrices and quaternions are very common objects in 3D graphics, so they will make immediate sense.

The matrix/vector/quaternion form is explicitly shown in the Raw hex and Value columns: no confusion possible.

In the OBAN example, it's easy to see that vectors, matrices and quaternions are structured groups of floats.

If people don't know what a vector, a matrix or a quaternion is, they'll see the structure in the Value column.

They'll see that they're bunches of floating-point values, and if they want more details, there's the help page.

As for the Description column, it will still explain the actual role of the vector, matrix, plane or quaternion.

Just as you don't detail the format of every float bit-by-bit, you shouldn't have to break down vectors etc...

You don't have to agree, but IMO the Description column should describe the actual function of the data.

As for the nature of the data, it should be clear from the other three columns: Type, Raw Hex and Value.

geyser 00:59, 6 September 2007 (CEST)

About union integer types (funny integers and bitfields):

bool32 and bool16 are indeed misleading: bool1[16] and bool1[32] are better. Another solution is flags16 and flags32.

However, int31flags1 will look weird, so for the indices with a high bit I'd recommend int31bool1 or (better) int31int1.

That would be consistent with int9int9int9int5, int12int20 and int8int24 in OTLF. And flags16 and flags32. There.

As for the signed-unsigned ambiguity, most of Oni's integers are positive and small, so there is no difference.

Some of them are expicitly signed (e.g., whenever -1 is allowed), but the rest of the time it doesn't matter.

So the above union types should actually be uint31uint1, uint9uint9uint9uint5, uint12uint20 and uint8uint24...

But since there are very few signed integers in Oni, I'd just drop the "u" and disambiguate when necessary.

Another option is to have "int" for usual integers (unsigned) and enum8, enum16, enum32 for IDs (signed).

geyser 00:59, 6 September 2007 (CEST)

About the "creepy OBAN table":

There's no arguing that "An overview table is not the same as a code snippet."

However, note that both are structures meant to define/describe the data format.

As an intermediate structure, you have the OUP "structdefs". So, not the same?

If you add comments to a C-style structure definition, you get an OBD table:

typedef struct ObjectAnimationKeyframe { // element of the array in OBAN
    Quaternion rotation; // 0x00 // rotation of the object (applied after fixed matrix)
    Vector position;     // 0x10 // absolute position of the object in the world
    short time;          // 0x1C // keyframe time in frames (60 frames in a second)
};
typedef struct OBAN {
    char blank_space[16];     // 0x00 // used for pointers at runtime
    Matrix transform_initial; // 0x10 // initial transform matrix (before animation)
    Matrix transform_fixed;   // 0x40 // fixed transform matrix (e.g., scaling)
    short shpadoinkle1;       // 0x70 // I wonder what this button does...
    short frames;             // 0x72 // object animation length, in frames
    short shpadoinkle2;       // 0x74 // I wonder what *this* button does, too...
    short n_keyframes;        // 0x76 // number of keyframes in array
    ObjectAnimationKeyframe keyframes[n_keyframes]; // 0x78 // array of keyframes
}

And since my point about vectors, matrix and quaternions was out of context:

I claim that variant #1 below is much more tidy and readable than variant #2.

1. Using aggregate types

Offset	Type	Raw Hex	Value	Description
0x00	res_id	01 86 00 00	134	00134-Blackvan_FB.OBAN
0x04	lev_id	01 00 00 06	3	level 3
0x08	blank[16]	00 00 00 00	0	blank filler
0x18	matrix	C2 F5 E8 3F AB D7 AA B3 EC 89 13 35 EC 89 13 35 ED 89 13 B4 C2 F5 E8 BF B1 D7 AA 33 C2 F5 E8 3F EB 89 13 B4 6B 9A 94 44 97 FD 5B C2 5D 06 DA C2	1.819999 -7.955471e-8 5.496247e-7 5.496247e-7 -1.374061e-7 -1.819999 7.955475e-8 1.819999 -1.374061e-7 1188.825561 -54.997646 -109.012428	initial position transform matrix
0x48	matrix	C2 F5 E8 3F 00 00 00 00 00 00 00 00 00 00 00 00 C2 F5 E8 3F 00 00 00 00 00 00 00 00 00 00 00 00 C2 F5 E8 3F 00 00 00 00 00 00 00 00 00 00 00 00	1.819999 0.0 0.0 0.0 1.819999 0.0 0.0 0.0 1.819999 0.0 0.0 0.0	fixed transform matrix
0x78	int16	50 00	80	unknown
0x7A	int16	F5 01	501	animation length in frames
0x7C	int16	00 00	0	unknown
0x7E	int16	65 00	10	101 keyframes in array
First keyframe (black outline)
0x00	quaternion	F4 04 35 BF 6A 19 C4 B3 CE 3C 03 B4 F3 04 35 BF	-0.7071068 -9.131584e-8 -1.222244e-7 -0.7071067	object rotation
0x10	vector	C2 F5 E8 3F AB D7 AA B3 EC 89 13 35	1188.825561 -54.997646 -109.012428	object position
0x1C	int32	00 00 00 00	0	elapsed time in frames

2. Without aggregate types

Offset	Type	Raw Hex	Value	Description
0x00	res_id	01 86 00 00	134	00134-Blackvan_FB.OBAN
0x04	lev_id	01 00 00 06	3	level 3
0x08	blank[16]	00 00 00 00	0	blank filler
0x18	float	C2 F5 E8 3F	1.819999	m11 element of the initial position transform matrix
0x1C	float	AB D7 AA B3	-7.955471e-8	m21 element of the initial position transform matrix
0x20	float	EC 89 13 35	5.496247e-7	m31 element of the initial position transform matrix
0x24	float	EC 89 13 35	5.496247e-7	m12 element of the initial position transform matrix
0x28	float	ED 89 13 B4	-1.374061e-7	m22 element of the initial position transform matrix
0x2C	float	C2 F5 E8 BF	-1.819999	m32 element of the initial position transform matrix
0x30	float	B1 D7 AA 33	7.955475e-8	m13 element of the initial position transform matrix
0x34	float	C2 F5 E8 3F	1.819999	m23 element of the initial position transform matrix
0x38	float	EB 89 13 B4	-1.374061e-7	m33 element of the initial position transform matrix
0x3C	float	6B 9A 94 44	1188.825561	m14 element of the initial position transform matrix
0x40	float	97 FD 5B C2	-54.997646	m24 element of the initial position transform matrix
0x44	float	5D 06 DA C2	-109.012428	m34 element of the initial position transform matrix
0x48	float	C2 F5 E8 3F	1.819999	m11 element of the fixed position transform matrix
0x4C	float	00 00 00 00	0.0	m21 element of the fixed position transform matrix
0x50	float	00 00 00 00	0.0	m31 element of the fixed position transform matrix
0x54	float	00 00 00 00	0.0	m12 element of the fixed position transform matrix
0x58	float	C2 F5 E8 3F	1.819999	m22 element of the fixed position transform matrix
0x5C	float	00 00 00 00	0.0	m32 element of the fixed position transform matrix
0x60	float	00 00 00 00	0.0	m13 element of the fixed position transform matrix
0x64	float	00 00 00 00	0.0	m23 element of the fixed position transform matrix
0x68	float	C2 F5 E8 3F	1.819999	m33 element of the fixed position transform matrix
0x6C	float	00 00 00 00	0.0	m14 element of the fixed position transform matrix
0x70	float	00 00 00 00	0.0	m24 element of the fixed position transform matrix
0x74	float	00 00 00 00	0.0	m34 element of the fixed position transform matrix
0x78	int16	50 00	80	unknown
0x7A	int16	F5 01	501	animation length in frames
0x7C	int16	00 00	0	unknown
0x7E	int16	65 00	10	101 keyframes in array
First keyframe (black outline)
0x00	float	F4 04 35 BF	-0.7071068	x-value of the rotation quaternion
0x04	float	6A 19 C4 B3	-9.131584e-8	y-value of the rotation quaternion
0x08	float	CE 3C 03 B4	-1.222244e-7	z-value of the rotation quaternion
0x0C	float	F3 04 35 BF	-0.7071067	w-value of the rotation quaternion
0x10	float	6B 9A 94 44	1188.825561	x-position
0x14	float	97 FD 5B C2	-54.997646	y-position (height)
0x18	float	5D 06 DA C2	-109.012428	z-position
0x1C	int32	00 00 00 00	0	elapsed time in frames

There.

If you say loud and clear "variant #2 is nicer", I won't even try to argue.

We don't have to agree on that matter and I'm quite happy either way.

geyser 00:59, 6 September 2007 (CEST)