Skip to content

Conan the Cimmerian

Conan the Cimmerian standing on a battlefield, sword in one hand and a severed head in the other, under "the Cimmerian" title plate

A human-readable guide to the internal data formats of Conan the Cimmerian (1991, Virgin Games / Synergistic Software) — composited above from three of its own title-screen resources (TITLE.L32 #700’s sky, #701’s battlefield silhouette, #702’s Conan figure, and #718’s logotype plate; see Image Gallery for all of them decoded individually).

Conan uses a different engine from the three Melbourne House games this site also covers (War in Middle Earth, Spirit and Vengeance of Excalibur) — same Mac-style resource-fork container format, but its own image, animation and scene-object encodings, and by far the most hostile executable structure of the four: both Amiga executables carry only 632 bytes of static code, with the real game logic self-decompressing a custom backwards-reading LZ77 stream into memory at runtime. See Cracking a Hostile Executable for how that was worked out anyway (a 68k emulator harness, and a DOS port whose scrambled executable header turned out to be evidence of a copy-protection crack rather than an unsupported compressor).

  • IMAG — 6-byte-header interleaved-bitplane still images. Confirmed across every content category the game ships: loader/title screens, UI chrome, tavern/temple/street/dungeon backdrops, and object art. See Image Gallery.
  • FRML — animation-frame sprite sheets. All 101 resources decode; 23 of those are code-confirmed as single-clip scene decoration (torches, fire, drips), and the rest carry a render-derived, honestly-labelled confidence: 'hypothesis' guess at where a combat sprite’s action pose ends and its death pose begins — no code-level table for that split survived in either executable. See Animation Gallery.
  • .L32/.L16 loader assets — ordinary resource forks despite the extension, cross-checked pixel-for-pixel against the DOS port (58/60 comparable images identical). Included in the Image Gallery above.
  • SCEN — the scene/room object-placement format is fully traced (6,542 object entries, zero residue), though nothing yet turns that data into a rendered scene the way this site’s other games’ scene galleries do — see the executable-cracking page for why the trace itself was still worth telling as its own story.

Palette extraction, the executable’s self-decompressing loader, and the DOS port’s disguised copy-protection crack are all covered in Cracking a Hostile Executable — arguably the most interesting part of this game’s reverse-engineering, even though (or because) so much less of its actual game logic has been recovered compared to the other three games in this project.