HedgeDocs - User contributions [en]

Games

2026-11-05T10:38:54Z

Arg!!: Added Version number for Golden Axe

This section lists games by their engine, alongside their internal name. In this page, you can access each game's own wiki page, containing game-specific guides, tools, and documentation.

This section may also list non-Sonic games, but there is no intent on documenting these games on this wiki, as they're listed for research purposes only.

== Hedgehog Engine ==
{| class="wikitable"
!Game Name
!Internal Name
!Year
|-
|[[Sonic Unleashed|Sonic Unleashed (Sonic World Adventure)]]
|SWA
|2008
|-
|[[Sonic Colors]]
|sonic2010
|2010
|-
|[[Sonic Generations]]
|BlueBlur
|2011
|-
|[[Sonic Lost World]]
|sonic2013
|2013
|-
|Sonic Colors: Ultimate*
|Rainbow
|2021
|-
|Sonic Generations (SONIC X SHADOW GENERATIONS)
|miller_g
|2024
|}
''* Sonic Colors: Ultimate also makes use of a forked version of Godot 3.''

== Hedgehog Engine 2 ==
{| class="wikitable"
!Game Name
!Internal Name
!Year
|-
|[[Mario & Sonic at the Rio 2016 Olympic Games]]
|unison
|2016
|-
|[[Sonic Forces]]
|wars
|2017
|-
|Olympic Games Tokyo 2020 - The Official Video Game
|musashi
| rowspan="3" |2019
|-
|Mario & Sonic at the Tokyo 2020 Olympic Games
|rings
|-
|(New) Sakura Wars
|arukas
|-
|Puyo Puyo Tetris 2
|tenpex
|2020
|-
|[[Sonic Origins]]*
|hite
| rowspan="3" |2022
|-
|[[Sonic Frontiers]]
|rangers
|-
|Sonic Frontiers: Digital Art Book with Mini Digital Soundtrack
|rangers_artbook
|-
|[[Sonic Origins|Sonic Origins Plus]]*
|hiteplus
| rowspan="2" |2023
|-
|Sonic Superstars - Digital Artbook and mini-OST
|orion_artbook
|-
|[[Shadow Generations]] / SONIC X SHADOW GENERATIONS
|miller
| rowspan="2" |2024
|-
|SONIC X SHADOW GENERATIONS: Art Book with Mini Soundtrack
|miller_das
|}
''* Sonic Origins (Plus) also makes use of Retro Engine v5U.''

== Acroarts ==
'''Acroarts''' is a proprietary graphics middleware developed by SEGA Games before ownership was transferred to CRI in 2016.<ref>SEGA Press Release (June 22, 2016). [https://web.archive.org/web/20260114134140/https://www.sega.co.jp/release/sega-games/images/160622_01.pdf SEGA Games and CRI Agree to Transfer the "Acroarts" Graphics Middleware Business].</ref>
{| class="wikitable"
!Game Name
!Internal Name
!Version
!Year
|-
|[[Sonic the Hedgehog (2006)]]
|Marathon
|Ver20060209 R1
|2006
|-
|Rambo
|Clarith
|Ver20050809 R2
|2008
|-
|Mushiking Battle Gacchu Guts!!
|mk4exp
| rowspan="2" |Ver20100108 R1
|2010
|-
|Transformers: Human Alliance
|TF_Gun
|2013
|}

== NN ==
'''NN''' is a proprietary graphics library developed by SEGA Creative Center's Graphics Section.
{| class="wikitable"
!Game Name
!Internal Name
!Version
!Year
|-
|Sega Ages 2500 Series Vol. 5: Golden Axe<ref name="ref_sega_nn_tools">Argx2121 (2020-2025). [https://github.com/Argx2121/Sega_NN_tools/blob/master/io/nn_import_data.py Sega NN Tools import data].</ref>
|
|1.04.03 for PlayStation2
| rowspan="2" |2003
|-
|Dabi Tsuku 3 - Derby-ba o Tsukurou!<ref name="ref_sega_nn_tools"/>
|
|1.07.02 for GAMECUBE 1.07.04l for PlayStation2
|-
|Sega Superstars
|
|1.13.00 for PlayStation2
|2004
|-
|The House of the Dead 4<ref name="ref_sega_nn_tools"/>
|
|1.03.03 for Lindbergh
|2005
|-
|Phantasy Star Universe<ref name="ref_sega_nn_tools"/>
|
|?
| rowspan="5" |2006
|-
|[[Sonic the Hedgehog (2006)]]<ref name="ref_sega_nn_tools"/>
|Marathon
|?
|-
|Sonic Riders<ref name="ref_sega_nn_tools"/>
|SonicR
|1.18.43 for PlayStation2 1.18.43 for DirectX G1.1 1.18.52 for Xbox
|-
|Bleach: Shattered Blade<ref name="ref_sega_nn_tools"/>
|nigo
|1.19.095 for GAMECUBE
|-
|Super Monkey Ball: Banana Blitz<ref name="ref_sega_nn_tools"/>
|
|1.19.09 for GAMECUBE
|-
|Sonic and the Secret Rings<ref name="ref_sega_nn_tools"/>
|SonicWildFire
|1.19.095 for GAMECUBE
| rowspan="3" |2007
|-
|Too Spicy<ref name="ref_sega_nn_tools"/>
|
|1.04.03 for LINDBERGH
|-
|Ghost Squad<ref name="ref_sega_nn_tools"/>
|
|1.20.02 for GAMECUBE
|-
|Sonic Riders: Zero Gravity<ref name="ref_sega_nn_tools"/>
|SR2
|1.20.04 for GAMECUBE 1.18.56 for PlayStation2
| rowspan="3" |2008
|-
|Rambo
|Clarith
|1.04.04 for LINDBERGH
|-
|Sonic Unleashed (Sonic World Adventure) (Wii/PS2)<ref name="ref_sega_nn_tools"/>
|
|1.20.14 for GAMECUBE 1.18.56 for PlayStation2
|-
|Sonic and the Black Knight<ref name="ref_sega_nn_tools"/>
|
|1.20.20 for Wii
| rowspan="2" |2009
|-
|Loving Deads: The House of the Dead EX<ref name="ref_sega_nn_tools"/>
|
|?
|-
|Super Monkey Ball: Step & Roll<ref name="ref_sega_nn_tools"/>
|
|1.20.20 for Wii
| rowspan="6" |2010
|-
|Mushiking Battle Gacchu Guts!!
|mk4exp
|1.01.06 for DirectX G2.0
|-
|K-On! After School Live!!<ref name="ref_sega_nn_tools"/>
|
|?
|-
|Sonic the Hedgehog 4: Episode I<ref name="ref_sega_nn_tools"/>
|hog
|1.01.05 for DirectX G2.0
|-
|Sonic Free Riders<ref name="ref_sega_nn_tools"/>
|SRN
|1.01.06 for DirectX G2.0 on XBOX360
|-
|Sega Golden Gun<ref name="ref_sega_nn_tools"/>
|
|1.01.06 for DirectX G2.0
|-
|Super Monkey Ball: Ticket Blitz<ref name="ref_sega_nn_tools"/>
|
|1.01.06 for DirectX G2.0
|2011
|-
|The House of the Dead 4 (PSN)<ref name="ref_sega_nn_tools"/>
|
|?
| rowspan="3" |2012
|-
|Sonic the Hedgehog 4: Episode II<ref name="ref_sega_nn_tools"/>
|
|1.01.06b for DirectX G2.0
|-
|Let's Go Safari<ref name="ref_sega_nn_tools"/>
|
|1.01.06 for DirectX G2.0
|-
|K.O. Drive<ref name="ref_sega_nn_tools"/>
|
|1.01.06 for DirectX G2.0
| rowspan="2" |2013
|-
|Transformers: Human Alliance<ref name="ref_sega_nn_tools"/>
|TF_Gun
|1.01.06 for DirectX G2.0
|}

== Unity ==
{| class="wikitable"
|+
!Game Name
!Internal Name
!Version
!Year
|-
|Sonic Dash
|
|6000.0.58f2
|2013
|-
|Sonic Runners
|
|4.6.9f1
| rowspan="2" |2015
|-
|Sonic Boom Dash (Sonic Dash 2: Sonic Boom Run)
|
|6000.0.68f1
|-
|Sonic Forces: Speed Battle
|sprint
|6000.0.58f2
|2017
|-
|Sonic Racing
|
|2018.4.16f1
|2019
|-
|The Murder of Sonic the Hedgehog
|
|2021.3.9f1
| rowspan="3" |2023
|-
|Sonic Superstars
|orion
|2021.3.25f1
|-
|Sonic Dream Team
|
|2022.3.54f1
|-
|Sonic Rumble Party
|
|2022.3.64f1
|2025
|}

== Unreal Engine ==
{| class="wikitable"
|+
!Game Name
!Internal Name
!Version
!Year
|-
|Sonic Racing: CrossWorlds
|UNION
|5.4
|2025
|}

== References ==

NN Chunk Format

2026-11-02T08:41:55Z

Arg!!:

{{Notice|type=warn|content=This page is still a work in progress! Any additions and updates are greatly appreciated!}}{{Notice|type=info|content=HedgeDocs' initial NN documentation was written by: Radfordhound. 
Thanks to:
* ItsEasyActually: For sharing his NN findings with me, which helped immensely in getting me started on my journey to reverse-engineer and document all of NN across all of its many crazy iterations and platforms.
* ArMM1998: For sharing his documentation on some more obscure NN file types with me (specifically Puyo Puyo stuff, including DS games that used NN which I didn't know was a thing); I never would've known about these otherwise!
* TGE and WamWooWam: For decompiling SEGA's <s>unholy</s> port of Sonic 4 Episode I to Windows Phone 7, which used the NN library, and just-so-happened to include complete symbols for everything (even enum values)! I can't understate how much this information has helped me!
* Shadowth117 for a ton of extremely useful information and help throughout, especially with regards to the PSO2 variants of the formats!
* SEGA: For making these games, and for letting us freely mod them. Seriously, not many companies let us do this stuff openly, and I think it's awesome. (Also, for releasing that awful version of Sonic 4 Episode I on Windows Phone 7 which had all the symbols in it. Thanks guys, you're the best!! <3)}}
The NN Chunk Format is a generic "container" format developed by SEGA Creative Center's Graphics Section.

The format is heavily based on the older "SEGA Ninja Chunk Model" format, which was originally developed for the SEGA Dreamcast and was utilized in many Dreamcast games (it was even included as part of the Dreamcast's "Katana" SDK).

While the exact meaning of the "NN" is still currently unknown, given that it is so heavily based off of the older Ninja format, it's almost certainly an acronym for something like "New Ninja" or "Ninja Next".

== Common Definitions ==
Please see the [[NN Chunk Format - Common Definitions|Common Definitions]] page for a list of definitions (structs, enums, etc.) that are referenced throughout this specification.

== Platforms ==
The NN Chunk Format, much like the older Ninja format it's based on, is designed heavily around the specific hardware/software requirements of whatever platform it is intended to be used on.

Unlike the older Ninja format, however (which only supports one platform: the SEGA Dreamcast), the NN Chunk Format is "multi-platform", and therefore comes in many different platform-specific variants.

All known used platforms are listed in the following chart:
{| class="wikitable"
|+
!ID
!CC
!Used on
!Endianness
!Alignment
!NN Library Version
|-
|NS
|s
|PlayStation 2
|Little
|16
|PlayStation2
|-
|NG
|g
|GameCube/Wii
|Big
|32
|GAMECUBE/Wii
|-
|NX
|x
|Xbox/Xbox 360/Windows
|Little
|16
|DirectX G1.1
|-
|NY
|y
|Xbox
|Big
|16
|DirectX G1.1
|-
|NL
|l
|SEGA Lindbergh
|Little
|16
|LINDBERGH
|-
|NU
|u
|PlayStation Portable
|Little
|16
|PSP
|-
|NC
|c
|PlayStation 3
|Big
|16
|PS3
|-
|NE
|e
|Xbox 360
|Little
|16
|DirectX G2.0 on XBOX360
|-
|NZ
|z
|Windows
|Little
|16
|DirectX G2.0 on WINDOWS
|-
|NI
|i
|iOS/Android/Windows Phone
|Little
|16
|OpenGL ES 1.1
|-
|DS
|?
|Nintendo DS/3DS
|Little
|16
|?
|}

== Data Chunks ==
As the name implies, files in the NN Chunk Format are comprised of a series of one or more "data chunks", one after another.

A "data chunk" is simply a block of data (structs, arrays, strings, etc.) that represents a single resource of a specific type.

All known data chunk types are listed in the following chart:
{| class="wikitable"
|+
!ID
!CC
!Type
!Description
|-
|TL
|t
|[[NN Chunk Format - TEXLIST|TEXLIST]]
|A list of textures.
|-
|EF
|e
|EFFECTLIST
|A list of effects (shaders).
|-
|NN
|a
|[[NN Chunk Format - NODENAMELIST|NODENAMELIST]]
|A list of names for the nodes (bones) within an object (a model).
|-
|MN
|u
|[[NN Chunk Format - MATERIALNAMELIST|MATERIALNAMELIST]]
|A list of names for the materials within an object (a model).
|-
|TN
|h
|MTNAMELIST
|A list of names for the morph targets within an object (a model).
|-
|OB
|j/o
|OBJECT
|A model. Sometimes uses 'j' as its CC if there is no TEXLIST is embedded, and uses 'o' otherwise.
|-
|MO
|m
|[[NN Chunk Format - MOTION|MOTION]]
|A node (bone) animation.
|-
|MM
|f
|[[NN Chunk Format - MOTION|MOTION]]
|A morph animation.
|-
|MC
|d
|[[NN Chunk Format - MOTION|MOTION]]
|A camera animation.
|-
|ML
|i
|[[NN Chunk Format - MOTION|MOTION]]
|A light animation.
|-
|MA
|v
|[[NN Chunk Format - MOTION|MOTION]]
|A material animation.
|-
|LI
|i/l
|LIGHT
|A light. Uses 'i' as its CC if its animation is embedded, and 'l' otherwise.
|-
|CA
|c/d
|CAMERA
|A camera. Uses 'd' as its CC if its animation is embedded, and 'c' otherwise.
|-
|MT
|g
|MORPH
|A morph target.
|-
|NT
|p
|NODE_TREE_OBJECT
|A list of nodes (bones) for a model.
|-
|ME
|q
|MESH_OBJECT
|A list of meshes and materials for a model.
|-
|SF
|?
|SHADERFILE
|?
|-
|SI
|?
|SHADERIDX
|?
|}
Each data chunk has a "root struct" associated with it, which is the starting point for the data in the chunk, and usually references other data (structs, arrays, strings, etc.).

For information on the formats of the data contained within these data chunk types, please refer to the linked pages in the above chart.

== File Types ==
Just like with the older Ninja format, NN chunk files come in two forms:

* [[NN Chunk Format#Binary-Form File Format|Binary-Form]]
* [[NN Chunk Format#Text-Form File Format|Text-Form]] (aka "Ascii-Form")
{{Notice|type=info|content=The vast majority of NN chunk files in released games are in binary-form.

To our knowledge, all released games using NN don't support loading text-form files at runtime, meaning that all NN text-form files found in the games are unused developer leftovers!}}
Both of these forms represent the same thing: A series of one or more data chunks. However, they do so in different ways.

File extensions for NN chunk files typically consist of three characters:

# The "CC" (character-code) of the [[NN Chunk Format#Platforms|platform]].
# <code>n</code> for [[NN Chunk Format#Binary-Form File Format|Binary-Form]] files, or <code>t</code> for [[NN Chunk Format#Text-Form File Format|Text-Form]] files.
# The "CC" (character-code) of the last [[NN Chunk Format#Data Chunks|data chunk]] contained within the file.

=== Examples ===
{| class="wikitable"
|+
!Extension
!Meaning
|-
|.xno
|<nowiki>Xbox | Binary-Form | OBJECT</nowiki>
|-
|.gno
|<nowiki>Gamecube | Binary-Form | OBJECT</nowiki>
|-
|.xtv
|<nowiki>Xbox | Text-Form | MOTION (material)</nowiki>
|-
|.snt
|<nowiki>PlayStation 2 | Binary-Form | TEXLIST</nowiki>
|}

== Binary-Form File Format ==
Binary-Form NN chunk files are represented as a series of consecutive "binary chunks", each of which begins with the following data:
{{Notice|type=note|content=All instances of this struct (and ONLY this struct) are represented in little-endian, regardless of the endianness specified by the [[#Platforms|platform]]. Everything else in Binary-Form NN chunk files is represented in the endianness specified by the [[#Platforms|platform]].}}{{Notice|type=note|content=A struct type with this name does not actually exist (to my knowledge) in real Sega NN implementations; these fields are just embedded directly within every NNS_BINCNK_ struct. This is just an easier way to think about it for our purposes.}}<syntaxhighlight lang="cpp">
struct NNS_BINCNK_HEADER
{
// The four-character identifier for this binary chunk;
// specifies what type of binary chunk this is.
uint32_t Id;

// The offset to the next four-character identifier in the
// file, relative to the end of this struct (such that after
// doing `fread(&OfsNextId, sizeof(OfsNextId), 1, file)`
// you can just do `fseek(file, OfsNextId, SEEK_CUR)`.
int32_t OfsNextId;
};
</syntaxhighlight>Immediately following this struct comes all of the data (structs, strings, etc.) required to represent the binary chunk. The format of this data depends on the value of the Id field.

After each binary chunk (including all of its data) has been written, the file is padded (with null bytes) to a position that is divisible by the "alignment" specified by the [[NN Chunk Format#Platforms|platform]] (usually it's 16, but notably, it's 32 on Gamecube/Wii).

What follows is documentation for all known binary chunk types, in the order that they appear within binary-form NN chunk files.

=== Info Chunk ===
{{Notice|type=note|content=This chunk is required to be present at the beginning of all binary-form NN chunk files! The Sega NN games I've checked actually rely on this behavior, so you can too.}}
This binary chunk serves as the header for a binary-form NN chunk file, and contains info needed to parse the file. It is represented as the following struct:<syntaxhighlight lang="cpp">
struct NNS_BINCNK_FILEHEADER
{
// Binary chunk header; must be present at the beginning of all binary chunks.
//
// The chunk ID is set to "**IF", where "**" is the "ID" of
// the platform (e.g. "NGIF" for Gamecube binary chunk headers).
NNS_BINCNK_HEADER ChunkHeader;

// The number of data chunks in the file.
int32_t nChunk;

// The absolute offset to the first data chunk in the file.
int32_t OfsData;

// The combined size of all of the data chunks in the file, in bytes, including any padding.
int32_t SizeData;

// The absolute offset to the (required) NOF0 binary chunk.
int32_t OfsNOF0;

// Size of the (required) NOF0 binary chunk, including its header.
// Depending on the variant of the format, this size either includes
// the padding that comes after the NOF0 binary chunk, or it doesn't.
//
// TODO: Figure out exactly which versions include padding.
// It seems PSP files and .[x]ncp files don't count the padding,
// but everything else does??
int32_t SizeNOF0;

// 1 in most files, 0 in some newer variants.
// (Maybe they just stopped using this value?)
int32_t Version;
};
</syntaxhighlight>{{Notice|type=note|content=Further research NIFL header chunks and add info on those.}}

=== Data Chunk Header ===
After the [[NN Chunk Format#Info Chunk|Info Chunk]], comes the main contents of the file: A sequence of one or more [[NN Chunk Format#Data Chunks|data chunks]].

In binary-form NN chunk files, each data chunk begins with the following struct:<syntaxhighlight lang="cpp">
struct NNS_BINCNK_DATAHEADER
{
// Binary chunk header; must be present at the beginning of all binary chunks.
//
// The chunk ID is set to the "ID" of the platform, followed
// by the "ID" of the data chunk type being written (e.g.
// "NXOB" for Xbox OBJECT data chunks).
NNS_BINCNK_HEADER ChunkHeader;

// The offset to the root struct that makes up this data chunk
// (e.g. an offset to a NNS_NODENAMELIST if the chunk type indicates
// that this is a NODE_NAME data chunk), relative to the
// position specified by the [OfsData] field from the info chunk.
//
// Please refer to the linked pages in the data chunks chart
// to learn about their root structs.
int32_t OfsMainData;

// Always 0 in every file I've seen thus far.
int32_t Version;
};

</syntaxhighlight>Immediately following this struct comes all of the data (structs, strings, etc.) required to represent the data chunk. The format of this data depends on the value of the Id field.

See the linked pages in the [[NN Chunk Format#Data Chunks|data chunks chart]].

=== Offsets List Chunk ===
{{Notice|type=note|content=This chunk is required to be present in all binary-form NN chunk files!}}
After all of the data chunks, comes the offsets list chunk.

This binary chunk represents a list of positions for all of the pointers ("offsets") in all of the data chunks in the file, relative to the value of the <code>[OfsData]</code> field from the info chunk.<syntaxhighlight lang="cpp">
struct NNS_BINCNK_NOF0HEADER
{
// Binary chunk header; must be present at the beginning of all binary chunks.
//
// The chunk ID is set to "NOF0".
NNS_BINCNK_HEADER ChunkHeader;

// The number of pointer positions listed within this chunk.
int32_t nData;

// Padding; must always be 0 in files.
//
// This is because some games use this value as a marker that states
// whether or not the pointers have been "fixed".
//
// In those games, after they're done "fixing" all of the pointers
// listed within this chunk, they will set this value to 1 in memory.
int32_t Pad;
};
</syntaxhighlight>Immediately following this struct comes an array of <code>uint32_t</code> values of size <code>[nData]</code>. These values represent the positions of every pointer in all of the data chunks in the file, relative to the <code>[OfsData]</code> field from the info chunk.

Most NN games use this chunk to quickly "fix" all of the pointers within the data chunks (that is, to convert all of the offsets into absolute memory addresses that can then just be used as normal pointers).

Some games, however, (namely: Sonic 4 Episode I for Windows Phone) ignore the values in this chunk, and instead, just manually add <code>[OfsData]</code> to each offset to get an absolute file position whenever they need to jump there.

Regardless of whether the data is actually used or not, it is always present in valid files.
{{Notice|type=note|content=Add pseudo-code for "fixing" the offsets listed in this chunk.}}

=== File Name Chunk ===
{{Notice|type=info|content=This chunk is completely optional and seems to only be used for debugging/internal-tooling purposes.}}
This chunk simply states the name and extension (without the path) of the file it's contained in.<syntaxhighlight lang="cpp">
struct NNS_BINCNK_NFN0HEADER
{
// Binary chunk header; must be present at the beginning of all binary chunks.
//
// The chunk ID is set to "NFN0".
NNS_BINCNK_HEADER ChunkHeader;

// Padding; always 0 in files.
uint32_t Pad[2];
};
</syntaxhighlight>Immediately following this header comes a null-terminated string which represents the file's name and extension (without its path).

=== End Chunk ===
{{Notice|type=note|content=This chunk is required to be present in all binary-form NN chunk files!}}
This is the last chunk in all binary-form NN chunk files. It exists purely to indicate that there are no more chunks left in the file, so that you know when to stop reading if you're reading the file sequentially, one chunk at a time.<syntaxhighlight lang="cpp">
struct NNS_BINCNK_NENDHEADER
{
// Binary chunk header; must be present at the beginning of all binary chunks.
//
// The chunk ID is set to "NEND".
NNS_BINCNK_HEADER ChunkHeader;

// Padding; always 0 in files.
uint32_t Pad[2];
};
</syntaxhighlight>

== Text-Form File Format ==
Text-form NN chunk files, just like the text-form Ninja chunk model files that precede them, are text files comprised of code in what is actually a very limited subset of the C programming language, heavily utilizing special NN types/preprocessor defines, which are, presumably, defined within the official NN SDK.

This allows them to both be parsable by tooling (it is unclear if they actually do this), and to be directly <code>#include</code>d within the C or C++ files which make up their game's source code, embedding the data directly within the game's executable!

Their general layout is as follows:
{{Notice|type=note|content=Replace these special phrases in all of the following <code>text</code> snippets as follows:

* \t: Replace with one or more tab characters (NOT spaces), used to align the text.
* TYPE: Replace with the name of the type currently being written.
* NAME: Replace with the name of whatever you're currently writing.}}

# A (required?) "header" comment that is comprised of the following, in order:
## The name and version number of the tool used to create this file.
## <code>Create\t:</code> followed by the date this file was created in the <code>ddd MMM dd HH:mm:ss yyyy</code> .NET DateTime format.
## The names of each of the root structs for every data chunk in the file, in this format: <code>TYPE\t: NAME</code>, where <code>TYPE</code> refers to the root struct's type (e.g. <code>NNS_TEXFILELIST</code>). See the linked pages in the [[NN Chunk Format#Data Chunks|data chunks chart]].
# One or more data chunks, each of which is comprised of the following, in order:
## A comment with the text: <code>TYPE START</code>, where <code>TYPE</code> refers to the [[NN Chunk Format#Data Chunks|data chunk's type]] (e.g. <code>TEXLIST</code>).
## All of the data used by this data chunk, represented as C code comprised heavily of special NN preprocessor macros. See the linked pages in the [[NN Chunk Format#Data Chunks|data chunks chart]].
## A comment with the text: <code>TYPE END</code>, where <code>TYPE</code> refers to the [[NN Chunk Format#Data Chunks|data chunk's type]] (e.g. <code>TEXLIST</code>).
# A (required?) comment with the text: <code>End of File</code>.

The files also always use tab characters (<code>\t</code>) for indentation, rather than spaces.

Here's a sample Text-form NN chunk file, to better understand the format:
{{Notice|type=example|content=<syntaxhighlight lang="cpp">
/*
Sample NN Exporter Version 1.00.00
Create : Wed Feb 08 21:06:46 2023
NNS_TEXFILELIST : nntexfilelist_SampleFile
*/

/* TEXLIST START */

NNS_TEXFILE nntexfile_SampleFile[] =
{
TEXFILE(
TF_FILENAME( "SampleTex_dif.dds" ),
TF_FILTER( NND_MIN_LINEAR_MIPMAP_NEAREST, NND_MAG_LINEAR )
),
TEXFILE(
TF_FILENAME( "SampleTex_spec.dds" ),
TF_FILTER( NND_MIN_LINEAR_MIPMAP_NEAREST, NND_MAG_LINEAR )
),
TEXFILE(
TF_FILENAME( "SampleTex_norm.dds" ),
TF_FILTER( NND_MIN_LINEAR_MIPMAP_NEAREST, NND_MAG_LINEAR )
),
};

NNS_TEXFILELIST nntexfilelist_SampleFile[] =
{
TEXFILELIST(
TFL_N_TEXFILE( 3 ),
TFL_TEXFILE( nntexfile_SampleFile )
)
};

/* TEXLIST END */

/* End of File */
</syntaxhighlight>}}{{Notice|type=info|content=All of the following in the above example are type/preprocessor defines from the NN library:

* NNS_TEXFILE
* TEXFILE
* TF_FILENAME
* TF_FILTER
* NND_MIN_LINEAR_MIPMAP_NEAREST
* NND_MAG_LINEAR
* NNS_TEXFILELIST
* TEXFILELIST
* TFL_N_TEXFILE
* TFL_TEXFILE

For a complete list of all of these defines, please refer to the individual pages linked in the [[#Data Chunks|data chunks chart]] (for the ones used in this example, refer to the [[NN Chunk Format - TEXTLIST|TEXLIST]] documentation).}}
Note that in C, code is parsed sequentially: left-to-right, top-to-bottom.

If a name is used in the file before it has been declared, that's an error.

Thus, the ordering of the data within each data chunk is generally written to the file in "reverse" order, such that any reference to a value will not be written until ''after'' the value it is referencing has been written, avoiding this problem.

In some cases, the NN exporters will instead declare the value early, and define it later on in the file, using an extern declaration like so:
{{Notice|type=example|content=Here, the <code>nnvertex_plb_op_en_Kyozoress_head_l__2_w2_Eye</code> value is declared so that it can be referenced by the <code>VTX_LISTPTR</code> field in <code>nnvertexdesc_plb_op_en_Kyozoress_head_l__2_w2_Eye</code>:

<syntaxhighlight lang="cpp">
extern NNS_VTXTYPE_XB_PW4INCT nnvertex_plb_op_en_Kyozoress_head_l__2_w2_Eye[];

NNS_VTXLIST_DX_DESC nnvertexdesc_plb_op_en_Kyozoress_head_l__2_w2_Eye[] =
{
VTXDESC(
/* ... */
VTX_LISTPTR( nnvertex_plb_op_en_Kyozoress_head_l__2_w2_Eye ),
/* ... */
),
};
</syntaxhighlight>

Then, later on in the file, the referenced <code>nnvertex_plb_op_en_Kyozoress_head_l__2_w2_Eye</code> value is defined as usual (contents redacted due to extreme length):

<syntaxhighlight lang="cpp">
NNS_VTXTYPE_XB_PW4INCT nnvertex_plb_op_en_Kyozoress_head_l__2_w2_Eye[] =
{
/* ... */
};
</syntaxhighlight>}}
[[Category:File Formats]]

NN Chunk Format

2026-11-02T03:53:03Z

Arg!!: Updated information for some NN chunks

{{Notice|type=warn|content=This page is still a work in progress! Any additions and updates are greatly appreciated!}}{{Notice|type=info|content=HedgeDocs' initial NN documentation was written by: Radfordhound. 
Thanks to:
* ItsEasyActually: For sharing his NN findings with me, which helped immensely in getting me started on my journey to reverse-engineer and document all of NN across all of its many crazy iterations and platforms.
* ArMM1998: For sharing his documentation on some more obscure NN file types with me (specifically Puyo Puyo stuff, including DS games that used NN which I didn't know was a thing); I never would've known about these otherwise!
* TGE and WamWooWam: For decompiling SEGA's <s>unholy</s> port of Sonic 4 Episode I to Windows Phone 7, which used the NN library, and just-so-happened to include complete symbols for everything (even enum values)! I can't understate how much this information has helped me!
* Shadowth117 for a ton of extremely useful information and help throughout, especially with regards to the PSO2 variants of the formats!
* SEGA: For making these games, and for letting us freely mod them. Seriously, not many companies let us do this stuff openly, and I think it's awesome. (Also, for releasing that awful version of Sonic 4 Episode I on Windows Phone 7 which had all the symbols in it. Thanks guys, you're the best!! <3)}}
The NN Chunk Format is a generic "container" format developed by SEGA Creative Center's Graphics Section.

The format is heavily based on the older "SEGA Ninja Chunk Model" format, which was originally developed for the SEGA Dreamcast and was utilized in many Dreamcast games (it was even included as part of the Dreamcast's "Katana" SDK).

While the exact meaning of the "NN" is still currently unknown, given that it is so heavily based off of the older Ninja format, it's almost certainly an acronym for something like "New Ninja" or "Ninja Next".

== Common Definitions ==
Please see the [[NN Chunk Format - Common Definitions|Common Definitions]] page for a list of definitions (structs, enums, etc.) that are referenced throughout this specification.

== Platforms ==
The NN Chunk Format, much like the older Ninja format it's based on, is designed heavily around the specific hardware/software requirements of whatever platform it is intended to be used on.

Unlike the older Ninja format, however (which only supports one platform: the SEGA Dreamcast), the NN Chunk Format is "multi-platform", and therefore comes in many different platform-specific variants.

All known used platforms are listed in the following chart:
{| class="wikitable"
|+
!ID
!CC
!Used on
!Endianness
!Alignment
!NN Library Version
|-
|NS
|s
|PlayStation 2
|Little
|16
|PlayStation2
|-
|NG
|g
|GameCube/Wii
|Big
|32
|GAMECUBE/Wii
|-
|NX
|x
|Xbox/Xbox 360/Windows
|Little
|16
|DirectX G1.1
|-
|NY
|y
|Xbox
|Big
|16
|DirectX G1.1
|-
|NL
|l
|SEGA Lindbergh
|Little
|16
|LINDBERGH
|-
|NU
|u
|PlayStation Portable
|Little
|16
|PSP
|-
|NC
|c
|PlayStation 3
|Big
|16
|PS3
|-
|NE
|e
|Xbox 360
|Little
|16
|DirectX G2.0 on XBOX360
|-
|NZ
|z
|Windows
|Little
|16
|DirectX G2.0 on WINDOWS
|-
|NI
|i
|iOS/Android/Windows Phone
|Little
|16
|OpenGL ES 1.1
|-
|DS
|?
|Nintendo DS/3DS
|Little
|16
|?
|}

== Data Chunks ==
As the name implies, files in the NN Chunk Format are comprised of a series of one or more "data chunks", one after another.

A "data chunk" is simply a block of data (structs, arrays, strings, etc.) that represents a single resource of a specific type.

All known data chunk types are listed in the following chart:
{| class="wikitable"
|+
!ID
!CC
!Type
!Description
|-
|TL
|t
|[[NN Chunk Format - TEXLIST|TEXLIST]]
|A list of textures.
|-
|EF
|e
|EFFECTLIST
|A list of effects (shaders).
|-
|NN
|a
|[[NN Chunk Format - NODENAMELIST|NODENAMELIST]]
|A list of names for the nodes (bones) within an object (a model).
|-
|MN
|u
|[[NN Chunk Format - MATERIALNAMELIST|MATERIALNAMELIST]]
|A list of names for the materials within an object (a model).
|-
|TN
|?
|MTNAMELIST
|A list of names for the morph targets within an object (a model).
|-
|OB
|j/o
|OBJECT
|A model. Sometimes uses 'j' as its CC if there is no TEXLIST is embedded, and uses 'o' otherwise.
|-
|MO
|m
|[[NN Chunk Format - MOTION|MOTION]]
|A node (bone) animation.
|-
|MM
|f
|[[NN Chunk Format - MOTION|MOTION]]
|A morph animation.
|-
|MC
|d
|[[NN Chunk Format - MOTION|MOTION]]
|A camera animation.
|-
|ML
|i
|[[NN Chunk Format - MOTION|MOTION]]
|A light animation.
|-
|MA
|v
|[[NN Chunk Format - MOTION|MOTION]]
|A material animation.
|-
|LI
|i/l
|LIGHT
|A light. Uses 'i' as its CC if its animation is embedded, and 'l' otherwise.
|-
|CA
|c/d
|CAMERA
|A camera. Uses 'd' as its CC if its animation is embedded, and 'c' otherwise.
|-
|MT
|g
|MORPH
|A morph target.
|-
|NT
|p
|NODE_TREE_OBJECT
|A list of nodes (bones) for a model.
|-
|ME
|q
|MESH_OBJECT
|A list of meshes and materials for a model.
|-
|SF
|?
|SHADERFILE
|?
|-
|SI
|?
|SHADERIDX
|?
|}
Each data chunk has a "root struct" associated with it, which is the starting point for the data in the chunk, and usually references other data (structs, arrays, strings, etc.).

For information on the formats of the data contained within these data chunk types, please refer to the linked pages in the above chart.

== File Types ==
Just like with the older Ninja format, NN chunk files come in two forms:

* [[NN Chunk Format#Binary-Form File Format|Binary-Form]]
* [[NN Chunk Format#Text-Form File Format|Text-Form]] (aka "Ascii-Form")
{{Notice|type=info|content=The vast majority of NN chunk files in released games are in binary-form.

To our knowledge, all released games using NN don't support loading text-form files at runtime, meaning that all NN text-form files found in the games are unused developer leftovers!}}
Both of these forms represent the same thing: A series of one or more data chunks. However, they do so in different ways.

File extensions for NN chunk files typically consist of three characters:

# The "CC" (character-code) of the [[NN Chunk Format#Platforms|platform]].
# <code>n</code> for [[NN Chunk Format#Binary-Form File Format|Binary-Form]] files, or <code>t</code> for [[NN Chunk Format#Text-Form File Format|Text-Form]] files.
# The "CC" (character-code) of the last [[NN Chunk Format#Data Chunks|data chunk]] contained within the file.

=== Examples ===
{| class="wikitable"
|+
!Extension
!Meaning
|-
|.xno
|<nowiki>Xbox | Binary-Form | OBJECT</nowiki>
|-
|.gno
|<nowiki>Gamecube | Binary-Form | OBJECT</nowiki>
|-
|.xtv
|<nowiki>Xbox | Text-Form | MOTION (material)</nowiki>
|-
|.snt
|<nowiki>PlayStation 2 | Binary-Form | TEXLIST</nowiki>
|}

== Binary-Form File Format ==
Binary-Form NN chunk files are represented as a series of consecutive "binary chunks", each of which begins with the following data:
{{Notice|type=note|content=All instances of this struct (and ONLY this struct) are represented in little-endian, regardless of the endianness specified by the [[#Platforms|platform]]. Everything else in Binary-Form NN chunk files is represented in the endianness specified by the [[#Platforms|platform]].}}{{Notice|type=note|content=A struct type with this name does not actually exist (to my knowledge) in real Sega NN implementations; these fields are just embedded directly within every NNS_BINCNK_ struct. This is just an easier way to think about it for our purposes.}}<syntaxhighlight lang="cpp">
struct NNS_BINCNK_HEADER
{
// The four-character identifier for this binary chunk;
// specifies what type of binary chunk this is.
uint32_t Id;

// The offset to the next four-character identifier in the
// file, relative to the end of this struct (such that after
// doing `fread(&OfsNextId, sizeof(OfsNextId), 1, file)`
// you can just do `fseek(file, OfsNextId, SEEK_CUR)`.
int32_t OfsNextId;
};
</syntaxhighlight>Immediately following this struct comes all of the data (structs, strings, etc.) required to represent the binary chunk. The format of this data depends on the value of the Id field.

After each binary chunk (including all of its data) has been written, the file is padded (with null bytes) to a position that is divisible by the "alignment" specified by the [[NN Chunk Format#Platforms|platform]] (usually it's 16, but notably, it's 32 on Gamecube/Wii).

What follows is documentation for all known binary chunk types, in the order that they appear within binary-form NN chunk files.

=== Info Chunk ===
{{Notice|type=note|content=This chunk is required to be present at the beginning of all binary-form NN chunk files! The Sega NN games I've checked actually rely on this behavior, so you can too.}}
This binary chunk serves as the header for a binary-form NN chunk file, and contains info needed to parse the file. It is represented as the following struct:<syntaxhighlight lang="cpp">
struct NNS_BINCNK_FILEHEADER
{
// Binary chunk header; must be present at the beginning of all binary chunks.
//
// The chunk ID is set to "**IF", where "**" is the "ID" of
// the platform (e.g. "NGIF" for Gamecube binary chunk headers).
NNS_BINCNK_HEADER ChunkHeader;

// The number of data chunks in the file.
int32_t nChunk;

// The absolute offset to the first data chunk in the file.
int32_t OfsData;

// The combined size of all of the data chunks in the file, in bytes, including any padding.
int32_t SizeData;

// The absolute offset to the (required) NOF0 binary chunk.
int32_t OfsNOF0;

// Size of the (required) NOF0 binary chunk, including its header.
// Depending on the variant of the format, this size either includes
// the padding that comes after the NOF0 binary chunk, or it doesn't.
//
// TODO: Figure out exactly which versions include padding.
// It seems PSP files and .[x]ncp files don't count the padding,
// but everything else does??
int32_t SizeNOF0;

// 1 in most files, 0 in some newer variants.
// (Maybe they just stopped using this value?)
int32_t Version;
};
</syntaxhighlight>{{Notice|type=note|content=Further research NIFL header chunks and add info on those.}}

=== Data Chunk Header ===
After the [[NN Chunk Format#Info Chunk|Info Chunk]], comes the main contents of the file: A sequence of one or more [[NN Chunk Format#Data Chunks|data chunks]].

In binary-form NN chunk files, each data chunk begins with the following struct:<syntaxhighlight lang="cpp">
struct NNS_BINCNK_DATAHEADER
{
// Binary chunk header; must be present at the beginning of all binary chunks.
//
// The chunk ID is set to the "ID" of the platform, followed
// by the "ID" of the data chunk type being written (e.g.
// "NXOB" for Xbox OBJECT data chunks).
NNS_BINCNK_HEADER ChunkHeader;

// The offset to the root struct that makes up this data chunk
// (e.g. an offset to a NNS_NODENAMELIST if the chunk type indicates
// that this is a NODE_NAME data chunk), relative to the
// position specified by the [OfsData] field from the info chunk.
//
// Please refer to the linked pages in the data chunks chart
// to learn about their root structs.
int32_t OfsMainData;

// Always 0 in every file I've seen thus far.
int32_t Version;
};

</syntaxhighlight>Immediately following this struct comes all of the data (structs, strings, etc.) required to represent the data chunk. The format of this data depends on the value of the Id field.

See the linked pages in the [[NN Chunk Format#Data Chunks|data chunks chart]].

=== Offsets List Chunk ===
{{Notice|type=note|content=This chunk is required to be present in all binary-form NN chunk files!}}
After all of the data chunks, comes the offsets list chunk.

This binary chunk represents a list of positions for all of the pointers ("offsets") in all of the data chunks in the file, relative to the value of the <code>[OfsData]</code> field from the info chunk.<syntaxhighlight lang="cpp">
struct NNS_BINCNK_NOF0HEADER
{
// Binary chunk header; must be present at the beginning of all binary chunks.
//
// The chunk ID is set to "NOF0".
NNS_BINCNK_HEADER ChunkHeader;

// The number of pointer positions listed within this chunk.
int32_t nData;

// Padding; must always be 0 in files.
//
// This is because some games use this value as a marker that states
// whether or not the pointers have been "fixed".
//
// In those games, after they're done "fixing" all of the pointers
// listed within this chunk, they will set this value to 1 in memory.
int32_t Pad;
};
</syntaxhighlight>Immediately following this struct comes an array of <code>uint32_t</code> values of size <code>[nData]</code>. These values represent the positions of every pointer in all of the data chunks in the file, relative to the <code>[OfsData]</code> field from the info chunk.

Most NN games use this chunk to quickly "fix" all of the pointers within the data chunks (that is, to convert all of the offsets into absolute memory addresses that can then just be used as normal pointers).

Some games, however, (namely: Sonic 4 Episode I for Windows Phone) ignore the values in this chunk, and instead, just manually add <code>[OfsData]</code> to each offset to get an absolute file position whenever they need to jump there.

Regardless of whether the data is actually used or not, it is always present in valid files.
{{Notice|type=note|content=Add pseudo-code for "fixing" the offsets listed in this chunk.}}

=== File Name Chunk ===
{{Notice|type=info|content=This chunk is completely optional and seems to only be used for debugging/internal-tooling purposes.}}
This chunk simply states the name and extension (without the path) of the file it's contained in.<syntaxhighlight lang="cpp">
struct NNS_BINCNK_NFN0HEADER
{
// Binary chunk header; must be present at the beginning of all binary chunks.
//
// The chunk ID is set to "NFN0".
NNS_BINCNK_HEADER ChunkHeader;

// Padding; always 0 in files.
uint32_t Pad[2];
};
</syntaxhighlight>Immediately following this header comes a null-terminated string which represents the file's name and extension (without its path).

=== End Chunk ===
{{Notice|type=note|content=This chunk is required to be present in all binary-form NN chunk files!}}
This is the last chunk in all binary-form NN chunk files. It exists purely to indicate that there are no more chunks left in the file, so that you know when to stop reading if you're reading the file sequentially, one chunk at a time.<syntaxhighlight lang="cpp">
struct NNS_BINCNK_NENDHEADER
{
// Binary chunk header; must be present at the beginning of all binary chunks.
//
// The chunk ID is set to "NEND".
NNS_BINCNK_HEADER ChunkHeader;

// Padding; always 0 in files.
uint32_t Pad[2];
};
</syntaxhighlight>

== Text-Form File Format ==
Text-form NN chunk files, just like the text-form Ninja chunk model files that precede them, are text files comprised of code in what is actually a very limited subset of the C programming language, heavily utilizing special NN types/preprocessor defines, which are, presumably, defined within the official NN SDK.

This allows them to both be parsable by tooling (it is unclear if they actually do this), and to be directly <code>#include</code>d within the C or C++ files which make up their game's source code, embedding the data directly within the game's executable!

Their general layout is as follows:
{{Notice|type=note|content=Replace these special phrases in all of the following <code>text</code> snippets as follows:

* \t: Replace with one or more tab characters (NOT spaces), used to align the text.
* TYPE: Replace with the name of the type currently being written.
* NAME: Replace with the name of whatever you're currently writing.}}

# A (required?) "header" comment that is comprised of the following, in order:
## The name and version number of the tool used to create this file.
## <code>Create\t:</code> followed by the date this file was created in the <code>ddd MMM dd HH:mm:ss yyyy</code> .NET DateTime format.
## The names of each of the root structs for every data chunk in the file, in this format: <code>TYPE\t: NAME</code>, where <code>TYPE</code> refers to the root struct's type (e.g. <code>NNS_TEXFILELIST</code>). See the linked pages in the [[NN Chunk Format#Data Chunks|data chunks chart]].
# One or more data chunks, each of which is comprised of the following, in order:
## A comment with the text: <code>TYPE START</code>, where <code>TYPE</code> refers to the [[NN Chunk Format#Data Chunks|data chunk's type]] (e.g. <code>TEXLIST</code>).
## All of the data used by this data chunk, represented as C code comprised heavily of special NN preprocessor macros. See the linked pages in the [[NN Chunk Format#Data Chunks|data chunks chart]].
## A comment with the text: <code>TYPE END</code>, where <code>TYPE</code> refers to the [[NN Chunk Format#Data Chunks|data chunk's type]] (e.g. <code>TEXLIST</code>).
# A (required?) comment with the text: <code>End of File</code>.

The files also always use tab characters (<code>\t</code>) for indentation, rather than spaces.

Here's a sample Text-form NN chunk file, to better understand the format:
{{Notice|type=example|content=<syntaxhighlight lang="cpp">
/*
Sample NN Exporter Version 1.00.00
Create : Wed Feb 08 21:06:46 2023
NNS_TEXFILELIST : nntexfilelist_SampleFile
*/

/* TEXLIST START */

NNS_TEXFILE nntexfile_SampleFile[] =
{
TEXFILE(
TF_FILENAME( "SampleTex_dif.dds" ),
TF_FILTER( NND_MIN_LINEAR_MIPMAP_NEAREST, NND_MAG_LINEAR )
),
TEXFILE(
TF_FILENAME( "SampleTex_spec.dds" ),
TF_FILTER( NND_MIN_LINEAR_MIPMAP_NEAREST, NND_MAG_LINEAR )
),
TEXFILE(
TF_FILENAME( "SampleTex_norm.dds" ),
TF_FILTER( NND_MIN_LINEAR_MIPMAP_NEAREST, NND_MAG_LINEAR )
),
};

NNS_TEXFILELIST nntexfilelist_SampleFile[] =
{
TEXFILELIST(
TFL_N_TEXFILE( 3 ),
TFL_TEXFILE( nntexfile_SampleFile )
)
};

/* TEXLIST END */

/* End of File */
</syntaxhighlight>}}{{Notice|type=info|content=All of the following in the above example are type/preprocessor defines from the NN library:

* NNS_TEXFILE
* TEXFILE
* TF_FILENAME
* TF_FILTER
* NND_MIN_LINEAR_MIPMAP_NEAREST
* NND_MAG_LINEAR
* NNS_TEXFILELIST
* TEXFILELIST
* TFL_N_TEXFILE
* TFL_TEXFILE

For a complete list of all of these defines, please refer to the individual pages linked in the [[#Data Chunks|data chunks chart]] (for the ones used in this example, refer to the [[NN Chunk Format - TEXTLIST|TEXLIST]] documentation).}}
Note that in C, code is parsed sequentially: left-to-right, top-to-bottom.

If a name is used in the file before it has been declared, that's an error.

Thus, the ordering of the data within each data chunk is generally written to the file in "reverse" order, such that any reference to a value will not be written until ''after'' the value it is referencing has been written, avoiding this problem.

In some cases, the NN exporters will instead declare the value early, and define it later on in the file, using an extern declaration like so:
{{Notice|type=example|content=Here, the <code>nnvertex_plb_op_en_Kyozoress_head_l__2_w2_Eye</code> value is declared so that it can be referenced by the <code>VTX_LISTPTR</code> field in <code>nnvertexdesc_plb_op_en_Kyozoress_head_l__2_w2_Eye</code>:

<syntaxhighlight lang="cpp">
extern NNS_VTXTYPE_XB_PW4INCT nnvertex_plb_op_en_Kyozoress_head_l__2_w2_Eye[];

NNS_VTXLIST_DX_DESC nnvertexdesc_plb_op_en_Kyozoress_head_l__2_w2_Eye[] =
{
VTXDESC(
/* ... */
VTX_LISTPTR( nnvertex_plb_op_en_Kyozoress_head_l__2_w2_Eye ),
/* ... */
),
};
</syntaxhighlight>

Then, later on in the file, the referenced <code>nnvertex_plb_op_en_Kyozoress_head_l__2_w2_Eye</code> value is defined as usual (contents redacted due to extreme length):

<syntaxhighlight lang="cpp">
NNS_VTXTYPE_XB_PW4INCT nnvertex_plb_op_en_Kyozoress_head_l__2_w2_Eye[] =
{
/* ... */
};
</syntaxhighlight>}}
[[Category:File Formats]]