Ecstatica Engine: How Andrew Spencer Built 3D Ellipsoid Tech
The Ecstatica engine is a custom software renderer built by Andrew Spencer using mathematical ellipsoids instead of polygons, letting 1990s CPUs deliver smooth, organic 3D character animation without requiring dedicated 3D graphics hardware acceleration.

The Ecstatica engine is a custom software renderer built by Andrew Spencer using mathematical ellipsoids instead of polygons, letting 1990s CPUs deliver smooth, organic 3D character animation without requiring dedicated 3D graphics hardware acceleration.
Conceived on the Commodore Amiga before moving to MS-DOS for its 1994 release, developer Andrew Spencer spent five years writing the proprietary engine and its custom editing toolset from scratch. At a time when triangle meshes produced angular, rigid figures and consumer 3D accelerator cards did not yet exist, Spencer chose curved mathematical ellipsoids to create fluid movement for the monstrous cast of Tirich.
Ellipsoid Technology vs Polygon Rendering
During the early 1990s, realtime 3D gaming was limited by low processing power and the absence of dedicated GPUs. Spencer noticed that traditional animation studios, including Disney, used circular base geometry across animation cels because curved shapes remained easier to keep uniform between frames. He applied that logic to software rendering.
Instead of constructing characters out of textured triangular polygons, the core system assembled models entirely from curved spheres and ellipsoids. Gouraud shading was applied across these curved bodies to create smooth light gradation within a 256-color palette. Because rounded shapes require fewer individual primitives to convey anatomical volume than low-poly models, the renderer could produce organic outlines using minimal processing overhead.
Flat polygons were not eliminated entirely. The engine reserved untextured polygons for environments where ellipsoids could not form clean planes, such as wooden doorways, interior shelving, cliff edges, and human facial features like character noses. By shading those flat geometric faces with varied brightness levels, the renderer established clean perspective cues alongside the bulbous character models.
Depth Handling and Environmental Occlusion
To blend moving ellipsoid models into static backgrounds, Spencer implemented an active Z-buffer system. In traditional early adventure games, pre-rendered scenes often relied on crude sprite layering that made objects clip erratically or float over terrain.
The proprietary depth buffer calculated spatial distance for each rendered ellipsoid point, ensuring that dynamic entities properly interacted with background scenery. Clumps of grass reliably covered character feet, small dropped quest items sank into foliage, and defeated creatures rested accurately on uneven floor geometry.
Because background depth coordinates were strictly mapped in software, character geometry occasionally showed visual overlap errors when colliding tightly with complex scenery boundaries. However, it allowed the entire game to preserve persistent world state: corpses, dropped weapons, and triggered objects remained exactly where the player left them without resetting between room transitions.
Rendering Pipeline Across Engine Iterations
The technical structure evolved across multiple operating systems, transitioning from pure DOS CPU routines to modern high-resolution software scalers.
| Engine Version | Target Hardware | Rendering Method | Primary Performance Bottleneck |
|---|---|---|---|
| MS-DOS (1994) | Intel 386 / 486 CPU | 320x200 software rasterizer capped at 56 FPS | Integer math throughput and single-core CPU speed |
| Windows 95 (1997) | Pentium Windows PC | 640x400 SVGA direct draw software renderer | Unoptimized DirectDraw calls causing frame drops |
| SNEG Modern (2026) | 64-bit Windows 10/11 | Multithreaded CPU renderer supporting 4K | Screen fill rate at extreme widescreen resolutions |
The initial DOS release targeted a baseline 386 CPU with 4 MB of RAM, achieving its maximum engine cap of 56 frames per second on 100 MHz Pentium processors. Because the entire rasterization pipeline ran on the central processor, the game required no 3D graphics accelerator card. When Spencer adapted the engine for the 1997 Windows 95 release alongside early development of the sequel, the rendering resolution expanded to 640x400, adding simultaneous turning and walking movements to improve on the original rigid controls.
Animation Pipeline and Dynamic Behaviors
To populate Tirich with expressive monsters, Spencer teamed up with animator Alain Maindron, formerly of Amblin Entertainment and Walt Disney Studios. Spencer coded a dedicated 3D editor that allowed Maindron to sculpt curved characters and configure their skeletal behavior without needing direct programming knowledge.
Maindron created over 700 distinct animation sets. These routines drove complex physics-like visual reactions: the werewolf lunged with sweeping tackles, player models visibly limped and clutched damaged limbs instead of tracking hit points on a graphical interface, and heavy plate armor caused the protagonist to collapse onto the floor under excessive weight.
Custom scripting routines gave key adversaries dynamic spatial tracking. Rather than adhering to fixed path nodes, stalker entities actively pursued the player through connected courtyard environments. The engine supported over 200 scripted narrative vignettes and camera cuts, allowing monsters to spring sudden ambushes or flee defensively when taking consecutive hits in combat.
Legacy and Modern Re-Release Enhancements
The ellipsoid approach delivered striking visuals, but industry hardware soon standardized around polygonal pipeline acceleration. The Sony PlayStation and competing 32-bit hardware were architected around triangle rasterization, making Spencer's CPU-based mathematical sphere routines incompatible with console hardware without a total architectural rebuild.
The PC re-release published by SNEG preserves the original software rendering philosophy. The game continues to run entirely on the CPU without requiring a dedicated graphics card, scaling the underlying math to modern 16:9 displays and 4K resolutions. Players exploring the current release can switch in real time between three distinct graphics modes—Classic DOS at 320x200, Windows 95 at SVGA, and modern high-resolution Software rendering—while utilizing modernized options like controller support and toggles for DOS-era animation characteristics such as leg jitter.
Next step
Graphics Modes
Examine how each display option changes rendering resolution, camera framing, and retro visual toggles across modern hardware setups.
