Sphinx and the Cursed Mummy Wiki
Sphinx and the Cursed Mummy Wiki

EngineX DataBase (*.edb) files are the binary, general-purpose workhorse container format used in Eurocom's EngineX titles. They are created by exporting an .ELF from the EuroLand editor. Every file has an unique hashcode that needs to be referenced in the Filelist descriptor for the game to find the path and load it.

Characters are usually self-contained into a single file, while levels are prefixed by area and are generally split into the main file, an IO_*.edb file for trigger objects and sometimes a CS_*.edb for cutscenes. In the original Eurocom release all these assets were bundled into uncompressed Filelist archives.


A non-exhaustive list of things you can find inside:

  • BSP maps
    • Submaps
      • Trigger instances
        • Gamescript events
      • AI navigation paths
  • Entities (3D models, often with several LOD meshes)
  • Entity trees (when the model is a composite or too big/complicated)
    • 3D geometry (in nested entities)
  • Textures (Generally S3TC-compressed)
    • Texture regions (mainly for button prompts stored into a single UV atlas)
    • Material properties (like sound or texture flags)
  • Animations (skinned animations with morph targets and complex blending rules)
    • Animation skins
    • Animation datums
    • Animation modes
    • Animation sets
  • Scripts (event-driven timelines that contain animations/particle effects/actors/camera movements, like cutscenes)
    • HUD and GUI elements (internally called HudScripts, the title screen and pause menus are built using script events, while the memory card and the inventory screens, as well as the in-game HUD are hardcoded in behavior to use certain entity/mesh elements by hashcode)
  • Particle effects (it supports textured billboard rectangles or custom 3D meshes)
  • Swooshes (camera-facing speed trail effects used for demonic red eyes or sword hits)
  • Spreadsheets (loaded from a referenced Excel spreadsheet on export)
    • Text spreadsheets (different sections per language)
      • Localized text strings
    • Data spreadsheets (where the data structure is fixed but the data itself is configurable)
      • Level data descriptors
      • Inventory items
        • Ability Items
        • Quest Items
        • Weapon Items
      • Shop prices
      • Context actions
      • Monster tweaks (stats and monster abilities)
      • Surface types
      • ...
  • Bitmap fonts (Internally bound to a texture; this look-up table stores Unicode codepoints and its UV rects and glyph metrics)

Debug output files[]

Euroland is full of surprises, and it has a hidden debug mode that dumps a text version of the exported target file and their fields, and can be used to interpret the different sections and blocks visually[1].

  • The secret menu that appears when you hold the Shift key while pressing Output.

    You get secret menus by pressing different key combinations. In this case Shift while exporting an .EDB file.
  • Example output of some exported _ab_sewr.dbg file for a PC _ab_sewr.edb.

    Pressing Ctrl while using the Output function dumps the target .EDB into a readable text version with a .DBG extension. I have been searching for this functionality for a while, it was there all along.[2]

This was originally added to debug the exporter itself, but it can be used to analyze the very complex binary format in a more straightforward way. Here is a rough overview of what the different keys mean, they seem to mirror the MSVC assembler directives for the most part (e.g. see here):

(Writing Raw Data)

DB -> BYTE (note: these are raw data because the value is written directly from the exporter)
DW -> WORD: one or more
DD -> DWORD: one or more
DF -> write floats, one or more in the same line, a float is a number with decimals stored in a special way and takes 32 bits / 4 bytes
DS -> deferred string (note: strings have variable size)
DS.nn -> deferred string (with nn being the length)

(Writing deferred data)

DB -> deferred BYTE (note: these are deferred (i.e. delayed) because the final value is computed right after writing from some instructed computation)
DW -> deferred WORD
DD -> deferred DWORD (appears formatted with >> (shifts), hex or decimal values or + XX hex or decimal data)
DD -> deferred float (appears formatted with +X.Xxx, probably should be DF)

ALIGN.W -> WORD padding, 2 bytes of 16 bits (note: block alignment, pads to the next WORD)
ALIGN.DW -> DWORD alignment, 4 bytes or 32 bits
ALIGN.QUADWORD -> QWORD; 8 bytes or 64 bits
ALIGN.BYTES nn -> pad to nn BYTEs
ALIGN.CDSECTOR -> pad to a CD sector (0x800 / 2048 bytes by default)

(Sub blocks within the main file)

INSERT.BLK -> (Sub) Block within the main file

(Text File Comments)

////////////////////////////////////////////////////////////////////// -> separator
xxxxxxxxxxxxxxxxxxxxxxxxxxxxx -> other custom separators with user-specified characters
// Comment Blah Blah Bleh -> formatted comment line

(Offset Management)

OFFSET.B -> BYTE offset (note: these are relative offsets, i believe. all offsets have a tag and are only resolved at the end once the number and size of sections is available)
OFFSET.W -> WORD offset

OFFSET.AB -> absolute BYTE offset
OFFSET.AW -> absolute WORD offset
OFFSET.ADW -> absolute DWORD offset (with * for unit multipliers, << shifts, | data and + for added values)

TF -> Target file (for errors)