3D Coding TAT - Gallons Into Pint Pots
If you absolutely need to keep reading the level because it won't all fit into memory in one go then try some of the following tips.
a. Blame your data structures, did you really need all those data fields and a dword for a single bit flag?
b. Tokenize. Often this can actually help speed up certain tasks and applied to levels with lifts, doors and so on can allow the recycling of things without having to re-process all the states and logic (e.g. blinking lights).
c. Design your levels so that lifts or transporters can be used to illustrate to the player why the game halts there. If the machine suddenly stop for a few seconds then players might think it has crashed and hits reset just as your games loads from their hard-drive... blammo....
d. Depending on the available memory at load time try using a lower sample rate when sounds are loaded or halve the resolution of your textures as you load 'em. Both of these are really easy to implement and can boost performance on slower machines too!
e. Compression. This should be used with a large pinch of salt as the time taken to decompress may be slower than actually performing the load from disk.
f. Allow the user to install often loaded stuff onto their hard-drive from the CD. I know many new CDs are 32x speed or something silly, but they still tend to be much slower than a hard-drive. My CD drive IS faster but it spends a second or so spinning upto speed before data can be read - this is a real pain for lots of little transfers.
g. Don't have too many files open at once. Use a single file if possible instead of switching between many file handles. Group all the levels, graphics and other data into a few library files and simply seek within these rather than keep opening and closing files.
h. Remove disk caches? These little memory chewers store up disk writes and then pounce a few seconds later. They can often be useful when reading (opening files, reading the directory or FAT tables) but for very large files the cache is mostly flushed which doesn't help much. In a lot of ways your program can cache more effeciently than DOS or Windows etc. because YOU know the likely order in which the data will be accessed.