
Prehistorik 2 has made an unexpected return. The 1993 DOS platform game now runs as a native Python application, without launching the original executable and without placing a DOS emulator between the game and your computer. It still looks, sounds and behaves like Prehistorik 2, but underneath, almost everything has changed. This isn’t a modern remake with redesigned levels, altered controls or new gameplay systems. The developers have rebuilt the original game’s behaviour in Python, using the old data files for graphics, sound and levels. The result is a version that runs directly on modern operating systems.
A DOS game rebuilt in Python
At first glance, the idea sounds simple. Take an old DOS game, rewrite the code and make it work on Windows, Linux and macOS. It isn’t simple. Prehistorik 2 was written for hardware and software conventions that disappeared decades ago. The original game expects DOS services, BIOS functions, fixed memory layouts and behaviour tied closely to early PC processors. You can’t just open the source code and translate it. There is no original source code available here.
Instead, the team worked from the compiled game itself. They studied how the programme behaved, identified individual routines and recreated them in Python. The native version uses Pygame for graphics, sound and input, with NumPy handling some of the lower-level data work.
Players still need the original game files. They don’t need PRE2.EXE while playing, though, because the new version doesn’t run the DOS programme in the background. That distinction matters. This is a native port, not a launcher wrapped around an emulator.
The whole game runs in the new engine
The port covers far more than a few playable levels. It includes the introduction, menus, world map, level transitions, scoring screens, game-over sequence and endings. The Python code also handles movement, collisions, enemy behaviour, attacks, moving platforms, checkpoints and level progression. That’s the difficult part of any source port. A game can look correct and still feel wrong.
A jump may last a fraction too long. An enemy might turn one frame too early. Collision detection can become slightly more forgiving, or slightly harsher. Those tiny changes add up quickly, especially in a platform game built around precise timing. The developers tackled that problem with a reverse-engineering framework called DOS_RE.
How the original game checks the new code
DOS_RE acts as a controlled test environment for the old game. It models the sort of system Prehistorik 2 expected, including an 8086-style processor environment, DOS calls, BIOS behaviour, memory and period hardware. That allows the developers to run parts of the original code, inspect what happens and compare the results with their Python replacements. Think of it as a referee.
When a routine is rewritten, the framework can compare registers, memory values, graphics output and other internal state against the original game. If the Python version produces a different result, the mismatch becomes visible. This approach helps catch problems that ordinary playtesting might miss.
The emulator is only used during development and testing. It doesn’t ship as the game engine. The released port doesn’t execute x86 instructions, load the old programme file or secretly switch back to emulation when something gets difficult. Everything players interact with runs through the native Python code.
Smoother output without changing the gameplay
The port also adds a few modern display options. The original game logic still runs at roughly 23 updates per second. That keeps movement, enemy timing and collisions close to the DOS release. The display can refresh more often, however, using frame interpolation to make motion appear smoother. So the game feels the same, but scrolling looks less jerky.
There’s also a widescreen mode. It doesn’t stretch the old 4:3 picture across a modern monitor. Instead, it shows more of the level by drawing extra map columns at the sides. That’s a better solution. Characters keep their proper proportions, and players gain a wider view without turning the image into a distorted mess.
Other options include borderless fullscreen, integer scaling, smoother transitions, adjustable frame limits and a performance display. Sound effects can use positional stereo, while the original music remains unchanged. Players can control these additions through an enhancement menu opened with F10. Crucially, the visual features sit outside the core game state. They change how the game is presented, not how it plays.
Not every unknown has been guessed
The port is playable from the opening screens through to the ending, but the developers haven’t pretended that every rare behaviour is fully understood. In a few unusual situations, the programme may stop rather than continue with an invented approximation. That may sound strict, but it makes sense.
A visible gap is easier to fix than a guessed routine that appears correct while quietly changing the game. It also says something about the project’s priorities. Accuracy comes first.
A useful test case for other DOS games
The bigger story isn’t only that Prehistorik 2 now runs in Python. DOS_RE could offer a repeatable way to rebuild other DOS games. Instead of manually translating thousands of assembly instructions and hoping for the best, developers can replace routines gradually, test them against the original and keep checking the results as the native version grows.
That won’t make reverse engineering easy. Nothing will. But it could make the work more organised, measurable and practical. Prehistorik 2 is a strong demonstration of that idea. It runs natively, supports modern displays and keeps the original timing at the centre of the experience. No emulator is required during play. Just the old game data, a new Python engine and a lot of careful technical work.














