Will Fowler
When building levels for game engines based on id Software's Quake engine, after you have finished your work in the level editor you must then compile the map. This process results in a BSP file, a binary data file containing all map geometry and definitions for the entities (interactive elements) in the map.
The main advantage to using the BSP format was that all visibility information was built into the file. This allowed only certain portions of the level geometry to be rendered depending on the player's position in the level. In the early days of 3D gaming on computers, video cards were virtually unheard of, and most rendering was done directly on the CPU through software (SLOW!). The process of traversing a list of volumes in the map could be completed very fast, even when it was done 60 times per second, by using a binary tree structure. Depending on the volume in which the player was standing, it was possible to exclude certain geometry from being drawn, increasing framerates and allowing for a better gaming experience.
When the player is standing here, the next room isn't drawn.
When the player moves toward the doorway, the engine renders the next room in anticipation of the player being able to see it.
When the player is standing here, the next room isn't drawn.
One drawback of this approach, however, was that the original map file could not be recovered from the compiled version. While this provided greater security to level designers who did not want their work tampered with, it also meant you could not recover your lost work if all you had was the compiled version.
BSP decompilers have been created to address this, usually with a single specific game in mind. James Bond 007: Nightfire was a strange case, becuase it had been released with no map editor or compiler. Being built on Valve's GoldSrc engine, it used its own version of the BSP format, and no decompiler could touch it. However, the BSP format had been reverse engineered and documented, and a map editor and compiler had been leaked. Shortly after starting the JBN BSP Tools project, I began attempting to add a decompiler to it. Eventually, I forked the code so the two projects could go their own way, and the Decompiler project was born.
Over time, I have added more features and options, including producing output files compatible with many different level editors. The primary goal was to allow porting of maps from one engine to another with minimal effort. I have gone to great lengths to make this process as smooth and easy as possible. Results have been good; the entire Nightfire: Source project would not have been possible without it.
The list of games supported is extensive, and includes most games based on Source, id Tech 2, and id Tech 3 engines with varying degrees of support.
The same map as above, decompiled, open in Valve Hammer Editor.
A map from 007: Nightfire, open in Valve Hammer Editor. This may be compiled for use in any Source engine game!
Note that texture alignment is impossible to replicate with 100% accuracy from Quake III.
The same map as above, decompiled, open in Valve Hammer Editor.
The application is written in C#, using WPF for the GUI. It features a multi-threaded queue system to allow decompiling of multiple maps at once, with others waiting to be decompiled in succession. If something goes wrong, the exception is caught and an error is displayed in the log window. The thread is then released and the next job in the queue can start.
The source code was initially available on Google Code and has since migrated to GitHub. The application also depends on the LibBSP library, a library I developed to read data from the many different BSP formats. As support for different BSP formats improves, LibBSP is updated. This increases compatibility with maps from these games, and improves support for more features as well.
