Reconstructing Ecstatica’s Level Geometry

Alone in the Dark 3

Alone in the Dark 3

Ecstatica 1 takes place in a small village upon a rock, surrounded by a deep valley. The walkable area is restricted to this very rock, but still it is quite big and it is open. Not just a bunch of rooms but an exterior area. If you take a closer look at Ecstatica’s backgrounds, you will be puzzled by the really high-quality of the level geometry. Yes, there is real geometry behind the backgrounds. It even looks like not only the characters are all made of Ellipses but the walls, the floor and the plants as well. Those stone floors and walls look just like something you would use displacement mapping or metaballs for today. The Compare that to titles like „Alone in the Dark“ (see screenshot below) which were using painted environments. Alone in the Dark is quite a visually appealing title. But having actual geometry to render the backgrounds from is something different. Remember: When Ecstatica was shipped it was 1994!  How the hell did those Britons do this? This was not a multi-million dollar production. On what hardware were they able to create and render this vast amount of geometric data?

Screenshot demonstrating the high qualify of Ecstaticas level geometry

Screenshot demonstrating the high qualify of Ecstatica's level geometry

I recently worked on some code doing a reconstruction of the level geometry based on the set of about 240 background images. I managed to mix this reconstructed geometry with the collision- and navigation mesh. The current state already looks interesting. I propably won’t be able to explicitely reconstruct the complete geometry…

  • the available camera views are too sparsly distributed
  • the texture infomation I reconstruct is quickly diminishing in quality as you get farer away from the camera due to the projection effect
  • It would require a LOT of post-processing in order to merge and clean up the generated mesh data
  • It’s actually too much geometry. Given my 8 Gigs of RAM I’m unable to represent all 340 backgrounds in one blender session – even though I threw away around 99,5% of all generated polygons (using the „Decimate“ modifier).

How did they do it in 1994? My current assumptions are

  • They chopped the game world into chunks swallowable for 1994 hardware
  • For individual chunks they used some CAD software to create coarse geometry (walls, floors, stairs, etc.)
  • The used a custom raytracer to shoot rays through the world, querying the relevant geometry chunk and then, as a final step, they generated the ellipses on-the-fly using some form of texture mapping. I base this assumption on the fact that the stone walls show certain patterns. The basic principle of this last step actually is rather simple. Instead of calculating the ray intersection with a plane from the coarse geometry you put a set of ellipses there, each only described by its center and its radii. Because you’re systematically scanlining over the sensor area of your virtual camera, you should be able to keep only those ellipses in memory which are actually hit by rays.
Current state of my attempt to reconstruct Ecstatica's level geometry

Current state of my attempt to reconstruct Ecstatica's level geometry

Update on Reasearch on Ecstatica

Things move slowly forward. This weekend I have continued to implement some Python routines to

  • load an Ecstatica FANT file
  • write an Ecstatica FANT file
  • write a XML representation of the FANT file
  • read a XML representation of the FANT file

Those 4 building blocks are in an early stage right now. At the moment I have verified that I can load a FANT file and write it back without introducing any relevant differences. I’m still having some precision issues with converting the fixed-point numbers to floats and back.

Using these tools I will be able to modify the game data files and see, what happens. I’m thinking about giving the main character green hair or something like that 😀

Conflicting target names cause ’nmake test‘ to do nothing

Today I ran into a problem with using Microsoft’s nmake to build a project whose Makefile had been created by CMake. The build process ran fine but when I tried to run the test by calling „nmake test“, nmake just prompted

'test' is up-to-date

(in German: ‚test‘ ist aktuell). I was baffled, because under Linux it worked like a clockwork.

Thanks to Google, I found some IRC chat log where someone had had exactly the same problem and it was actually quite simple: My tests were located in a subdirectory called ‚test‘ and this name interfered with the make target ‚test‘ for running the tests. When Nmake was told to make target ‚test‘, it found the directory ‚test‘ existing already and thus prompted „‚test‘ is up-to-date“.

I changed the directory name to ‚tests‘. After that, calling ’nmake test‘ correctly executed my tests!

boost python and debug python binary

Today I had to deal with a rather naughty problem. At work, I have a C++ shared library which is made avaible for python using boost::python. In order to track down a segmentation fault in my C++ library , I created a python binary including debug data using
./configure --with-python-debuggingWhen I used the respective python binary, it crashed with a segmentation fault during import of the shared library. With the help of gdb I found out, that a data structure used at a specific point seemed to be screwed up or uninitialized. The memory access using a pointer from that struct caused the segmentation fault. Using a non-debug binary of python, I verified, that it was the debug version of python only, for which the error occured. After some thinking, I came to the conclusion, that the boost shared library might not be binary compatible to the debug version of the python shared library.

And later I found this link

which explains, why there’s a binary incompatibility. Damn, boost python docs reveal the important details in the smallprints! Sometimes I sincerely have the impression that they try to make it hard to use the library from the official documentation alone.

Btw. here they explain, how to debug your module without using a python debug-enabled binary.

Remaking Ecstatica

This morning, while I woke up, I glanced at one of the CD-ROMS in my shelf. It was ECSTATICA, published some year in the 90s in the neon edition. There’s a nice article about the game and it’s successor on the brilliant hardcore gaming site.

3 year ago I spent some months working on a Little Big Adventure 1 Remake, using yazor’s C code, which he afaik derived directly from disassembling the LBA binary. Btw. there is still the great Little Big Adventure Community Magicball Network, I was active at back then. Well, this morning I felt the urge to make another try to create an open-source remake of a game. For example, there’s an open source remake of Alone in the Dark by yazor (yah, it’s the genius again :)) you can use to play the games if you provide the original game data. I want to do exactly the same for ECSTATICA.

So this is the first article in a hopefully long series of articles covering my attempt to recreate ECSTATICA.