User Guide

161
Technical Notes
Technical Notes
Memory Management for the PC
In Harpoon II we used a 32-bit DOS-Extender allowing us to set aside
the pseudo-24-bit addressing limitations of MS-DOS. This provides
us with the ability to directly use all of the RAM on your computer
without having to "jump through hoops." The native 32-bit address-
ing of the 80386/486 family of processors makes Harpoon II run
much faster than similar sized applications running under DOS in
“real” mode. In addition to the 32-bit operation, we have used the
Virtual Memory features of the DOS Extender. This allows machines
with only 4 Megabytes of RAM run Harpoon II with far less risk of
running out of memory. Virtual Memory uses a portion of your hard
drive (in a temporary file) as RAM. When a program’s memory usage
grows beyond the capacity of your RAM, the Virtual Memory routines
find seldom-used variables or data blocks and puts them onto the
hard drive. This frees up some RAM for more items. If the program
later needs some of those variables or data blocks, the Virtual
Memory routines swap them back into RAM. While this process can
be slow, it allows play to continue where the simulation would
otherwise be unable to do so.
Navigation
In the original Computer Harpoon, as well as in many other wargames,
the ability of a computer AI to plot a course on its own was a risky
proposition at best. When the objects to be avoided (usually terrain)
are large and regular, or perhaps simple bitmaps, a simple right/left
path algorithm will work just fine. However, in Harpoon II we model
coastline polygons whose vertexes are a minimum of 1000 yards
apart, but vertexes from different polygons can be placed within 18
inches of each other. When a scenario may be thousands of miles
across and your coordinate scale is 18 inches, the math becomes a
little more complex. The Harpoon II Navigator uses many different
methods for finding a least-cost path for platforms. In many cases,
(such as planes) the restrictions are not as stringent, but ships
transiting straits or traveling great-circle paths on multiple map
projections were extremely difficult to write. As it was, we used multi-
threaded events to break up these calculations over a minute or more
of real-time. The game progresses normally while the navigator gets
a share of the CPU every few microseconds to complete its tasks
without stopping play. Even with all the hoops and tricks we used,
sometimes the Navigator will be forced to give up trying to solve a
complicated navigation problem so it can service requests from other