User talk:Ssg: Difference between revisions

From OniGalore
Jump to navigation Jump to search
m (Help page?)
m (veni vidi)
Line 21: Line 21:


boolean          = bool
boolean          = bool
color            = color
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).
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


>>I'd strongly suggest vectors, quaternions, planes and matrices.
:It's "length".
: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 [[wikipedia:bitfield|bitfield]]s 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]].
::[[User:Geyser|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". [[User:Ssg|Ssg]] 23:04, 4 September 2007 (CEST)
----
:I'd strongly suggest vectors, quaternions, planes and matrices.
::[[User:Geyser|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".
::[[User:Ssg|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''.
::[[User:Geyser|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.
: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'')
:Whereas having a vector type makes the description much lighter and more to the point
::(e.g., "translation in parent space / world space / whatever")
:In the case of the vector, at least, I'm sure that I'm right (it's that way in Oni) ^^
::[[User:Geyser|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?
::[[User:Geyser|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, ...).
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]]
::(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".
::[[User:Geyser|geyser]] 01:30, 5 September 2007 (CEST)


<!-- please don't delete this
<!-- please don't delete this
http://14mb.de/u/ccc/botright.gif
http://14mb.de/u/ccc/botright.gif
-->
-->

Revision as of 23:30, 4 September 2007

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".
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.
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)
Whereas having a vector type makes the description much lighter and more to the point
(e.g., "translation in parent space / world space / whatever")
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?
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
(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".
geyser 01:30, 5 September 2007 (CEST)