APA (asset package archive) packer is an asset manager for all computational projects with distinct needs for media distribution. It can pack assets akin to a stack which omits having to distribute raw media files thus protecting intellectual property. It may be used in many scenarios. Its key objective is to ease the issue of managing assets in game development projects. With access to an API, one can easily access the raw binary to import and manipulate hundreds of assets seamlessly.

With APA packer, you never need distribute multiple RAW assets with your projects. Omit installation overhead by adopting the APA file format. Simply pack, distribute and interface with the C++ API.

NSL::APA includes state of the art 2048-bit symmetric encryption to secure your valuable assets. It is a premier solution for intellectual property protection when dispatching assets with computational projects.

What often happens with a large project is that it soon acquires a large number of assets. Things such as icons, bitmaps, audio and video media each have their own file, size and add needless bulk to installation scripting, compiling and distribution efforts. If all these can be packed into a readable format and distributed as a single file and then efficiently unpacked and read at runtime then evidently the benefits become clear.

The biggest hurdle with large projects at runtime is managing hundreds if not thousands of distinct files. Each with its own IO processing time. It is thus alot faster to process the input stream of a single gigabyte file than it is to processing 1,000 files equal to the same size.

In addition, issues such as protecting intellectual property by not distributing valuable media in raw format which could otherwise be easily stolen is omitted since an APA package is packed and thereafter encrypted with a 2048-bit digital key.

In future research, we plan to embed compression directly into NSL::APA thus taking it to the next level of digital package management. As of version 2 where our research efforts passed verification testing, encryption is supported directly into the NSL::APA library.

Nullox has a library denoted as NSL, this is the Nullox standard library which is a large library governing all computation that takes place within Nullox Software and Nullox Game developments.

APA is a minute part of NSL thus it is indeed nested with the NSL namespace. The software APA does not discriminate between the potential distinct file types nested within an APA file format. This provides the benefit of catering to boundless files and asset types in a single package. All file operations use binary mode thus contamination of assets is never an issue with adequate testing over many epochs having taken place with sha1 file hashing to verify so.

What follows is a description of the file format thus you may gain an understanding of how the packing works and a glimpse of what is possible in future revisions such as compression.

The header within an APA file comprises of eight parts, these are:

The signature comprises of six bytes aka magic numbers. The bytes correspond to the decimal vector [78, 83, 76, 65, 80, 65]. These bytes are always present in a legitimate NSL::APA file.

The next byte after the signature (the seventh byte) indicates whether the encoding used little or big endian. If the value is equal to zero then the encoding used little endian. For any other value (one in a correct implementation), the encoding would alternatively have been big endian.

The next two bytes (an unsigned short integer) informs the decoder the version number of the original encoder.

The next byte signals the receiver whether the package has been encrypted. If set to zero, the package has not been encrypted with a 2048-bit key

The eleven byte is currently reserved to signal compression. As of version 2, it is always set to zero. Decoders should refer to 2.1.3 to verify the version of the encoder. It is likely pending research efforts that this byte will be utilised in version 3 of NSL::APA.

The next four bytes (a long integer) indicates the number of assets packed within the archive.

Next follows an arbitrary number of bytes encompassing filename lengths and filename text. The order of each filename .length() and filename .c_str() are equal to the order of the binary dump further on within the archive.

For each filename length and text pair, the length is always four bytes long (a long integer) followed by the textual string corresponding to its original path name. Repeat the extraction process for each asset, since you already know the number of packed assets, the process is feasible without a terminator symbol within the stream.

Next follows a linear collection of asset sizes. Each size uses four bytes (a long integer). These asset sizes can be used to offset within the main binary data to differentiate between the number of assets.

Immediately following the header is the raw binary data for all packed assets, one asset after another. Each asset is ordered thus aligned with the filenames and sizes within the header.

The footer within an APA file comprises of one part in version 2, and is of the form: