User talk:Ssg: Difference between revisions
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 | |||
: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)