Graphics and Music Challenges for Classic-Style Computer Applications

This version of the document is dated 2026-03-17. Post an issue or comment on this document.

The following are challenges I make to the computer community, relating to:

All may interest 1990s computer users.

Contents

Graphics Challenge for Classic-Style Games

An interesting challenge for game developers, relating to designing games with classic graphics that run on an exceptional variety of modern and recent computers.

In this document, classic graphics generally means two- or three-dimensional graphics achieved by video games from 1999 or earlier, before the advent of programmable “shaders”. For details, see “Classic Graphics in Scope”, later. (To summarize: In general, a game screen of 640 × 480 or smaller, up to 12,800 3-D polygons at a time [fewer if the game screen is smaller], and tile- or sprite-based 2-D graphics are involved.)

This challenge is intended to encourage the making of video games with very low resource requirements (say, no more than 64 million bytes of system memory); most desktop and laptop computers from 2010 on, and most smartphones from 2016 on, can draw even high-quality pre-2000 graphics using only software — without relying on specialized video cards — at 640 × 480 pixels or smaller, screen resolutions typically targeted by video games in the 1990s and earlier.1

The challenge sets an upper bound on the kind of computer graphics that are of interest. Further constraints to graphics computation (such as memory, resource, color, resolution, or triangle limits) are highly encouraged. It is also encouraged to write a free and open-source graphics engine2 or establish a lean programming interface for this graphics specification. For details, see “Lean Programming Interfaces for Classic Graphics”.

The Specification

Define the larger screen dimension as the larger of the screen width and the screen height.

Limit 3-D graphics to the following:3

  1. The maximum number of primitives that can be shown at a time is equal to screen width times screen height divided by 24.4 (See also survey project in “Other Challenges and Projects”, later.)
    • A primitive is either a triangle or a line segment. An application may also consider a convex quadrilateral to be a primitive.
    • Each vertex of the primitive points to a vertex from the vertex list described later.
    • Each primitive can be translucent.
  2. The maximum number of vertices that can be displayed at a time is 3 times the maximum number of primitives.
    • A vertex consists of an XYZ position, an XY texture coordinate, and a red–green–blue vertex color.
    • Each vertex color follows this color format: The red, green, and blue components occupy up to 5 bits each.5
  3. Each texture (an image that is applied to the surface of 3-D objects)—
    • is in a 16-bit-per-pixel format, where each pixel has the vertex color format given earlier, or
    • is in a 1-, 2-, 4-, or 8-bit-per-pixel format and has a table of colors with that color format.
  4. The width and height of each texture are each powers of 2.
  5. A texture’s maximum width and maximum height, in pixels, are each equal to 256 or the larger screen dimension, whichever is smaller.
  6. Textures may contain transparent pixels.
  7. Textures should not be “pixelated” before the game uses them. A “pixelated” image occurs when an image is enlarged with point filtering (also called nearest-neighbor filtering), with the result that some or all of the resulting image’s rows and columns are repeated.
  8. For 3-D graphics, Z buffering (depth buffering), flat shading, Gouraud shading, per-vertex specular highlighting, per-vertex depth-based fog, line drawing, two-texture blending, MIP mapping, source alpha blending, and destination alpha blending are supported.6 Bilinear filtering and edge antialiasing (smoothing)7 are optional.
  9. The 3-D graphics buffer’s resolution is the same as the “screen resolution”.
  10. 3-D primitives should undergo perspective correction, but this is optional.8

Example: For a “screen resolution” (see later) of 640 × 480 pixels, no more than 12,800 primitives (640 × 480 / 24) and 38,400 vertices can be shown at a time, and the maximum texture size is 256 × 256 pixels. For 320 × 240 pixels, the maximums are 3200 primitives, 9600 vertices, and textures of 256 × 256 pixels. For 320 × 200 pixels, the maximums are 2666 primitives, 8000 vertices, and textures of 256 × 256 pixels.

Limit 2-D graphics to the following: 9

  1. Layers:
    1. Up to four 2-D layers can be displayed at a time. Each 2-D layer is a rectangular array of references to tiles (see later), and can also be called a tile map.
    2. Up to two of the 2-D layers can undergo a 2-D affine transformation.
    3. If 3-D graphics are being displayed, one of the 2-D layers is replaced with a 3-D layer, which is an image on which the 3-D graphics are drawn. The 2-D layer replaced this way can vary over time.
    4. The 2-D layers may contain transparent pixels. The 3-D layer may contain transparent and translucent (semitransparent) pixels.10
  2. Tiles. A tile is a small rectangular array of pixels.
    1. Every tile has the same width and the same height as every other. The width must be 32 or less, and the height must be 32 or less.
    2. The application chooses one:
      1. Each tile is in a 1-bit-per-pixel format and uses one of 16 color tables, with 2 colors per table.
      2. Each tile is in a 2-bit-per-pixel format and uses one of 16 color tables, with 4 colors per table.
      3. Each tile is in a 4-bit-per-pixel format and uses one of 16 color tables, with 16 colors per table.
      4. There is a single 256-color table for use by tiles. Each tile is in an 8-bit-per-pixel format.
    3. Each color in each color table used by tiles is of the vertex color format given earlier.
    4. Tiles may contain transparent, but not translucent, pixels.
    5. Tiles should not be “pixelated” before the game uses them.
    6. When referenced in a 2-D layer, a tile can be horizontally flipped, vertically flipped, or both.
  3. Sprites. A sprite is a rectangular array of either tiles or pixels.
    1. Each sprite has up to X × Y pixels, where X and Y are each 1/4 the larger screen dimension, rounded up to the nearest power of 2. (An alternative limit is X = 64 and Y = 64.)
    2. Besides the previous point, sprites can have any width and height.
    3. Each sprite made of pixels (rather than tiles) has a pixel format allowed for 3-D textures, given earlier, and may contain transparent, but not translucent, pixels.
    4. Each sprite can be drawn above or below any of the 2-D or 3-D layers.
    5. The application chooses one:
      1. Each sprite can undergo a 2-D affine transformation.
      2. Each sprite can be horizontally flipped, vertically flipped, or both.11
      3. No affine transformation or flipping of sprites is allowed.
    6. Sprites should not be “pixelated” before the game uses them.
    7. Up to N sprites can be displayed at a time, where N is calculated as (screen width × screen height × 16) / (X × Y), rounded up, but not more than 512.12

Note: The suggested width and height for tiles is 8 pixels × 8 pixels.

Example: For a “screen resolution” (see later) of 640 × 480 pixels, one choice is: 4-bit-per-pixel tiles, 8 × 8 tiles, sprites up to 160 × 160 pixels, no more than 192 sprites at a time, and no flipping or transformation of sprites.

Other requirements:

Classic Graphics in Scope

This specification for “classic graphics”15 in modern games largely reflects the graphics limitations of—

In addition, video-game graphics for personal digital assistants, graphical calculators, and cellular phones (generally those released before 2007) are within the spirit of this specification, up to the performance of consumer PCs released before 2000.16

Some video game hardware from the late 1990s may have 3-D graphics capabilities beyond what is “classic” here, such as SEGA Model 3 (1996), SEGA NAOMI (1998), or NVIDIA GeForce 256 (late 1999).

In general, PC applications that feature classic graphics include:

  1. Windows applications written for DirectX versions earlier than 7 and using Direct3D or DirectDraw for graphics.
  2. Windows games using GDI or WinG for graphics and supporting Windows 98 or earlier. Examples are Chip’s Challenge for Windows (1992) and Brian Goble’s The Adventures of MicroMan (1993).
  3. Games for MS-DOS or PC-9801 that were published before 2000. Examples are Quake (1996), WarCraft (1994), and the first titles of the Touhou Project series (1997-1998).
  4. Games using OpenGL 1.2 or earlier for graphics.
  5. So-called “multimedia titles” from the 1990s, or applications resembling interactive versions of books (generally reference and other nonfiction works), complete with sound, animation, and video. See the Authoring Guide that came with Microsoft’s Multimedia Development Kit.

One of the following games can be considered an upper limit to what is considered “classic graphics” in this specification.

Optional Limits

A game may impose further constraints to this specification (for example, to reduce the maximum number of 3-D triangles, to disallow 3-D graphics, to reduce the number of colors per tile allowed, or to reduce to a limited set the colors ultimately displayed on screen). I would be interested in knowing about these limitations that a new game that adopts this document decides to impose.

Examples of optional constraints are the following:

Notes on Specification

This section has notes on this specification, such as how its requirements correspond to the graphics abilities of pre-2000 video games.

Screen resolutions

Frame rate

3-D graphics

Screen image effects (filters)

Sounds

Memory

Seeking Comments

As with the rest of this open-source article, comments on this specification are welcome. But most useful would be comments that improve or refine the specification to fit the graphics abilities of pre-2000 video games.

Examples are comments that give measurements (or references to other works that make such measurements) on the graphics capabilities (for example, polygons shown each frame, average frame rate, memory use, sprite count, etc.) actually achieved by video games released in 1999 and earlier (or released in, say, 1994 or earlier) for home computers or game consoles. (I repeat: measurements, not inferences or guesses from screenshots or videos.)

This includes statements like the following, with references or measurements:

(Those statements will also help me define constraints for video games up to an earlier year than 1999.)

Statements like the following are also useful, with references:

By contrast, statements like the following are not very useful, since they often don’t relate to the actual performance of specific video games:

The following are examples of the kind of statements desired:

Further Reading

Building a Public-Domain music synthesis library and instrument banks

To improve support for MIDI (Musical Instrument Digital Interface) music playback in open-source and other applications, I challenge the community to write the following items, all of which must be released to the public domain or under the Unlicense.

Other Challenges and Projects

Other challenges and projects I make to the computer community.

Classic desktop wallpaper

See the “peteroupc/classic-wallpaper” repository for a challenge on creating tileable desktop wallpapers with a limited selection of colors and limited dimensions in pixels — such wallpapers are getting ever harder to find because desktop backgrounds today tend to cover the full computer screen, to employ thousands of colors, and to have a high-definition resolution (1920 × 1080 or larger).

Button and border styles for classic interfaces

See “Traditional User-Interface Graphics” for a challenge on writing computer code (released to the public domain or under the Unlicense) to draw button and border styles for classic graphical user interfaces.

Sound bank development guide

Write an open-source and detailed guide on using free-of-cost software to produce decent-quality instrument banks from the recordings of real musical instruments (rather than copying or converting other instrument banks or recording from commercial synthesizers). See the section on building instrument banks, earlier. For this purpose, a sound bank in SoundFont 2 or Downloadable Sounds format that is of decent quality is about 4 million bytes in size.

Guide for creating 3-D models in the pre-2000 style

Develop a guide for creating 3-D models for use in modern video games that follow the specification given earlier on classic (pre-2000) 3-D graphics, in a similar vein to “Game-Ready 3D Models: Requirements, Creation, and Export” (which was designed for high-system-resource games from 2024 or so). Notably, no shader-based techniques should be required for any such models, and advice should apply to models for a game just as though the game were developed in 1999 (or an earlier year) rather than today, but the use of modern creation tools is allowed. (For example, instead of normal, roughness, or ambient-occlusion maps, late-1990s 3-D game models typically employed light maps and bump maps, and such models were generally much coarser than today’s models.)

License

Any copyright to this page is released to the Public Domain. In case this is not possible, this page is also licensed under Creative Commons Zero.

Notes

  1. A computer has adequate performance for classic graphics if it achieves a score of—
    (a) 3108 or more 3D marks on the 3DMark2000 benchmark (640 × 480) when run without graphics acceleration, or
    (b) 195 or greater on the 3DMark2000 CPU speed test.
    Both figures correspond to the running of two graphically demanding 3-D demos, at three levels of detail each, at 60 frames per second (adjusted downward as needed if a demo’s detail level averages more than 12,800 triangles per frame; see the section “Test Descriptions” in the 3DMark2000 help).

    The games this challenge encourages are those with very low resource requirements, namely those that can run with acceptable performance even on very low-end computers, say, those that date from 2010 or earlier or support Windows 7, Windows XP, or an even older operating system. In this sense, even though today’s Unity and Unreal game engines can allow the making of games with “classic graphics”, they are far from lightweight and their use is not within the spirit of this challenge. ↩

  2. The following are examples of a graphics library that follows the spirit, even if not the letter, of this specification: Tilengine, kit, DOS-like, raylib’s rlsw software renderer. Michal Strehovský published an interesting technique to create small game applications, and so did Jani Peltonen.
    I offer a template for Win32 applications that supports 8- and 24-bit-per-pixel game images and paints finished game images using StretchDIBits. ↩

  3. One editor specialized for creating classic 3-D models is the open-source tool Blockbench. For classic 3-D scenes, there is the open-source tool Trenchbroom. ↩

  4. This is also known as visible primitives or visible primitives per frame; in the case of polygons or triangles, this is also called visible polygons (per frame) or visible triangles (per frame). ↩

  5. If there is interest, this format may instead be: The red and blue components occupy 5 bits each; the green component, 6 bits. ↩

  6. Quake (1996) also employed subdivision rasterization for drawing small and relatively distant triangles whose vertices are rounded to integers, an algorithm likewise in scope here (Abrash (1997), chapter 69). ↩

  7. Antialiasing “didn’t appear in home console graphics architectures until the debut of the [Nintendo 64] in late 1996”. Tricks of the Mac Game Programming Gurus (1995) considers antialiasing among the features “unlikely” to be needed in game programming ↩

  8. Perspective correction accounts for distance from the viewer: closer objects appear larger. The lack of perspective correction (as in what is called affine texture mapping), together with the lack of smoothing (antialiasing) of edges, contributed to the characteristic distortion and instability of 3-D graphics in many PlayStation (One) games. ↩

  9. It is being considered whether to replace these 2-D limits with one of the following alternatives:

    1. Instead of tiles, sprites, and layers, the game uses a frame buffer (array of color samples, called pixels, in computer memory) with no more than 8 bits per pixel (no more than 256 simultaneous colors) and all graphics in the game must be rendered in software. But I don’t know of a way to describe further restrictions useful for game programming in the mid- to late 1990s style.
    2. The 2-D limits in the specification apply, but instead of replacing a 2-D layer, the 3-D layer is simply a special sprite that covers the game screen (the usual size limits for sprites don’t apply) and can have transparent and translucent pixels.
    3. Same as (2), but in addition, there are no tiles or 2-D layers (all the graphics are sprites).

    The tile-based limits in this specification also suit games that support only text display, and thus have graphics that resemble the text modes (as opposed to graphics modes) found in PCs and computer terminals. ↩

  10. Translucent pixels enable alpha blending techniques (the mixing of one image with another). But alpha blending was “relatively new to PC games” at the time of Quake’s release in 1996, according to Abrash (1997), and is practically not discussed at all in Tricks of the Mac Game Programming Gurus (1995). Only images with opaque and/or transparent pixels tended to be supported in early-1990s video games. ↩

  11. SEGA arcade machines from the 1980s and earlier had rudimentary systems for scaling (stretching or shrinking) sprites horizontally and vertically. In the Super Famicom/Super Nintendo Entertainment System (1990), sprites could not be scaled, but they could be flipped. ↩

  12. Tile- and sprite-based graphics were in place largely because they saved memory; they were popularized by the arcade game Galaxian. Indeed, this system, present in the Nintendo DS and many earlier game consoles, was abandoned in the Nintendo 3DS in favor of a frame buffer.
    Game consoles employing tile-based graphics tended to limit not only the number of sprites per frame, but also the number of sprites per row of pixels, but a per-row limit is not adopted here. As for the per-frame limit, the Famicom/Nintendo Entertainment System (1983), SEGA Master System/SEGA Mark III (1985), and PC Engine/TurboGrafx 16 (1987) had a limit of 64 sprites; the Game Boy (1989), 40; the SEGA Mega Drive/Genesis (1988), 80; the Super Famicom/Super Nintendo Entertainment System (1990), 128; and the relatively expensive Neo Geo (1990), 381. ↩

  13. If the game screen image uses two colors only (such as black and white), the game could choose to allow it to have up to 800,000 total pixels. For example, a 1024 × 768 display has 786,432 total pixels. However, two-color graphical display modes larger than 307,200 total pixels are probably rare among consumers. The modern game Return of the Obra Dinn employs a two-color 800 × 450 display (378,000 total pixels).

    In the Godot engine, the screen resolution corresponds to the “Viewport Width” (window/size/viewport_width) and “Viewport Height” (window/size/viewport_height) project settings. For the Unity engine, there is advice from 2019 relating to the graphics style in “8-bit” and “16-bit” game consoles. In Unreal Engine, the screen resolution apparently corresponds to ResolutionSizeX and ResolutionSizeY. But a lighter-weight graphics engine than Unity, Unreal, or even Godot would better suit the spirit of this specification. ↩

  14. Standard MIDI files should be played back using a cross-platform open-source software synthesizer (see section “Building a Public-Domain music synthesis library and instrument banks”), using either FM or wave-table synthesis; most modern PCs no longer come with hardware synthesizers. I note that it’s possible to write an FM software synthesizer supporting every MIDI instrument in less than 1024 kibibytes of code.
    Standard MIDI files organize MIDI commands into up to 16 channels, each occupied by at most one “instrument” at a time. Under the Multimedia PC Specification (1992), the first ten channels were intended for high-end synthesizers (where the tenth is percussion); the thirteenth through sixteenth, for low-end ones (sixteenth is percussion), and the nonpercussion channels were arranged in decreasing order of importance. This convention was abandoned with the rise in support for the General MIDI System level 1 (see Q141087, “DOCERR: MarkMIDI Utility Not Provided in Win32 SDK”, in the Microsoft Knowledge Base): now all 16 channels are supported (with only the tenth for percussion) and need not be arranged by importance. ↩

  15. Matt Saettler, “Graphics Design and Optimization”, Multimedia Technical Note (Microsoft), 1992, contains a rich discussion of graphics used in computer games and other audiovisual computer applications up to 1992. Not mentioned in that document are graphics resembling:
    (1) Segmented liquid crystal displays, of the kind found in Nintendo’s Game & Watch and many Tiger Electronics handheld games. These are simple to emulate, though: design a screen-size image that assigns each segment a unique color and, each frame, draw black where where the segments that are “on” are, and draw white (or another background) elsewhere on the screen.
    (2) Vacuum fluorescent displays, notable in user interfaces of some media player applications that resemble a “stereo rack system”. ↩

  16. Examples are the Sharp MI-Zaurus (2000) and the many cellular phones that came with Java 2 Micro Edition (J2ME). ↩

  17. An example is Loom (1990). ↩

  18. This was recommended for Macintosh games in J. McCornack et al., Tricks of the Mac Game Programming Gurus (Hayden Books, 1995), notably because 8-bit-per-pixel images transfer faster and save memory over images with more bits per pixel; see also chapter 70 of Abrash (1997) (dealing with the porting of an 8-bit-per-pixel game to a 16-bit-per-pixel video card). ↩

  19. Popular file size limit of so-called “64K intros”. ↩

  20. MS-DOS applications are normally limited to 640 kibibytes or less of conventional memory, along with whatever memory is carried by the video card. (PCs running on the very early Intel 8086 and 8088 processors can map out no more than 640 kibibytes of system memory.) 262,144 bytes is the usual minimum of graphics memory for VGA video cards. ↩

  21. It wasn’t until the Pentium processor’s advent that floating-point arithmetic was embraced in 3-D game programming: for example, see chapter 63 of Abrash (1997). ↩

  22. In addition to the resolutions shown here, there are modern games that employ low resolutions with the same 16:9 aspect ratio as high-definition displays. These include 640 × 360 (Blasphemous); 400 × 225 (Unsighted); 480 × 270 (Enter the Gungeon); 320 × 180 (Celeste). ↩

  23. VGA mode 12h (16 colors). ↩ ↩2

  24. PlayStation (One); Nintendo 3DS lower screen; larger VGA “mode X” (256 colors). ↩ ↩2

  25. Commodore 64; NEC PC-8001; VGA mode 13h (256 colors), especially seen in MS-DOS games; Color/Graphics Adapter (CGA) 4-color mode; Atari ST 16-color mode; Amiga NTSC. ↩ ↩2

  26. One commonly supported “super-VGA” mode, especially in mid-1990s gaming, and which was also recommended by the PC 98 System Design Guide. ↩

  27. One low resolution recommended by the PC 98 System Design Guide. ↩

  28. Nintendo DS; NEC PC-6001; SEGA Master System/SEGA Mark III; MSX; Colecovision. ↩

  29. Rarely used VGA display mode. ↩

  30. PlayStation 2 NTSC. ↩

  31. SEGA Mega Drive/SEGA Genesis; Neo Geo NTSC. ↩

  32. Effective resolution of Famicom/Nintendo Entertainment System NTSC; Super Famicom/Super Nintendo Entertainment System NTSC; minimum resolution of PC Engine/TurboGrafx 16. ↩

  33. Nintendo Entertainment System PAL; Super Nintendo Entertainment System PAL. ↩

  34. Game Boy Advance. ↩

  35. Game Boy, Game Boy Color, SEGA Game Gear. ↩

  36. Aspect ratio found above all in PAL (phase-alternating-line) displays. The resolution 640 × 512 (PlayStation 2 PAL), included in this category, covers more than 307,200 total pixels. ↩

  37. Amiga PAL (same pixel spacing horizontally as vertically); Neo Geo PAL. ↩

  38. PAL overscan. ↩

  39. Hercules Graphics Card two-color. ↩

  40. Color/Graphics Adapter (CGA) two-color; NEC PC-8801 8-color mode; Atari ST 4-color mode. ↩

  41. 12-inch classic Macintosh. ↩

  42. 16 colors. ↩

  43. NEC PC-9801 8-color mode; Atari ST two-color. ↩

  44. Apple II. ↩

  45. PlayStation Portable. ↩

  46. MSX 2. ↩

  47. Effective resolution of Nintendo 3DS upper screen without parallax effect. ↩

  48. Virtual Boy. ↩

  49. One “Tandy graphics adapter” mode. ↩

  50. Minimum resolution for “handheld PCs” (Windows CE Programmer’s Guide, MSDN Library, June 1998). ↩

  51. S. Pruitt, “Frequently Asked Questions About HTML Coding for Internet Explorer 3.0”, updated Jan. 30, 1997. ↩

  52. Fabien Sanglard, Game Engine Black Book: Doom. ↩ ↩2

  53. Until the early 1990s, the number of color samples (pixels) an application can transfer per second was usually small, limiting the supported size and frame rate for arbitrary video content. Indeed, for example, the Multimedia PC Specification (1992) recommended that video cards be able to transfer up to 8-bit-per-sample graphics at a rate of 140,000 samples per second or faster given 40 percent of CPU bandwidth. The Multimedia PC level 2 specification (1993) upped this recommendation to 1.2 million samples per second (sufficient for 320 × 240 video at 15 frames per second, the recommendation in article Q139826, “AVI Video Authoring Tips & Compression Options Dialog Box”, 1995). For details on these specifications, see article Q106055 in the Microsoft Knowledge Base. Both recommendations are far from the 6.144 million samples per second needed to display 640 × 480 video smoothly at 20 frames per second. ↩

  54. Stands for the National Television Standards Committee of the Electronics Industries Association. “NTSC” often refers to the video standard known as RS-170A. ↩

  55. Stands for phase alternating line. ↩

  56. By contrast, 3-D video cards have been offered for professional-use computers since the mid-1980s; the first such cards for PCs that supported real-time display were introduced in 1988. ↩

  57. CRT displays, or cathode-ray-tube displays, were the typical kind of computer monitors and TVs in the 1980s and 1990s. ↩

  58. Effects to scale the game screen include so-called “pixel-art scaling algorithms” such as HQX and 2xSaI, as well as bilinear or point filtering.
    Effects to scale the game screen do not include the decoding of small videos to fit the game screen, as opposed to the player’s display. It was common for 1990s games to have videos smaller than the game screen and to scale those videos to fit the game screen “on the fly”, in the process of displaying them. For example, such a game could decode videos of size 160x100 to fit a game screen of 320 × 200. (See, for instance, Nigel Thompson, “Stretching 256-Color Images Using Interpolation”, Microsoft Developer Network, March 7, 1995.) ↩

  59. Sound today is most commonly digitized by pulse-code modulation (PCM), and PCM-digitized sound is often stored in computer files ending in “.WAV”. ↩

  60. The Multimedia PC Specification (1992) required support in “multimedia PCs” for playback of at least 8-bit-per-sample mono digitized sound at 11,025 and 22,050 Hz. The Multimedia PC level 2 specification (1993) required support in “multimedia PCs” for playing back at least 16-bit-per-sample stereo digitized sound at 44,100 Hz. ↩

  61. PC games released in 1999 tended to require 32 million bytes of system memory. Meanwhile, Quake (1996) required 8 million and recommended 16 million bytes of system memory. ↩

  62. “MB” is ambiguous here; it often means either one million bytes or 1024 times 1024 bytes. ↩

  63. “Typical PCs in 1994”, https://www.dosdays.co.uk/topics/1994.php. ↩

  64. “Typical PCs in 1997”, https://www.dosdays.co.uk/topics/1997.php. ↩

  65. “Typical PCs in 1998”, https://www.dosdays.co.uk/topics/1998.php. ↩

  66. Statements like this that relate to polygons or triangles per frame are hard to find and often anecdotal, and they cannot always be inferred from screenshots or videos of gameplay. For example:
    (1) “A typical scene in a current [PC] application has 2000 to 2500 triangles per frame” (R. Fosner, “DirectX 6.0 Goes Ballistic With Multiple New Features And Much Faster Code”, Microsoft Systems Journal January 1999).
    (2) “For context, Quake on a Pentium Pro pumped out maybe 100K triangles/second (tris/sec.) … at best” (M. Abrash, “Inside Xbox Graphics”, Dr. Dobb’s Journal, August 2000); to be noted here is that the game normally ran at a screen resolution of 320 × 240.
    (3) According to the help for the 3DMark2000 benchmark, that benchmark comes with two game scenes that average up to 9,400 polygons in low detail and up to 55,000 in high detail.
    (4) The game engine for SpecOps: Rangers Lead the Way (1998) targeted 10,000 triangles per frame (“Postmortem: Zombie’s SpecOps: Rangers Lead the Way“, Jan. 31, 2000). So did Quake III Arena (1999) (John Carmack .plan, Sep. 2, 1999). ↩

  67. Antochi, Iosif, et al. “3D Graphics Benchmarks for Low-Power Architectures.” 14th Annual Workshop on Circuits, Systems and Signal Processing. 2003. ↩

  68. Antochi, Iosif, et al., “GraalBench: a 3D graphics benchmark suite for mobile phones”, ACM SIGPLAN Notices 39(7), 2004. ↩