{"id":9204,"date":"2026-08-26T18:21:39","date_gmt":"2026-08-26T16:21:39","guid":{"rendered":"https:\/\/www.wegneronline.com\/blog\/?p=9204"},"modified":"2026-08-27T18:00:50","modified_gmt":"2026-08-27T16:00:50","slug":"3-d-ultra-interesting-digital-archaeology-in-3-d-ultra-pinball-creep-night","status":"publish","type":"post","link":"https:\/\/www.wegneronline.com\/blog\/2026\/08\/26\/3-d-ultra-interesting-digital-archaeology-in-3-d-ultra-pinball-creep-night\/","title":{"rendered":"3-D Ultra Interesting: Digital Archaeology in 3-D Ultra Pinball: Creep Night"},"content":{"rendered":"\n
Deutsche Version hier!<\/a> \/ Extractor tool<\/a> \/ Complete Infosite<\/a><\/pre>\n\n\n\n
Sometimes a technical investigation starts completely by accident – and end with a game engine torn apart, and discovering new cheats and eastereggs.<\/p>\n\n\n\n
In my case, all I wanted to do was play Sierra’s 1996 3-D Ultra Pinball: Creep Night<\/em> again on an emulated Windows 98 PC. It was one of those games I played so much as a child that, decades later, quite a surprising amount of it still seems to live in muscle memory.<\/p>\n\n\n\n
While playing it again, however, I noticed something I had obviously never thought about as a child: despite its name, 3-D Ultra Pinball<\/em> is not really a 3D game in the modern sense.<\/p>\n\n\n\n
\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
The three 3D-Fake-Tables „The Castle“…<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
…then „The Tower“ (well, it’s more a lab)…<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
…and then „The Dungeon“.<\/figcaption><\/figure>\n<\/figure>\n\n\n\n
<\/p>\n\n\n\n
The tables look three-dimensional. So do the characters, ball, ramps and animations. But there is no polygonal 3D world being rendered in real time. Instead, the game developed by Dynamix relies heavily on pre-rendered 2D graphics.<\/p>\n\n\n\n
That observation started a journey into the internals of its engine. \ud83d\ude0a<\/p>\n\n\n\n\n\n\n\n
\u201c3-D\u201d Without 3D<\/h2>\n\n\n\n
The basic idea is remarkably simple and clever from today’s perspective: The pinball tables appear to have been created using 3D tools and then rendered into finished images. In the game itself, each table has a complete 640 \u00d7 480 pixel background.<\/p>\n\n\n\n
Smaller sprites for moving objects such as the ball, characters, bumpers and animations are drawn on top of that background.<\/p>\n\n\n\n
In simplified form, the rendering process therefore looks something like this:<\/p>\n\n\n\n
Pre-rendered 640\u00d7480 background\n                +\n          animated sprites\n                +\n              ball\n                +\n       flippers \/ targets \/ effects\n                =\n          final game image\n<\/code><\/pre>\n\n\n\n
The \u201c3-D\u201d therefore primarily describes the visual production of the assets. At runtime, the game itself operates largely with 2D graphics.<\/p>\n\n\n\n
For a Windows PC in 1996 this was a very sensible solution. The expensive 3D work could be done in advance, while the player’s computer only had to draw prepared pixel graphics.<\/p>\n\n\n\n
Looking Inside RESOURCE.001<\/h2>\n\n\n\n
The game’s CD contains, among other files, the following pair:<\/p>\n\n\n\n
RESOURCE.MAP\nRESOURCE.001<\/code><\/pre>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
RESOURCE.MAP<\/code> acts as an index, while RESOURCE.001<\/code> contains the actual data.<\/p>\n\n\n\n
In my copy of the game, the archive contains 854 individual resources:<\/p>\n\n\n\n
430 \u00d7 WAV\n275 \u00d7 BMP\n109 \u00d7 ANM\n 19 \u00d7 ITF\n  7 \u00d7 PAL\n  4 \u00d7 TBL\n  4 \u00d7 TBM\n  4 \u00d7 RES\n  2 \u00d7 PFT\n<\/code><\/pre>\n\n\n\n
The file extensions are somewhat misleading. A resource named GHOST0.BMP<\/code>, for example, is not a standard Windows BMP file. Instead, its contents start with a proprietary Dynamix header BMP:<\/code>. Similar internal formats exist for animations (ANM:<\/code>) and other resources.<\/p>\n\n\n\n
The resources themselves are stored sequentially inside RESOURCE.001<\/code>. RESOURCE.MAP<\/code> contains a hash and offset for each entry. At that offset in the data file, a DOS-compatible filename is followed by the resource size and finally its data.<\/p>\n\n\n\n
What Does the \u201cLarge\u201d Installation Actually Do?<\/h2>\n\n\n\n
This also answered a small question raised by the original installer.<\/p>\n\n\n\n
Creep Night<\/em> offers a \u201cLarge\u201d installation option. When selected, the file ENGLISH\\LARGE\\OVERRIDE.DAT<\/code> is copied to the hard drive. The installer explains that afterwards essentially only audio will still be streamed from the CD.<\/p>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
OVERRIDE.DAT<\/code> contains both an index and resource data, effectively making it a self-contained local version of the RESOURCE.MAP<\/code>\/RESOURCE.001<\/code> system.<\/p>\n\n\n\n
While RESOURCE.001<\/code> contains 854 resources, OVERRIDE.DAT<\/code> contains 817. The 37 missing files are:<\/p>\n\n\n\n
SX_4000.WAV\n...\nSX_4036.WAV<\/code><\/pre>\n\n\n\n
and all of them are indeed long audio files. Together, they account for roughly 34 minutes of audio and around 90 MB of data.<\/p>\n\n\n\n
This gives a surprisingly precise explanation of what a \u201cLarge Installation\u201d meant in 1996: almost all graphics, animations and short sound effects were copied to the faster hard drive, while the large audio tracks remained on the CD to save disk space.<\/p>\n\n\n\n
GHOST0.BMP: Four Ghosts in Two Kilobytes<\/h2>\n\n\n\n
One particularly interesting resource is GHOST0.BMP<\/code>. It is only around 2 KB in size, yet it contains not one but four separate sprite frames:<\/p>\n\n\n\n
Frame 1: 56 \u00d7 38 pixels\nFrame 2: 56 \u00d7 64 pixels\nFrame 3: 64 \u00d7 62 pixels\nFrame 4: 64 \u00d7 51 pixels<\/code><\/pre>\n\n\n\n
Each frame has a small header containing its width, height, an encoding byte, compressed size and uncompressed size.<\/p>\n\n\n\n
The first frame, for example, begins effectively as follows:<\/p>\n\n\n\n
38 00          Width:  56\n26 00          Height: 38\n83             Encoding: 0x83\n61 01 00 00    Compressed block: 353 bytes\n50 08 00 00    Uncompressed: 2128 bytes<\/code><\/pre>\n\n\n\n
And this reveals something important:<\/p>\n\n\n\n
56 \u00d7 38 = 2128\n<\/code><\/pre>\n\n\n\n
After decompression, there is exactly one byte for every pixel. The graphics are classic 8-bit paletted images.<\/p>\n\n\n\n
What Does 0x83 Mean?<\/h2>\n\n\n\n
This encoding value initially became the central mystery. For this encoding, there is no documentation. Only a few fragments of other people on the internet that tried to reverse engineer the proprietary Dynamix compression. However, by examining the original PINBALL2.EXE<\/code>, it was possible to locate the relevant code path.<\/p>\n\n\n\n
The original program reads the encoding byte and effectively performs:<\/p>\n\n\n\n
encoding = encoding & 0x7F<\/code><\/pre>\n\n\n\n
So 0x83<\/code> becomes 0x03<\/code>. Execution then branches to the decoder for compression type 3. That decoder could be reconstructed from the original x86 code.<\/p>\n\n\n\n
The Dynamix Type-3 Codec<\/h2>\n\n\n\n
The algorithm is a compact form of LZ-style compression. The stream first contains the number of following tokens. A block of flag bits follows, followed by the actual token data.<\/p>\n\n\n\n
Each token can represent one of two things:<\/p>\n\n\n\n
Flag = 0\n\u2192 the next byte is a literal pixel value\n\nFlag = 1\n\u2192 copy pixels that have already been decompressed\n<\/code><\/pre>\n\n\n\n
A back-reference uses two bytes, or 16 bits.<\/p>\n\n\n\n
Conceptually, the value is divided like this:<\/p>\n\n\n\n
DDDDDDDD DDLLLLLL<\/code><\/pre>\n\n\n\n
The lower six bits encode the length:<\/p>\n\n\n\n
length = value + 3<\/code><\/pre>\n\n\n\n
The upper ten bits encode the distance:<\/p>\n\n\n\n
distance = value + 1<\/code><\/pre>\n\n\n\n
The stream can therefore express something conceptually similar to:<\/p>\n\n\n\n
\u201cGo back 56 pixels and copy\nthe following 42 pixels again.\u201d<\/code><\/pre>\n\n\n\n
This is extremely efficient for sprites containing large repeated or empty areas.<\/p>\n\n\n\n
The first ghost frame requires 2,128 bytes uncompressed, while its compressed stream needs only around 350 bytes.<\/p>\n\n\n\n
Using this compression, all animations, overlays, buttons, etc. are stored in the RESOURCE.001<\/code> file, one after the other as a constant stream. If extracted correctly, you can get all the game’s sprites and graphics – and potentially make your own flip book out of it.<\/p>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
You could make a little flip book out of the exported sprites (more on exporting sprites below)…<\/figcaption><\/figure>\n\n\n\n
How Does Transparency Work?<\/h2>\n\n\n\n
This is particularly charming from a modern perspective, since the developers only had the tools to work with that existed back then. Modern graphics normally use alpha channels. A pixel can be 25, 50 or 80 percent transparent and is blended with whatever is behind it.<\/p>\n\n\n\n
The developers of Creep Night<\/em> had no such luxury.<\/p>\n\n\n\n
After decompression, each sprite consists entirely of 8-bit palette indices. The first frame of GHOST0.BMP<\/code> contains 2,128 pixels – 1,425 of which have the value 0.<\/p>\n\n\n\n
Conceptually, much of the sprite therefore looks like:<\/p>\n\n\n\n
0 0 0 0 0 0 0\n0 0 0 X X 0 0\n0 0 X X X X 0\n0 X X X X X X\n0 0 X X X X 0\n0 0 0 X X 0 0<\/code><\/pre>\n\n\n\n
All available evidence strongly suggests that palette index 0 is used as a color key:<\/p>\n\n\n\n
Pixel = 0\n\u2192 leave the existing background unchanged\n\nPixel != 0\n\u2192 draw the sprite pixel\n<\/code><\/pre>\n\n\n\n
This is not alpha transparency. A pixel is either fully visible or not drawn at all.<\/p>\n\n\n\n
The image data strongly supports this interpretation, although the exact blitting routine would still need to be traced instruction by instruction for absolute confirmation. (Feel free to do so!)<\/p>\n\n\n
\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Even the light inserts on the field (lit\/unlit) are superimposed onto the actual background.<\/figcaption><\/figure>\n<\/div>\n\n\n
GHOST0, GHOST1 and GHOST2<\/h2>\n\n\n\n
Three particularly interesting resources appear next to each other:<\/p>\n\n\n\n
GHOST0.BMP\nGHOST1.BMP\nGHOST2.BMP\n<\/code><\/pre>\n\n\n\n
They contain:<\/p>\n\n\n\n
GHOST0:  4 frames\nGHOST1:  9 frames\nGHOST2: 12 frames\n<\/code><\/pre>\n\n\n\n
Together, that is 25 individual images of the ghost animations.<\/p>\n\n\n\n
Once exported, they demonstrate very nicely what the term \u201c3-D Ultra\u201d really means: the characters clearly have the appearance of pre-rendered 3D models, while the game itself treats them as small 2D sprites using paletted colour and color-key transparency.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
That is not a shortcoming. It is a wonderful example of how cleverly developers in the mid-1990s worked within the limitations of contemporary hardware.<\/p>\n\n\n\n
By the way, that dude is the ghost circling the towers from „The Castle“ table. \ud83d\ude09 <\/p>\n\n\n
\n
\"\"
He also appears elsewhere, thus the unused animation frames in the sheet above.<\/figcaption><\/figure>\n<\/div>\n\n\n
The Strange \u201cWobble\u201d \u2014 Simulating Depth in 2D<\/h2>\n\n\n\n
This visual oddity was actually what started the entire investigation: At certain positions, especially on a modern display, something strange happens when the ball passes behind a foreground object. The edge of that object appears to change slightly – almost as if a small piece of the background had been placed over the existing background without matching it perfectly.<\/p>\n\n\n\n
Comparing two screenshots from consecutive game states makes the effect much easier to see:<\/p>\n\n\n\n
\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Screenshot 1<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Screenshot 2<\/figcaption><\/figure>\n<\/figure>\n\n\n\n
<\/p>\n\n\n\n
Screenshot 1:<\/strong> The ball is elsewhere. All good.<\/p>\n\n\n\n
Screenshot 2:<\/strong> The ball is behind the foreground object. At the same time, a subtle seam or change in the object’s pixels becomes visible. In these screenshots most noticeable when switching between the two, or if seen in motion in the game.<\/p>\n\n\n\n
The interesting part is that the pixels changing between the screenshots cover a much larger area than the ball itself. The affected region resembles a rectangular section of the foreground object.<\/p>\n\n\n\n
This suggests another very effective 2D technique: an occlusion sprite or foreground layer.<\/p>\n\n\n\n
The engine could render the table and ball first, then redraw a prepared section of the foreground whenever the ball is supposed to appear behind it:<\/p>\n\n\n\n
Table background\n      \u2193\nDraw ball\n      \u2193\nIs the ball behind an object?\n      \u2193\nDraw foreground \/ occlusion sprite\nover the ball\n<\/code><\/pre>\n\n\n\n
This provides convincing depth for pipes, ramps and other table components without requiring any real 3D geometry or a Z-buffer.<\/p>\n\n\n\n
The visible \u201cwobble\u201d may therefore come from the overlay itself. A slightly different dithering pattern, palette representation or even a one-pixel alignment difference between the overlay and the original background would be enough to create the subtle seam visible on a modern LCD.<\/p>\n\n\n\n
Same is true if we look at our ghost GIF from above: Pay attention to the stone structure of the tower. As soon as the ghost sprite enters the screen, the pixels of the background shift slightly. It seems that the logic for palette index 0 (i.e. draw the background again here) is not perfect:<\/p>\n\n\n
\n
\"\"
The effect is mostly visible when the GIF starts to loop again and the background „resets“.<\/figcaption><\/figure>\n<\/div>\n\n\n
On a typical 1990s CRT, analog video, the shadow mask or aperture grille and the general characteristics of the display would blur these differences much more naturally.<\/p>\n\n\n\n
A modern display, meanwhile, reproduces every emulated 640\u00d7480 pixel with brutal precision.<\/p>\n\n\n\n
Lost and Found: Resource File<\/h2>\n\n\n\n
I just love going through such internal files. The developers never anticipated anyone else looking at them, so you sometimes find exciting stuff that was never taken out or meant as eastereggs. (Greetings to The Cutting Room Floor!<\/a>)<\/p>\n\n\n\n
Here are some exciting things to see:<\/p>\n\n\n\n
\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
The Sierra mascot including all of its animation frames are in there, as seen in the intro sequence<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
If needed, just fake your own highscores on this \ud83d\ude09<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Saddest dialog of them all \ud83d\ude41 Note how the buttons are separate spites!<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Proof that Dynamix was the developer – their logo is in the files as well (and also shown in the intro)<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Most important sprite of them all \ud83d\ude42<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Settings are also sprites, with the candles (on\/off switches) as separate sprites<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Somewhere in the game there must be a cow easteregg, replacing the goblins with cows. Hm!<\/figcaption><\/figure>\n<\/figure>\n\n\n\n
<\/p>\n\n\n\n
I really need to investigate more about the cow easteregg. Cows are a strange, but well-loved easteregg tradition in physical pinball machines<\/a>, so it would be a nice callback by the game. I’d also say that the designers were absolutely aware of physical pinball, because in the Help documents, there is a dedicated chapter with recommended reading about the history and principles of physical pinball, with works e.g. by Roger Sharpe<\/a> – a very nice tip of the hat to pinball machines!<\/p>\n\n\n\n
Well…. let’s do this right now! \ud83d\ude0a <\/p>\n\n\n\n
New Cheats and Easter Eggs<\/h2>\n\n\n\n
These are as of today completely undocumented cheats and easter eggs. I am a little proud, to be honest.<\/p>\n\n\n\n
If you open up the highscore table, you can enter „data“. Just type it into the void with your keyboard. You will hear a voice saying „Excellent!“. That means, cheat or debug mode is now enabled (the variable DYNAMIX<\/code> is set to 1<\/code>).<\/p>\n\n\n\n
Now for the fun part:<\/p>\n\n\n\n
If you enter „cows“ during the game, you will hear a moo sound. This confirms that the flag cow_mode<\/code> is now set to true. If you start the Shooting Gallery bonus game, all sprites are replaced with cows – some trotting, some running and even one cow riding an ATV. To start the bonus game, you will have to complete all modes in „The Castle“ and then shoot the portal.<\/p>\n\n\n\n
Another useful developer code to help you with this is „fin“. If you enter this one during the game, all modes are marked as done and you can move on to the final boss phase of each table. It’s most likely a shortcut for developers during testing (I guess?). This code only works, if „All Tables“ is selected as game mode. If you start a game with only one table, nothing happens.<\/p>\n\n\n\n
Also, there is another state called mcow<\/code> with corresponding animation:<\/p>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n\n\n\n
Unfortunately, I could not yet find out how to trigger this easter egg. From the code it’s clear that the cow would replace the goblins in their mode on all three tables. Instead of hunting down goblins on their seven random positions with the silver ball, one would shoot for a cow that circles on the playfield instead. It seems that the needed trigger was, however, never included in the game. Bummer.<\/p>\n\n\n\n
However, I wrote a little patch tool that basically applies the flag cow_mode<\/code> also to this easter egg. You can download it here, patch your PINBALL2.EXE<\/code> with it and try for yourself (type „DATA“ in Highscores screen, then type „COWS“ in active game). See the README.MD<\/code> in the ZIP file for more info.<\/p>\n\n\n\n
\n
Download MCOW Patch Tool (6KB, ZIP)<\/a><\/div>\n<\/div>\n\n\n\n
And that is how it looks like<\/a> – pretty cool in my opinion! \ud83d\ude0a <\/p>\n\n\n\n
There is another little undocumented extra: The boss key „U“. If this key is pressed during gameplay, the game window is minimized and the title of the window changed to „New Text Document“ (and thus displayed as such in the task bar). <\/p>\n\n\n
\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n<\/div>\n\n\n
Boss keys like these were quite popular in the 90s, when games would often be played on workplace computers.<\/p>\n\n\n\n
<\/p>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
Creep Night Resource Tool<\/h2>\n\n\n\n
This investigation resulted in a small Python utility capable of reading the resource archives and decoding the proprietary Dynamix bitmap resources.<\/p>\n\n\n\n
Among other things, it can:<\/p>\n\n\n\n