Version Lineage And Preservation Targets

Issue 31 Edition 2026-01-31 8 min read

General

Sources: 1 • Confidence: High • Updated: 2026-02-12 18:44

Key takeaways

Crimsonland’s release lineage includes a 2002 freeware prototype series, a 2003 shareware v1.8–v1.9 line, and a GOG “classic” build v1.9.93 (Feb 2011) that was later bundled as a bonus alongside the 2014 remaster.
A Ghidra-driven workflow maintains a name_map.json to iteratively rename and type functions based on evidence such as strings, call patterns, and struct sizes, allowing improved types to propagate across decompilations.
Crimsonland assets are stored in custom PAQ archives with magic 'paq\0' and entries consisting of filename, size, and payload, using Windows-style backslash paths.
The rewrite’s acceptance criteria require exactly matching the behavior of the GOG classic v1.9.93 executable, including replicating bugs and pixel-level asset quirks, treating the binary as the specification.
The target binary is a DirectX 8.1 build produced with Visual Studio 2003 (VC++ 7.1 SP1) and relies on grim.dll (Grim2D) accessed via an 84-method vtable exposed through GRIM__GetInterface.

Crimsonland’s release lineage includes a 2002 freeware prototype series, a 2003 shareware v1.8–v1.9 line, and a GOG “classic” build v1.9.93 (Feb 2011) that was later bundled as a bonus alongside the 2014 remaster.
Multiple early freeware Crimsonland builds are preserved, including v1.0.2 (May 2002), v1.3.0 (July 2002, with extra music), and v1.4.0 (Sept 2002).
Crimsonland 2 was teased with features such as network multiplayer and a rewritten engine but was effectively canceled by 2010 as 10tons shifted focus to casual mobile titles.
The 2014 Crimsonland remaster was initiated via Steam Greenlight and released on Steam on June 11, 2014, with subsequent GOG and multi-platform releases.
The author prefers the 2003 mechanics over the 2014 remaster’s mechanics.

A Ghidra-driven workflow maintains a name_map.json to iteratively rename and type functions based on evidence such as strings, call patterns, and struct sizes, allowing improved types to propagate across decompilations.
Ghidra initially missed substantial functions, including initialization, and some entrypoints were recovered only after runtime capture and manual function creation.
Runtime debugging shifted from Wine to native Windows via Bootcamp using WinDbg/cdb plus Frida for breakpoints, memory inspection, and call tracing because Wine introduced many translation layers.
A persistent WinDbg server/client setup using cdb -server and -remote with external log tailing enabled sustained headless interactive debugging without the agent terminating the debugged process each turn.

Crimsonland assets are stored in custom PAQ archives with magic 'paq\0' and entries consisting of filename, size, and payload, using Windows-style backslash paths.
The game’s fonts are identified as Xirod Regular, Armor Piercing Regular, Pixel Arial 11, and Courier New Bold.
The JAZ texture format is a JPG wrapped with a custom run-length encoded alpha channel and then zlib-compressed, and at least one asset’s alpha stream is exactly one pixel short.

The rewrite’s acceptance criteria require exactly matching the behavior of the GOG classic v1.9.93 executable, including replicating bugs and pixel-level asset quirks, treating the binary as the specification.
Each reimplemented function must be justified by decompiled code or runtime evidence, and the new code must not depend on the original runtime beyond loading the original asset archives.

The target binary is a DirectX 8.1 build produced with Visual Studio 2003 (VC++ 7.1 SP1) and relies on grim.dll (Grim2D) accessed via an 84-method vtable exposed through GRIM__GetInterface.
Mapping grim.dll vtable offsets to semantic operations is used to interpret draw sequences and compare runtime calls against the rewrite.

An optional enhancement under consideration is a “night mode” that preserves gameplay while adding high-quality lighting with signed-distance-field raymarched soft shadows driven by muzzle flashes and emissive projectiles.

What concrete parity test methodology is used to prove behavior matches the reference binary across edge cases (beyond anecdotal playability)?
What is the intended distribution model and licensing posture for the rewrite and for use of original assets (beyond loading original archives)?
How is grim.dll behavior emulated or replaced in the rewrite, and what compatibility risks remain for rendering/input equivalence?
What platforms are targeted for the rewrite, and what performance constraints exist (especially if optional high-end lighting is pursued)?
What specific remaining bugs and content gaps are known, and what evidence confirms whether hidden/obfuscated features are fully discovered?

Binary as spec parity and asset quirk replication suggests a preservation focused engine rewrite that could enable reliable compatibility across versions and systems, if distribution and licensing are resolved.
Mapping an 84 method grim.dll vtable and using runtime capture implies an approach that could generalize to other legacy DirectX era titles requiring DLL interface emulation.
Optional night mode with advanced lighting indicates potential for a premium enhancement layer that preserves gameplay while offering modern visual features, contingent on performance targets and platform scope.

Documented parity test methodology with repeatable differential checks against the GOG classic v1.9.93 executable across edge cases, beyond anecdotal playability.
Clear distribution model and licensing posture for the rewrite and for original assets, including how PAQ archives are handled and what is required from users.
Demonstrated grim.dll emulation or replacement with validated rendering and input equivalence, plus stated target platforms and performance constraints for baseline and optional lighting.

Inability to define or pass rigorous parity tests against the reference binary, or persistent unexplained behavior gaps that block bug and pixel quirk replication.
Unresolved licensing or distribution constraints that prevent practical release or require removal of key functionality tied to original assets.
grim.dll compatibility risks remain unresolved, leading to material rendering or input differences that prevent meeting the stated acceptance criteria.