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.

What’s still open is on the Status & Open Work page. The container and pixel formats Conan shares with the other four games are documented once, in Shared Formats.

These pages are a curated summary of the main repository’s raw research notes (not part of this site) — and where they disagree, the raw notes win:

  • docs/conan/plan.md — the status table and format-by-format summary.
  • docs/conan/amiga/engine.md — the full byte-level spec: resource fork layout, IMAG/FRML/.L32/SCEN formats, palette tables, and the executable-structure and decompression investigation.
  • docs/conan/TODO.md — the single status surface for open work.

Two platforms are extracted: amiga (this game’s reference platform — all loader and title art, and all 101 FRML sprite animations) and dosvga (the only platform whose pipeline config currently exports the large in-game scenery resources — temple, tavern, streets, dungeon, objects).