Time to get our sleeves up and dig into the nitty gritty dirty details about how all that worked together.

Before entering into the details, I need to highlight a few facts about why things were somewhat better back in the days¹!

Perfect knowledge

Modern 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 browser².

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
  

Optimizations

When 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 fine³.

If you dig into the files on the Time Commando CD ROM⁴, you will see that the game levels are made of one HQR⁵ and one ACF⁶ 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 Files

HQR files are basically the conceptual equivalent of archives such as ZIP or PAK files, and were created by the MAKE_HQR tool.

MAKE_HQR.EXE

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 files⁷ 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.

VIEWHQR.EXE

The command C:\HQR\VIEWHQR.EXE SCENE.HQR -lSCENEPC.LST returns the following list:

The tools

Of 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...

1. 3DS (PC) or SoftImage (Silicon Graphics)
   
2. TCED aka "Time Commando EDitor"
   
3. DOFIELD
   
4. DELUXE PAINT
   
5. VOLGRAPH
   
6. MAKE_HQR
   
7. PALEDIT
   
8. CODE
   
9. DECOMP
   
10. VIEWACF
    
11. COMPRESS
    
12. ACFTOOLS
    
13. ACFCONC
    
14. ACFPAD (.BAT file using #10/#12)
    
15. ACFIDX
    
16. ACFSTAT
    
17. ACFLOAD
    
18. RECOUVRE
    
19. MAKEFLOW
    
20. PSXSND
    
21. AIFF28
    
22. PSCONV (.BAT file using #21)
    
23. SNDPCNV
    

and in addition we can use whatever text editor (Boxer/BC/Edit/MultiEdit/QEdit/...) people would choose to use to edit the scripts or configuration files.

File formats

And 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 this⁸:

Level Export Flowchart

That's all for today!

---