Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualServant of the Lord

Posted 08 July 2013 - 03:20 PM

Looking here, assuming this is the same format you're talking about, it seems some of the numbers are spaced so as to provide future expansion or revisions.

 

For example:

0x4000 // Object Block
│  │  ├─ 0x4100 // Triangular Mesh
│  │  │  ├─ 0x4110 // Vertices List
│  │  │  ├─ 0x4120 // Faces Description
│  │  │  │  ├─ 0x4130 // Faces Material
│  │  │  │  └─ 0x4150 // Smoothing Group List
│  │  │  ├─ 0x4140 // Mapping Coordinates List
│  │  │  └─ 0x4160 // Local Coordinates System
│  │  ├─ 0x4600 // Light
│  │  │  └─ 0x4610 // Spotlight
│  │  └─ 0x4700 // Camera

You'll notice they leave spaces for future blocks, and I'd bet that the lowest digit (0x414X) is for future versions of the same block.

Once they start putting out files with numbers, those numbers are locked in stone. They can add new numbers, but they can't reuse old numbers or it'll break backwards compatibility. If they need an arbitrary number for identification, e.g. to identify a "light" chunk (0x4600) of the object block (0x4000), then they might as well space out their numbers enough to leave room for additional chunk types and additional subchunks (like Spotlight - 0x4610) and versions (0x4610). I'm speculating that the final digit is for versions.

 

See FourCC (did someone already post that? I thought someone did). 

"In 1985, Electronic Arts introduced the Interchange File Format (IFF) meta-format (family of file formats), originally devised for use on the Amiga. These files consisted of a sequence of "chunks" which could contain arbitrary data, each chunk prefixed by a four-byte ID. The IFF specification explicitly mentions that the origins of the FourCC idea lie with Apple.

...

Other file formats that make important use of the four-byte ID concept are the Standard MIDI File Format, the PNG image file format, the 3DS (3D Studio Max) mesh file format and the ICC profile format."

 

It also says, "Four byte identifiers are useful because they can be made up of four human-readable characters with mnemonic qualities, while still fitting in the four byte memory space typically allocated for integers in 32-bit systems (although endian issues may make them less readable). Thus, the codes can be used efficiently in program code as integers as well as giving cues in binary data streams when inspected."

 

So, while observing the data of the binary files in a hex editor, it's easier to visually see the chunk identifiers. See 0xDEADC0DE again. wink.png

This kind of thing is useful for debugging. Imagine trying to figure out where you are in a pile of hex values in RAM in Microsoft Visual Studio, and suddenly you see 0xBAADF00D. You know the memory was A) Allocated on the heap and B) never initialized properly.


#2Servant of the Lord

Posted 08 July 2013 - 03:11 PM

Looking here, assuming this is the same format you're talking about, it seems some of the numbers are spaced so as to provide future expansion or revisions.

 

For example:

0x4000 // Object Block
│  │  ├─ 0x4100 // Triangular Mesh
│  │  │  ├─ 0x4110 // Vertices List
│  │  │  ├─ 0x4120 // Faces Description
│  │  │  │  ├─ 0x4130 // Faces Material
│  │  │  │  └─ 0x4150 // Smoothing Group List
│  │  │  ├─ 0x4140 // Mapping Coordinates List
│  │  │  └─ 0x4160 // Local Coordinates System
│  │  ├─ 0x4600 // Light
│  │  │  └─ 0x4610 // Spotlight
│  │  └─ 0x4700 // Camera

You'll notice they leave spaces for future blocks, and I'd bet that the lowest digit (0x414X) is for future versions of the same block.

Once they start putting out files with numbers, those numbers are locked in stone. They can add new numbers, but they can't reuse old numbers or it'll break backwards compatibility. If they need an arbitrary number for identification, e.g. to identify a "light" chunk (0x4600) of the object block (0x4000), then they might as well space out their numbers enough to leave room for additional chunk types and additional subchunks (like Spotlight - 0x4610) and versions (0x4610). I'm speculating that the final digit is for versions.


#1Servant of the Lord

Posted 08 July 2013 - 03:10 PM

Looking here, assuming this is the same format you're talking about, it seems some of the numbers are spaced so as to provide future expansion or revisions.

 

For example:

0x4000 // Object Block
│  │  ├─ 0x4100 // Triangular Mesh
│  │  │  ├─ 0x4110 // Vertices List
│  │  │  ├─ 0x4120 // Faces Description
│  │  │  │  ├─ 0x4130 // Faces Material
│  │  │  │  └─ 0x4150 // Smoothing Group List
│  │  │  ├─ 0x4140 // Mapping Coordinates List
│  │  │  └─ 0x4160 // Local Coordinates System
│  │  ├─ 0x4600 // Light
│  │  │  └─ 0x4610 // Spotlight
│  │  └─ 0x4700 // Camera

You'll notice they leave spaces for future blocks, and I'd bet that the lowest digit (0x414X) is for future versions of the same block.

Once they start putting out files with numbers, those numbers are locked in stone. They can add new numbers, but they can't reuse old numbers or it'll break backwards compatibility. If they need an arbitrary number for identification, e.g. to identify a "light" chunk (0x4600) of the object chunk (0x4000), then they might as well space out their numbers enough to leave room for additional chunk types and additional subchunks (like Spotlight - 0x4610) and versions (0x4610). I'm speculating that the final digit is for versions.


PARTNERS