From caec2689b54843d05224ad457ff30db9caa63fae Mon Sep 17 00:00:00 2001 From: angelsl Date: Mon, 17 Jun 2013 19:02:58 +0800 Subject: [PATCH 01/14] NX Spec: Squash PKG5 commits. NX Spec: Bring PKG5 up to master branch. NX Spec: Use instead of NX Spec: Update acknowledgements; @aaronweiss74 NX Spec: Metadata fields in byte arrays and header. NX Spec: Rewrite PKG5. Now backwards-compatible with PKG4 for servers. NX Spec: Correct inconsistency. NX Spec: Add string null terminator, and Metadata field for WZ-specific data. NX Spec: Allow omission of bitmaps/audio. (WZ) NX Spec: Fix small errors; more specific. NX Spec: Missed one MP3. NX Spec: Refine WZ-specific data types. NX Spec: Add WZ-specific data types. NX Spec: Begin 4th version. Signed-off-by: angelsl --- README.md | 4 +-- index.html | 80 ++++++++++++++++++++++++++++++++++++++---------------- 2 files changed, 58 insertions(+), 26 deletions(-) diff --git a/README.md b/README.md index 6f589c7..44811a7 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,3 @@ -#NX Specification [PKG4] +#4th NX Format Specification [PKG5] -This repository hosts the NX (PKG4) specification, which is currently under development. \ No newline at end of file +This repository hosts the 4th NX Format (PKG5) specification, which is currently under development. \ No newline at end of file diff --git a/index.html b/index.html index ddd36ae..9c50de6 100644 --- a/index.html +++ b/index.html @@ -1,7 +1,7 @@ -NX (PKG4) Format Specification +NX (PKG5) Format Specification -

3rd NX File Format [PKG4.1]

+

4th NX File Format [PKG5]

The NX file format was designed with speediness and ease of reading in mind, to speed up loading times for anything that uses a node-tree-based data file format.

In the NX file format, the following should be followed:

@@ -68,25 +68,26 @@

Recommended File Format

Node dataNode[]Node data, including all children. String offset tableUInt64[]String offset table. Contiguous block. String dataString[]String data. -Bitmap offset tableUInt64[]Bitmap offset table. Contiguous block. -BitmapsBitmap[]Bitmap data. -Audio offset tableUInt64[]Audio offset table. Contiguous block. -Audio dataAudio[]Audio data. +Compressed Byte Array offset tableUInt64[]Compressed Byte Array offset table. Contiguous block. +Compressed Byte ArraysCompressed Byte Array[]Compressed byte array data. +Uncompressed Byte Array offset tableUInt64[]Uncompressed Byte Array offset table. Contiguous block. +Uncompressed Byte Array dataUncompressed Byte Array[]Uncompressed byte array data. -

Header (52 bytes)

+

Header (60 bytes)

- + - - - - + + + + +
NameTypeDescription
MagicUInt8[4]"PKG4" = {0x50, 0x4B, 0x47, 0x34}
MagicUInt8[4]"PKG5" = {0x50, 0x4B, 0x47, 0x35}
Node countUInt32Total number of nodes in the file. Cannot be zero.
Node block offsetNode*Offset to the start of the node block, which should be the base node: the parent of all other nodes in the file. This must be a multiple of 4.
String countUInt32Total number of String entries in the file. Cannot be zero.
String offset table offsetOffsetTable*Offset to the string offset table in the file, with the number of entries equal to the String count. This must be a multiple of 8.
Bitmap countUInt32Total number of Bitmap entries in the file. Zero indicates no bitmap data.
Bitmap offset table offsetOffsetTable*Offset to the bitmap offset table in the file, with the number of entries equal to Bitmap count. This must be a multiple of 8. Ignored if Bitmap count is 0.
Audio countUInt32Total number of Audio entries in the file. Zero indicates no audio data.
Audio offset table offsetOffsetTable*Offset to the audio offset table in the file, with the number of entries equal to Audio count. This must be a multiple of 8. Ignored if Audio count is 0.
Compressed Byte Array countUInt32Total number of Compressed Byte Array entries in the file.
Compressed Byte Array offset table offsetOffsetTable*Offset to the compressed byte array offset table, with the number of entries equal to the Compressed Byte Array count. This must be a multiple of 8.
Uncompressed Byte Array countUInt32Total number of Uncompressed Byte Array entries in the file.
Uncompressed Byte Array offset table offsetOffsetTable*Offset to the uncompressed byte array offset table in the file, with the number of entries equal to the Uncompressed Byte Array count. This must be a multiple of 8.
MetadataUInt64This field is ignored by parsers and can be used to store application-specific metadata.

Node (20 bytes)

@@ -103,7 +104,7 @@

Node (20 bytes)

Node nameUInt32String ID representing the name of this node First Child IDUInt32Node ID of first child. Present but ignored if child count is zero (0). Children countUInt16Zero means there are no children. -TypeUInt160 = No data
1 = Int64
2 = Double
3 = String (UInt32 ID)
4 = Vector
5 = Bitmap (UInt32 ID, UInt16 Width, UInt16 Height)
6 = Audio (UInt32 ID, UInt32 Length) +TypeUInt160 = No data
1 = Int64
2 = Double
3 = String (UInt32 ID)
4 = Vector
5 = Compressed Byte Array (UInt32 ID)
6 = Uncompressed Byte Array (UInt32 ID) DataVariesThis field is always 8 bytes. TypeDescription @@ -112,8 +113,8 @@

Node (20 bytes)

2Double64-bit IEEE double-precision floating point. 3String32-bit unsigned string ID. 4VectorTwo 32-bit signed integers (Int32), for X and Y respectively. -5Bitmap32-bit unsigned bitmap ID, followed by 16-bit unsigned width and height in that order. Ignored if Bitmap count in Header is 0. -6Audio32-bit unsigned audio ID, followed by 32-bit unsigned data length. Ignored if Audio count in Header is 0. +5Compressed byte array32-bit unsigned compressed byte array ID. Ignored if Compressed Byte Array count in Header is 0. +6Uncompressed byte array32-bit unsigned uncompressed byte array ID. Ignored if Uncompressed Byte Array count in Header is 0 @@ -124,33 +125,64 @@

String (2-65537 bytes)

LengthUInt16Length, in bytes, of the following string data String dataUInt8[]String data, encoded in UTF-8. This byte array is Length bytes long. +NullUInt8'\0' = {0x00} -

Bitmap (4-4294967299 bytes)

-

Each Bitmap is assigned a zero-based unsigned 32-bit ID. Offsets to Bitmaps are located in the bitmap offset table. Bitmaps do not need to be in a contiguous block, though this is recommended.

+

Compressed Byte Array (24-4294967319 bytes)

+

Each Compressed Byte Array is assigned a zero-based unsigned 32-bit ID. Offsets to Compressed Byte Arrays are located in the uncompressed byte array offset table. Byte arrays do not need to be in a contiguous block, though this is recommended. Byte arrays must be aligned to an 8-byte boundary.

- + - - + + + +
NameTypeDescription
NameTypeDescription
LengthUInt32Length, in bytes, of the image data. Uncompressed length is Width * Height * 4. Width and Height are specified in the Node's Data field after the bitmap ID.
Bitmap dataUInt8[]Bitmap data, stored in BGRA8888 format, that is, 1 byte each for the blue, green, red and alpha components, in that order. This data is compressed with LZ4. This byte array is Length bytes long.
LengthUInt64Length, in bytes, of the compressed byte array.
Uncompressed lengthUInt64Length, in bytes, of the byte array.
MetadataUInt64This field is ignored by parsers and can be used to store application-specific metadata.
DataUInt8[]Data, compressed using LZ4. This byte array is Length bytes long.
-

Audio (0-4294967295 bytes)

-

Each Audio is assigned a zero-based unsigned 32-bit ID. Offsets to Audios are located in the audio offset table. Audios do not need to be a contiguous block, though this is recommended.

+

Uncompressed Byte Array (16-4294967311 bytes)

+

Each Uncompressed Byte Array is assigned a zero-based unsigned 32-bit ID. Offsets to Uncompressed Byte Arrays are located in the uncompressed byte array offset table. Byte arrays do not need to be in a contiguous block, though this is recommended. Byte arrays must be aligned to an 8-byte boundary.

- + + +
NameTypeDescription
Audio dataUInt8[]Audio data, including the 82-byte WZ header. This byte array is Length bytes long. Length is specified in the NX node's data field after the audio ID.
LengthUInt64Length, in bytes, of the byte array.
MetadataUInt64This field is ignored by parsers and can be used to store application-specific metadata.
DataUInt8[]Data. This byte array is Length bytes long.

Offset Table

-

Offset tables are used to refer to Strings, Bitmaps and Audios. String offsets must be a multiple of 2. Bitmap and audio offsets must be a multiple of 8.

+

Offset tables are used to refer to Strings and byte arrays. String offsets must be a multiple of 2. Byte array offsets must be a multiple of 8.

NameTypeDescription
Offset ArrayUInt64[]Sequential offset array; the first offset has ID 0, the second has ID 1, and so on.
+

WZ-specific Data Types

+

This section recommends how Bitmaps and Audio files from WZs should be stored. This is also how the reference converter, WZ2NX, will store Bitmaps and MP3s.
+
+In a NX file containing Bitmaps and Audio files from WZs that follows this recommendation, the first 2 bytes of the Metadata field of the Header should have bits 15, 10, 6 and 0 set to 1, that is, ORed with 0b1000010001000001 = {0x84, 0x41}.

+

Bitmap

+

The Metadata field of the byte array containing a bitmap should be set to "WZBITMAP" = {0x57, 0x5A, 0x42, 0x49, 0x54, 0x4D, 0x41, 0x50}. Bitmaps can be stored as either Compressed Byte Arrays or Uncompressed Byte Arrays.
+
+If bitmap data is omitted in an NX file, the Nodes containing a bitmap should point to an empty byte array, or the byte array type should be omitted (count 0 in Header). Otherwise, the structure of the data within the byte array is as follows.

+ + + + + + +
NameTypeDescription
WidthUInt32Width of the following image.
HeightUInt32Height of the following image.
DataUInt8[]Bitmap data, stored in BGRA8888 format, that is, 1 byte each for the blue, green, red and alpha components, in that order. This byte array is Width * Height * 4 bytes long.
+ +

Audio

+

The Metadata field of the byte array containing audio should be set to "WZAUDION" = {0x57, 0x5A, 0x41, 0x55, 0x44, 0x49, 0x4F, 0x4E}. Audio can be stored as either Compressed Byte Arrays or Uncompressed Byte Arrays.
+
+If audio data is omitted in an NX file, the Nodes containing audio should point to an empty byte array, or the byte array type should be omitted (count 0 in Header). Otherwise, the structure of the data within the byte array is as follows.

+ + + + +
NameTypeDescription
Audio dataUInt8[]Audio data, including the 82-byte WZ audio header. This byte array is Length bytes long. Length is specified in the Byte Array structure.
+

Acknowledgements:

  • Retep998, one of the two co-writers of the NX format.
    • From 0187f3892244c2235e70e4b036ab09054d78c428 Mon Sep 17 00:00:00 2001 From: angelsl Date: Mon, 24 Jun 2013 05:24:16 +0800 Subject: [PATCH 02/14] NX Spec: Missed one table header. Make bitmap definition more concise. Signed-off-by: angelsl --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 9c50de6..1c40589 100644 --- a/index.html +++ b/index.html @@ -131,7 +131,7 @@

    String (2-65537 bytes)

    Compressed Byte Array (24-4294967319 bytes)

    Each Compressed Byte Array is assigned a zero-based unsigned 32-bit ID. Offsets to Compressed Byte Arrays are located in the uncompressed byte array offset table. Byte arrays do not need to be in a contiguous block, though this is recommended. Byte arrays must be aligned to an 8-byte boundary.

    - + @@ -170,7 +170,7 @@

    Bitmap

    - +
    NameTypeDescription
    NameTypeDescription
    LengthUInt64Length, in bytes, of the compressed byte array.
    Uncompressed lengthUInt64Length, in bytes, of the byte array.
    WidthUInt32Width of the following image.
    HeightUInt32Height of the following image.
    DataUInt8[]Bitmap data, stored in BGRA8888 format, that is, 1 byte each for the blue, green, red and alpha components, in that order. This byte array is Width * Height * 4 bytes long.
    DataUInt8[]Bitmap data, stored in BGRA8888 format, that is, 1 byte each for blue, green, red and alpha, in that order. This byte array is Width * Height * 4 bytes long.

    Audio

    From a99b8daf79234deeb1ba11f175c1c6fd98aa81b4 Mon Sep 17 00:00:00 2001 From: angelsl Date: Sat, 25 Jul 2015 00:03:19 +0800 Subject: [PATCH 03/14] NX Spec: Stylistic changes. Signed-off-by: angelsl --- index.html | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/index.html b/index.html index 1c40589..d78725c 100644 --- a/index.html +++ b/index.html @@ -4,10 +4,11 @@ NX (PKG5) Format Specification @@ -118,7 +119,7 @@

    Node (20 bytes)

    -

    String (2-65537 bytes)

    +

    String (2–65537 bytes)

    Each String is assigned a zero-based unsigned 32-bit ID. Offsets to Strings are located in the String offset table. Strings do not need to be in a contiguous block, though this is recommended. Strings must be aligned to a 2-byte boundary.

    @@ -128,7 +129,7 @@

    String (2-65537 bytes)

    NameTypeDescription
    NullUInt8'\0' = {0x00}
    -

    Compressed Byte Array (24-4294967319 bytes)

    +

    Compressed Byte Array (24–4294967319 bytes)

    Each Compressed Byte Array is assigned a zero-based unsigned 32-bit ID. Offsets to Compressed Byte Arrays are located in the uncompressed byte array offset table. Byte arrays do not need to be in a contiguous block, though this is recommended. Byte arrays must be aligned to an 8-byte boundary.

    @@ -139,7 +140,7 @@

    Compressed Byte Array (24-4294967319 bytes)

    NameTypeDescription
    DataUInt8[]Data, compressed using LZ4. This byte array is Length bytes long.
    -

    Uncompressed Byte Array (16-4294967311 bytes)

    +

    Uncompressed Byte Array (16–4294967311 bytes)

    Each Uncompressed Byte Array is assigned a zero-based unsigned 32-bit ID. Offsets to Uncompressed Byte Arrays are located in the uncompressed byte array offset table. Byte arrays do not need to be in a contiguous block, though this is recommended. Byte arrays must be aligned to an 8-byte boundary.

    From 8d5b4429c325770b41dee4f211da49a3663d2597 Mon Sep 17 00:00:00 2001 From: angelsl Date: Sat, 25 Jul 2015 00:08:54 +0800 Subject: [PATCH 04/14] NX Spec: Update acknowledgements Signed-off-by: angelsl --- index.html | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index d78725c..63c38c2 100644 --- a/index.html +++ b/index.html @@ -186,13 +186,12 @@

    Audio

    Acknowledgements:

      -
    • Retep998, one of the two co-writers of the NX format.
      • -
    • angelsl, the other co-writer and the author of this Specification.
      • -
    • aaronweiss74, for his suggestions, help and support, and for writing pkgnx.
      • +
    • retep998 and angelsl, the two co-writers of the NX format.
      • +
    • aaronweiss74, for his suggestions, help and support, and for writing pkgnx.
    • Cedric, for his suggestions, help and support, and for writing javanx.
    • Sami, for his support and for writing nx-pkg4.
      • -
    • LZ4, the compression algorithm used in NX.
      • -
    • GitHub, for hosting this and all our projects.
      • +
    • LZ4, the compression algorithm used in NX.
      • +
    • GitHub, for hosting this and all our projects.

    Contributions to this specification are welcome. Please fork and then send a pull request to this repository.
    From 202039393dff99c28f8f9686ff2f14515098b636 Mon Sep 17 00:00:00 2001 From: angelsl Date: Sat, 25 Jul 2015 00:16:47 +0800 Subject: [PATCH 05/14] NX Spec: Parsers should ignore unrecognised types Signed-off-by: angelsl --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 63c38c2..15bd833 100644 --- a/index.html +++ b/index.html @@ -105,7 +105,7 @@

    Node (20 bytes)

     - + From 7d55d6b78349f5565447084f5591b0b5485fc3c5 Mon Sep 17 00:00:00 2001 From: angelsl Date: Sat, 29 Aug 2015 22:09:14 +0800 Subject: [PATCH 06/14] Write changes as discussed. 1. 16-byte metadata for byte arrays 2. Allow different compression methods 3. WZ bitmap metadata format --- index.html | 137 +++++++++++++++++++++++++++++++---------------------- 1 file changed, 81 insertions(+), 56 deletions(-) diff --git a/index.html b/index.html index 15bd833..8692cfa 100644 --- a/index.html +++ b/index.html @@ -8,7 +8,7 @@ body { font-family: 'Source Sans Pro', sans-serif; margin: 0 auto; - max-width: 800px; + max-width: 1000px; } table { border-collapse: collapse; @@ -26,24 +26,31 @@ font-weight: bold; } th.name { - width:12.2%; - min-width:11em; + width: 12.2%; + min-width: 11em; } th.type { - width:8.5%; - min-width:6.7em; + width: 8.5%; + min-width: 6.7em; } .mono, code { font-family: 'Inconsolata', 'Consolas', monospace; } +p { + margin-top: 0px; + margin-bottom: 6pt; +} +h1, h2, h3, h4, h5, h6 { + margin-top: 18px; + margin-bottom: 0px; +}

    4th NX File Format [PKG5]

    The NX file format was designed with speediness and ease of reading in mind, to speed up loading times for anything that uses a node-tree-based data file format.

    -

    In the NX file format, the following should be followed:

    - +

    In the NX file format, the following should be followed:

    • All offsets are unsigned 64-bit integers, zero-based, and are from the beginning of the file.
    • Signed integers use Two's complement.
      • @@ -51,19 +58,19 @@

      4th NX File Format [PKG5]

    • Floating point types follow IEEE standards.
    • Any compression should be done using LZ4.
    • The file extension should be .nx.
      • -
    - -

    These are the reference implementations of the NX format:

    +

    +

    These are the reference implementations of the NX format:

    • NoLifeNx (C++), by retep998, a library for reading NX files.
    • NoLifeWzToNx (C++), by retep998, a tool to convert WZ files to NX.
    • reNX (C#), by angelsl, a library for reading and writing NX files.
    • WZ2NX (C#), by angelsl, a tool to convert WZ files to NX.
    +

    Recommended File Format

    -
    NameTypeDescription
    Node nameUInt32String ID representing the name of this node
    First Child IDUInt32Node ID of first child. Present but ignored if child count is zero (0).
    Children countUInt16Zero means there are no children.
    TypeUInt160 = No data
    1 = Int64
    2 = Double
    3 = String (UInt32 ID)
    4 = Vector
    5 = Compressed Byte Array (UInt32 ID)
    6 = Uncompressed Byte Array (UInt32 ID)
    TypeUInt160 = No data
    1 = Int64
    2 = Double
    3 = String (UInt32 ID)
    4 = Vector
    5 = Compressed Byte Array (UInt32 ID)
    6 = Uncompressed Byte Array (UInt32 ID)

    Parsers should ignore types they do not recognise.
    DataVariesThis field is always 8 bytes.
    TypeDescription
    +

    @@ -73,10 +80,10 @@

    Recommended File Format

    -
    NameTypeDescription
    HeaderHeaderFile header
    Node dataNode[]Node data, including all children.
    Compressed Byte ArraysCompressed Byte Array[]Compressed byte array data.
    Uncompressed Byte Array offset tableUInt64[]Uncompressed Byte Array offset table. Contiguous block.
    Uncompressed Byte Array dataUncompressed Byte Array[]Uncompressed byte array data.
    +

    Header (60 bytes)

    - +

    @@ -88,24 +95,25 @@

    Header (60 bytes)

    - -
    NameTypeDescription
    MagicUInt8[4]"PKG5" = {0x50, 0x4B, 0x47, 0x35}
    Compressed Byte Array offset table offsetOffsetTable*Offset to the compressed byte array offset table, with the number of entries equal to the Compressed Byte Array count. This must be a multiple of 8.
    Uncompressed Byte Array countUInt32Total number of Uncompressed Byte Array entries in the file.
    Uncompressed Byte Array offset table offsetOffsetTable*Offset to the uncompressed byte array offset table in the file, with the number of entries equal to the Uncompressed Byte Array count. This must be a multiple of 8.
    MetadataUInt64This field is ignored by parsers and can be used to store application-specific metadata.
    +MetadataUInt8[]This field is ignored by parsers and can be used to store application-specific metadata. Note that this field can be of any length, by virtue of NX being offset-based. +

    Node (20 bytes)

    -

    Each Node is assigned a zero-based 32-bit unsigned ID in the order they appear in the node block; that is, the first Node (the base node) has ID 0, the second node has ID 1, and so on. This ID is used to point to child nodes of Nodes.
    -
    -All Nodes should be in one contiguous block, which should be of size 20 * Number of nodes. Nodes must be aligned to an 8-byte boundary.
    -
    -Children Nodes of each parent Node must be consecutive in one contiguous block, and the ID of the first child in the block is specified in the First Child ID field of the parent Node. Children Nodes of each parent Node must be sorted in ascending order according to the UTF-8 value of the node name of each child. Children Nodes of any given parent Node must have unique node names.
    -
    -The base node should have an ID of 0, and preferably have type 0 (None).

    - +

    Each Node is assigned a zero-based 32-bit unsigned ID in the order they appear in the node block; that is, the first Node (the base node) has ID 0, the second node has ID 1, and so on. This ID is used to point to child nodes of Nodes.

    + +

    All Nodes should be in one contiguous block, which should be of size 20 * Number of nodes. Nodes must be aligned to an 8-byte boundary.

    + +

    Children Nodes of each parent Node must be consecutive in one contiguous block, and the ID of the first child in the block is specified in the First Child ID field of the parent Node. Children Nodes of each parent Node must be sorted in ascending order according to the UTF-8 value of the node name of each child. Children Nodes of any given parent Node must have unique node names.

    + +

    The base node should have an ID of 0, and preferably have type 0 (None).

    + +

    - + @@ -117,74 +125,90 @@

    Node (20 bytes)

    -
    NameTypeDescription
    Node nameUInt32String ID representing the name of this node
    First Child IDUInt32Node ID of first child. Present but ignored if child count is zero (0).
    Children countUInt16Zero means there are no children.
    TypeUInt160 = No data
    1 = Int64
    2 = Double
    3 = String (UInt32 ID)
    4 = Vector
    5 = Compressed Byte Array (UInt32 ID)
    6 = Uncompressed Byte Array (UInt32 ID)

    Parsers should ignore types they do not recognise.
    TypeUInt160 = No data
    1 = Int64
    2 = Double
    3 = String (UInt32 ID)
    4 = Vector
    5 = Compressed Byte Array (UInt32 ID)
    6 = Uncompressed Byte Array (UInt32 ID)
    Parsers should ignore types they do not recognise.
    DataVariesThis field is always 8 bytes.
    TypeDescription
    5Compressed byte array32-bit unsigned compressed byte array ID. Ignored if Compressed Byte Array count in Header is 0.
    6Uncompressed byte array32-bit unsigned uncompressed byte array ID. Ignored if Uncompressed Byte Array count in Header is 0
    +

    String (2–65537 bytes)

    Each String is assigned a zero-based unsigned 32-bit ID. Offsets to Strings are located in the String offset table. Strings do not need to be in a contiguous block, though this is recommended. Strings must be aligned to a 2-byte boundary.

    - + +

    - -
    NameTypeDescription
    LengthUInt16Length, in bytes, of the following string data
    String dataUInt8[]String data, encoded in UTF-8. This byte array is Length bytes long.
    NullUInt8'\0' = {0x00}
    +

    Compressed Byte Array (24–4294967319 bytes)

    Each Compressed Byte Array is assigned a zero-based unsigned 32-bit ID. Offsets to Compressed Byte Arrays are located in the uncompressed byte array offset table. Byte arrays do not need to be in a contiguous block, though this is recommended. Byte arrays must be aligned to an 8-byte boundary.

    - + +

    - + + -
    NameTypeDescription
    LengthUInt64Length, in bytes, of the compressed byte array.
    Uncompressed lengthUInt64Length, in bytes, of the byte array.
    MetadataUInt64This field is ignored by parsers and can be used to store application-specific metadata.
    Compression methodUInt16Compression method.
    0 = LZ4
    1 = Deflate
    2 = Zlib
    MetadataUInt8[16]This field is ignored by parsers and can be used to store application-specific metadata.
    DataUInt8[]Data, compressed using LZ4. This byte array is Length bytes long.
    +

    Uncompressed Byte Array (16–4294967311 bytes)

    Each Uncompressed Byte Array is assigned a zero-based unsigned 32-bit ID. Offsets to Uncompressed Byte Arrays are located in the uncompressed byte array offset table. Byte arrays do not need to be in a contiguous block, though this is recommended. Byte arrays must be aligned to an 8-byte boundary.

    - + +

    - + -
    NameTypeDescription
    LengthUInt64Length, in bytes, of the byte array.
    MetadataUInt64This field is ignored by parsers and can be used to store application-specific metadata.
    MetadataUInt8[16]This field is ignored by parsers and can be used to store application-specific metadata.
    DataUInt8[]Data. This byte array is Length bytes long.
    +

    Offset Table

    Offset tables are used to refer to Strings and byte arrays. String offsets must be a multiple of 2. Byte array offsets must be a multiple of 8.

    - + +

    -
    NameTypeDescription
    Offset ArrayUInt64[]Sequential offset array; the first offset has ID 0, the second has ID 1, and so on.
    +

    WZ-specific Data Types

    -

    This section recommends how Bitmaps and Audio files from WZs should be stored. This is also how the reference converter, WZ2NX, will store Bitmaps and MP3s.
    -
    -In a NX file containing Bitmaps and Audio files from WZs that follows this recommendation, the first 2 bytes of the Metadata field of the Header should have bits 15, 10, 6 and 0 set to 1, that is, ORed with 0b1000010001000001 = {0x84, 0x41}.

    +

    This section recommends how Bitmaps and Audio files from WZs should be stored. This is also how the reference converter, WZ2NX, will store Bitmaps and MP3s.

    + +

    In a NX file containing Bitmaps and Audio files from WZs that follows this recommendation, the first 2 bytes of the Metadata field of the Header should have bits 15, 10, 6 and 0 set to 1, that is, ORed with 0b1000010001000001 = {0x84, 0x41}.

    +

    Bitmap

    -

    The Metadata field of the byte array containing a bitmap should be set to "WZBITMAP" = {0x57, 0x5A, 0x42, 0x49, 0x54, 0x4D, 0x41, 0x50}. Bitmaps can be stored as either Compressed Byte Arrays or Uncompressed Byte Arrays.
    -
    -If bitmap data is omitted in an NX file, the Nodes containing a bitmap should point to an empty byte array, or the byte array type should be omitted (count 0 in Header). Otherwise, the structure of the data within the byte array is as follows.

    - +

    The 16-byte Metadata field of the byte array containing a bitmap should have the following format.

    + +

    + + + + + + +
    NameTypeDescription
    MagicUInt8[4]"WZBM" = {0x57, 0x5A, 0x42, 0x4D}
    FormatUInt32Format of the image.
    WidthUInt32Width of the image.
    HeightUInt32Height of the image.

    + +

    Bitmaps can be stored as either Compressed Byte Arrays or Uncompressed Byte Arrays.

    + +

    If bitmap data is omitted in an NX file, the Nodes containing a bitmap should point to an empty byte array. Otherwise, the structure of the data within the byte array is as follows.

    + +

    - - - -
    NameTypeDescription
    WidthUInt32Width of the following image.
    HeightUInt32Height of the following image.
    DataUInt8[]Bitmap data, stored in BGRA8888 format, that is, 1 byte each for blue, green, red and alpha, in that order. This byte array is Width * Height * 4 bytes long.
    +DataUInt8[]Bitmap data. This byte array is Length bytes long. Length is specified in the Byte Array structure. +

    Audio

    -

    The Metadata field of the byte array containing audio should be set to "WZAUDION" = {0x57, 0x5A, 0x41, 0x55, 0x44, 0x49, 0x4F, 0x4E}. Audio can be stored as either Compressed Byte Arrays or Uncompressed Byte Arrays.
    -
    -If audio data is omitted in an NX file, the Nodes containing audio should point to an empty byte array, or the byte array type should be omitted (count 0 in Header). Otherwise, the structure of the data within the byte array is as follows.

    - +

    The first 8 bytes of the Metadata field of the byte array containing audio should be set to "WZAUDIO\0" = {0x57, 0x5A, 0x41, 0x55, 0x44, 0x49, 0x4F, 0x00}. Audio can be stored as either Compressed Byte Arrays or Uncompressed Byte Arrays.

    + +

    If audio data is omitted in an NX file, the Nodes containing audio should point to an empty byte array. Otherwise, the structure of the data within the byte array is as follows.

    + +

    -
    NameTypeDescription
    Audio dataUInt8[]Audio data, including the 82-byte WZ audio header. This byte array is Length bytes long. Length is specified in the Byte Array structure.
    +

    -

    Acknowledgements:

    +

    Acknowledgements:

    • retep998 and angelsl, the two co-writers of the NX format.
    • aaronweiss74, for his suggestions, help and support, and for writing pkgnx.
      • @@ -193,9 +217,10 @@

      Audio

    • LZ4, the compression algorithm used in NX.
    • GitHub, for hosting this and all our projects.
    +

    + +

    Contributions to this specification are welcome. Please fork and then send a pull request to this repository.

    -

    Contributions to this specification are welcome. Please fork and then send a pull request to this repository.
    -
    -Creative Commons License
    This specification is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. +

    Creative Commons License This specification is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

    \ No newline at end of file From 97647fe4975a9da1693b52b3438562ede96c168f Mon Sep 17 00:00:00 2001 From: angelsl Date: Sat, 29 Aug 2015 22:19:58 +0800 Subject: [PATCH 07/14] Add nx-rs and remove NoLifeWzToNx. --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 8692cfa..61464a0 100644 --- a/index.html +++ b/index.html @@ -63,7 +63,7 @@

    4th NX File Format [PKG5]

    These are the reference implementations of the NX format:

    • NoLifeNx (C++), by retep998, a library for reading NX files.
      • -
    • NoLifeWzToNx (C++), by retep998, a tool to convert WZ files to NX.
      • +
    • nx-rs (Rust), by retep998, a library for reading NX files.
    • reNX (C#), by angelsl, a library for reading and writing NX files.
    • WZ2NX (C#), by angelsl, a tool to convert WZ files to NX.
    From d555eebb383af5a6368849c264c72920373032bc Mon Sep 17 00:00:00 2001 From: angelsl Date: Sun, 6 Sep 2015 12:05:48 +0800 Subject: [PATCH 08/14] Remove distinction between un/compressed byte arrays. --- index.html | 104 ++++++++++++++++++++++------------------------------- 1 file changed, 42 insertions(+), 62 deletions(-) diff --git a/index.html b/index.html index 61464a0..b431ecc 100644 --- a/index.html +++ b/index.html @@ -9,6 +9,8 @@ font-family: 'Source Sans Pro', sans-serif; margin: 0 auto; max-width: 1000px; + padding: 0 3%; + box-sizing: content-box; } table { border-collapse: collapse; @@ -50,40 +52,36 @@

    4th NX File Format [PKG5]

    The NX file format was designed with speediness and ease of reading in mind, to speed up loading times for anything that uses a node-tree-based data file format.

    -

    In the NX file format, the following should be followed: +

    In the NX file format, the following should be followed:

    • All offsets are unsigned 64-bit integers, zero-based, and are from the beginning of the file.
    • Signed integers use Two's complement.
    • All multi-byte integer and and floating point types are in little endian byte order.
    • Floating point types follow IEEE standards.
      • -
    • Any compression should be done using LZ4.
    • The file extension should be .nx.
      • -

    +
-

These are the reference implementations of the NX format: +

These are the reference implementations of the NX format:

  • NoLifeNx (C++), by retep998, a library for reading NX files.
  • nx-rs (Rust), by retep998, a library for reading NX files.
  • reNX (C#), by angelsl, a library for reading and writing NX files.
  • WZ2NX (C#), by angelsl, a tool to convert WZ files to NX.
-

Recommended File Format

-

+
- - - - -
NameTypeDescription
HeaderHeaderFile header
Node dataNode[]Node data, including all children.
String offset tableUInt64[]String offset table. Contiguous block.
String dataString[]String data.
Compressed Byte Array offset tableUInt64[]Compressed Byte Array offset table. Contiguous block.
Compressed Byte ArraysCompressed Byte Array[]Compressed byte array data.
Uncompressed Byte Array offset tableUInt64[]Uncompressed Byte Array offset table. Contiguous block.
Uncompressed Byte Array dataUncompressed Byte Array[]Uncompressed byte array data.

- -

Header (60 bytes)

-

+ + +
Byte Array offset tableUInt64[]Byte array offset table. Contiguous block.
Byte ArraysByte Array[]Byte array data.
+ +

Header (40+ bytes)

+ @@ -91,12 +89,10 @@

Header (60 bytes)

- - - - + + -
NameTypeDescription
MagicUInt8[4]"PKG5" = {0x50, 0x4B, 0x47, 0x35}
Node block offsetNode*Offset to the start of the node block, which should be the base node: the parent of all other nodes in the file. This must be a multiple of 4.
String countUInt32Total number of String entries in the file. Cannot be zero.
String offset table offsetOffsetTable*Offset to the string offset table in the file, with the number of entries equal to the String count. This must be a multiple of 8.
Compressed Byte Array countUInt32Total number of Compressed Byte Array entries in the file.
Compressed Byte Array offset table offsetOffsetTable*Offset to the compressed byte array offset table, with the number of entries equal to the Compressed Byte Array count. This must be a multiple of 8.
Uncompressed Byte Array countUInt32Total number of Uncompressed Byte Array entries in the file.
Uncompressed Byte Array offset table offsetOffsetTable*Offset to the uncompressed byte array offset table in the file, with the number of entries equal to the Uncompressed Byte Array count. This must be a multiple of 8.
Byte Array countUInt32Total number of Byte Array entries in the file.
Byte Array offset table offsetOffsetTable*Offset to the byte array offset table, with the number of entries equal to the Byte Array count. This must be a multiple of 8.
MetadataUInt8[]This field is ignored by parsers and can be used to store application-specific metadata. Note that this field can be of any length, by virtue of NX being offset-based.

+

Node (20 bytes)

Each Node is assigned a zero-based 32-bit unsigned ID in the order they appear in the node block; that is, the first Node (the base node) has ID 0, the second node has ID 1, and so on. This ID is used to point to child nodes of Nodes.

@@ -107,14 +103,14 @@

Node (20 bytes)

The base node should have an ID of 0, and preferably have type 0 (None).

-

+
- - + @@ -122,53 +118,40 @@

Node (20 bytes)

- - - -
NameTypeDescription
Node nameUInt32String ID representing the name of this node
First Child IDUInt32Node ID of first child. Present but ignored if child count is zero (0).
Children countUInt16Zero means there are no children.
TypeUInt160 = No data
1 = Int64
2 = Double
3 = String (UInt32 ID)
4 = Vector
5 = Compressed Byte Array (UInt32 ID)
6 = Uncompressed Byte Array (UInt32 ID)
Parsers should ignore types they do not recognise.
DataVariesThis field is always 8 bytes. +
TypeUInt160 = No data
1 = Int64
2 = Double
3 = String (UInt32 ID)
4 = Vector
5 = Byte Array (UInt32 ID)
Parsers should ignore types they do not recognise.
DataVariesThis field is always 8 bytes.
TypeDescription
0NoneThis field is ignored.
2Double64-bit IEEE double-precision floating point.
3String32-bit unsigned string ID.
4VectorTwo 32-bit signed integers (Int32), for X and Y respectively.
5Compressed byte array32-bit unsigned compressed byte array ID. Ignored if Compressed Byte Array count in Header is 0.
6Uncompressed byte array32-bit unsigned uncompressed byte array ID. Ignored if Uncompressed Byte Array count in Header is 0

+5Byte array32-bit unsigned byte array ID. Ignored if Byte Array count in Header is 0. +

String (2–65537 bytes)

Each String is assigned a zero-based unsigned 32-bit ID. Offsets to Strings are located in the String offset table. Strings do not need to be in a contiguous block, though this is recommended. Strings must be aligned to a 2-byte boundary.

-

+
-
NameTypeDescription
LengthUInt16Length, in bytes, of the following string data
String dataUInt8[]String data, encoded in UTF-8. This byte array is Length bytes long.

- -

Compressed Byte Array (24–4294967319 bytes)

-

Each Compressed Byte Array is assigned a zero-based unsigned 32-bit ID. Offsets to Compressed Byte Arrays are located in the uncompressed byte array offset table. Byte arrays do not need to be in a contiguous block, though this is recommended. Byte arrays must be aligned to an 8-byte boundary.

- -

- - - - - - - -
NameTypeDescription
LengthUInt64Length, in bytes, of the compressed byte array.
Uncompressed lengthUInt64Length, in bytes, of the byte array.
Compression methodUInt16Compression method.
0 = LZ4
1 = Deflate
2 = Zlib
MetadataUInt8[16]This field is ignored by parsers and can be used to store application-specific metadata.
DataUInt8[]Data, compressed using LZ4. This byte array is Length bytes long.

+ -

Uncompressed Byte Array (16–4294967311 bytes)

-

Each Uncompressed Byte Array is assigned a zero-based unsigned 32-bit ID. Offsets to Uncompressed Byte Arrays are located in the uncompressed byte array offset table. Byte arrays do not need to be in a contiguous block, though this is recommended. Byte arrays must be aligned to an 8-byte boundary.

+

Byte Array (34+ bytes)

+

Each Byte Array is assigned a zero-based unsigned 32-bit ID. Offsets to Byte Arrays are located in the byte array offset table. Byte arrays do not need to be in a contiguous block, though this is recommended. Byte arrays must be aligned to an 8-byte boundary.

-

+
- + + + - -
NameTypeDescription
LengthUInt64Length, in bytes, of the byte array.
LengthUInt64Length, in bytes, of the Data field.
Decoded lengthUInt64Length, in bytes, of the byte array once decoded.
EncodingUInt16Encoding.
0 = None
1 = LZ4
2 = Deflate
MetadataUInt8[16]This field is ignored by parsers and can be used to store application-specific metadata.
DataUInt8[]Data. This byte array is Length bytes long.

+DataUInt8[]Data, encoded using the method specified in Encoding. This byte array is Length bytes long. +

Offset Table

Offset tables are used to refer to Strings and byte arrays. String offsets must be a multiple of 2. Byte array offsets must be a multiple of 8.

-

+
-
NameTypeDescription
Offset ArrayUInt64[]Sequential offset array; the first offset has ID 0, the second has ID 1, and so on.

+

WZ-specific Data Types

This section recommends how Bitmaps and Audio files from WZs should be stored. This is also how the reference converter, WZ2NX, will store Bitmaps and MP3s.

@@ -178,49 +161,46 @@

WZ-specific Data Types

Bitmap

The 16-byte Metadata field of the byte array containing a bitmap should have the following format.

-

+
-
NameTypeDescription
MagicUInt8[4]"WZBM" = {0x57, 0x5A, 0x42, 0x4D}
FormatUInt32Format of the image.
WidthUInt32Width of the image.
HeightUInt32Height of the image.

- -

Bitmaps can be stored as either Compressed Byte Arrays or Uncompressed Byte Arrays.

+

If bitmap data is omitted in an NX file, the Nodes containing a bitmap should point to an empty byte array. Otherwise, the structure of the data within the byte array is as follows.

-

+
-
NameTypeDescription
DataUInt8[]Bitmap data. This byte array is Length bytes long. Length is specified in the Byte Array structure.

+

Audio

-

The first 8 bytes of the Metadata field of the byte array containing audio should be set to "WZAUDIO\0" = {0x57, 0x5A, 0x41, 0x55, 0x44, 0x49, 0x4F, 0x00}. Audio can be stored as either Compressed Byte Arrays or Uncompressed Byte Arrays.

+

The first 8 bytes of the Metadata field of the byte array containing audio should be set to "WZAUDIO\0" = {0x57, 0x5A, 0x41, 0x55, 0x44, 0x49, 0x4F, 0x00}.

If audio data is omitted in an NX file, the Nodes containing audio should point to an empty byte array. Otherwise, the structure of the data within the byte array is as follows.

-

+
-
NameTypeDescription
Audio dataUInt8[]Audio data, including the 82-byte WZ audio header. This byte array is Length bytes long. Length is specified in the Byte Array structure.

+ -

Acknowledgements: +

Acknowledgements

  • retep998 and angelsl, the two co-writers of the NX format.
    • -
  • aaronweiss74, for his suggestions, help and support, and for writing pkgnx.
    • +
  • aaronweiss74, for his suggestions, help and support, and for writing pkgnx.
  • Cedric, for his suggestions, help and support, and for writing javanx.
  • Sami, for his support and for writing nx-pkg4.
  • LZ4, the compression algorithm used in NX.
  • GitHub, for hosting this and all our projects.
-

Contributions to this specification are welcome. Please fork and then send a pull request to this repository.

-

Creative Commons License This specification is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

+

Creative Commons License This specification is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

\ No newline at end of file From 439d1778d8f2a3f8b3589841c3870cf4ad23b5b8 Mon Sep 17 00:00:00 2001 From: angelsl Date: Sun, 6 Sep 2015 12:08:32 +0800 Subject: [PATCH 09/14] Change node alignment to 4 (nodes are 20 bytes..) --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index b431ecc..eca7eef 100644 --- a/index.html +++ b/index.html @@ -97,7 +97,7 @@

Header (40+ bytes)

Node (20 bytes)

Each Node is assigned a zero-based 32-bit unsigned ID in the order they appear in the node block; that is, the first Node (the base node) has ID 0, the second node has ID 1, and so on. This ID is used to point to child nodes of Nodes.

-

All Nodes should be in one contiguous block, which should be of size 20 * Number of nodes. Nodes must be aligned to an 8-byte boundary.

+

All Nodes should be in one contiguous block, which should be of size 20 * Number of nodes. Nodes must be aligned to a 4-byte boundary.

Children Nodes of each parent Node must be consecutive in one contiguous block, and the ID of the first child in the block is specified in the First Child ID field of the parent Node. Children Nodes of each parent Node must be sorted in ascending order according to the UTF-8 value of the node name of each child. Children Nodes of any given parent Node must have unique node names.

From 4d905514084b4e72ea32ab2a7f6e7542739bcae7 Mon Sep 17 00:00:00 2001 From: angelsl Date: Sun, 13 Sep 2015 22:52:14 +0800 Subject: [PATCH 10/14] Properly handle WZ audio header --- index.html | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index eca7eef..7810611 100644 --- a/index.html +++ b/index.html @@ -15,6 +15,7 @@ table { border-collapse: collapse; width: 100%; + margin-bottom: 6pt; } table, td, th { border: 1px solid black; @@ -179,14 +180,24 @@

Bitmap

Audio

-

The first 8 bytes of the Metadata field of the byte array containing audio should be set to "WZAUDIO\0" = {0x57, 0x5A, 0x41, 0x55, 0x44, 0x49, 0x4F, 0x00}.

+

The 16-byte Metadata field of the byte array containing audio should have the following format.

+ + + + + + + +
NameTypeDescription
MagicUInt8[4]"WZAU" = {0x57, 0x5A, 0x41, 0x55}
DurationUInt32Audio duration, in milliseconds.
NullUInt8[8]{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}

If audio data is omitted in an NX file, the Nodes containing audio should point to an empty byte array. Otherwise, the structure of the data within the byte array is as follows.

- + + +
NameTypeDescription
Audio dataUInt8[]Audio data, including the 82-byte WZ audio header. This byte array is Length bytes long. Length is specified in the Byte Array structure.
Header lengthUInt16Length of the header.
HeaderWAVEFORMATEXFormat header. This structure is Header length bytes long.
Audio dataUInt8[]Audio data. This byte array is Length bytes long. Length is specified in the Byte Array structure.

Acknowledgements

From 6122ba6f7da04847a29c469ba9acfd61392ec198 Mon Sep 17 00:00:00 2001 From: angelsl Date: Tue, 15 Sep 2015 17:12:22 +0800 Subject: [PATCH 11/14] Specify audio data length correctly. --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 7810611..764ce0a 100644 --- a/index.html +++ b/index.html @@ -197,7 +197,7 @@

Audio

Header lengthUInt16Length of the header. HeaderWAVEFORMATEXFormat header. This structure is Header length bytes long. -Audio dataUInt8[]Audio data. This byte array is Length bytes long. Length is specified in the Byte Array structure. +Audio dataUInt8[]Audio data. This byte array is Length - Header length bytes long. Length is specified in the Byte Array structure.

Acknowledgements

From c39c5f4887ef824ad676fd4436b379afa3fff9a0 Mon Sep 17 00:00:00 2001 From: angelsl Date: Tue, 15 Sep 2015 18:36:51 +0800 Subject: [PATCH 12/14] Add WZ bitmap format 0. --- index.html | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/index.html b/index.html index 764ce0a..acac123 100644 --- a/index.html +++ b/index.html @@ -166,11 +166,13 @@

Bitmap

NameTypeDescription MagicUInt8[4]"WZBM" = {0x57, 0x5A, 0x42, 0x4D} -FormatUInt32Format of the image. +FormatUInt32Format of the image.
0 = 32 bpp ARGB WidthUInt32Width of the image. HeightUInt32Height of the image. +

Note that since NX is a little-endian format, e.g. ARGB is actually stored as BGRA — it is treated as a 32-bit field, and not four octets.

+

If bitmap data is omitted in an NX file, the Nodes containing a bitmap should point to an empty byte array. Otherwise, the structure of the data within the byte array is as follows.

From c404827a72d4d10c5b66369cf5ab56fa2de062d6 Mon Sep 17 00:00:00 2001 From: angelsl Date: Thu, 17 Sep 2015 22:14:48 +0800 Subject: [PATCH 13/14] Make wording more precise --- index.html | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/index.html b/index.html index acac123..0478f55 100644 --- a/index.html +++ b/index.html @@ -53,13 +53,13 @@

4th NX File Format [PKG5]

The NX file format was designed with speediness and ease of reading in mind, to speed up loading times for anything that uses a node-tree-based data file format.

-

In the NX file format, the following should be followed:

+

In the NX file format, the following must be followed:

  • All offsets are unsigned 64-bit integers, zero-based, and are from the beginning of the file.
    • -
  • Signed integers use Two's complement.
    • +
  • Signed integers use two's complement.
  • All multi-byte integer and and floating point types are in little endian byte order.
  • Floating point types follow IEEE standards.
    • -
  • The file extension should be .nx.
    • +
  • The file extension is .nx.

These are the reference implementations of the NX format:

@@ -87,7 +87,7 @@

Header (40+ bytes)

 - + @@ -98,11 +98,11 @@

Header (40+ bytes)

Node (20 bytes)

Each Node is assigned a zero-based 32-bit unsigned ID in the order they appear in the node block; that is, the first Node (the base node) has ID 0, the second node has ID 1, and so on. This ID is used to point to child nodes of Nodes.

-

All Nodes should be in one contiguous block, which should be of size 20 * Number of nodes. Nodes must be aligned to a 4-byte boundary.

+

All Nodes must be in one contiguous block, which must be of size 20 * Number of nodes. Nodes must be aligned to a 4-byte boundary.

Children Nodes of each parent Node must be consecutive in one contiguous block, and the ID of the first child in the block is specified in the First Child ID field of the parent Node. Children Nodes of each parent Node must be sorted in ascending order according to the UTF-8 value of the node name of each child. Children Nodes of any given parent Node must have unique node names.

-

The base node should have an ID of 0, and preferably have type 0 (None).

+

The base node has an ID of 0, and should preferably be of type 0 (None).

MagicUInt8[4]"PKG5" = {0x50, 0x4B, 0x47, 0x35}
Node countUInt32Total number of nodes in the file. Cannot be zero.
Node block offsetNode*Offset to the start of the node block, which should be the base node: the parent of all other nodes in the file. This must be a multiple of 4.
Node block offsetNode*Offset to the start of the node block, which must be the base node: the parent of all other nodes in the file. This must be a multiple of 4.
String countUInt32Total number of String entries in the file. Cannot be zero.
String offset table offsetOffsetTable*Offset to the string offset table in the file, with the number of entries equal to the String count. This must be a multiple of 8.
Byte Array countUInt32Total number of Byte Array entries in the file.
@@ -110,7 +110,7 @@

Node (20 bytes)

- + @@ -133,20 +133,22 @@

String (2–65537 bytes)

NameTypeDescription
Node nameUInt32String ID representing the name of this node
First Child IDUInt32Node ID of first child. Present but ignored if child count is zero (0).
Children countUInt16Zero means there are no children.
TypeUInt160 = No data
1 = Int64
2 = Double
3 = String (UInt32 ID)
4 = Vector
5 = Byte Array (UInt32 ID)
Parsers should ignore types they do not recognise.
TypeUInt160 = None
1 = Int64
2 = Double
3 = String (UInt32 ID)
4 = Vector
5 = Byte Array (UInt32 ID)
Parsers must ignore types they do not recognise.
DataVariesThis field is always 8 bytes.
TypeDescription

Byte Array (34+ bytes)

-

Each Byte Array is assigned a zero-based unsigned 32-bit ID. Offsets to Byte Arrays are located in the byte array offset table. Byte arrays do not need to be in a contiguous block, though this is recommended. Byte arrays must be aligned to an 8-byte boundary.

+

Each Byte Array is assigned a zero-based unsigned 32-bit ID. Offsets to Byte Arrays are located in the byte array offset table. Byte arrays do not need to be in a contiguous block, though this is recommended. Byte Arrays must be aligned to an 8-byte boundary.

- +
NameTypeDescription
LengthUInt64Length, in bytes, of the Data field.
Decoded lengthUInt64Length, in bytes, of the byte array once decoded.
EncodingUInt16Encoding.
0 = None
1 = LZ4
2 = Deflate
EncodingUInt16Encoding.
0 = None
1 = LZ4
2 = LZ4 Frame
3 = Deflate
MetadataUInt8[16]This field is ignored by parsers and can be used to store application-specific metadata.
DataUInt8[]Data, encoded using the method specified in Encoding. This byte array is Length bytes long.
+Note that the LZ4 algorithm can only compress up to 2,147,483,647 bytes. For larger sizes, LZ4 Frame should be used. +

Offset Table

-

Offset tables are used to refer to Strings and byte arrays. String offsets must be a multiple of 2. Byte array offsets must be a multiple of 8.

+

Offset tables are used to refer to Strings and byte arrays. String offsets must be a multiple of 2. Byte Array offsets must be a multiple of 8.

@@ -157,10 +159,10 @@

Offset Table

WZ-specific Data Types

This section recommends how Bitmaps and Audio files from WZs should be stored. This is also how the reference converter, WZ2NX, will store Bitmaps and MP3s.

-

In a NX file containing Bitmaps and Audio files from WZs that follows this recommendation, the first 2 bytes of the Metadata field of the Header should have bits 15, 10, 6 and 0 set to 1, that is, ORed with 0b1000010001000001 = {0x84, 0x41}.

+

In a NX file containing Bitmaps and Audio files from WZs that follows this recommendation, the first 2 bytes of the Metadata field of the Header must have bits 15, 10, 6 and 0 set to 1, that is, ORed with 0b1000010001000001 = {0x84, 0x41}.

Bitmap

-

The 16-byte Metadata field of the byte array containing a bitmap should have the following format.

+

The 16-byte Metadata field of the byte array containing a WZ bitmap must have the following format.

NameTypeDescription
@@ -171,9 +173,9 @@

Bitmap

NameTypeDescription
HeightUInt32Height of the image.
-

Note that since NX is a little-endian format, e.g. ARGB is actually stored as BGRA — it is treated as a 32-bit field, and not four octets.

+

Note that since NX is a little-endian format, e.g. ARGB is actually stored as BGRA — it is treated as a 32-bit field, and not four octets.

-

If bitmap data is omitted in an NX file, the Nodes containing a bitmap should point to an empty byte array. Otherwise, the structure of the data within the byte array is as follows.

+

If bitmap data is omitted in an NX file, the Nodes containing a bitmap must point to an empty byte array. Otherwise, the structure of the data within the byte array is as follows.

@@ -182,7 +184,7 @@

Bitmap

NameTypeDescription

Audio

-

The 16-byte Metadata field of the byte array containing audio should have the following format.

+

The 16-byte Metadata field of the byte array containing audio must have the following format.

@@ -192,14 +194,14 @@

Audio

NameTypeDescription
NullUInt8[8]{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
-

If audio data is omitted in an NX file, the Nodes containing audio should point to an empty byte array. Otherwise, the structure of the data within the byte array is as follows.

+

If audio data is omitted in an NX file, the Nodes containing audio must point to an empty byte array. Otherwise, the structure of the data within the byte array is as follows.

- +
NameTypeDescription
Header lengthUInt16Length of the header.
HeaderWAVEFORMATEXFormat header. This structure is Header length bytes long.
Audio dataUInt8[]Audio data. This byte array is Length - Header length bytes long. Length is specified in the Byte Array structure.
Audio dataUInt8[]Audio data. This byte array is Length − Header length − 2 bytes long. Length is specified in the Byte Array structure.

Acknowledgements

From fe498cc31a40561a6cfe0a7e9826a036ba05761b Mon Sep 17 00:00:00 2001 From: angelsl Date: Sun, 27 Dec 2015 14:33:24 +0800 Subject: [PATCH 14/14] Add logo --- nxl.svg | 299 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 299 insertions(+) create mode 100644 nxl.svg diff --git a/nxl.svg b/nxl.svg new file mode 100644 index 0000000..427de6a --- /dev/null +++ b/nxl.svg @@ -0,0 +1,299 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + +