Windows Flight Simulators: Flights of Fancy?
by Matthew T. Smith (CIS: 70661,3235) 3/5/94


As a full-time Windows programmer and flight sim enthusiast, I
often feel that I serve two masters; certainly my computers do.  My
friends joke that my Windows income invariably is spent on DOS
programs, and they aren't exaggerating.

It is true that I make my money writing Windows applications.  I
do all my work in Windows and, in fact, no longer run any DOS-based
programs -- except flight simulators.

That said, I don't mind admitting that I've spent more cash
purchasing DOS flight simulators and accessory programs than any of
my Windows programs.  Most of the hardware I own was purchased not
because I couldn't do my work on the old equipment (heck, I can
compile a Windows app from the DOS prompt on an 80286 if I have to),
but because one sim or another wasn't running smoothly enough.

Rightly or wrongly, few things get me dipping into my wallet faster
than a slow frame rate in a great new sim product.  There are a lot
of great ones out there to choose from and, believe me, I've done a
lot of choosing.

But I can see the handwriting on the wall, too.

When they eventually get here -- and they WILL -- the coming
generation of Windows-based flight simulators will have a number
of advantages over today's (even TOMORROW'S) DOS-sims.  Chief among
these, particularly in the long term, is the simple fact that
Microsoft, Intel, and hundreds of other software and hardware
companies are investing huge amounts of time, money, and energy in
support of graphical user interface GUI computing -- much more than
is being spent on product development on the "plain old DOS" side.

This industry momentum has been a major factor in the improvements
demanded and delivered in recent releases of Windows, as well as
improvements demanded and delivered on the hardware side
(microprocessors, video chipsets, wide-bus video and disk standards,
etc.).

Say what you like about Windows; the fact remains that its popularity
has been a tremendous spur to hardware manufacturers to develop the
faster equipment required to run it acceptably.  As more users
migrate to Windows-based computing, the incentives for the hardware
industry only increase (which would hardly be the case if everyone
was still using DOS programs).

Users of DOS-based flight sim products have benefited indirectly from
this trend for some time.  Intel may have had Windows in mind when
they designed the Pentium, but that doesn't mean that users of Flight
Simulator or Falcon 3.0 or Strike Eagle III don't get a nice
performance boost at the same time.  The VESA Local Bus (and now
Intel's PCI) standards were most likely created in response to
performance bottlenecks created by high end Windows products, but
that hasn't kept DOS sim users from enjoying the results.

At the same time, hardware evolution seems to be favoring PCs that
run Windows and Windows applications.

Like it or not, the fortunes of Intel and Microsoft are very much
intertwined, and more than a few video card manufacturers have struck
gold by hammering out speedy Windows accelerated cards.  This is the
PC industry's direction, and as long as the incentive (money) is
there, the trend will continue.

A "Win-Sim" will exploit this industry momentum instead of bucking
it, and will exploit it DIRECTLY rather than merely riding along
on its coattails.


Here are some particular advantages the Windows environment has to
offer a Win-Sim:

1. Future (even current!) versions of Windows are designed to
manage your PC's hardware directly, without having to deal with DOS.

If you're used to running Windows 3.1 or Windows for Workgroups
3.1/3.11, this takes some explaining.  Within the context of those
versions, just about everything that you (or your programs) ask
Windows to do, IT must then ask DOS to do.  This runs the gamut from
disk access to memory management to screen painting, and it exacts a
high price in extra processor cycles.  32-bit Windows (today's NT and
all future Win releases) does away with the DOS middle-man.  Graphics
intensive applications simply work more efficiently on a true Windows
OPERATING SYSTEM (i.e., NT / Win 4.0) than they do in a DOS-based
Windows OPERATING ENVIRONMENT (Win 3.0 / 3.1 / 3.11).

It's worth remembering that the evolution of Windows computing has
actually been hampered by Microsoft's desire NOT to alienate the
scores of DOS-only users.  It's likely that we'd have had rock-solid
32-bit Windows quite a while back if Microsoft had abandoned support
for running DOS apps from Windows -- but this was not economically
feasible.

The perceived need to maintain Windows' ability to run programs
designed for other operating systems (i.e., DOS) has probably slowed
Microsoft in its attempts to "revolutionize" its OS software -- in
much the same way that Microsoft/BAO's Flight Simulator 5.0 is only
as "revolutionary" as its backwards compatibility with FS 4.0 allows.

The lesson here: yes, Windows as we know it has always seemed
slower than DOS -- but having to run Windows on top of DOS has kept
the playing field from being totally level.

It's always smart to be a wary consumer (and we've learned the hard
way not to accept everything that comes out of Redmond, Washington,
as the gospel truth), but don't let prejudice from yesterday's
Windows performance close your eyes to the versions right around the
corner.


2. More and more high-end video cards implement hardware-based
Windows acceleration.  This is another by-product of the hardware
industry's desire to cater to the Windows user base.

Hardware based video acceleration provides a huge, noticable boost to
the bitmap block transfers used in paint programs, DTP programs, and
both live video (overlay, as from a PC-TV card) and digitized (AVI)
video.

For this to work, many of Windows' graphical routines are off-loaded
to a video processor/accelerator chipset on the video card; the
particular routines which are off-loaded and the manner in which they
are optimized at the hardware level is determined by a proprietary
video driver under which Windows is being run.  Individually, the
accelerator card and the driver software offer no advantage, but
working together, they provide a marked increase in video
performance.

A dedicated Win-Sim (or any other Windows program) can exploit this
advantage, since the accelerated video chipsets optimize the very
graphics functions likely to be used most heavily by a sim product.

Remember that hardware manufacturers are falling over themselves
trying to produce the best, most cost-efficient Windows-optimizing
CPUs and video chips.  It's a safe assumption that, as more PC users
move to Windows (or are brought up on it from scratch), demand for
Windows-optimized hardware will spur even more rapid product
development and, with it, competitive pricing.

A Win-Sim takes advantage of this trend (and the flow of affordable
high-end hardware).


3. In conjunction with hardware Windows acceleration, don't
underestimate the advantage of optimized Windows video drivers.
I've run dozens of tests using accelerated cards with and without
their proprietary drivers -- in virtually all tests, the optimized
drivers produce HUGE speed boosts.  Most optimized proprietary
drivers can run Windows at 1024x768 with 256 (or even 65,536)
colors MUCH faster than a generic "vanilla" driver at 640x480
16-colors.

With the right drivers, there won't be any speed hits to endure
when running a Win-Sim at a high color depth.


4. Believe it or not, the techniques for acceptable screen/frame
updates for fluid Windows-based simulator visuals are already "out
there."  We don't see them so much in entertainment software -- yet
-- but they're creeping into business presentation software and
CAD/design applications (which is where they started on the DOS
side).

I'm not talking about Video for Windows, mind you.  It's nice to
be able to record and play a weenie 160x120 pixel video clip at 15
to 30 frames per second, but that's a far cry from animating an
entire screenful of dissimilar elements, as is the case in a true
simulator product.

Strictly speaking, VFW is simply the result of throwing a series
of bitmapped images on screen and interleaving a waveform audio
track in (rough) synchronization with the video.  If VFW
demonstrates anything, though, it's that even a clunky approach can
be made to look strikingly fluid with accelerated video hardware.

There are a number of Windows-based arcade games out right now
that are surprisingly responsive.  You can find a number of
"shoot-em-up" Windows games right here on CompuServe that are
visually impressive (supporting 256 or more colors) and their
animation routines have a nice smooth, fluid quality.

There is nothing "magic" or "secret" to the programming techniques
used to write these applications; in fact, the functions for
putting images on screen in Windows are arguably better documented
than those for doing it directly from DOS.

Almost any Windows programmer with time on his/her hands can create
a stunning front end that rivals the look of any top-end DOS
flight simulator.  Getting those good looks to "move" in the right
directions at the right times takes work.

For speed's sake, Windows developers can write portions of their
programs in assembly language code if they have to, just like
programmers on the DOS side.  Many of the same tricks used to
optimize the performance of DOS sims are available in one form or
another to Windows programmers.

Traditionally, the developments of DOS-based flight sims have
followed on the heels of DOS-based CAD design software.  In many
respects, the visual modeling (both scenery and airframe) of a
good sim has much in common with a dedicated CAD program.  It's no
coincidence that most of today's "virtual reality" programs are
really variations on interior/exterior design software (e.g., tour
the house before you build it, etc.)

Well, CAD programs for Windows are only now beginning to hit
their stride.  Just as they did on the DOS side, the coming Win-Sims
will follow suit.


5. Code for a Win-Sim will probably end up being smaller than
that of DOS-based sims, if only because the sim code itself can
off-load much of the "grunt-work" to Windows itself.  This makes for
a shorter development period -- and for smaller, faster programs that
are easier to troubleshoot and debug later on.

A DOS developer must create almost every facility his/her program
implements: for video, for hardware support, for printing, for
handling interrupts and port assignments, etc.  Because of this,
every top-end DOS flight sim "reinvents the wheel" in one way or
another.

A Windows developer doesn't have to do this -- doesn't have to
write separate modules for VGA, SuperVGA, or UltraVGA displays;
doesn't have to write dozens of routines for each possible
combination of joysticks and flight control accessories; doesn't
have to grapple with baud rates and port addresses for
head-to-head, multi-player, and network support; etc., etc.

Multimedia support for waveform audio, MIDI sequencer, timers,
laser discs, CD audio, and (yes) full motion video is built into the
Windows 3.1 API, and is fairly easy for a developer to access.

The Windows developer knows that a lot of the basic stuff involving
the interaction of his/her code with the user's hardware is already
handled by Windows itself, or by the authors of the hardware
device drivers.

One of the early, and not entirely correct, buzz-phrases of Windows
application development was: "Never talk directly to the hardware."
A more accurate way of putting this is: "Let somebody ELSE talk to
the hardware."

This doesn't matter much as far as file size or disk space; the
REAL advantage is that the sim programmer can pay attention to
the simulator-specific issues (flight model, scenery, AI, etc.)
and not worry so much about menus, cursors, printers, display
compatibilities, device drivers, audio support, and the like.

The Windows developer writes code for a "virtualized" environment in
which all PC's, video cards, and monitors are treated the same.  The
developer is free to concentrate on the specifics of his/her vision,
leaving the hardware-specific issues to Windows itself.


6. The existing Windows joystick driver is clunky, but it works
(and does prove that an installed joystick can be "virtualized").

As sims move to the Windows environments, proprietary drivers for
joysticks or flight control systems will be written (just as they
have for video cards, printers, scanners, mice, etc.).  When this
happens, it will provide for a measure of "standardization" that
doesn't exist today (i.e., ALL Win-Sims will be able to take
advantage of a single joystick driver -- you won't need different
setups for each one).


7. In conjunction with #6, Win-Sims will be relatively easy to
install and get "up and running" (or at least as easy as any other
Windows app).

Traditionally, the worst headaches for users of DOS-based sims
come about as a result of the various configuration tweaks required
by the program (set this jumper, change that interrupt, run this TSR,
remove that EMM386 setting, edit your FILES/BUFFERS values, etc.)
during installation and setup.  This is what prompts users to keep
multiple sets of CONFIG.SYS/AUTOEXEC.BAT files on their machine, one
for each sim they try to run.

Win-Sims, on the other hand, will conform to a fairly common set of
system requirements, which is not as restrictive to the developer as
it sounds -- and is a huge boon for the end-user.

The Win-Sim will say, in effect, "If you run Windows, you can run
this sim."


8. Don't forget that Win-Sims will (or should) all share a fairly
common set of menu and keyboard commands.  Won't it be nice when "G"
toggles your landing gear in EACH sim?  Or the same joystick buttons
activate the same view or weapon features in EACH sim?  The Windows
interface provides for a measure of "common ground" and familiarity
that isn't seen across too many DOS-sims.


9. A Win-Sim will have access to all sorts of memory, both physical
and virtual, by way of the Windows resource pool.  Again, Windows
itself works behind the scenes to swap data out to memory and/or
disk as needed.  The Win-Sim will have to ask Windows -- politely
-- for extra memory, but it WILL be available.

There will be no 640 kb limits to worry about, no EMS/XMS juggling
behind the scenes, and no CONFIG.SYS acrobatics will be needed to
free up enough memory (and users won't have to reboot your machine
to run their "regular" programs).


10. In Windows 3.1, it is possible to control (via Control Panel's
386 Enhanced Mode applet) the relative "slice" of processor time
allocated to a particular application (foreground vs. background).
This is more straightforward in Windows NT.  Future versions of
Windows will make it easier to allow an application to enjoy the
lion's share of processor cycles.  Users will literally be able
to allocate CPU "processing power" to a Win-Sim according to what
other applications, if any, are running at the same time.


11. A 32-bit Win-Sim will be able to take advantage of full 32-bit
processing, which will bring a number of performance and
reliability benefits.  When running on top of 16-bit DOS, current
versions of Windows are simply unable to take advantage of today's
386, 486, and Pentium processors; processing cycles are wasted,
stability is always in question, and multitasking is accomplished
with smoke and mirrors since DOS can really only do one thing at a
time.

When the DOS underpinnings are left behind, a true 32-bit operating
system (Windows or OS/2) really sings.  Stability is enhanced as
well, since most of the instabilities associated with 16-bit Windows
are by products of the shell games it plays with its DOS foundation.


12. Don't forget the advantages of Windows' help system.  Run-time
help in complete detail will be available directly from the Win-Sim
interface via WinHelp.  Users can use the hypertext jumps or built-in
search engine to access documentation on any sim feature; you can
even print help topics directly from WinHelp.

Aircraft specs, airport locations, maps, charts, and much more can
be placed within easy reach in the Win-Sim help file.


SUMMARY
-------
In a nutshell, when the first Win-Sims do arrive, they probably
won't be as snappy as today's DOS-sims seem.  But they won't be as
"bad" or as "slow" as many of us have been fearing.  And they'll
probably catch up faster than anybody expects, due to Microsoft's
continuing efforts to optimize each successive release of Windows
AND to the hardware industry's incentives to constantly improve its
Windows-supportive microprocessor and video hardware (incentives
which ramp up with each new version of Windows).

Bear in mind that it wasn't so long ago that crude wireframe
renderings at CGA video resolution were considered the cutting edge
in DOS-based flight simulators.

In time, improved hardware platforms for DOS sims allowed for more
sophisticated software.  Today's sims push 16-bit DOS to the limit
-- and that's exactly the point.  For good or ill, DOS is hamstrung
by inescapable "brick wall" limitations that restrict the scope of
future DOS-based sims.

16-bit DOS isn't dead; it isn't even sick.  It's just approaching
the end of its productive service life.  DOS can only do so much,
and the computer industry is putting its big money elsewhere.

As that continues, it becomes more and more likely that we'll
simply move past DOS in search of something better, faster, more
efficient, and with plenty of room to grow.  32-bit Windows won't
be the only game in town, mind you, but it's looming as the best
bet right now.

If we are as forgiving during the "growing pains" of the coming
generation of Windows flight simulators as we have been over the
past decade of DOS sims, our patience will be rewarded with a
number of highly stable, highly ENJOYABLE simulator products.

Just a thought.

______


This document is hereby released to the public domain.  As such,
it may be freely contributed, in its original form, to any
electronic bulletin board, network, or on-line information
service.


Matthew T. Smith
CIS: 70661,3235

______


Microsoft(TM) is a trademark and Windows(R) is a registered
trademark of Microsoft Corporation.  All other trademarks mentioned
herein are trademarks or registered trademarks of their respective
corporations and are hereby acknowledged.
