From: wallace@titan.trl.OZ.AU (Glenn Wallace)
Subject: Comanche - mini review and Voxel Space discussion
Organization: Telecom Research Labs, Melbourne, Australia
Date: Sat, 19 Dec 1992 01:36:17 GMT

                   *******************************
                   *                             *
                   * Comanche : Maximum Overkill *
                   *                             *
                   *******************************
 
Just seeing this game running was enough to make me want to buy it!
 
It came into stock over here this week. RRP (recommended retail
price) here was AUD$99.95, but I walked the 30ft from Games'R'Us to
Mr Toys and paid AUD$89.95.
 
Install
=======
 
The install is very simple, but you need 12MB space while installing
as it copies the archive files to your hard disk and then extracts
the game files. It takes up about 7-8MB on disk after install.
 
It supports VGA only, not MCGA (who cares). You need a 386/486 with
4MB of RAM.
 
My main problem on my work machine was 386MAX which I had to neuter.
It doesn't like EMM386 either. A bare CONFIG.SYS with HIMEM is all
you really need.
 
There's no copy protection. 
 
 
The Game
========
 
You fly the (yet to be introduced) RAH-66 Comanche 'copter.
 
Armament:
	- Hellfire air-ground missiles
	- 70mm rockets
	- 20mm cannon
	- Stinger air-air missiles
 
Also you can vector (presumable) Hellfire missiles from your Wingman
if he is present in the scenario you're playing.
 
You can also call in artillery fire.
 
It also has auto-chaff and auto-flare dropping, which is cool but I
wish I could turn it off at times to save stock of them. They also
have manual release.
 
I found the missions to be a bit easy, once you figure out the
way each weapon is best used you can pretty well nuke anything
that moves. I'm up to the very last scenario, and apparently they
will have add-on scenario disks.
 
 
Flight Dynamics
===============
 
Well, the copter is pretty smart, auto-adjusting throttle to suit
your collective setting. It annoys me at times because you lose that
little bit of control. It does make it simpler to fly.
 
I'm pretty sure the flight envelope is too simple. You set low
collective, and get a matching low throttle, and then when you push 
the cyclic forward you can move forward at maximum speed?!!!
 
They just seem to equate collective with altitude and cyclic with
outright speed. It is more complex than that, but perhaps the
auto-throttle reduces the coupling between, say collective and speed.
 
Compared to say, Gunship (I think) on the Amiga, it is lousy.
 
They've got the ground-effect NapOfEarth flying down OK though.
 
 
The Graphics
============
 
The best part of the game (in my opinion) is the Voxel Space (tm)
technology. It seems to be a cool way of rendering terrain.
 
The only way to describe it is that it looks like a 3-D shaded
bitmap! Similar to Wolfenstein, perhaps.
 
I'm pretty sure I've figured out how it works.
 
First - some clues.
 
1) You can only fly up to 500ft altitude - the manual says something
   about restricting you to that type of flying.
 
Well, 500 is pretty close to 512. Why this crazy restriction?
Hmm, oh, your alitutde seems to move in 2 ft increments... ok, let's
make that 256 units from bottom to top in terms of vertical movement.
 
What if the terrain was expressed as an array (1k x 1k??) of bytes,
with each byte denoting the terrain height at that point.
 
Pretty wasteful space wise, but very convenient to render and
describe!
 
2) runs in 386/346 flat mode. At first I though, oh great! They're
   doing some cool stuff.... and then I thought, hey, it is a pretty 
   'light and easy' processor wise game (apart from the rendering).
 
Maybe they needed flat mode for these huge arrays? Convenient!
 
3) There are no overhangs or vertical features. A good example of
   this is the Mayan temple in one of the scenery areas. It is like a
   truncated pyramid.... something that would be quite natural to draw
   using technology like this.
 
4) extensive shading. There is some excellent shading detail on the
   terrain... it just HAS to be stored discretely, NO WAY is it
   calculated on the fly.
 
5) Display readout shows you how close the ground is.... like a radar
   altimeter. This would be very easy to implement with the huge array,
   you just look up the terrain height at your x,y location and subtract
   it from your z-height! Simple!
 
6) the world 'wraps around'...
 
I then reasoned that the way I would implement it is to have two
bitmap arrays. One for topography, i.e. terrain height. 
 
The other one would be for shading (i.e. basically a palette index).
 
So you'd draw your topographic map, an easy way to do it would be to
assume dark colors are deep valleys and light colors are peaks...
etc. Your palette index becomes your terrain height.
 
Then you copy that bitmap and start shading the edges of ravines,
sides of mountains etc. This is used as your palette index for
coloring.
 
They have about 4 different terrain 'worlds', so each one would have
a data 'map' and a palette/color 'map'. They are extensively re-used
with different palettes giving them different 'looks'... lush,
night-time, lunar, volcanic, etc.
 
See those files C1.DTA through C4.DTA? and D1.DTA through D4.DTA?
 
Of course, you'd run-length-encode them for disk storage.
 
Anyone agree or disagree with this?
 
Don't ask me about the clouds...
 
 
Glenn