File Structure of a Demo
Before we begin to sketch the internal structure of our demo, let’s take a look on how to organise files in the final archive. You will also need to decide if you want to protect the data files (textures, the soundtrack and so on) or make them freely accessible to others. Let’s review some real life examples.
In case of a 64 kB and all other size intros, it’s easy: according to the rules, you have to include everything in one executable. No external data files, additional libraries and so on. For example, Offscreen Colonies by Conspiracy:
Even that there are other text files inside the official archive, they are not required to run it. It is self-contained.
In case of demos, the rules usually limits the total size of a package (although there may be no limits for it as well). It’s up to you to choose structure of the files and directories inside the archive. Let’s look at some possible approaches.
Single data file
Main executable accompanied by a resource file. For example, FR-043: Rove by Farbrausch:
All additional libraries are linked statically or are available in the system (like DirectX libraries). Clean and simple.
The one downfall (at least for some people) is that the container has a custom format, so you cannot easily get this nice soundtrack you wanted to listen to while programming your own demo :).
Single data file with additional DLL’s
To avoid DLL hell or to be sure that demo looks exactly as on your computer, sometimes it is a good idea to include specific versions of libraries next to the main executable. If you want to enter your demo into a competition, there are usually some rules like: you cannot create any kind of installer for your demo (and add files to the system directories), and you cannot ask the organisers to install any other libraries or packages to compo-machine. Actually, it’s a good practice to test your demo on a “clean” system, so your PC isn’t the only one that it works on. Check out We Stand Divided by Cocoon:
What’s nice about this Megademo.dat file, is that it’s actually a ZIP archive, so you can rename it and unpack all the data. Are you curious how the environment textures looks like? And how about this bokeh shader? It’s all there.
It’s worth noting that sometimes such curious people may stumble upon an unpleasant surprise. The data file is a valid archive, you can browse it, but you cannot extract anything; it’s password protected. In this case, you can hack the executable, brute-force the archive or… just ask the authors. Some of them revealed it themselves, like Bonzaj / Plastic did after finding out, that 16 MB (well, it’s really almost 20 MB, but you don’t get this nice 256 compression ratio then) demo 195/95 by Plastic have been done in just 64 kB and released as 195/95/256 by RGBA. It was a nice move to help them with some final tweaks. So, if you want to take a look at the original resources, just enter “zbVj[kmesw”.
Multiple files in directories
During the development of a demo, it’s handy to work directly on files, without any additional compression / decompression layer. For example, you can open texture files in an editor, and change them between test runs of the main executable. There is no rule that could stop you from releasing them in the same way. For example, Lifeforce by Andromeda Software Development:
There are total 246 files in Cgeffects, meshes, music and textures folders. Even if this doesn’t answer all your “How did he do that?!” questions, you can get some clues by looking at these data files.
I would like to notice one thing: even that you can extract (or just copy) textures, shaders or music from freeware demos, you still need the author’s permission to use them (unless the licence allows this – check the readme file for details). In most cases, you want to mess with other’s files only for educational purposes.
We will start with the last file layout, as it’s the easiest to implement. It’s also more convenient for moving or editing the files, especially when you want to change shader’s code. Later, we will switch to zipped data file for a more compact and elegant structure.
Comments are automatically closed on articles older than 512 days.