Graphics and Music Challenges for Classic Computer Applications

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

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

All three serve to arouse nostalgia among 1990s computer users.

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.

Classic graphics here means two- or three-dimensional graphics achieved by video games from 1999 or earlier, before the shader model of 3-D graphics programming became mainstream among game software.1

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 late-1990s games.2

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.

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

Limit 3D graphics to the following:

  1. The maximum number of primitives that can be displayed at a time is equal to screen width times screen height divided by 24.3 (Examples: 256 × 192 / 24 = 2048 polygons; 640 × 480 / 24 = 12800 primitives.)
    • A primitive is either a triangle, a convex quadrilateral, or a line segment.
    • Each vertex of the primitive must point to a vertex from the vertex list described later.
    • Each primitive can be translucent and/or wireframed.
  2. The maximum number of vertices that can be used 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 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. Depth buffers (Z buffers), clear colors, and fog colors are supported.
  5. The 3D graphics buffer’s resolution is the same as the screen resolution.
  6. Primitives should undergo perspective-correct texture mapping, but affine mapping may be implemented instead.4

Limit 2D graphics to the following: 5

  1. Up to three 2D layers can be displayed at a time. If 3D graphics are not being displayed, a fourth 2D layer can also be displayed. Otherwise, a layer for the 3D graphics can be displayed. Each 2D 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 2D and 3D layers may contain transparent pixels.
  5. Up to two of the 2D layers can undergo a 2D affine transformation.

  6. Separate from layers, 2D 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 2D 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.6
  7. Tiles and sprites can be rendered flipped on either or both axes.

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

Other requirements:

This specification was inspired by the graphics limitations of—

A game may impose further resource limits to those specifications (for example, to reduce the maximum number of 3D triangles, to disallow 3D rendering, to reduce the number of colors per tile allowed, or 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.11 Examples of optional constraints are the following:

Notes on Specifications

Screen resolution:

Music and sound:

Frame rate:

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

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. Matt Saettler, “Graphics Design and Optimization”, Multimedia Technical Note (Microsoft), 1992, contains a rich discussion of graphics used in classic multimedia and game 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”. ↩

  2. A computer has adequate performance for classic graphics if it achieves a score of—
    (a) 2700 or greater on the 3DMark2000 benchmark when run without graphics acceleration, or
    (b) 1500 or greater on the 3DMark2000 CPU Speed Test.
    Either score corresponds to the running of a then-demanding 3-D graphics demo at 60 frames per second or faster. ↩

  3. To bolster the suggestions in this specification, it would be of interest to find the number of triangles or polygons per frame and graphics memory use (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. 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. ↩

  4. Affine (as opposed to perspective-correct) texture mapping, together with the rounding of vertex coordinates to integers and the lack of antialiasing, contributed to the characteristic distortion and instability of 3-D graphics in many PlayStation (One) games. ↩

  5. A possible alternative to these 2D limits is to require the use of a frame buffer with no more than 8 bits per pixel 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. ↩

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

  7. But alpha blending (the partial 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. ↩

  8. If the game screen is two-level monochrome (one bit per pixel), 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-level monochrome 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-level monochrome 800 × 450 display (378,000 total pixels). ↩

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

  10. This includes:
    (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) and WarCraft (1994).
    (4) Games using an OpenGL version earlier than 1.2 for graphics. ↩

  11. 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.
    This specification does not preclude the use of prerendered graphics (as in Space Quest 5, Myst, or the original Final Fantasy VII on PlayStation) to simulate showing more triangles or vertices at a time than otherwise allowed. Doing this simulation using other software programming tricks would not be within the spirit of this specification, though. ↩

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

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

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

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

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

  17. 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

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

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

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

  21. Rarely used VGA display mode. ↩

  22. PlayStation 2 NTSC. ↩

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

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

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

  26. Game Boy Advance. ↩

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

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

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

  30. PAL overscan. ↩

  31. Hercules Graphics Card two-level monochrome. ↩

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

  33. 12-inch classic Macintosh. ↩

  34. 16 colors. ↩

  35. NEC PC-9801 8-color mode; Atari ST two-level monochrome. ↩

  36. Apple II. ↩

  37. PlayStation Portable. ↩

  38. MSX 2. ↩

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

  40. Virtual Boy. ↩

  41. CGA 16-color mode. ↩

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

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

  44. Until the early 1990s, the number of pixels rendered 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. 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.
    It is worth noting that, before 1995, computer memory was expensive, so that computers with more than 4096 kibibytes of system memory (and 1024 kibibytes of video memory) were rare among consumers. ↩

  46. A sound bank of decent quality in either format is about 4 million bytes in size. Making these banks would be easier if there were a guide on producing decent-quality instrument banks from the recordings of real musical instruments (rather than copying or converting other instrument banks or recording from commercial synthesizers). ↩