• Source: SGI Dogfight

Dogfight is a demonstration program initially written by Gary Tarolli (later founder of 3dfx) at Silicon Graphics, Inc in the summer of 1983. It represents landmarks in two key areas of Internet development: games and multicasting, and notable advancement in creating rendered virtual environments.




Overview


Dogfight might more properly be referred to as three programs, flight, dog, and shadow. Flight is a flight simulator, dog is an air combat game in which multiple people use the flight interface to control their aircraft, and Shadow is an observation program that allows a user to see what a user of either dog or flight sees.
dog and shadow could also be run in "airshow mode", using the -i and -o command-line switches. With -o, the path taken by the plane would be saved to a file instead of being broadcast to the network. With -i, the user could specify a file containing a saved flight path of this sort, and it would be displayed. Missiles fired by a plane in this mode would not affect planes in non-airshow mode. The intention was for the user to be able to record the paths of several aircraft, and then, by replaying them simultaneously, to be able to display complex aerial formations with multiple planes.
At some point, the -h command-line switch was also added. This would replace the standard instrument panel with a head-up display (HUD). Such a display was commonly used in military aircraft and would allow for a larger view, but at the cost of a slower update rate. This was added because Williams Air Force Base was interested in using flight for F-16 training, debriefing and "human-interaction studies", but wanted it to have a HUD similar to the HUD on a real F-16.
The following planes were available:

Cessna 150
P-38 Lightning
Boeing 747
F-16
F-15 (In the GT/GTX/VGX version, this was described as looking like an F-14 model with the wings swept back. The F-15 is neither a delta-wing nor a swing-wing plane, so this would have been inaccurate if the wings were fully swept back.)
F-14D (wings laid on)
Later versions added:

different F-16 geometry
F-18
Boeing 727




History


Flight was written in the summer of 1983 by Gary Tarolli, as a demo for SGI workstations. It was inspired by the Blue Angels airshows at Moffett Field, across the street from SGI's original headquarters.
In 1984, networking capabilities began to be added. Initially, two workstations were connected by a serial cable. This allowed about 7 frames per second and 500 polygons per second on a machine with a Motorola 68000 CPU capable of approximately 1 MIPS. By SIGGRAPH 1984, XNS multicast support was added, allowing play over an Ethernet network. After the event, the networked version of Flight was distributed on all SGI workstations. In this networked version, users could see each others' planes, but could not interact with them.
Probably in early 1985, dog was created, and dog and flight were shipped as demonstration software included with SGI workstations. Message packets were transmitted at frame rate, and the number of players was capped due to bandwidth limitations, although sources differ as to whether this cap was 10 players or a value in the tens of players. Due to the network congestion resulting from so many packets being transmitted at frame rate, many system administrators removed dogfight from newly installed systems in order to prevent abuse of resources. Other sysadmins limited play to restricted off-peak hours.
Dead reckoning was later added, to reduce the amount of data that needed to be transmitted.
In 1986, UDP broadcast protocol capability was added (using port 5130). Information was transmitted via broadcast packets and at frame rate, meaning that the program made intensive use of network resources and even a small number of players was capable of saturating an Ethernet. So while it was probably the first game to use the Internet Protocol Suite, gateways would refuse to transmit UDP broadcast packets, and thus could not be played across the Internet itself.
By 1988, with the introduction of SGI's 4D series of machines, Dogfight had forked, with one version running on most SGI machines of the time (3000 series, 4DxxG's, Personal IRIS, GT, GTX) and another for use only on the higher-end GT, GTX and VGX machines. These could interoperate, with both versions playing in the same game. The 4D/20 was observed to run dog at around 12 frames per second, while the faster 4D/70 would be capable of 20-25 fps. The other version was observed to run on a GT at around 15 frames/second. In the Irix 6.5 documentation, it was noted that the Boeing 727 and F-14 were not available to choose as planes in the normal version of the software, but were present in the GT/GTX/VGX version.
SGI would supply the source code to IRIS owners upon request if a non-disclosure agreement was signed. Some Usenet posts claimed that the code was not supplied standalone, but as part of a "Software Exchange Release Tape". A fee of $100 was charged for this, and the user had to specifically request that the dog source code be included on the tape. Others stated that this was for the physical media and shipping/handling, not the source code itself, and that no charge was made if the IRIS owner supplied SGI with a blank tape of their own to put the code on. Based on the dates of the various postings, it is possible that SGI initially supplied the code for free, but began charging for it at a later date.
Several programmers used this code as an example, to teach themselves UDP and how to use it in their own code.
For the IRIX 3.3 version, circa 1989, IP multicast capability was added, and the game became playable between any compatible hosts on the Internet, assuming that they had multicast access (which was quite uncommon). The multicast address was 224.0.1.2 (SGI-DOG.MCAST.NET), making this only the third multicast application to receive an address assignment, with only the Versatile Message Transaction Protocol (VMTP) protocol (224.0.1.0) and the Network Time Protocol (224.0.1.1) having arrived first. SGI would later use the same address for their objectserver daemon, which handled GUI icons. This caused confusion for some system administrators.




= Unofficial forked versions

=
Due to the availability of the source code, various SGI customers created and distributed their own unofficial modifications to the original flight program.



The point-to-point communication fork

A version replacing the UDP broadcast with point-to-point communication between two hosts was created at the Lund Institute of Technology in Sweden. The source code patch for this was posted on comp.sys.sgi in September 1989. The reason given for this fork was to allow machines on different subnets to play against each other. It may also have been intended to reduce network congestion compared to the broadcast version, and probably pre-dated the addition of multicast to the official version.



The air traffic control server, and a different TCP/IP implementation

Prior to 1988, the US Army's Ballistic Research Laboratory (BRL) had a copy of the XNS version of the software, but XNS did not work on their network. An engineer by the name of Ron Natalie had access to the source code and was able to create a TCP/IP version. This version communicated with a central server with its own "air traffic control" display.
There is no record of code from this version being used in the "official" version, or of its own networking implementation influencing the official one in any way. This means that the BRL version is probably an independent fork with different TCP/IP networking, which may not have been compatible with SGI's own. It may not even have used port 5130.
A server program called atc (Air Traffic Control) for dog was mentioned on comp.sys.sgi in November 1988. This was probably Ron Natalie's air traffic control server, running on the BRL's forked version of dog. There is no evidence of such a feature ever being added to the "official" version.



Porting for Sun Microsystems compatibility

In a 1992 thread on the rec.aviation.simulators Usenet group, a list of available flight simulators included a port of dog/flight to pixrect - a "low-level raster operations library for writing device-independent applications for Sun products."
This port was described as "(an) unauthorized copy of SGI flight/dog programs ported to run with pixrect. Very difficult to find one of these, and probably not legal. Nice fast network dogfighting. Tends to bog down the whole LAN with packets."
Another Sun port - specifically compiled for Sun's SPARCstation hardware - was also mentioned.
In a 1990 post to comp.sys.sgi, a Sun port was mentioned which "runs reasonably well on a colour GX Sparcstation although it doesn't fill the polygons so a lot of the realism is lost". It is not clear whether this was a third Sun port, or whether it was one of the ports listed in the rec.aviation.simulators thread.
The author of the thread stated that he had received this version in source code form, as a combination of the original SGI source code and a library to emulate SGI's graphics. In a later post, he stated that he had been informed by SGI that the source code should not have been made publicly available, and was distributed in violation of an NDA. He also mentioned that he had originally downloaded it from an FTP server.



Sci-fi craft, World War 1 planes, and the X-29

In a 1993 Usenet posting, one user mentioned having seen a version of flight with X-wing and TIE fighter models in the autumn 1987 issue of SGI's house magazine "IRIS Universe". In a reply, a user from NASA's Langley Research Center said that they had had such a version running on an SGI 3130, and that as well as new vehicles there were also new weapons for some craft. The full list was as follows:

X-wing, with lasers as weapons.
TIE fighter, also with laser weapons, and with Snoopy as the pilot.
Grumman X-29, with only the conventional set of weapons.
Sopwith Camel, again with Snoopy as its pilot.
Fokker Tri-Plane, again with Snoopy as the pilot.
Klingon battlecruiser from Star Trek: The Original Series, with phasers and photon torpedoes as weapons.
However, they only had a compiled binary of this version, and not the source code.
In a 1994 Usenet post, another user claimed authorship of the modified version, and offered to supply source code "for a price". The same user also stated that "It might need some changes for some of the newer machines." Whether this user was indeed the author is not confirmed.
In an earlier Usenet posting, another user had claimed that the Klingon craft could cause lasting terrain damage with its weapons, leaving "craters in the Earth".
Asked about this version, flight lead developer Rob Mace said that it had come "from a university", and that due to the copyrighted status of Snoopy and the sci-fi vehicles, SGI could not legally supply copies of it.
The Klingon vessel may have had unlimited maximum speed, and may also have been immune to stalling.




Developers



The manual page for the IRIX 6.5 (circa 1998) version of the program lists the following:

Gary Tarolli (Original version)
Network communications David "Ciemo" Ciemiewicz (Ciemiewicz worked on the UDP broadcast code) and Andrew Cherenson (IP multicast).
Rob Mace (Main coder by 1989, maybe involved as far back as 1988. Listed as responsible for IRIX 6.5 version. Credited with the geometry for the F-14. Also co-credited with Thad Beier for the F-18, with Marc Ondrechen for the 727, and with Marshall Levine for the new instrument panel)
Barry Brouillette (Described as a "contributor", geometry for F-16 and P-38)
Marshall Levine (Described as a "contributor", co-credited with Rob Mace for the new instrument panel)
Thad Beier (Co-credited with Rob Mace for the F-18 geometry)
Marc Ondrechen (Co-credited with Rob Mace for the 727 geometry)
Sound effects by Chris Perry and Chris Schoeneman




Gameplay






= The "city of lights"

=
In a 1991 Usenet posting, one user asked about an "interesting city" which the manual had claimed would exist north-north-west of the airport. Tarolli and others explained that there was no physical city at that location, but that lights were shown at night as if there were a city there.




= SAM threat cones

=
Pressing 'T' (shift+'t') in-game would cause wireframe domes to appear around the small brown rectangles in the swamp. These rectangles were intended to represent surface-to-air missile (SAM) sites, and the domes would represent the regions in which the player was in danger from the missiles. This was added at the request of Williams Air Force Base, as part of the changes that included the -h option described earlier. This behaviour was not documented.
The game did not in fact include code to fire SAMs from those sites, merely to show the "threat cones" that would exist for SAMs in these locations. However, a forked version was created (presumably by Williams AFB personnel) that did include this feature. The University of Calgary in Canada possessed a copy of this version. In a Usenet post referring to this version, David Jevans of the University of Calgary mentioned that several other versions of flight now existed, including a version running on the IRIS Power Series with Gouraud shaded planes.
SAMs were added to the official version in a later revision. However, they were only added to the "low end" version, not the GT/GTX/VGX version. In this revision, the SAMs could not be intercepted, had higher acceleration than the player's sidewinders, and would detonate themselves after 10 seconds when they ran out of fuel. If the user had a weapon in flight (e.g. a rocket or sidewinder) it would be automatically destroyed at the moment the SAM was launched. The user would then be unable to fire any more weapons until the SAM was destroyed.
A user in Germany had access to one of these versions, although it is not clear which one.




= In-game physics

=



Yaw and roll coupling

The game's physics did not include yaw/roll coupling. Tarolli knew that this existed, but did not have a reference for the relevant equations and was unable to derive them himself. He was also unsure how much of an effect the shape of the wings would have, and whether yaw and roll would be strongly coupled for all shapes of wing. As a result, he was unable to implement it in code.



Stall and spin

Two users complained about the game's stall/spin physics, arguing that stalls and spins did not occur as often as they would in real life, or in as many circumstances. They also complained about unrealistic behaviour when a stall did happen.
In his response to this, Tarolli pointed out that while minor stalls were predictable, violent stalls were not. He also noted that modelling minor stalls would depend heavily on the wing design, and that it would require custom equations to be coded for every different wing shape on each of the planes. The calculations involved in modelling minor stalls would also be intensive and complicated enough to cause significant in-game slowdown.
At least one user felt that the criticism levelled at Gary for the in-game physics was unfair, noting that flight and dog were intended primarily as fun games, not as precise simulations. He added that the relevant aerodynamics were often described in "a highly qualitative fashion" in relevant books, and that coding them into a simulation could be extremely difficult even if one had been able to learn them from such a book. Tarolli himself noted that since he had not been able to model a real stall, he had coded random spins for very bad stalls (depending on how bad the stall was), in the hope that this would be "something fun" for the players. He also stated that "half the things in flight are meant to be real - the other half are there to make dog more fun than it would be if things were too real."




Use in academic research






= 1989

=
A group of researchers interfaced the flight simulator with the US military's SIMNET. In their report, they stated:
"We were able to translate the SG "Dogfight" PDU's by "stealing" packets from the ETHERNET via a PC/AT with an Excelan 205E ETHERNET board installed. The software written to perform this operation uses UDP/IP to capture the SG broadcast packets and saves them to a disk file. Information contained in the SG PDU was reformatted or translated into SIMNET type packets, and then retransmitted over the ETHERNET to the SIMNET M1 tank modules."
The simulator itself ran on a Silicon Graphics 4D/70GT workstation.




= 1990

=
A researcher at the US Air Force Institute of Technology attempted to reduce the cost of flight simulators used in pilot training by using a head-mounted display with a simulator that could run on PC hardware. As part of this, an attempt was made to port dog/flight to a PC platform based on a 20MHz 80386 processor with 80387 coprocessor, and a Real World Graphics Ltd. PC Reality board containing two Intel i860 RISC processors. The PC was running ESIX, a version of System V UNIX. Due to the presence of the head-mounted display, the PC also had to host a device to track user head movements.
The flight simulator program needed to maintain cross-platform portability, so rewriting it in assembler instead of C was not allowed. Calls to the SGI hardware graphics pipeline were "emulated", translated on-the-go to calls to the PC Reality board's library functions.
The planes used in the experiments were the F-14D, F-16, and Cessna C150. The Cessna model had a lower polygon count than either of the other two planes. Problems were mentioned with the PC's graphics software being unable to handle the F-15 model, although this may only have applied if another plane was also present.
For this experiment to be considered a success, the PC would have to achieve a frame rate of at least 15fps with Z-buffered, flat-shaded polygons. The PC's performance was also compared to that of the Silicon Graphics IRIS 4D/85GT with an unmodified version of the flight simulator.
It was noted that the unmodified version of dog used "makes extensive use of the Silicon Graphic's immediate mode graphics pipeline. In addition to including the new graphics functions released with the SGI 4D architecture, the program contains significant use of older functions that constituted the outdated SGI IRIS 31XX graphics pipeline methods. The SGI 4D machines provide built-in support for those older methods; however, they clearly identify that those methods do not optimally exploit the graphics pipeline provided in the 4D architecture."
However, the experiment was not a success. Some of the SGI functionality could not easily be ported/emulated, and was either omitted or replaced with a workaround. Wing stalls and G-limits were not enforced and all the aircraft were able to pull outside loops. Collision detection also had to be omitted, allowing the plane to fly through hangars, hills, and mountains. Furthermore, the PC Reality board was not able to support the polygon count or frame rate claimed, and some advertised capability was missing. Its approach to 3D graphics did not "allow for methods that write directly to the screen in device coordinates.", which caused problems. Only 4 frames per second were obtained, and even in tests with "an out-the-window view without the runway, buildings, or other terrain visible" no more than 10 fps could be achieved.
An additional research goal had been to network the PC and IRIS together, and to have them run dog interoperably. This was not achieved in the time available. One problem was that ESIX's UDP/IP support did not support programming below the OSI transport layer, unlike SGI's.




= 1991

=
Code from the SGI flight simulator was incorporated into a project to develop a low-cost flight simulator using object-oriented programming techniques and the C++ language.




= 1992

=
Another group of researchers modified flight to log the actions of the human "pilot", and to use these logged actions as input to an "induction program". This program would use machine learning to create an autopilot for a specific flight plan. The researchers chose the Cessna as their plane, stating that it was easier to learn how to fly the Cessna than any of the others. They also claimed that the rudder did not have "a realistic effect on the aircraft", although it is not clear if this claim applied only to the Cessna or to any/all of the other planes available. A poster on comp.sys.sgi had previously noted that the rudder would have a significant effect on a real-life Cessna, but had very little effect on the simulated Cessna of the flight program, and almost no effect on the other simulated planes in flight.
The researchers noted that the flight simulator was non-deterministic, since it "runs on a multi-tasking Unix system, not on a dedicated real-time system. Thus, it is not possible to give a guaranteed real-time response because the flight simulator can be interrupted by other processes or I/O traffic." This meant that simply repeating the same set of inputs across multiple runs of the flight simulator would not be guaranteed to give the same results. The researchers hoped that the work they had done in addressing this problem would later be applicable to real-world situations, such as the effects of varying wind conditions on a plane.




See also


Airfight flight simulator (1974)
Microsoft Flight Simulator (1982)




References






External links


[1] An episode (Series 1, Episode 16) of PBS's Computer Chronicles, in which a Silicon Graphics employee demonstrated flight on an SGI Iris.
[2] The same episode, hosted on the Internet Archive.
[3] A video showing version 2.4 of flight and various other demos running on an SGI Indigo. The Boeing 727 and F-14D are not available to select as planes, suggesting that this is not the GT/GTX/VGX version.
[4] A video showing version 3.4 of flight for the GT/GTX/VGX running on a later model of Indigo, with IRIX 5.3.
History of IRIX Archived 17 April 2022 at the Wayback Machine. Additional archives: 31 July 2021.
IRIS users discussion list archive, 1988
Unix Manual Page from SGI IRIX version 6.5
Unix Manual Page including references to an earlier version of the game, before multicasting was added.
A downloadable Windows port of version 3.4.1, plus source for version 2.4. The port is dated April 4, 1997 and has its own version number of 1.01. It is a port of the GT/GTX/VGX version. The source code appears to be source for the other version, since the 727 and F-14D are not selectable.
The source code for a 2018 port of flight v2.4 to custom ARM hardware.
A forum posting describing two undocumented features in at least one version of flight Archived 7 May 2022 at the Wayback Machine. Additional archives: 7 May 2022.
A download link for a compiled binary of version 2.4. This was probably compiled for an Iris3000 target, and is not the GT/GTX/VGX version.
Cadiz, J.; Ouyang, R.; Thompson, J. (5 October 1989). Interfacing of the Silicon Graphics Networkable Flight Simulator with SIMNET; (citation information). University of Central Florida Orlando Institute for Simulation and Training. Accession number ADA241023, publication number IST-TR-89-1.
suggested mods for "dog" (a forum posting by a former commercial pilot containing detailed discussion of in-game physics and the behaviour of the simulated planes) Archived 20 August 2022 at archive.today

Kata Kunci Pencarian:

• SGI Dogfight
• Dogfight (disambiguation)
• List of free flight simulators
• Airfight
• History of online games
• Oolite (video game)
• SCO Group