User talk:Ssg

From OniGalore
Revision as of 22:59, 5 September 2007 by Geyser (talk | contribs) (reveni revidi)
Jump to navigation Jump to search

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[16] blank_space;
    Matrix transform_initial;
    Matrix transform_fixed;
    short shpadoinkle1;
    short frames;
    short shpadoinkle2;
    short n_keyframes;
    ObjectAnimationKeyframe[n_keyframes] 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[16] blank_space;
    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[n_keyframes] 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[16] blank_space;     // 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[n_keyframes] 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)


Retrieved from "https://wiki.oni2.net/w/index.php?title=User_talk:Ssg&oldid=5664"