I don’t know if I am violating someone’s copyright, but I asked my AI (OpenAI Codex) to help recreate the World Toolkit libraries so I could re-compile my old apps, like SpaceRocks. And it worked. And it only took like 15 minutes!
Nearly thirty years ago, I developed several real-time 3D applications using Sense8’s WorldToolKit. (I have written about it previously here.) The software ran on the desktop PCs and specialized VR hardware of the era. Like many projects from that period, the source code and original assets survived long after the operating systems, development tools, and commercial libraries needed to run them had disappeared.
Recently, I decided to see whether these applications could be brought back to life.
The project began with a game called Space Rocks. It eventually grew into something more ambitious: a modern compatibility layer for WorldToolKit applications and the restoration of another substantial project—a virtual Mars rover.
Space Rocks
Space Rocks is an asteroid-style game that I originally wrote around 1996–1997. It combines real-time 3D graphics, textured models, animation, sound, collision detection, mouse control, and several scripted sequences.
The source code was still available, along with its original models, textures, sound effects, and configuration files. What was missing was the environment in which it had been built.
The original application depended on Sense8 WorldToolKit, a commercial 3D and virtual-reality development system. It also assumed the graphics conventions, input devices, file formats, and compilers of a 1990s PC. Simply recompiling the old C source on a modern computer was not an option.
I have tried to bring it back to life in the past:
This time, the objective was not to rewrite Space Rocks, but to preserve as much of the original application as possible.
Along with ChatGPT Codex (GPT 5.6 Sol light), we created a modern macOS build around the existing source and gradually worked through the incompatibilities. The application could eventually open a window and draw its world, but getting from “it runs” to “it behaves correctly” involved a long series of smaller discoveries.
Some of the problems were immediately visible:
- Textured objects worked from outside but disappeared when viewed from inside.
- The opening Space Rocks logo did not render.
- Explosion frames were missing.
- The ending sequence failed.
- Mouse movement did not align correctly with the screen.
- Vertical mouse control was reversed.
- The game began with an unintended explosion instead of placing the player inside the ship.
- The Sense8 logo was mirrored.
- Sound initially did not play.
Each problem exposed another assumption made by the original runtime. Polygon winding, back-face culling, texture orientation, coordinate conventions, animation timing, relative file paths, audio initialization, and camera transforms all needed to be reconstructed.
Eventually, the opening sequence, internal ship view, gameplay, sound, explosions, textures, and ending sequence were operating again.
The result is not a visual imitation of Space Rocks. It is the original C application, running through a newly implemented compatibility layer.
Building WTK-NG
Restoring Space Rocks required recreating enough of WorldToolKit for the original program to run. That work became a separate open-source project called WTK-NG.
WTK-NG is a compatibility runtime for legacy applications written against the WorldToolKit API. It does not attempt to reproduce every feature of the original commercial product. Instead, it implements the parts needed by the surviving applications while preserving their original structure and behavior wherever practical.
The runtime currently provides support for areas including:
- Scene graphs and object hierarchies
- Viewpoints and camera transforms
- Geometry and model loading
- Legacy NFF and OpenFlight assets
- Textures and materials
- Lighting
- Animation sequences
- Collision detection
- Mouse and keyboard input
- Overlays and simple user-interface elements
- WAV audio playback
- Compatibility implementations for older WorldToolKit functions
SDL2 provides the modern window, input, and audio foundation, while OpenGL handles rendering. The compatibility API allows the original application code to continue calling familiar WorldToolKit functions.
One of the most interesting aspects of this work has been discovering how much behavior was implicit in the old runtime. A function’s name and arguments are only part of an API. Applications also depend on undocumented conventions: coordinate handedness, transformation order, default lighting, normal orientation, texture wrapping, back-face behavior, and the meaning of “forward.”
Recreating those conventions accurately is often more important than merely reproducing the function signatures.
We also separated the compatibility layer from Space Rocks itself. WTK-NG now has its own public Git repository, allowing it to support other surviving WorldToolKit projects.
https://github.com/tompayne36/rocks
https://github.com/tompayne36/wtk-ng
Packaging Space Rocks
Once the game was working locally, the next challenge was making it shareable.
A binary that runs on one development computer is not yet a distribution. The initial executable depended on Homebrew installations of SDL2 and libjpeg at absolute paths. It also expected all its legacy assets to be present in the current working directory.
We created a repeatable macOS packaging process that builds a conventional application bundle containing:
- The Space Rocks executable
- All required models, textures, sounds, and animation frames
- Private copies of SDL2 and libjpeg
- A launcher that establishes the expected asset directory
- Rewritten dynamic-library paths
- An application property list
- An ad-hoc code signature
Running:
make dist-macosnow produces a self-contained ZIP archive containing Space Rocks.app, ready to attach to a GitHub release.
The current package is an Intel x86_64 build. It runs on Intel Macs and can run on Apple silicon through Rosetta 2. A future improvement would be a universal build with native Apple silicon support.
Returning to the Mars Rover
With Space Rocks running, we turned to another WorldToolKit application: a virtual Mars rover.
The Rover project is more complex than Space Rocks. I have also written about it previously. It combines a detailed vehicle model with articulated wheels, terrain following, surface textures, camera control, lighting, and vehicle movement. Some versions of the original project also anticipated specialized VR equipment, including a Polhemus tracker.
For the initial restoration, we deliberately focused on the desktop experience. The goal was straightforward: run the application locally using a mouse and keyboard. Legacy tracking hardware could wait.
Once the missing source and assets were gathered, the Rover application compiled against WTK-NG and began rendering. As with Space Rocks, however, the first visible result revealed several deeper compatibility issues.
Initially:
- The rover appeared upside down.
- The terrain seemed to be rendered from below.
- The wheels did not rotate.
- Forward motion moved the rover backward.
- The left wheels rotated in the opposite direction from the right wheels.
- Parts of the rover floated above or passed through the terrain.
- The lighting was badly unbalanced.
- Wheel facets disappeared under some lighting conditions.
- The wheels changed brightness dramatically as they rotated.
The original executable provided an invaluable reference. Screenshots showed not only the intended model orientation, but also the visual relationship between the wheels, body, antenna, terrain, and light source.
Reconstructing Rover Movement
Correcting the Rover was not simply a matter of rotating the entire model.
The original program used a particular combination of coordinate axes, model orientation, and transformation order. WTK-NG initially interpreted some of these differently. We corrected the rover’s base orientation, reversed its movement direction, and accounted for the mirrored geometry of the left and right wheel assemblies.
The wheel problem was especially instructive. Wheels on opposite sides of a vehicle may need opposite local rotation signs even though they are all moving the rover in the same direction. Applying one rotation uniformly made half the wheels appear to run backward.
Terrain following required more than assigning the rover a height at its center. On an uneven surface, each wheel contacts the terrain at a different elevation. A vehicle can be correctly positioned at its center while its front wheels float and its rear wheels disappear underground.
The improved approach samples the terrain at multiple points around the rover. Those samples are then used to calculate both its elevation and its pitch and roll. This allows the vehicle body to follow the local slope instead of remaining rigidly horizontal.
It is still a simulation rather than a full suspension and tire-physics model, but it more closely reflects the behavior of the original program.
Solving the Pulsing Wheels
The most persistent visual problem involved the rover’s wheels.
As the wheels rotated, they repeatedly changed from dark brown to an almost glowing tan. At first this appeared to be a general brightness problem. Reducing the wheel material brightness helped at one angle but made the rover too dark at another.
The real issue was the interaction between rotating geometry, polygon normals, and the lighting model.
The original low-polygon wheels depended on visible facets to communicate their cylindrical form. Smooth or overly strong modern lighting erased those facets. At the same time, rotating the normals caused different faces to move rapidly into and out of direct illumination, producing the distracting pulse.
Several approaches were tested:
- Reducing overall brightness
- Rebalancing ambient and directional light
- Preserving flat shading
- Rotating normals with the wheel geometry
- Stabilizing the lighting calculation
- Separating wheel lighting from the rest of the rover
The final solution treats the wheels more like the original renderer did: their color remains stable as they rotate, while subtle polygon outlines preserve the faceted shape. This avoids the flashing without turning the wheels into featureless dark discs.
That work also led to useful additions in WTK-NG, including finer control over geometry lighting, brightness, normal handling, stable lighting, and outlines.
What Was Preserved
The goal of this work has not been to modernize the applications into entirely new games. The objective has been to preserve their original code, assets, appearance, and behavior while replacing the unavailable runtime beneath them.
That distinction matters.
A complete rewrite could produce smoother graphics and more contemporary controls, but it would no longer be the same software. By recreating the runtime interface, we can study and run the original programs—including their design decisions, limitations, and visual character.
The restored projects now consist of three related pieces:
- Space Rocks, the original asteroid game running again on modern macOS
- WTK-NG, the open compatibility runtime that makes the restoration possible
- Rover, a second and more demanding WorldToolKit application that continues to improve the runtime
Each application helps validate the others. Space Rocks exercises animation, sound, collision detection, scripted sequences, and first-person rendering. Rover exercises articulated models, terrain following, transformation hierarchies, flat-shaded geometry, and more complex lighting.
What Comes Next
There is still more to do.
The current macOS distributions use Intel binaries. Native Apple silicon and Windows builds would make the projects easier to share. Proper Developer ID signing and notarization would remove the additional Gatekeeper step on macOS. There are also opportunities to improve terrain contact, camera behavior, packaging, documentation, and compatibility with additional WorldToolKit applications.
A browser-based interpretation of Space Rocks has also been explored. That approach is useful for accessibility and sharing, but the native compatibility version remains the most historically faithful because it continues to execute the original application logic.
Most importantly, the projects are alive again.
What began as an attempt to run one old C program became an exercise in software preservation: recovering not only source code and assets, but also the undocumented behavior of an extinct development platform.
Thirty years later, Space Rocks is flying again, the rover is crossing Mars, and the foundation now exists to revive other WorldToolKit projects as well.
Credit for the rover app belongs to the late Dave Hinkle and others over the years.