Graphics and Music Challenges for Classic Computer Applications

This version of the document is dated 2025-11-22.

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

All of them serve to arouse nostalgia among 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 general, classic graphics 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.

Most desktop and laptop computers from 2010 on, and most smartphones from 2016 on, can render even high-quality classic graphics using only software — without relying on specialized video cards — at screen resolutions typically targeted by video games in the 1990s and earlier.1

The specification in this 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.

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:

  1. The maximum number of primitives that can be displayed at a time (per frame) is equal to screen width times screen height divided by 24. (Examples: 256 × 192 / 24 = 2048 primitives; 640 × 480 / 24 = 12800 primitives. 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 must point 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.
    • For each color, the red component is 5 bits, the green, 5 bits, and the blue, 5 bits.
  3. Textures (images that are applied to the surface of 3-D objects) must have the same color format as vertex colors, or may employ a 4-, 16-, or 256-color palette with that color format. The width and height of each texture must be a power of 2. A texture’s maximum width and maximum height, in pixels, are each equal to 256 or the larger screen dimension, whichever is smaller.
  4. Textures may contain transparent pixels.
  5. Depth buffers (Z buffers), screen-clearing colors, and fog colors are supported.
  6. The 3-D graphics buffer’s resolution is the same as the screen resolution.
  7. Primitives should undergo perspective-correct texture mapping, but affine mapping may be implemented instead.2

Limit 2-D graphics to the following: 3

  1. Up to three 2-D layers can be displayed at a time. If 3-D graphics are not being displayed, a fourth 2-D layer can also be displayed. Otherwise, a layer for the 3-D graphics can be displayed. Each 2-D layer is a rectangular array of references to tiles (a tile is a small rectangular array of pixels).
  2. There are sixteen palettes of 16 colors each (using the color format for vertex colors).
  3. The tiles have the same size (32 × 32 pixels or smaller) and each tile uses the colors of one of the sixteen palettes just described. A tile size of 8 × 8 pixels is suggested.
  4. The 2-D and 3-D layers may contain transparent pixels.
  5. Up to two of the 2-D layers can undergo a 2-D affine transformation.

  6. Separate from layers, 2-D sprites can be displayed. Each sprite is a rectangular array of either tiles or pixels, has size up to X × Y pixels, and may contain transparent pixels, but not translucent (semitransparent) pixels. Up to N sprites can be displayed at a time. Each sprite can be rendered above or below any of the 2-D layers.

    • 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.)
    • N is calculated as (screen width × screen height × 16) / (X × Y), rounded up, but not more than 512.4
  7. Tiles and sprites can be rendered flipped on either or both axes.

The 3-D graphics layer, if any, can be alpha blended with the 2-D graphics layers in any order. 5

Other requirements:

Classic Graphics in Scope

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

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

In general, PC applications that feature classic graphics include:

  1. Windows games and screen savers written for DirectX versions earlier than 7 and using Direct3D or DirectDraw for graphics.
  2. Windows games and screen savers 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 an OpenGL version earlier than 1.2 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.

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. I would also be interested in learning about a free and open-source graphics library that implements this specification.9 Examples of optional constraints are the following:

Notes on Specification

Screen resolution:

Frame rate:

3-D graphics:

Music and sound:

Memory:

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 a limited pixel size — 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” in the “peteroupc/classic-wallpaper” repository 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.

Survey of polygon and memory usage in 1990s 3-D games

To buttress the suggestions in the specification on classic graphics, given earlier in this page, it would be of interest to find the number of triangles or polygons per frame and graphics memory usage (for a given resolution and frame rate) actually achieved on average by 3-D video games in the mid- to late 1990s. Such information is hard to find and is often anecdotal.49

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.

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). ↩

  2. An affine texture mapping keeps parallel lines parallel. A perspective-correct texture mapping accounts for distance from the viewer: closer objects appear larger. Affine texture mapping, together with the rounding of vertex coordinates to integers and the lack of smoothing (antialiasing) of edges, contributed to the characteristic distortion and instability of 3-D graphics in many PlayStation (One) games. ↩

  3. A possible alternative to these 2-D limits is to require the use of a frame buffer (array of pixels in computer memory) with no more than 8 bits per pixel (no more than 256 simultaneous colors) and to require that all graphics 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.
    The tile-based limits specified here 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. ↩

  4. Tile- and sprite-based graphics were in place largely because they saved memory. 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. ↩

  5. But alpha blending (the mixing of one color with another) was “relatively new to PC games” at the time of Quake’s release in 1996, according to Michael Abrash’s Graphics Programming Black Book. Only images with opaque and/or transparent pixels tended to be supported in early-1990s video games. ↩

  6. If the game screen is two colors only (such as black and white), a game could choose to allow screen resolutions up to 800,000 total pixels. For example, a 1024 × 768 screen 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). ↩

  7. Standard MIDI files should be rendered 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 sounds into up to 16 channels, each occupied by at most one “instrument” at a time. Under the Multimedia PC Specification of 1991, 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. ↩

  8. Matt Saettler, “Graphics Design and Optimization”, Multimedia Technical Note (Microsoft), 1992, contains a rich discussion of graphics used in classic games and other audiovisual computer applications. Not mentioned in that document are graphics resembling:
    (1) Segmented liquid crystal displays, of the kind that Tiger Electronics was famous for. These are simple to emulate, though: design a screen-size picture that assigns each segment a unique color and, each frame, draw black pixels on the screen where the segments that are “on” are, and draw white pixels (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”. ↩

  9. Especially if the library is self-contained and implements the specification with as little source code as possible. The following are examples of a graphics library that follows the spirit of this specification, even though it doesn’t necessarily meet its requirements exactly: Tilengine, kit, DOS-like, raylib’s rlsw software renderer. Michal Strehovský published an interesting technique to create small game applications. ↩

  10. MS-DOS applications are normally limited to 640 kibibytes or less of conventional memory, along with whatever memory is carried by the video card. 262,144 bytes is the usual minimum of graphics memory for VGA video cards. ↩

  11. 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 Michael Abrash’s Graphics Programming Black Book. ↩

  12. 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). ↩

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

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

  15. Commodore 64; NEC PC-8001; VGA mode 13h (256 colors); Color/Graphics Adapter (CGA) 4-color mode; Atari ST 16-color mode; Amiga NTSC. ↩ ↩2

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

  17. One low resolution required by the PC 98 System Design Guide. ↩

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

  19. Rarely used VGA display mode. ↩

  20. PlayStation 2 NTSC. ↩

  21. Sega Mega Drive/Sega Genesis; Neo Geo NTSC. ↩

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

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

  24. Game Boy Advance. ↩

  25. Game Boy, Game Boy Color, Sega Game Gear. ↩

  26. Aspect ratio found above all in PAL (phase-alternating-line) displays. ↩

  27. Amiga PAL (“square” pixels); Neo Geo PAL. ↩

  28. PlayStation 2 PAL. Note that this covers more than 307,200 total pixels. ↩

  29. PAL overscan. ↩

  30. Hercules Graphics Card two-color. ↩

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

  32. 12-inch classic Macintosh. ↩

  33. 16 colors. ↩

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

  35. Apple II. ↩

  36. PlayStation Portable. ↩

  37. MSX 2. ↩

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

  39. Virtual Boy. ↩

  40. CGA 16-color mode. ↩

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

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

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

  44. Until the early 1990s, the number of 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 (1991) recommended that video cards be able to transfer up to 8-bit-per-pixel graphics at a rate of 140,000 pixels per second or faster given 40 percent of CPU bandwidth. The Multimedia PC level 2 specification (1993) upped this recommendation to 1.2 million pixels per second (sufficient for 320 × 240 pixel 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 pixels per second needed to display 640 × 480 pixel video smoothly at 20 frames per second. ↩

  45. Digitized sound is also known as pulse-code modulation (PCM) and is often stored in files ending in “.WAV”. ↩

  46. The Multimedia PC Specification (1991) required support in “multimedia PCs” for rendering 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 rendering at least 16-bit-per-sample stereo digitized sound at 44,100 Hz. ↩

  47. 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. ↩

  48. A “top-of-the-line” PC from 1994 came with 8192 kibibytes of system memory: Fabien Sanglard, Game Engine Black Book: Doom. ↩

  49. For example:
    (1) B. Tschirren, “Realism and Believability in MPEG-4 Facial Models”, Curtin University of Technology, 2000, includes a statement that games like Quake III Arena [1999] render up to 10,000 triangles per frame.
    (2) “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).
    (3) “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 320 × 240 pixels.
    (4) The 3DMark2000 benchmark comes with two game scenes that average up to 9,400 polygons in low detail and up to 55,000 in high detail and is intended for 640 × 480 resolution.
    (5) An early study of polygon rendering rates in DOS-based 3-D games, by B. Johanson and B. Oberstein (1996), shows the difficulty of finding triangle output rates in DOS games. ↩