WCDX Finds Lost Planets

Stinger pushes on in his quest to fix Kilrathi Saga's bugs and quirks; just recently he figured out why all the planets are missing in the Wing Commander 1 port. This and other patches will be included in an upcoming release of WCDX. Follow Stinger's topic on the Forums to keep up with the latest developments.

This one was interesting.

The PLANETS.VGA file (like the other VGA files) is a resource archive containing several image sets. The first image set (which I've dubbed the Space Junk image set) contains all of the normal floating debris images as well as the images for the individual stars that you see in the space backdrop (38 images in all). All of the other image sets contain only a single image; each of those is a planet or nebula or other large object (hereafter referred to only as planets). Of particular importance is that each planet image is alone in its image set.

The CAMP.00X files are resource archives. The first resource contains nothing but planet information, with four entries for each system. Information for a planet is stored in four two-byte values, in this order: Planet index, yaw, pitch, and roll. The index indicates which planet image should be used, with the special value -1 indicating that the slot is empty. The yaw, pitch, and roll values (given in degrees) determine where the planet should appear in the stellar backdrop. (The roll value is ultimately useless, but it's there anyway.)

The game keeps track of several space objects (up to 64, apparently). Each individual star is one such object, and so are the planets. Each object has a number of properties, including (among other things) orientation, position, a pointer to the image set, image index, and type. Stars are type 2; planets are type 3. For objects of type 2 (stars), the game doesn't keep track of the image set on a per-object basis. This is because the image sets are loaded on a per-object basis; if the game kept track of the image sets for individual stars, it would end up loading several copies of the image set in memory, one for each star. The game therefore has special handling for these objects, making the assumption that the image index refers to an image in the Space Junk image set. (This apparently also happens for type 4 objects, but I haven't bothered to figure out what those are yet.)

For whatever reason, possibly just because it was the expedient thing to do, the navigation crosshair (nav point indicator) is classed as a type 3 object, just like planets.

At draw time, the code cycles through all of the visible objects and draws them. For objects of type 2, 3, and 4, the game ignores orientation data and simply draws the image with no scaling or rotation. (You can see this by looking at the stars and planets as you roll your ship: the positions will change, but the orientations will remain the same.) The game checks to see if the object is the navigation crosshair; if it is, the game draws the image indicated by the object's image set and image index. If it isn't, the game uses the Space Junk image set instead, and therein lies the bug: All type 3 objects that are not the navigation crosshair are drawn using the Space Junk image set. Recall that each planet image is the only image in its respective image set; each planet, therefore, has an image index of 0, indicating that the game should use the first image in the image set. The game therefore loads the first image from the Space Junk image set and draws it where the planet should be.

The fix was very simple, once I understood what was going on. Instead of checking if the current object is the navigation crosshair, I just check to see if the object type is 3. If it is, I use the object's specified image set; if not, I use the Space Junk image set.

I would be very interested to know how this bug was introduced; it doesn't seem like the sort of thing that the KS developers should have been touching.