OBD:Data types: Difference between revisions

From OniGalore
Jump to navigation Jump to search
m (more...)
m (→‎Appearance: note on subtypes)
Line 9: Line 9:
:Same for longs with high bits/bytes and more generally, IDs.
:Same for longs with high bits/bytes and more generally, IDs.
Ideally, the labels for recurring bitsets and ID fields should be hardcoded, but it's OK to have them in struct defs ATM.
Ideally, the labels for recurring bitsets and ID fields should be hardcoded, but it's OK to have them in struct defs ATM.
:Sorta "subtypes" for short, long, etc, depending on what function the field corresponds to (a ''lot'' of subtypes)...
::No hurry for that...




----
----
==Resource links==
==Resource links==
===Level ID===
===Level ID===

Revision as of 00:46, 22 March 2007

General notes

Struct defs

Place here suggestions for data type IDs (for new-gen struct defs).

Appearance

OUP could/should have special GUI settings for some of the types:

  • Links to other resources (in the long term, also links by label and non-file ID)
  • Vectors, AABBs, planes, transformation matrices, quaternions.
  • Bitsets: checkboxes with labels specified in the struct def
Same for longs with high bits/bytes and more generally, IDs.

Ideally, the labels for recurring bitsets and ID fields should be hardcoded, but it's OK to have them in struct defs ATM.

Sorta "subtypes" for short, long, etc, depending on what function the field corresponds to (a lot of subtypes)...
No hurry for that...


Resource links

Level ID

A few special mentions about the x2 thing and the IDs for _Tools files.

Resource ID

Those should certainly be typed: a different ID for every DAT-resource type.

RAW/SEP links

I would type those too: a different ID for every RAW/SEP-resource type.

Note that the size of the RAW/SEP data is not always provided.

Links by label

Those are special string subtypes. I wouldn't specify them right now.

(but you can try and draw a list of what links-by-label there are)

Links by ID

(not to be confused with links by ID to DAT resources)

E.g., vocalization IDs, melee profile IDs, combat behaviour IDs, etc.

In most cases, they are not links to DAT/RAW/SEP resources, but lookups to hardcoded tables (which are also part of OBD, sort of...)


Strings

checked past BINA...

16 chars

32 chars

48 chars

63 chars

64 chars

68 chars

128 chars

132 chars

160 chars

256 chars

364 chars


Floats

Float

4-byte IEEE float

(amount, distance, angle, ...)

Vector

3 floats define a vector in 3D space

(position, normal, ...)

Axis-aligned bounding box

2 vectors define a min corner and a max corner

used in

Plane

4 floats define an oriented plane in 3D

(see PLEA for algorithm)

Quaternion

4 floats define a quaternion

(always normalized, i.e., rotation w/o scaling?)

Translation and rotation

  • 3 floats define a translation
  • 3 others define a rotation (Euler angles)
used in

Transformation matrix

12 floats define a 4x4 transformation matrix

(translation, rotation, scaling, mirroring)


Integers

Mostly non-negative indices, so possibly unsigned.

One known exception: the quantized Euler angles in TRAM

char

ever used?

short

everywhere...

long

everywhere...

long with high bit

The lower bits are used for an ID, the high bit is a flag

used in
  • ...

long with high byte

The lower bytes are used for an ID, the high byte is a group ID

(used for MELE moves)

quantized float

e.g., quantized Euler angles in TRAM_

other stuff

lots of funny stuff in PAR3, maybe...


Bitsets

1 byte

2 bytes

4 bytes

8 bytes

Misc

32-bit color

Always RGBA?

used in

4-character codes

In various BINA raw/sep parts

OBD:AKVA_0

Pathfinding grids

Retrieved from "https://wiki.oni2.net/w/index.php?title=OBD:Data_types&oldid=5161"