summaryrefslogtreecommitdiff
path: root/doc/devel/pkgformat
diff options
context:
space:
mode:
Diffstat (limited to 'doc/devel/pkgformat')
-rw-r--r--doc/devel/pkgformat174
1 files changed, 174 insertions, 0 deletions
diff --git a/doc/devel/pkgformat b/doc/devel/pkgformat
new file mode 100644
index 0000000..69a2513
--- /dev/null
+++ b/doc/devel/pkgformat
@@ -0,0 +1,174 @@
+The .pkg/.ndx format as used for Starcon.pkg on the 3DO cd.
+Acquired directly from the source.
+
+This format is used both in the file and is memory. There are some
+little differences; where this is this is the case, this is
+mentioned below in square brackets.
+
+Everything is stored LSB first.
+
+This document talks about packaged files.
+Packaged files have multiple resources stored in one file. All the resources
+in one package are stored in a single file, whose name is specified in
+p.packmem. The name may be '\0', in which case the package file itself
+is used.
+Non-packaged files have one resource per file. The name is specified
+in each resource instance info field.
+
+Main header: (resinit.c, _GetResFileData())
+position length meaning
+0x00 2 Whether or not the file is packaged (res_flags)
+ bit 0: 0 - the .pkg file is not packaged
+ 1 - the .pkg file is packaged
+0x02 4 offset from the beginning of the file where the list
+ of package information is stored (packmem_list_offs)
+0x06 4 offset from the beginning of the file where the list
+ of pathnames is stored (path_list_offs)
+0x0a 4 offset from the beginning of the file where the list
+ of file names is stored (file_list_offs)
+0x0e 2 number of packages in the file (num_packages)
+0x10 2 number of types of packages present in the file (num_types)
+0x12 4 length of this header. (index_info.header_len)
+ (unused if the .pkg file is not packaged)
+0x16 8*num_packages:
+ On position i the information for package i + 1 is
+ stored. There is no package 0.
+ 4 p.packmem_info
+ bits 0-7: number of resource types
+ bits 8-20: number of resource instances
+ bits 21-31:
+ For packaged files: index in file_list_offs of the
+ file name for this resource
+ For non-packaged files: unused (0)
+ 4 p.flags_and_data_loc
+ MSB is flags, rest is data_loc,
+ if MSB == 0, then of the data_loc only the low 16 bits
+ are used as a MEM_HANDLE [only in memory],
+ if MSB == 0xff, then the data_loc is an offset in the
+ file to the actual data
+0x16+8*num_packages Type information
+ 2*num_types
+ t.instance_count
+ The number of instances there are of this type.
+ On position i the instance count for type i + 1 is
+ stored. There's no type 0.
+packmem_list_offs (should be directly after the index info):
+ for each of the num_packages packages:
+ for each of the resource types for this package
+ (as in p.packmem_info):
+ 4 bits 0-7: The type number for this type. What that
+ number means isn't specified, and may
+ vary per .pkg file.
+ For the 3DO SC2 starcon.pkg file these are:
+ 0 - not a type
+ 1 - Graphics data (GFXRES)
+ 2 - String data (STRTAB)
+ 3 - Music data (MUSICRES)
+ 4 - Resource index (RES_INDEX)
+ 5 - Code (CODE)
+ bits 8-20: The instance number of the first instance
+ of this type in this package. Every
+ following instance has a number 1 higher
+ than the one before.
+ bits 21-31: number of resources of this type in the
+ package
+ for each of the resource instances for this package
+ (as in p.packmem_info):
+ 2 if this is a packaged file: multiply by 4 to get
+ the length of this resource. [1]
+ if this is a file that is not packaged:
+ index in file_list_offs of the file name for
+ this resource.
+ [the same position is in memory used as a MEM_HANDLE
+ to the actual data]
+path_list_offs (should be directly after the packmem list)
+ ? null terminated path strings, indexed from the file list
+ table
+file_list_offs (should be directly after the path list)
+ ? A number of file info structures. For packaged files,
+ these are indexed from the p.packmem_info (so (at most)
+ one per package). For non-packaged files, these are
+ indexed from an entry for an instance from
+ p.packmem_list (so possibly more per package)
+ These structures are in this form:
+ 13 file info:
+ 2 location relative to path_list_offs of the
+ the path to this file, or 0xffff if no path.
+ 8 file name (8 chars or null-terminated)
+ 3 extension (3 chars or null-terminated)
+
+The following section is present in the package only for packaged files.
+For non-packaged files, the fields below exist in the external file indicated
+by p.packmem_info.file_index.
+For each package p:
+p.data_loc for each type p.t:
+ for each instance p.t.i:
+ p.t.i.length
+ the data for the resource
+ As the length always is a multiple of 4, the last
+ few bytes may not belong to the resource itself.
+ Their content is unspecified.
+
+
+Resources with type 'resource index' (type 4 in the 3DO sc2 starcon.pkg file)
+are files with the same format as this .pkg file itself.
+
+
+The information above, about the format used on the 3DO, is gathered from
+the resource library sources itself.
+The information below, about the format used on the PC, and for SC1,
+is induced from the packed files themselves.
+
+
+The format used in SC1 is somewhat different. The differences are listed
+here:
+0x02 4 offset from the beginning of the file where the list
+ of pathnames is stored (path_list_offs)
+0x06 4 offset from the beginning of the file where the list
+ of file names is stored (file_list_offs)
+0x0a 4 offset from the beginning of the file where the list
+ of package information is stored (packmem_list_offs)
+0x0e 2 number of types of packages present in the file (num_types)
+0x10 2 ?
+0x12 2 number of packages in the file (num_packages)
+0x14 2 ?
+packmem_list_offs
+ 4 as for the 3DO
+ 2 if this is a packaged file: the length of this resource.
+ No multiplication by 2 or 4 as on other platforms. [1]
+
+
+The format used in the DOS version of SC2 is different yet again.
+The differences to the 3DO version are listed here:
+0x10 1 number of types of packages present in the file (num_types)
+0x11 1 unknown
+packmem_list_offs
+ 4 as for the 3DO
+ 2 if this is a packaged file: multiply by 2 to get
+ the length of this resource. [1]
+
+
+[1]. In some of the packaged .pkg files used in the Toys For Bob games,
+the length field of a resource instance is overflowed for some resources,
+even though the use of a multiplier will have had the purpose of preventing
+this. The actual size is a multiple of 0x10000 times the multiplier larger.
+This occurs in 18 packages in the PC version of Star Control II, in
+1 package of the Amiga version of Star Control 1, and in 2 packages of
+the PC version of The Horde. The PC version of Star Control 1, and the 3DO
+version of Star Control II don't have such overflows.
+The actual size of a package can be determined by looking at the
+difference in offset between two subsequent packages.
+Where the package contains only one resource instance, the extra data can
+only belong to that instance. Where a package contains more than one
+resource instance, the extra data most likely belongs to the last resource,
+as an incorrect size results in an incorrect offset for all subsequent
+instances in the package, which would most likely have been noticed due to
+corruption in the game.
+
+
+The part pointed to by file_list_offs is frequently followed by a bit of
+unused space, which may contain garbage.
+
+
+Initial version of this file 2002-10-10 by Serge van den Boom.
+