Soul Reaver's Gex Engine - Technical Documents - Legacy of Kain: The Lost Worlds

Soul Reaver's Gex Engine

This article was part of the content on the original (pre-2007) version of The Lost Worlds. I found it while looking around for things to post on the 10th anniversary of the site in 2012. It is presented here for historical interest, and has not been audited for 100% accuracy.

Younger readers have probably grown up entirely with videogames that operate like this article describes, but back in the late 1990s (when Soul Reaver was released), it was revolutionary for a free-roaming 3D adventure game to stream content off of the CD like this.

This particular article was last updated on 26 April, 2003.

Soul Reaver is based upon Crystal Dynamics' proprietary Gex engine, along with code from several others that they have worked on, apparently including a baseball game which was the source of the character animation code.

The Gex engine allows environment data to be streamed in as it is needed, which is how Soul Reaver can allow the player to run from end to end of the huge game world without pausing to load data or switch to a different "level" as in other adventure games.

This is accomplished by dividing the game world up into a series of "rooms" for lack of a better word. "Rooms" in this case can carry its traditional meaning (e.g. an enclosed area with roughly four walls, one or more doors, and possibly some windows) or in a broader sense such as a hallway or the underwater half of a lake area.

Soul Reaver's terrain data is stored in a file called bigfile.dat for both the PC and PSX versions of the game. On the Playstation, this file also contains the texture maps for the game world, while on the PC this information is stored in a seperate file called textures.big.

Each room in bigfile.dat is named using a seven- (or less) letter name and a one- or two-digit number.

The convention that is generally followed is that the same name is used for all the parts of a given area, with the numbers being used to subdivide it (e.g. cathy 1 is the first location from which you can see the exterior of the Silenced Cathedral, and cathy 55 is the room which contains Zephon, the boss character for the Cathedral). This convention is not adhered to 100%, especially with regards to the lighthouse area, which is comprised of roughly half a dozen different names, all with the number 1. The lighthouse area was apparently one of the first ones built however, so it is possible that the convention had not been agreed on yet. Every known room in bigfile.dat is listed in the Soul Reaver Area List (see Soul Reaver Technical Information (Overview)), which was accomplished by my searching bigfile.dat for likely keywords and then loading them individually to catalogue what room they represent.

These rooms are chained together by references also contained in bigfile.dat. Each room contains a list of entrance/exit points and a reference to the room that is joined there. For example, the section for cathy 1 might include a reference to cathy 2 (the cave tunnel which leads to the first Zephon Clan symbol Warp Gate) in the form "cathy2,12" where "cathy2" represents the area that is linked to and the second number represents something I can only express as "WTF?" This second number is somehow related to the way the two areas are linked at that particular entrance/exit point, but I am uncertain as to what exactly it does, and experiments to provide further information have proven... unwise.

What the Gex engine does is to stream in only the data for the room that the player is currently occupying, and when an entrance/exit point is approached, for the room that it leads to. This is most easily represented visually. For this example, I will presume the existence of a very small bigfile.dat containing three rooms: styro 1 (which is a mysterious pile of ancient styrofoam blocks), cdrack 1 (which is an ominously dark plastic 30-CD rack laying facedown), and vlad 6 (which is the internal development codename for a cardboard box I had lying on my project table). The player will be represented by my toy Raziel figure, modeled in loving detail by Blue Box Interactive and obtained by me from CyToys Online. Note: The scale of Raziel in relation to the terrain is greatly exaggerated. The rooms should be much bigger. But so should my project table.

In this first picture, Raziel has just crossed the entrance/exit point from styro 1 to cdrack 1.

At this point, most or all of both of these areas is loaded into memory. In front of him, near the far end of cdrack 1 is a fog that is the same colour as the background for the current area.

As Raziel moves further into cdrack 1, the Gex engine draws less and less of styro 1, and finally purges it from memory when it is no longer needed. To be totally accurate I should have start cutting away the far chunks of styro 1 with a knife as Raziel moved further and further away, but that would have been too messy. You'll just have to imagine the fog effect off to the left.

Moving towards the far end of cdrack 1, the Gex engine loads the data for vlad 6, and starts to draw it when it is close enough. If Raziel were to turn around at this point, he'd see a hazy mist back where the doorway between styro 1 and cdrack 1 should be. I am pretending that there is a hole cut in the side of vlad 6 to serve as a doorway between it and cdrack 1. You will have to also, since I didn't want to reduce the possible future utility of vlad 6 for this demonstration.

If Raziel goes through the (imaginary) doorway into vlad 6, the process starts all over again - Gex draws less and less of cdrack 1, and finally purges it from memory when it is no longer needed.

However, if the player decides to move from cdrack 1 to vlad 6 without going through the valid entrance/exit point (possibly by moving to just before the door, jumping, pausing the game, alt-tabbing back to Windows, then using an active memory editor to increase the DWORD value at memory location 00AF8AC4 (PC Soul Reaver v1.2 only)), then returning to the game, unpausing, and gliding down through the roof of vlad 6 (which is invisible and has no collision detection from above)...

...as soon as Raziel lands, Gex detects that a valid entrance/exit point was not used, and refuses to draw vlad 6 or stream terrain data from the rooms that it connects to. In this shot, Raziel is looking back in the direction of cdrack 1 and can see it just fine, but vlad 6 is invisible. It is still there, but Gex won't draw it and if Raziel reaches an entrance/exit point in the invisible area and tries to go through it, he will fall into nothingness because Gex isn't streaming in new areas.

It is possible to fool Gex into thinking that an entrance/exit point has been used. The size of these points seems to be relatively large, so if Raziel were to approach the doorway between cdrack 1 and vlad 6 (even if it were a closed door) generally this will kick-start Gex and it will display vlad 6 and begin streaming in data again.

Note that some areas have incredibly large entrance/exit points (e.g. the Stone Glyph area, since its canyon is split into several chunks) but most are the size of the doorway between the two rooms.

This aspect of Gex becomes readily apparent when searching for hidden areas. For example, even though city 10 and city 11 are right next to city 9, Gex will not stream them in if the player uses the PSX fly code or the aforementioned active memory edit to reach where they should be.

Gex does not appear to be able to stream more than one area in simultaneously. In areas where this would seem to be necessary (e.g. a hallway with two branching paths) this apparently is worked-around by having the first part of one of the branches be contained within the hub room, so that Gex will stream the data for the room beyond the first branch, and if the player chooses the second it has time to start streaming the other room in before they get to the end of the second hallway.