SGI Dogfight

Dogfight
Company type	Demonstration software
Industry	Software, Computer graphics, Networking
Founded	1983
Founder	Gary Tarolli
Headquarters	Silicon Graphics, Inc, United States
Products	Flight (flight simulator), Dog (multiplayer aerial combat game), Shadow (observer tool)

Adapted from the English Wikipedia article SGI Dogfight, available under CC BY-SA 4.0Updated 8 August 2025

Dogfight is a demonstration software developed by Gary Tarolli—who would later establish 3dfx—while at Silicon Graphics, Inc in 1983. It represents a significant milestone in the evolution of Internet gaming and multicast networking, contributing to advancements in rendered virtual environment technology.

Overview

The Dogfight package consists of three components: flight, a flight simulator application; dog, a multiplayer aerial combat game utilizing the flight interface; and shadow, an observer tool that displays the perspectives of users engaged with either dog or flight.

Both dog and shadow incorporate an "airshow mode" accessible through command-line options. This mode allows flight trajectories to be recorded to or played back from files, facilitating the capture and replay of intricate aerial maneuvers without interrupting ongoing gameplay.

A -h option introduced a head-up display (HUD), which replaced the conventional instrument panel with a larger visual field at the expense of slower refresh rates. This feature was developed in response to interest from Williams Air Force Base for F-16 pilot training and human factors research, requiring a HUD interface similar to that found on actual F-16 aircraft.

The available aircraft roster included:

Cessna 150
P-38 Lightning
Boeing 747
F-16
F-15 (in some iterations resembling an F-14 due to swept wing design)
F-14D (with wings folded)

Subsequent releases introduced:

refined F-16 model geometry
F-18
Boeing 727

History

In the summer of 1983, Gary Tarolli created Flight as a demonstration program for SGI workstations, drawing inspiration from the Blue Angels airshows near SGI’s initial headquarters. Networking capabilities were added in 1984, initially linking two workstations via serial cable, achieving approximately seven frames per second and rendering around 500 polygons per second on a Motorola 68000 CPU (~1 MIPS). By SIGGRAPH 1984, support for XNS multicast enabled gameplay over Ethernet networks. This networked iteration allowed participants to observe other players’ aircraft but lacked interaction features.

By early 1985, development of dog commenced, and both dog and flight were distributed as demonstration software with SGI workstations. Due to message packets being sent at frame rate, bandwidth constraints limited the number of simultaneous players—estimates vary from around ten up to several dozen. Network congestion prompted some system administrators to restrict or remove access to dogfight to prevent excessive resource consumption. To alleviate data transmission loads, dead reckoning techniques were later incorporated.

In 1986, a UDP broadcast protocol operating on port 5130 was implemented, sending data via broadcast packets synchronized with frame updates. This heavy network usage hindered Internet playability since routers typically blocked UDP broadcasts, despite Dogfight being among the earliest titles utilizing the Internet Protocol Suite.

By 1988, with the release of SGI’s 4D series, Dogfight was divided into two editions: one compatible with most SGI machines (including the 3000 series, 4DxxG models, Personal IRIS, GT, GTX) and another designed for higher-end GT, GTX, and VGX systems. Both versions could interoperate within the same session. Performance ranged from roughly 12 fps on a 4D/20 up to 20–25 fps on a 4D/70; the GT variant typically ran near 15 fps. The enhanced version incorporated additional aircraft such as the Boeing 727 and F-14. SGI provided source code access to IRIS owners under NDA; some sources mention a $100 charge for a software exchange tape containing the code, while others indicate no fee if users supplied blank tapes.

Numerous developers leveraged this codebase to acquire experience with UDP programming.

Around IRIX 3.3’s release (circa 1989), IP multicast support was added, enabling compatible hosts with multicast capability on the Internet to participate in games—though such setups were uncommon. The multicast address assigned was 224.0.1.2 (SGI-DOG.MCAST.NET), making it one of the earliest applications allocated an official multicast address. SGI later repurposed this address for their objectserver daemon responsible for managing GUI icons, which occasionally caused confusion among network administrators.

Unofficial derivative versions

A number of SGI users created their own unofficial adaptations of the original flight program, taking advantage of its open-source availability.

Point-to-point communication variant

At Sweden's Lund Institute of Technology, a modified edition replaced the UDP broadcast mechanism with direct point-to-point communication between two machines. In September 1989, a patch was shared on comp.sys.sgi enabling gameplay across separate subnets. This adaptation likely aimed to alleviate network traffic and was developed before multicast functionality was incorporated into the official software.

Air traffic control server and alternative TCP/IP adaptation

Prior to 1988, the US Army's Ballistic Research Laboratory (BRL) utilized an XNS-based version of the program, which did not align with their network infrastructure. Engineer Ron Natalie modified the source to implement a TCP/IP variant featuring a centralized server with an "air traffic control" style interface.

This BRL-derived fork appears to have been developed independently, with no indication that its code or networking approach influenced SGI’s official release or employed the same port number (5130). A server application named atc (Air Traffic Control) for dog was mentioned on comp.sys.sgi in November 1988, likely referring to Natalie's iteration. There is no evidence that this functionality was incorporated into the official product line.

Ports for Sun Microsystems systems

A 1992 discussion on rec.aviation.simulators referenced a port of dog/flight to pixrect, a low-level raster graphics library used on Sun platforms. This version was described as an unauthorized copy of SGI’s flight/dog software, noted for rapid networked dogfighting but causing congestion on LANs. Another Sun port compiled specifically for Sun’s SPARCstation hardware was also mentioned.

In 1990, a post on comp.sys.sgi reported a Sun port running on a color GX Sparcstation; however, it lacked polygon filling, which diminished visual realism. It remains unclear whether this was a distinct port or related to previously mentioned versions. The source combined original SGI code with an SGI graphics emulation library but was reportedly distributed in breach of an NDA.

Science fiction craft, World War I airplanes, and the X-29

In 1993, a user referenced a 'flight' version featuring X-wing and TIE fighter models as seen in SGI’s 1987 "IRIS Universe" magazine. NASA’s Langley Research Center confirmed operating this version on an SGI 3130 system, which included additional vehicles and armaments:

X-wing equipped with lasers
TIE fighter armed with lasers, piloted by Snoopy
Grumman X-29 outfitted with conventional weaponry
Sopwith Camel, flown by Snoopy
Fokker Tri-Plane, also piloted by Snoopy
Klingon battlecruiser from Star Trek: The Original Series, armed with phasers and photon torpedoes

Only a compiled executable existed; no source code was available.

In 1994, someone claimed to have created this modified edition and offered the source code "for a price," mentioning it might require updates for compatibility with newer hardware. This assertion has not been verified.

Earlier accounts noted that the Klingon vessel could cause persistent terrain deformation, producing "craters in the Earth." Lead developer Rob Mace indicated this version originated "from a university," but due to copyright limitations involving Snoopy and sci-fi elements, SGI was unable to distribute it. The Klingon ship reportedly possessed unlimited top speed and could not stall.

Developers

The IRIX 6.5 manual from around 1998 acknowledges the following principal contributors:

Gary Tarolli (Initial creation)
David "Ciemo" Ciemiewicz (Handled network communications and UDP broadcast programming) alongside Andrew Cherenson (IP multicast implementation)
Rob Mace (Lead developer by 1989; responsible for the IRIX 6.5 edition; credited with designing the F-14 geometry; also co-credited with Thad Beier for the F-18, Marc Ondrechen for the 727, and Marshall Levine for the updated instrument panel)
Barry Brouillette (Contributor; developed geometry for the F-16 and P-38)
Marshall Levine (Contributor; collaborated with Rob Mace on the instrument panel)
Thad Beier (Collaborated with Rob Mace on F-18 geometry)
Marc Ondrechen (Partnered with Rob Mace on 727 geometry)
Sound design created by Chris Perry and Chris Schoeneman

The "city of lights"

A 1991 Usenet conversation clarified that the "interesting city" located north-northwest of the airport, as referred to in the manual, does not physically exist. Instead, nighttime lighting effects simulate an urban landscape in that vicinity.

SAM threat cones

Within gameplay, pressing 'T' (shift + 't') reveals wireframe domes surrounding small brown blocks situated in the swamp area, representing surface-to-air missile (SAM) installations and their associated threat zones. This visual feature was introduced following a request from Williams Air Force Base during earlier updates but was never documented officially. The game itself lacked functionality to launch SAMs from these sites; it only displayed their threat areas. However, a derivative version—likely developed by personnel at Williams AFB—included active SAM launches; a copy of this iteration was reportedly held by the University of Calgary. A Usenet message mentioned multiple flight versions, including one featuring Gouraud shaded aircraft running on the IRIS Power Series.

Officially, SAMs were incorporated later but exclusively in the "low end" version, excluding GT/GTX/VGX editions. In this update, SAMs were non-interceptable, accelerated faster than player-fired sidewinders, and self-destructed after 10 seconds when out of fuel. If a weapon was airborne during a SAM launch, it was immediately destroyed, preventing further weapon deployment until the SAM threat was eliminated.

A German user reportedly obtained access to one of these versions, though which specific build remains uncertain.

Yaw and roll coupling

The game’s physics engine did not simulate yaw/roll coupling. Although Tarolli recognized its existence, he lacked the necessary equations and empirical data to implement it accurately. He was uncertain about how wing shape would influence this coupling or its intensity across different wing configurations, which prevented him from coding this feature.

Stall and spin

Some players criticized the stall and spin mechanics, arguing that stalls occurred less frequently and under fewer conditions than in reality, often exhibiting unrealistic behavior. Tarolli responded by explaining that while minor stalls could be anticipated, violent stalls were unpredictable. Accurately modeling minor stalls would require tailored equations for each wing design and involve complex computations that might significantly degrade game performance.

One defender noted that flight and dog were intended as entertaining games rather than strict simulations. They highlighted that relevant aerodynamic phenomena are frequently described only qualitatively in literature, complicating precise programming efforts. Tarolli acknowledged not simulating authentic stalls but incorporated random spins during severe stalls to improve gameplay enjoyment, stating 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."

1989

In 1989, researchers connected the flight simulator to the US military's SIMNET system. They converted SG "Dogfight" data packets captured over Ethernet into SIMNET-compatible packets and forwarded them to SIMNET M1 tank modules. The simulation operated on a Silicon Graphics 4D/70GT workstation.

1990

A researcher from the US Air Force Institute of Technology sought to cut flight simulator expenses by integrating a head-mounted display with a PC-based simulation platform. The flight simulator was adapted to run on a 20MHz 80386 PC equipped with an 80387 coprocessor and a Real World Graphics PC Reality board containing two Intel i860 RISC processors, under ESIX (a System V UNIX derivative). The PC system also incorporated head movement tracking.

To preserve portability, the software was maintained in C, emulating SGI hardware graphics calls through the PC Reality board’s library. Aircraft tested included the F-14D, F-16, and a simplified polygon model of the Cessna C150. Rendering complications arose with the F-15 model when multiple aircraft appeared simultaneously.

The project required a minimum of 15 frames per second using Z-buffered, flat-shaded polygons. Performance benchmarks were compared against the Silicon Graphics IRIS 4D/85GT running the original unmodified simulator, which utilized both modern and legacy SGI graphics pipelines.

The attempt was unsuccessful: essential SGI features were either omitted or substituted; wing stall behavior and G-force limitations were not enforced; collision detection was removed, permitting unrealistic flight maneuvers. The PC Reality board delivered poor performance, achieving only 4fps on average (peaking at 10fps in minimal scenes), failing to support claimed polygon counts or frame rates. Its 3D graphics method lacked direct screen coordinate writes, causing significant issues.

Networking between the PC and IRIS systems to enable interoperable dog sessions also failed due to ESIX's limited UDP/IP capabilities compared to SGI’s implementation.

1991

In 1991, code derived from the SGI flight simulator was utilized to create an affordable flight simulator developed with object-oriented programming techniques using the C++ language.

1992

By 1992, researchers had enhanced flight to record pilot inputs and apply machine learning algorithms for generating autopilot functions tailored to specific flight routes. The Cessna model was selected for its relative ease of operation; however, it was noted that the rudder's influence in the simulation was less pronounced than in real-world flying. Running on a multitasking Unix system introduced non-deterministic behavior with variable response times due to system interruptions. This variability underscored potential applications for managing real-world factors such as fluctuating wind conditions.

External links