293rently. For example, when level A is loaded, it might allocate and make use of
N chunks. Later, level B might allocate an additional M chunks. When level
A is eventually unloaded, its N chunks are returned to the free pool. If level
B is still active, its M chunks need to remain in memory. By associating each
chunk with a specifi c level, the lifetimes of the chunks can be managed easily
and effi ciently. This is illustrated in Figure 6.4.
One big trade-off inherent in a “chunky” resource allocation scheme is
wasted space. Unless a resource fi le’s size is an exact multiple of the chunk
size, the last chunk in a fi le will not be fully utilized (see Figure 6.5). Choos-
ing a smaller chunk size can help to mitigate this problem, but the smaller the
chunks, the more onerous the restrictions on the layout of the resource data.
(As an extreme example, if a chunk size of one byte were selected, then no
data structure could be larger than a single byte—clearly an untenable situ-
ation.) A typical chunk size is on the order of a few kilobytes. For example
at Naughty Dog, we use a chunky resource allocator as part of our resource
streaming system, and our chunks are 512 kB in size. You may also want to
consider selecting a chunk size that is a multiple of the operating system’s I/O
buff er size to maximize effi ciency when loading individual chunks.
6.2. The Resource Manager
File A
Chunk 1File A
Chunk 2File A
Chunk 3File B
Chunk 1File B
Chunk 2File C
Chunk 1
File C
Chunk 2File C
Chunk 3File C
Chunk 4File D
Chunk 1File D
Chunk 2File D
Chunk 3
File E
Chunk 1File E
Chunk 2File E
Chunk 3File E
Chunk 4File E
Chunk 5File E
Chunk 6Level X
(files A, D)Level Y
(files B, C, E)Figure 6.4. Chunky allocation of resources for levels A and B.
File size:
1638 kBUnused:
410 kB
Chunk 1 Chunk 2 Chunk 3 Chunk 4
Chunk size:
512 kB each
Figure 6.5. The last chunk of a resource fi le is often not fully utilized.