User talk:Ssg: Difference between revisions

From OniGalore
Jump to navigation Jump to search
m (navi.TXMP)
m (answer)
Line 24: Line 24:
:Not '''g206_controls_128x64.TXMP''', but something close...
:Not '''g206_controls_128x64.TXMP''', but something close...
::[[User:Geyser|geyser]] 20:14, 24 September 2007 (CEST)
::[[User:Geyser|geyser]] 20:14, 24 September 2007 (CEST)
<!--
<nowiki><font color=red>Answers are in red.</font>
<small>Mine are in small print.</small>
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". <font color=red>Oooohh... ummmm... that's somehow stored wrong in my head.</font>
<font color=red>To your text below:</font>
<font color=red size=7>I. DO. NOT. AGREE.</font>
: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)
----
----
----
To 1:
: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''.
<font color=red></font>
::[[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. <font color=red>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.</font>
: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'') <font color=red>That's a really a real problem. *hmpf*</font>
:Whereas having a vector type makes the description much lighter and more to the point
::(e.g., "translation in parent space / world space / whatever") <font color=red>If you're refering to the creepy [[OBD:OBAN|OBAN]] tables, forget it.</font>
: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 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? <font color=red>An overwiev table is not the same as a code snippet.</font>
::[[User:Geyser|geyser]] 01:30, 5 September 2007 (CEST)


#added WMDDs from Level0_Tools.dat to Level0_Final.dat
#replaced the dialog ID (0x108) of the [[OBD:WMDD|WMDD]] with the dialog ID of the help-window (or whatever it's called; it's the window that pops up when you press F1)


----
To 2:
----
:I'm not sure what you mean. Do you refer to the fact that some stuff in the iamges is overlapping? (If yes: Well, I never thought about that. I was too fixated on making the WMMDs visible, I guess.)
 
: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]] <font color=red>No, I don't. Sorry. My mistake. Please delete the word file in the previous sentence.</font>
::(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". <font color=red>??? Why ??? I only try to change the design. Plus wiki saves the original wiki code.</font>
::[[User:Geyser|geyser]] 01:30, 5 September 2007 (CEST)
 
 
 
----
----
----
<small>
: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 [[wikipedia:Little_Endian|Little Endian]], as well as specific notes about the [[wikipedia:IEEE_float|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.
::[[User:Geyser|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'''.
::[[User:Geyser|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).
::[[User:Geyser|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
{{Table}}
{{OBD Table Header}}
{{OBDtr|0x00|res_id|FF0000|01 '''86 00 00'''|134|00134-Blackvan_FB.OBAN}}
{{OBDtr|0x04|lev_id|FFFF00|01 00 00 '''06'''|3  |level 3}}
{{OBDtr|0x08|blank[16]|00FF00|00 00 00 00  |0  |blank filler}}
|- ALIGN=CENTER VALIGN=TOP
|0x18||matrix||
{|border=1 cellspacing=0 style="white-space:nowrap"
|-BGCOLOR="#FFC8C8"
|C2 F5 E8 3F||AB D7 AA B3||EC 89 13 35
|-BGCOLOR="#FFFFC8"
|EC 89 13 35||ED 89 13 B4||C2 F5 E8 BF
|-BGCOLOR="#C8FFC8"
|B1 D7 AA 33||C2 F5 E8 3F||EB 89 13 B4
|-BGCOLOR="#C8FFFF"
|6B 9A 94 44||97 FD 5B C2||5D 06 DA C2
|}
|
{|border=1 cellspacing=0 style="white-space:nowrap"
|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
|}
|ALIGN=LEFT|initial position transform matrix
|- ALIGN=CENTER VALIGN=TOP
|0x48||matrix||
{|border=1 cellspacing=0 style="white-space:nowrap"
|-BGCOLOR="#FFC8FF"
|C2 F5 E8 3F||00 00 00 00||00 00 00 00
|-BGCOLOR="#FFC800"
|00 00 00 00||C2 F5 E8 3F||00 00 00 00
|-BGCOLOR="#C800C8"
|00 00 00 00||00 00 00 00||C2 F5 E8 3F
|-BGCOLOR="#C87C64"
|00 00 00 00||00 00 00 00||00 00 00 00
|}
|
{|border=1 cellspacing=0 style="white-space:nowrap"
|1.819999||0.0||0.0
|-
|0.0||1.819999||0.0
|-
|0.0||0.0||1.819999
|-
|0.0||0.0||0.0
|}
| ALIGN=LEFT | fixed transform matrix
{{OBDtr|0x78|int16|B0C3D4|50 00|80  |unknown}}
{{OBDtr|0x7A|int16|E7CEA5|F5 01|501 |animation length in frames}}
{{OBDtr|0x7C|int16|FFDDDD|00 00|0 |unknown}}
{{OBDtr|0x7E|int16|64AAAA|65 00|10 |101 keyframes in array}}
{{OBDtrBK|First keyframe (black outline)}}
|- ALIGN=CENTER VALIGN=TOP
|0x00||quaternion||
{|border=1 cellspacing=0 style="white-space:nowrap"
|-BGCOLOR="#EBEBEB"
| F4 04 35 BF||6A 19 C4 B3||CE 3C 03 B4||F3 04 35 BF
|}
|
{|border=1 cellspacing=0 style="white-space:nowrap"
| -0.7071068|| -9.131584e-8|| -1.222244e-7|| -0.7071067
|}
|ALIGN=LEFT|object rotation
|- ALIGN=CENTER VALIGN=TOP
|0x10||vector||
{|border=1 cellspacing=0 style="white-space:nowrap"
|-BGCOLOR="#8C8CCC"
|C2 F5 E8 3F||AB D7 AA B3||EC 89 13 35
|}
|
{|border=1 cellspacing=0 style="white-space:nowrap"
|1188.825561||-54.997646||-109.012428
|}
|ALIGN=LEFT|object position
{{OBDtr|0x1C|int32|FF00C8|00 00 00 00  |0  |elapsed time in frames}}
|}
::;2. Without aggregate types
{{Table}}
{{OBD Table Header}}
{{OBDtr|0x00|res_id|FF0000|01 '''86 00 00'''|134|00134-Blackvan_FB.OBAN}}
{{OBDtr|0x04|lev_id|FFFF00|01 00 00 '''06'''|3  |level 3}}
{{OBDtr|0x08|blank[16]|00FF00|00 00 00 00  |0  |blank filler}}
{{OBDtr|0x18|float|FFC8C8|C2 F5 E8 3F|1.819999|m11 element of the initial position transform matrix}}
{{OBDtr|0x1C|float|FFC8C8|AB D7 AA B3|-7.955471e-8|m21 element of the initial position transform matrix}}
{{OBDtr|0x20|float|FFC8C8|EC 89 13 35|5.496247e-7|m31 element of the initial position transform matrix}}
{{OBDtr|0x24|float|FFFFC8|EC 89 13 35|5.496247e-7|m12 element of the initial position transform matrix}}
{{OBDtr|0x28|float|FFFFC8|ED 89 13 B4|-1.374061e-7|m22 element of the initial position transform matrix}}
{{OBDtr|0x2C|float|FFFFC8|C2 F5 E8 BF|-1.819999|m32 element of the initial position transform matrix}}
{{OBDtr|0x30|float|C8FFC8|B1 D7 AA 33|7.955475e-8|m13 element of the initial position transform matrix}}
{{OBDtr|0x34|float|C8FFC8|C2 F5 E8 3F|1.819999|m23 element of the initial position transform matrix}}
{{OBDtr|0x38|float|C8FFC8|EB 89 13 B4|-1.374061e-7|m33 element of the initial position transform matrix}}
{{OBDtr|0x3C|float|C8FFFF|6B 9A 94 44|1188.825561|m14 element of the initial position transform matrix}}
{{OBDtr|0x40|float|C8FFFF|97 FD 5B C2|-54.997646|m24 element of the initial position transform matrix}}
{{OBDtr|0x44|float|C8FFFF|5D 06 DA C2|-109.012428|m34 element of the initial position transform matrix}}
{{OBDtr|0x48|float|FFC8FF|C2 F5 E8 3F|1.819999|m11 element of the fixed position transform matrix}}
{{OBDtr|0x4C|float|FFC8FF|00 00 00 00|0.0|m21 element of the fixed position transform matrix}}
{{OBDtr|0x50|float|FFC8FF|00 00 00 00|0.0|m31 element of the fixed position transform matrix}}
{{OBDtr|0x54|float|FFC800|00 00 00 00|0.0|m12 element of the fixed position transform matrix}}
{{OBDtr|0x58|float|FFC800|C2 F5 E8 3F|1.819999|m22 element of the fixed position transform matrix}}
{{OBDtr|0x5C|float|FFC800|00 00 00 00|0.0|m32 element of the fixed position transform matrix}}
{{OBDtr|0x60|float|C800C8|00 00 00 00|0.0|m13 element of the fixed position transform matrix}}
{{OBDtr|0x64|float|C800C8|00 00 00 00|0.0|m23 element of the fixed position transform matrix}}
{{OBDtr|0x68|float|C800C8|C2 F5 E8 3F|1.819999|m33 element of the fixed position transform matrix}}
{{OBDtr|0x6C|float|C87C64|00 00 00 00|0.0|m14 element of the fixed position transform matrix}}
{{OBDtr|0x70|float|C87C64|00 00 00 00|0.0|m24 element of the fixed position transform matrix}}
{{OBDtr|0x74|float|C87C64|00 00 00 00|0.0|m34 element of the fixed position transform matrix}}
{{OBDtr|0x78|int16|B0C3D4|50 00|80  |unknown}}
{{OBDtr|0x7A|int16|E7CEA5|F5 01|501 |animation length in frames}}
{{OBDtr|0x7C|int16|FFDDDD|00 00|0 |unknown}}
{{OBDtr|0x7E|int16|64AAAA|65 00|10 |101 keyframes in array}}
{{OBDtrBK|First keyframe (black outline)}}
{{OBDtr|0x00|float|EBEBEB| F4 04 35 BF| -0.7071068 | x-value of the rotation quaternion}}
{{OBDtr|0x04|float|EBEBEB| 6A 19 C4 B3| -9.131584e-8 | y-value of the rotation quaternion}}
{{OBDtr|0x08|float|EBEBEB| CE 3C 03 B4| -1.222244e-7 | z-value of the rotation quaternion}}
{{OBDtr|0x0C|float|EBEBEB| F3 04 35 BF| -0.7071067 | w-value of the rotation quaternion}}
{{OBDtr|0x10|float|8C8CCC| 6B 9A 94 44| 1188.825561 | x-position}}
{{OBDtr|0x14|float|8C8CCC| 97 FD 5B C2| -54.997646 | y-position (height)}}
{{OBDtr|0x18|float|8C8CCC| 5D 06 DA C2| -109.012428 | z-position}}
{{OBDtr|0x1C|int32|FF00C8| 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.
::[[User:Geyser|geyser]] 00:59, 6 September 2007 (CEST)
</small></nowiki>
-->
 
<!-- please don't delete this
http://14mb.de/u/ccc/botright.gif
-->

Revision as of 21:02, 24 September 2007

I've found the following two templates:


  • OBD_Table_Header
  • OBDth


Both contain the same code:


|- BGCOLOR="#E9E9E9" ! WIDTH=5% | Offset || WIDTH=5% | Type || WIDTH=10% | Raw Hex || WIDTH=10% | Value || WIDTH=70% | Description


Which one should I use? IMO, OBDth looks better.


th ^_^
geyser 17:32, 9 September 2007 (CEST)
About the BBBB screenshots you've been adding to BINA
  1. It would be nice if you described how they were obtained.
  2. Are you sure navi.TXMP and buttons.TXMP are appropriate?
I'm pretty sure there is another, more plain-looking TXMP.
Not g206_controls_128x64.TXMP, but something close...
geyser 20:14, 24 September 2007 (CEST)

To 1:

  1. added WMDDs from Level0_Tools.dat to Level0_Final.dat
  2. replaced the dialog ID (0x108) of the WMDD with the dialog ID of the help-window (or whatever it's called; it's the window that pops up when you press F1)

To 2:

I'm not sure what you mean. Do you refer to the fact that some stuff in the iamges is overlapping? (If yes: Well, I never thought about that. I was too fixated on making the WMMDs visible, I guess.)
Retrieved from "https://wiki.oni2.net/w/index.php?title=User_talk:Ssg&oldid=5985"