Skip to content

DM2 Technical Reference

Jump to bottom
Daniel Nylander edited this page Aug 1, 2026 · 12 revisions

Dungeon Master II: Skullkeep Technical Reference

Scope

DM2 follows skproject as its reference source. It has an independent runtime path from DM1/CSB and requires original PC GRAPHICS.DAT plus DUNGEON.DAT by verified hash.

Architecture Overview

DM2 is structured around these major subsystems:

Subsystem Source files Description
Boot/Init dm2_v1_boot.c Game initialization, data scan, profile creation
CCM (Core Command Machine) dm2_v1_ccm.c, dm2_v1_ccm_dispatch_pc34_compat.c, dm2_v1_ccm_loop_pc34_compat.c Main game loop and command dispatch
Combat dm2_v1_combat.c, dm2_v1_combat_damage_pc34_compat.c Damage calculation, attack resolution
Champion lifecycle dm2_v1_champion_lifecycle_pc34_compat.c, dm2_v1_champion_stat_bridge.c Champion creation, stats, death, resurrection
HUD dm2_v1_champion_hud_helpers.c, dm2_v1_champion_portrait_gdat.c Health bars, portraits, status indicators
Asset loading dm2_v1_asset_loader.c GDAT record loading and decoding
Actuator/Events dm2_v1_actuator_event_pc34_compat.c Switches, pressure plates, timers, triggers
Animation dm2_v1_anim_bootstrap.c Creature and effect animation bootstrap
Memory (CAII) dm2_v1_caii_alloc_pc34_compat.c DM2-specific memory allocation
Touch/Click zones dm2_touch_click_zone_matrix_pc34_compat.c Input region mapping for mouse and touch

skproject Alignment

The DM2 implementation tracks skproject function-for-function. Source comments reference skproject identifiers and file locations. The alignment approach:

  • Each skproject function is implemented with matching logic and control flow.
  • Variable names follow skproject conventions where they clarify intent.
  • DM2-specific data structures (GDAT records, map descriptors, creature tables) use the same field layouts as skproject.
  • Tests verify behavior against skproject-documented outputs.

Boot and GDAT

An incomplete profile remains at the launcher and does not clear the viewport or paint generated floor/ceiling art. The boot receipt records source identity, typed GDAT sections, title/menu, HUD, dungeon, and no-fallback readiness.

The GDAT pipeline exposes dtPalIRGB, dtPalette16, dt07 interface/title records, Rect14 placement, map GRAPHICSSET values, and map-chip assets. The viewport resolves raw GDAT addresses before decode. Missing mandatory material is a no-draw receipt, never a substitute. Wall cache keys include graphics style to prevent material leakage between maps.

GDAT Renderer Architecture

The GDAT (Graphics Data) system is DM2's asset container format, distinct from DM1's simpler GRAPHICS.DAT. Key concepts:

  • GDAT sections: typed blocks identified by section ID and record type.
  • Record types: dtPalIRGB (IRGB palette), dtPalette16 (16-color palette), dt07 (interface/title graphics), and map-chip records.
  • Rect14: 14-byte rectangle placement descriptors for UI elements.
  • GRAPHICSSET: per-map graphics style selector that determines which wall, floor, and ceiling textures to use.
  • Address resolution: the viewport resolves raw GDAT byte addresses into decoded bitmap data. No fallback or procedural generation occurs for missing records.

Creature Renderer

DM2 creatures are rendered from GDAT sprite records. The creature renderer:

  • Looks up creature type and animation frame in the GDAT record chain.
  • Applies directional facing relative to the party's view direction.
  • Scales sprites for distance (near/mid/far viewport columns).
  • Supports DM2-specific creature types not present in DM1 (e.g., outdoor creatures, flying creatures with altitude state).

G1 Map Runtime

DM2 supports both indoor dungeons and outdoor areas. The map runtime handles:

  • Indoor maps: traditional grid-based dungeon with walls, doors, pits, stairs, and teleporters. Similar to DM1 but with DM2-specific actuator types and GDAT-driven textures.
  • Outdoor maps: open-area maps with sky, ground plane, and weather effects. The viewport switches rendering mode based on the current map type.
  • Map transitions: moving between indoor and outdoor maps updates the active GRAPHICSSET, sky/ground state, and weather overlays.

Weather state (rain, mist, thunder) is driven by map properties and does not create procedural pixels without a verified original overlay asset.

Runtime

M10 owns party, door, item, creature, projectile, actuator, and dungeon state. The viewport consumes typed plans. Outdoor routes pass the active source sky, ground, and weather state; indoor routes are clear. Rain, mist, and thunder do not create procedural pixels without a verified original overlay asset.

Save Interop

DM2 saves use SKSAVE.DAT. The save system:

  • Serializes the full dungeon state including all map layers.
  • Preserves creature positions, item locations, and actuator states.
  • Stores outdoor weather and time-of-day state.
  • Maintains compatibility with the original DOS save format for round-trip testing against skproject tools.

Verification

ctest --test-dir build -R "dm2" -j4 --output-on-failure

Key test targets:

cmake --build build --target test_dm2_v1_boot_profile_smoke \
  test_dm2_v1_runtime_handoff_smoke test_dm2_v1_weather_no_synthetic_overlay \
  --parallel
./build/test_dm2_v1_boot_profile_smoke
./build/test_dm2_v1_runtime_handoff_smoke
./build/test_dm2_v1_weather_no_synthetic_overlay

For the GDAT record chain, interface tables, and host receipts, see DM2 GDAT Internals.

See Also

Clone this wiki locally