Demos on the Win32 platform by Digital
2 of 2 files
brainpower
- Browsers may flag this download as unwanted or malicious. If unsure, scan it with VirusTotal.
-
Last modified Jan 13, 2000 1:00:00 PM
MD5 checksum dcbc12c0cffa66895088c5bf881c0c86
Mime type
Download d_encdec.zip
Size 1.8 MB
1999 April
- Text / Guides and how-tos
- Patch file
- Brainpower, writer credits
8 items in the archive
- ADDENDA.TXT
- DEMO.IDX
- ENCODE.EXE
- ENCODE.MTH
- FILE_ID.DIZ
- WIN32.TXT
- WINGFX.IDX
- BASS.DLL
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: [email protected]
homepage: www.gaffer.org/ptc/
- MIDAS Digital Audio System
author: Petteri Kangaslampi & Jarno Paananen
e-mail: [email protected]
homepage: www.s2.org/midas/
- BASS
author: Ian Luck
e-mail: [email protected]
homepage: www.icl.ndirect.co.uk/music/
- JiNX
author: Mark Hodson
e-mail: [email protected]
homepage: www.adelaide.net.au/~mjhodson/JSS.html
- FMOD
author: Brett Paterson
e-mail: [email protected]
homepage: www.zip.com.au/~fl/
- Petite
author: Ian Luck
e-mail: [email protected]
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: [email protected]
digital artists homepage: dawn3.cjb.net
[DA::VK]