
Demos on the Win32 platform
---------------------------
                                                          brainpower / digital artists


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 2 years. There were proven
   rumours that version 11.0 had bugs when faced with the try/catch/throw C++
   exception framework and at least 5 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 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 DLLs' 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) 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: www.gaffer.org/ptc/

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

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

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

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

   - Petite
     author: Ian Luck
     e-mail: petite@icl.ndireck.co.uk
     homepage: 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.

     You may distribute and publish this text by the use of any media if:
       a) you let me know via e-mail (address below)
       b) this file is not changed in any way.

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



[DA::VK]
