User talk:Ssg

Answers are in red.

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)