Demos on the Win32 Platform

Written by brainpower

1. Win32 vs. MS-DOS
2. Microsoft Visual C/C++ vs. Watcom C/C++ (DOS)
3. 64K intros on the Win32 platform
4. Software to use in demos
5. Software reference
6. Last words

1. Win32 vs. MS-DOS

One of the reasons why the demoscene has historically sticked to MS-DOS since it was born on the PC was because of its speed and relatively low resource consumption, which was, for the machines of yesteryear, everything when a group wanted to make a demo. Another one was that until around 1997, Win32 just didn't offer more power and ease of development than the old DOS-based environment. This latter reason has lead to a chronic phobia of anything that resembles using the Win32 platform to code cycle-eating "multimedia presentations". After all, it took too much time, even after the development of Windows 95, to convince the gaming industry that Windows was the platform of the future.

But now nearly every game and non-business application which combines even the least elements of multimedia works in Windows 95/98/NT only, so why shouldn't demos move too?

2. Microsoft Visual C/C++ vs. Watcom C/C++ (DOS)

Speed issues

In early 1998, more than a year ago, the winning 64K intro of The Party 97 ("Stash" by TBL) was released on the Win32 platform. It required a special loader to work, but soon a stand-alone executable version was released. The very first sign of amazement when one ran the intro for the first time was the speed at which the pre-calculating bar blazed through the screen. It was actually much faster in Windows, and that's what set people off in the first place. One could watch the fluid graphics update as if a faster processor had been installed.

This is the most obvious example of the great optimising ability of Visual C++. People have bragged on about Watcom C/C++ being the best compiler for demos ever since PMODE/W appeared on the scene. It did, in fact, suit it very well. Many 64K intros were made with it and the number of 100%-assembly productions dropped considerably. Hardcore coders still did everything "by hand" but the truth is, it spawned a wave of more productions and more structured code. From 1992 until late 1996, almost every demo was coded in assembly, either old & limited real-mode or using the original 100%-assembly protected mode header PMODE by Tran.

Today's CPUs are all about floating-point math. The increase in speed from the 486DX to Pentium and Pentium II PCs has been astronomical - at least 40% from the 486DX/2 to the first Pentium. This has led to common arithmetic operations being performed much faster by the FPU than by the CPU. An old trick of the old days, shifting left/right to mimmic multiplication by a power of 2, is bound to become ineffective: now we want to force the compiler to do these operations with the floating-point unit, because they're a whole lot faster. That's right - demos done today may run at a slug's pace on a 2-year-old computer but that will be directly related to the FPU speed factor.

Watcom C/C++ 10.6 and 11.0, the most used versions of the compiler to build demos, were very good at producing Pentium-optimised assembly. One of the reasons it was so immediately accepted was because it optimised for the Pentium, which meant taking a lot of conventions in x86 optimising techniques and tossing them over. Now the compiler has been untouched for more than two years. There were proven rumours that version 11.0 had bugs when faced with the try/catch/throw C++ exception framework and at least five patches were made available for it.

Size issues

It's true that programming under Windows alone justifies a big upgrade to one's computer. What's most quickly noticed is how slow it is to compile and link a program relatively to the MS-DOS way. The Visual C++ compiler eats up a lot of memory even when compiling the most simple of programs, and this is sure one of its many downsides; nevertheless it still pays off to endure long build periods, not only because of the better code-optimising but because the resulting EXEs are, in fact, smaller in average than those produced by Watcom.

In the old days, WWPACK and Propack were used to compress non-overlayed executable files. In demoscene terms, this meant a lot of assembly-coded intros and demos were compressed internally using these programs. When Watcom came along, people had to stick to PMWLITE, the PMODE/W extender's own EXE compressor. It was possible to do a much better job of compressing executables, so other utilities such as VEPack and UPX were used, the latter being the one with the most acceptance. (UPX compresses Win32 executables as well, but they become unstable and may crash.)

Even so, Petite (a Win32 executable compressor), which can safely manage resource data as well as normal code, proves that compressing simple EXEs yields better results than doing the same process in MS-DOS with Watcom C/C++. A simple program using PTC (the old statically-linked 2.0 release library) and generating some effect on the screen, waiting for a key to be pressed and exiting is, in fact, smaller than the same thing in MS-DOS. You can run a simple test with some code and PTC in DOS, and the same in Windows. If you use the new OpenPTC, then the EXE will be even smaller but PTC.DLL's size has to be added to the total. As Petite can compress executables, little or next to nothing is actually lost. By using DLLs you can speed up the disk-chugging link process that slows down the process of building an application such as a demo.

3. 64K intros on the Win32 platform

(As of this writing, Takeover'98 accepts Windows 64K intros - www.takeover.nl)

As a corollary of the section above, 64K intros can be done on the Win32 platform with considerably less effort than that of making the same magic under MS-DOS. You just have to rely on your compressor's efficiency and little more. As there are no extenders or soundcard-specific code, things tend to get smaller.

Note that there are other Windows EXE compressors than Petite - a much wider range than that of those available for the MS-DOS platform. Petite has proven to run stable and does a pretty good job at compressing, so that's the one exemplified here as well. (You may check out the size of ENCODE.EXE in our demo "encode/decode" from The Gathering '99 to see for yourself.)

A suggestion for party organisers would be to accept productions that required the latest PTC.DLL and BASS.DLL to be in the system's path, say, in the WINDOWS\SYSTEM subdirectory. The organisers would publicly state the version numbers of the DLLs and compress them internally. They could let the entries supply their own versions of these two DLLs, if necessary.

By not including resource data such as an icon for the executable file, your intro could drop 5 to 10 kilobytes of data when packed. It's best not to mess with the resource compiler, as it will only add extra size and is not really necessary for the development of a 64K intro.

If the rules specify that the DLL's size will be added to the 64K limit, there's not a lot of space to code an intro. As some parties allowed in the past that DOS4GW.EXE (Watcom's DOS/4G extender stub file) could be deducted from the total size, a similar strategy could be used with this case. All in all, when was the last time you ran a 64K intro safely and with reasonably little hassle?

The 64K intro arena is technically very difficult and frustrating to work in and makes it difficult for other people to watch demos. There have been a lot of gems of the scene over the years that become increasingly difficult to be re-experienced because of these old MS-DOS limitations that have to be put up with to watch a 64K. Now is a good time to end it and persuade democoders to do their stuff in Windows.

4. Software to use in demos

The descriptions above should not blindly influence your choice. Read the text files and decide which library is best for you.

OpenPTC

The use of namespaces in the source code has been removed, although it was useful, at least in the Win32 platform. You may find yourself having to change class names in your own code to avoid conflicts with PTC's. This is, without a doubt, the easiest library to get into graphics programming under Windows. Instead of having to learn the complex DirectX interface, you just have to delve into PTC a bit to realise how easy it is to use. It does pixel format conversion (its original main feature) and handles all the Windows bureaucracy for you. And, best of all, it's good, well-written C++ code.

MIDAS Digital Audio System

The only long-lasting player in the demoscene. Under Windows, there are better alternatives, such as BASS and JiNX (see below). Its disadvantages include not being able to load files from memory and not having proper Visual C++ 5.0/6.0 support, although it's not really a big thing. If you already have code which uses MIDAS and just want to port it to Win32, this would be the best option.

BASS

Probably the best playing library around today. Can play modules all the way up to IT, interpolates sound by default, can load from memory and, best of all, it's very small (a compressed DLL and an export library). This is a very good advantage over other players because it makes it suitable to use in Windows 64K intros.

JiNX

This player is loaded with options and effects: you can add reverbs and echoes, add external samples (as well as BASS) and generally play around with the control that is given to you. It's available in the form of a statically-linked library and its downside includes not interpolating sound and being comparatively slow regarding other players.

FMOD

A Win32 rewrite of the famous FMOD player included in old docs that tought how to code a module-player (around 1995). This is a rather powerful one: you can choose from every available sound device in the system, and although it doesn't have interpolation, its best advantage is the customized mixer code for Pentium, Pentium Pro and MMX systems. This turns it into possibly the fastest player around.

5. Software reference

The following programmers are helping the scene move to Win32 by making their libraries and programs (see above) free for non-commercial use and must, therefore, be mentioned.

   - OpenPTC
     author: Glenn Fiedler, et al
     e-mail: gaffer@gaffer.org
     homepage: http://www.gaffer.org/ptc/

   - MIDAS Digital Audio System
     author: Petteri Kangaslampi & Jarno Paananen
     e-mail: pekangas@sci.fi
     homepage: http://www.s2.org/midas/

   - BASS
     author: Ian Luck
     e-mail: bass@icl.ndirect.co.uk
     homepage: http://www.icl.ndirect.co.uk/music/

   - JiNX
     author: Mark Hodson
     e-mail: mjhodson@camtech.net.au
     homepage: http://www.adelaide.net.au/~mjhodson/JSS.html

   - FMOD
     author: Brett Paterson
     e-mail: fl@zip.com.au
     homepage: http://www.zip.com.au/~fl/

   - Petite
     author: Ian Luck
     e-mail: petite@icl.ndireck.co.uk
     homepage: http://www.icl.ndirect.co.uk/petite/

6. Last words

I hope this text shed some light on the DOS scene and highlighted the most important reasons why a change to the Win32 platform is necessary.

Opinions, reasonable criticism or corrections: pcadavez@mail.esoterica.pt digital artists homepage: http://dawn3.cjb.net

- brainpower / digital artists

PS: A fix for our demo "encode/decode" to make it run under Windows 95 is available at our homepage. It also uses updated OpenPTC and BASS libraries.