1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
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.
|
