Before entering into the details, I need to highlight a few facts about why things were somewhat better back in the days1!
Perfect knowledgeModern game development is fundamentally different to what it used to be.
These days, the same code base is expected to run with as little modifications on a Windows PC, Nintendo Switch, even sometimes on a mobile phone or web browser2.
These games may be running on hard drives or SSD, on mobile processors or overclocked crunching beasts, on a vast range of gpus.
These games even have to support patches, downloadable updates and user created content.
For the developer, what that means is that you cannot rely on anything really, because you don't know how much cpu power, memory, graphical ability, storage or amout of data to deal with, so you can't really do any assumption about memory layout, number of animations, disk capacity and speed, etc...
By comparison, back in the days we could look at a PlayStation, and clearly see that:
- We have two megabytes of main RAM
- There is one megabyte of 2D addressable Video RAM
- We can use up to 512 kilobytes of ADPCM compressed audio
- All the data is static and comes from a 2X CD ROM drive
- The CPU is a R3000A running at 33mhz
- We know exactly how many clock cycles each instruction takes
- We know exactly how the cache behaves
- We have full control on the co-processors and DMA
OptimizationsWhen you know all that, you can do many assumptions, and you can do many optimizations based on these:
- Since you know all the resources up-front, you can access them directly by index instead of fancy look-up strategies
- You can load all the data you need as one big blob directly into memory, without any allocation
- You can make the program cache friendly by playing with the linking order
Obviously for the PC version of Time Commando some of the possible optimization would not apply since the hardware could change, but we could still target for the lowest spec system, knowing that better machines would just handle that fine3.
If you dig into the files on the Time Commando CD ROM4, you will see that the game levels are made of one HQR5 and one ACF6 file.
People who digged into Little Big Adventure already know the HQR format because it already existed, while the ACF file format was created specifically for Time Commando.
The ACF files contains data which is only relevant at specific locations in the level sequence, such as the background pictures, the additional rooms, as but also the camera position and zbuffer data used to handle the overlapping sections of graphics behind which the character can move... and they will require their own posts because there's quite a lot thing to cover!
HQR FilesHQR files are basically the conceptual equivalent of archives such as ZIP or PAK files, and were created by the MAKE_HQR tool.
The way it's used in Time Commando, our scene compiler would look at what the gameplay designers did, collect the list of all the 3D models and textures, animations and particle effects, musics and sound, ... and then use this information to generate binary versions of the level data optimized specifically for this specific scene content, as well as creating the LST files used by MAKE_HQR to generate the final data for both platforms.
Here is an example of what the .LST files7 for the first level of the game look like on PC and PlayStation:
Logically, the same files should have been present at the same location, but for some reason it did not happen because of the two different codebases.
Using these LST files and VIEWHQR.EXE, it's then possible to extract back the content of the HQR files.
The command C:\HQR\VIEWHQR.EXE SCENE.HQR -lSCENEPC.LST returns the following list:
The toolsOf course, we did not only have MAKE and VIEW HQR, we had plenty more tools!
I will have to dig in my archive to find a complete list of all the file formats and tools involved, but that should give you a rough idea of what we used.
Here is a list of some of the tools involved...
- 3DS (PC) or SoftImage (Silicon Graphics)
- TCED aka "Time Commando EDitor"
- DELUXE PAINT
- ACFPAD (.BAT file using #10/#12)
- PSCONV (.BAT file using #21)
File formatsAnd the associated list of file formats (the number refers to the tool number on the list above)
- (STG) Level configuration (text)
- (HQR) Resource archives (8,6)
- (SCE) Scene description (text)
- (VUE) Camera information (1)
- (ACF) Compressed video streams (11-17)
- (ZBF) Source ZBuffer data (1+IPAS)
- (ZMI) Masks (18)
- (SOL,FIE) 3D ground information (2/3)
- (S3D,O3D,F3D,3DP) 3D characters and items (6)
- (ANI,A3D) Animations (6)
- (GIF,JPG,TGA,TIF,FLC,PCX) Misc pictures formats
- (GPH,GPR) Compressed sprites sheets (5)
- (SHD) Color palettes (7)
- (MAT) Materials and effects (text)
- (ARM) Weapons (text)
- (FIC) Character sheets (text)
- (FLW) Particle flows (19)
- (MID,XMI,WAV) PC audio formats
- (SNG,SNP,SNV,VAG) PlayStation audio formats (20-23)
- (C,CPP,H,S,ASM) Source code (text)
When put all together, the actual process looks like this8:
That's all for today!
1. Or at least, things that made it somewhat easier to make games↩
2. At least some of us tried, you can find them drooling in mental asylums↩
3. With the exception of the Pentium Pro CPU, which unfortunately would drop in performance like a ston when trying to access 8 bit part of registers such as AL, BL, AH and BH, which our video decompression system did a lot↩
4. There are slight differences between the PC and PSX version, but these are not relevant for the discussion↩
5. HQR stands for "High Quality Resource"↩
6. ACF stands for "Adeline Chunk Format"↩
7. Including the original French comments with proper accentuation.↩
8. Click on the picture to see a larger view↩