peteroupc.github.io/graphics.html at master · peteroupc/peteroupc.github.io · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
<!DOCTYPE html><html  xmlns:dc="http://purl.org/dc/terms/" xmlns:og="http://ogp.me/ns#" ><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><title>Graphics and Music Challenges for Classic-Style Computer Applications</title><meta name="citation_pdf_url" content="https://peteroupc.github.io/graphics.pdf"><meta name="citation_url" content="https://peteroupc.github.io/graphics.html"><meta name="citation_title" content="Graphics and Music Challenges for Classic-Style Computer Applications"><meta name="dc.date" content="2026-03-27"><meta name="citation_date" content="2026/03/27"><meta name="citation_publication_date" content="2026/03/27"><meta name="citation_online_date" content="2026/03/27"><meta name="og:title" content="Graphics and Music Challenges for Classic-Style Computer Applications"><meta name="og:type" content="article"><meta name="og:url" content="https://peteroupc.github.io/graphics.html"><meta name="og:site_name" content="peteroupc.github.io"><meta name="dc.format" content="text/html"><meta name="dc.language" content="en"><meta name="title" content="Graphics and Music Challenges for Classic-Style Computer Applications"><meta name="dc.title" content="Graphics and Music Challenges for Classic-Style Computer Applications"><meta name="twitter:title" content="Graphics and Music Challenges for Classic-Style Computer Applications"><meta name="dc.creator" content="Peter Occil"/><meta name="author" content="Peter Occil"/><meta name="citation_author" content="Peter Occil"/><meta name="viewport" content="width=device-width"><link rel=stylesheet type="text/css" href="/style.css">
            <script type="text/x-mathjax-config"> MathJax.Hub.Config({"HTML-CSS": { availableFonts: ["STIX","TeX"], linebreaks: { automatic:true }, preferredFont: "TeX" },
                    tex2jax: { displayMath: [ ["$$","$$"], ["\\[", "\\]"] ], inlineMath: [ ["$", "$"], ["\\\\(","\\\\)"] ], processEscapes: true } });
            </script><script type="text/javascript" async src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.5/MathJax.js?config=TeX-AMS_HTML-full"></script></head><body>  <div class="header">
<nav><p><a href="#navigation">Menu</a> - <a href="#top">Top</a> - <a href="/">Home</a></nav></div>
<div class="mainarea" id="top">
<h1 id="graphics-and-music-challenges-for-classic-style-computer-applications">Graphics and Music Challenges for Classic-Style Computer Applications</h1><p>This version of the document is dated 2026-03-27.  <a href='https://github.com/peteroupc/peteroupc.github.io/issues'>Post an issue or comment on this document</a>.</p>

<p>The following are challenges I make to the computer community, relating to:</p>

<ul>
  <li><a href="#Graphics_Challenge_for_Classic_Style_Games"><strong>Graphics for classic-style game development</strong></a>.</li>
  <li><a href="#Building_a_Public_Domain_music_synthesis_library_and_instrument_banks"><strong>MIDI music synthesis for classic-style games and apps</strong></a>.</li>
  <li><a href="https://peteroupc.github.io/classic-wallpaper"><strong>Tileable wallpapers with limited colors and resolution</strong></a>.</li>
  <li><a href="#Other_Challenges_and_Projects"><strong>Other challenges and projects</strong></a>.</li>
</ul>

<p>All may interest 1990s computer users.</p>

<p><a id="Contents"></a></p>

<h2 id="contents">Contents</h2>

<ul>
  <li><a href="#Contents"><strong>Contents</strong></a></li>
  <li><a href="#Graphics_Challenge_for_Classic_Style_Games"><strong>Graphics Challenge for Classic-Style Games</strong></a>
    <ul>
      <li><a href="#The_Specification"><strong>The Specification</strong></a></li>
      <li><a href="#Classic_Graphics_in_Scope"><strong>Classic Graphics in Scope</strong></a></li>
      <li><a href="#Optional_Limits"><strong>Optional Limits</strong></a></li>
      <li><a href="#Notes_on_Specification"><strong>Notes on Specification</strong></a>
        <ul>
          <li><a href="#Screen_resolutions"><strong>Screen resolutions</strong></a></li>
          <li><a href="#Frame_rate"><strong>Frame rate</strong></a></li>
          <li><a href="#3_D_graphics"><strong>3-D graphics</strong></a></li>
          <li><a href="#Screen_image_effects_filters"><strong>Screen image effects (filters)</strong></a></li>
          <li><a href="#Sounds"><strong>Sounds</strong></a></li>
          <li><a href="#Memory"><strong>Memory</strong></a></li>
        </ul>
      </li>
      <li><a href="#Seeking_Comments"><strong>Seeking Comments</strong></a></li>
      <li><a href="#Further_Reading"><strong>Further Reading</strong></a></li>
    </ul>
  </li>
  <li><a href="#Building_a_Public_Domain_music_synthesis_library_and_instrument_banks"><strong>Building a Public-Domain music synthesis library and instrument banks</strong></a></li>
  <li><a href="#Other_Challenges_and_Projects"><strong>Other Challenges and Projects</strong></a>
    <ul>
      <li><a href="#Classic_desktop_wallpaper"><strong>Classic desktop wallpaper</strong></a></li>
      <li><a href="#Button_and_border_styles_for_classic_interfaces"><strong>Button and border styles for classic interfaces</strong></a></li>
      <li><a href="#Sound_bank_development_guide"><strong>Sound bank development guide</strong></a></li>
      <li><a href="#Guide_for_creating_3_D_models_in_the_pre_2000_style"><strong>Guide for creating 3-D models in the pre-2000 style</strong></a></li>
    </ul>
  </li>
  <li><a href="#Acknowledgments"><strong>Acknowledgments</strong></a></li>
  <li><a href="#License"><strong>License</strong></a></li>
  <li><a href="#Notes"><strong>Notes</strong></a></li>
</ul>

<p><a id="Graphics_Challenge_for_Classic_Style_Games"></a></p>

<h2 id="graphics-challenge-for-classic-style-games">Graphics Challenge for Classic-Style Games</h2>

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

<p>In this document, <em>classic graphics</em> generally means two- or three-dimensional graphics achieved by video games from 1999 or earlier, before the advent of programmable “shaders”.  For details, see “<a href="#Classic_Graphics_in_Scope"><strong>Classic Graphics in Scope</strong></a>”, 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.)</p>

<p>This challenge is intended to encourage the making of—</p>

<ul>
  <li>modern video games that simulate pre-2000 graphics and run with very low resource requirements (say, 64 million bytes of memory or less) and even on very low-end computers (say, those that date from 2010 or earlier or support Windows 7, Windows XP, or even older), and</li>
  <li>graphics engines (especially free and open-source ones) devoted to pre-2000 computer graphics and meant for developing such modern video games.<sup id="fnref:1"><a href="#fn:1" class="footnote" rel="footnote" role="doc-noteref">1</a></sup></li>
</ul>

<p>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.<sup id="fnref:2"><a href="#fn:2" class="footnote" rel="footnote" role="doc-noteref">2</a></sup></p>

<p>The challenge sets an <em>upper bound</em> on the kind of computer graphics that are of interest.  Further <a href="#Optional_Limits"><strong>constraints to graphics computation</strong></a> (such as memory, resource, color, resolution, or triangle limits) are highly encouraged. It is also encouraged to establish a lean programming interface for this graphics specification; for details, see “<a href="https://peteroupc.github.io/graphicsapi.html"><strong>Lean Programming Interfaces for Classic Graphics</strong></a>”.</p>

<p><a id="The_Specification"></a></p>

<h3 id="the-specification">The Specification</h3>

<p>Define the <em>larger screen dimension</em> as the larger of the screen width and the screen height.</p>

<p>Limit 3-D graphics to the following:<sup id="fnref:3"><a href="#fn:3" class="footnote" rel="footnote" role="doc-noteref">3</a></sup></p>

<ol>
  <li>The maximum number of primitives that can be shown at a time is equal to screen width times screen height divided by 24.<sup id="fnref:4"><a href="#fn:4" class="footnote" rel="footnote" role="doc-noteref">4</a></sup> (See also survey project in “Other Challenges and Projects”, later.)
    <ul>
      <li>A <em>primitive</em> is either a triangle or a line segment.  An application may also consider a convex quadrilateral to be a primitive.</li>
      <li>Each vertex of the primitive points to a vertex from the vertex list described later.</li>
      <li>Each primitive can be translucent.</li>
    </ul>
  </li>
  <li>The maximum number of vertices that can be displayed at a time is 3 times the maximum number of primitives.
    <ul>
      <li>A <em>vertex</em> consists of an XYZ position, an XY texture coordinate, and a red–green–blue vertex color.</li>
      <li>Each vertex color follows this color format: The red, green, and blue components occupy up to 5 bits each.<sup id="fnref:5"><a href="#fn:5" class="footnote" rel="footnote" role="doc-noteref">5</a></sup></li>
    </ul>
  </li>
  <li>Each <em>texture</em> (an image that is applied to the surface of 3-D objects)—
    <ul>
      <li>is in a 16-bit-per-pixel format, where each pixel has the vertex color format given earlier, or</li>
      <li>is in a 1-, 2-, 4-, or 8-bit-per-pixel format and has a table of colors with that color format.</li>
    </ul>
  </li>
  <li>The width and height of each texture are each powers of 2.</li>
  <li>A texture’s maximum width and maximum height, in pixels, are each equal to 256 or the larger screen dimension, whichever is smaller.</li>
  <li>Textures may contain transparent pixels.</li>
  <li>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.</li>
  <li>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.<sup id="fnref:6"><a href="#fn:6" class="footnote" rel="footnote" role="doc-noteref">6</a></sup>  Bilinear filtering and edge antialiasing (smoothing)<sup id="fnref:7"><a href="#fn:7" class="footnote" rel="footnote" role="doc-noteref">7</a></sup> are optional.</li>
  <li>3-D primitives should undergo perspective correction, but this is optional.<sup id="fnref:8"><a href="#fn:8" class="footnote" rel="footnote" role="doc-noteref">8</a></sup></li>
  <li>The 3-D graphics buffer’s resolution is the same as the “screen resolution”.</li>
</ol>

<blockquote>
  <p><strong>Example:</strong> 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.</p>
</blockquote>

<p>Limit 2-D graphics to the following: <sup id="fnref:9"><a href="#fn:9" class="footnote" rel="footnote" role="doc-noteref">9</a></sup></p>

<ol>
  <li>Layers:
    <ol>
      <li>Up to four <em>2-D layers</em> can be displayed at a time.  Each 2-D layer is a rectangular array of references to <em>tiles</em> (see later), and can also be called a <em>tile map</em>.<sup id="fnref:10"><a href="#fn:10" class="footnote" rel="footnote" role="doc-noteref">10</a></sup></li>
      <li>Up to two of the 2-D layers can undergo a 2-D affine transformation.</li>
      <li>If 3-D graphics are being displayed, one of the 2-D layers is replaced with a <em>3-D layer</em>, which is an image on which the 3-D graphics are drawn. The 2-D layer replaced this way can vary over time.</li>
      <li>The 2-D layers may contain transparent pixels.  The 3-D layer may contain transparent and translucent (semitransparent) pixels.<sup id="fnref:11"><a href="#fn:11" class="footnote" rel="footnote" role="doc-noteref">11</a></sup></li>
    </ol>
  </li>
  <li>Tiles. A <em>tile</em> is a small rectangular array of pixels.
    <ol>
      <li>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.</li>
      <li>The application chooses one:
        <ol>
          <li>Each tile is in a 1-bit-per-pixel format and uses one of 16 <em>color tables</em>, with 2 colors per table.</li>
          <li>Each tile is in a 2-bit-per-pixel format and uses one of 16 color tables, with 4 colors per table.</li>
          <li>Each tile is in a 4-bit-per-pixel format and uses one of 16 color tables, with 16 colors per table.</li>
          <li>There is a single 256-color table for use by tiles.  Each tile is in an 8-bit-per-pixel format.</li>
        </ol>
      </li>
      <li>Each color in each color table used by tiles is of the vertex color format given earlier.</li>
      <li>Tiles may contain transparent, but not translucent, pixels.</li>
      <li>Tiles should not be “pixelated” before the game uses them.</li>
      <li>When referenced in a 2-D layer, a tile can be horizontally flipped, vertically flipped, or both.</li>
    </ol>
  </li>
  <li>Sprites.  A <em>sprite</em> is a rectangular array of either tiles or pixels.
    <ol>
      <li>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.)</li>
      <li>Besides the previous point, sprites can have any width and height.</li>
      <li>Each sprite made of pixels (rather than tiles) has a pixel format allowed for <em>3-D textures</em>, given earlier, and may contain transparent, but not translucent, pixels.</li>
      <li>Each sprite can be drawn above or below any of the 2-D or 3-D layers.</li>
      <li>The application chooses one:
        <ol>
          <li>Each sprite can undergo a 2-D affine transformation.</li>
          <li>Each sprite can be horizontally flipped, vertically flipped, or both.<sup id="fnref:12"><a href="#fn:12" class="footnote" rel="footnote" role="doc-noteref">12</a></sup></li>
          <li>No affine transformation or flipping of sprites is allowed.</li>
        </ol>
      </li>
      <li>Sprites should not be “pixelated” before the game uses them.</li>
      <li>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.<sup id="fnref:13"><a href="#fn:13" class="footnote" rel="footnote" role="doc-noteref">13</a></sup></li>
    </ol>
  </li>
</ol>

<blockquote>
  <p><strong>Note:</strong> The suggested width and height for tiles is 8 pixels × 8 pixels.</p>

  <p><strong>Example:</strong> 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.</p>
</blockquote>

<p>Other requirements:</p>

<ul>
  <li><strong>Screen resolution:</strong> The game screen image has no more than 307,200 total pixels (for example, 640 × 480, or 640 pixels horizontally and 480 pixels vertically).<sup id="fnref:14"><a href="#fn:14" class="footnote" rel="footnote" role="doc-noteref">14</a></sup>  Support for game screen resolutions larger than this limit, in addition to resolutions meeting the limit, is optional.</li>
  <li><strong>Rendering in software:</strong> The game should include a mode in which the graphics are <em>rendered in software</em>.  This means that the rendering of graphics does not rely on a video card, a graphics accelerator chip, or the operating system’s graphics API (such as GDI, OpenGL, or Direct3D) with the sole exception of sending a finished game screen image to the player’s display (such as through GDI’s <code>StretchDIBits</code> or copying to VGA’s video memory).  The game can optionally support hardware acceleration of graphics as well (and can even use such acceleration by default when the game detects its availability).</li>
  <li><strong>Music:</strong> Music is in Standard MIDI files (SMF) only. The General MIDI System level 1 should be followed for such files.<sup id="fnref:15"><a href="#fn:15" class="footnote" rel="footnote" role="doc-noteref">15</a></sup></li>
</ul>

<p><a id="Classic_Graphics_in_Scope"></a></p>

<h3 id="classic-graphics-in-scope">Classic Graphics in Scope</h3>

<p>This specification for “classic graphics”<sup id="fnref:16"><a href="#fn:16" class="footnote" rel="footnote" role="doc-noteref">16</a></sup> in modern games largely reflects the graphics limitations of—</p>

<ul>
  <li>consumer PCs (personal computers) released in the mid- to late 1990s,</li>
  <li>home computers released before 1995,</li>
  <li>game consoles (handheld and for TVs) released before 2000,</li>
  <li>arcade machines with similar performance to machines described earlier, and</li>
  <li>the Game Boy Advance and Nintendo DS, both of which were released after 2000 but have relatively meager graphics ability.</li>
</ul>

<p>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.<sup id="fnref:17"><a href="#fn:17" class="footnote" rel="footnote" role="doc-noteref">17</a></sup></p>

<p>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).</p>

<p>In general, PC applications that feature classic graphics include:</p>

<ol>
  <li>Windows applications written for DirectX versions earlier than 7 and using Direct3D or DirectDraw for graphics.</li>
  <li>Windows games using GDI or <a href="https://www.pcgamingwiki.com/wiki/List_of_WinG_games"><strong>WinG</strong></a> for graphics and supporting Windows 98 or earlier.  Examples are  <em>Chip’s Challenge</em> for Windows (1992) and Brian Goble’s <em>The Adventures of MicroMan</em> (1993).</li>
  <li>Games for MS-DOS or PC-9801 that were published before 2000.  Examples are <em>Quake</em> (1996), <em>WarCraft</em> (1994), and the first titles of the Touhou Project series (1997-1998).</li>
  <li>Games using OpenGL 1.2 or earlier for graphics.</li>
  <li>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 <em>Authoring Guide</em> that came with Microsoft’s Multimedia Development Kit.</li>
</ol>

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

<ul>
  <li><em>Quake III Arena</em> (December 1999), which <a href="https://www.dosdays.co.uk/topics/early_3d_games.php"><strong>required DirectX 7 and at least 64 million bytes of memory</strong></a>.</li>
  <li><em>Falcon 4.0</em> (1998).</li>
</ul>

<p><a id="Optional_Limits"></a></p>

<h3 id="optional-limits">Optional Limits</h3>

<p>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 <a href="https://peteroupc.github.io/classic-wallpaper#Color_Palettes"><strong>reduce to a limited set the colors</strong></a> ultimately displayed on screen).  I would be interested in knowing about these limitations that a new game that adopts this document decides to impose.</p>

<p>Examples of optional constraints are the following:</p>

<ul>
  <li>The game displays no more than 16 colors at a time.<sup id="fnref:18"><a href="#fn:18" class="footnote" rel="footnote" role="doc-noteref">18</a></sup></li>
  <li>The game is limited to the 16 colors of the so-called <em>VGA palette</em>.
    <ul>
      <li>In the 8-bit-per-component color format, this palette’s colors are: light gray, that is, (192, 192, 192); or each color component is 0 or 255; or each color component is 0 or 128.</li>
      <li>In the vertex color format, the closest colors to this palette are: 24/24/24; or each color component is 0 or 16; or each color component is 0 or 31.</li>
    </ul>
  </li>
  <li>The game displays no more than 256 colors at a time.<sup id="fnref:19"><a href="#fn:19" class="footnote" rel="footnote" role="doc-noteref">19</a></sup></li>
  <li>All game files can be packaged in a ZIP file or Win32 program file that takes no more than—
    <ul>
      <li>1,457,664 bytes (the capacity of a file-allocation-table (FAT) formatted high-density 3.5-inch floppy disk), or</li>
      <li>1,213,952 bytes (the capacity of a FAT formatted high-density 5.25-inch floppy disk), or</li>
      <li>730,112 bytes (the capacity of a FAT formatted normal-density 3.5-inch floppy disk), or</li>
      <li>362,496 bytes (the capacity of a FAT formatted double-density 5.25-inch floppy disk), or</li>
      <li>65,536 bytes,<sup id="fnref:20"><a href="#fn:20" class="footnote" rel="footnote" role="doc-noteref">20</a></sup> or</li>
      <li>681 million bytes (slightly less than the maximum capacity of a formatted CD-ROM).</li>
    </ul>
  </li>
  <li>The game uses no more than 16 million bytes of system memory at a time.</li>
  <li>The game uses no more than 655,360 bytes of system memory (plus 262,144 bytes of additional memory for graphics use only) at a time.<sup id="fnref:21"><a href="#fn:21" class="footnote" rel="footnote" role="doc-noteref">21</a></sup></li>
  <li>The game is a Win32 application compatible with Windows XP.</li>
  <li>The game is a Win32 application compatible with Windows 98.</li>
  <li>The game aims for a rate of 30 frames per second.</li>
  <li>The game’s graphics must be <em>rendered in software</em>.</li>
  <li>The game’s graphics rendering employs only 32-bit and smaller integers and fixed-point arithmetic.<sup id="fnref:22"><a href="#fn:22" class="footnote" rel="footnote" role="doc-noteref">22</a></sup></li>
  <li>The game renders only one-unit-thick white line segments on a black background (or vice versa), and displays no more than 320 of those segments at a time.</li>
</ul>

<p><a id="Notes_on_Specification"></a></p>

<h3 id="notes-on-specification">Notes on Specification</h3>

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

<p><a id="Screen_resolutions"></a></p>

<h4 id="screen-resolutions">Screen resolutions</h4>

<ul>
  <li>
    <p>Screen resolutions larger than 307,200 total pixels (such as 800 × 600) are not within the spirit of this challenge, even though more demanding games in the late 1990s, as well as the <em>PC 98 System Design Guide</em> (1997), aimed for the 800 × 600 resolution or higher for 3-D graphics.   Indeed, for the most part, major game consoles and arcade machines in the 1990s and earlier supported a resolution of no more than 307,200 total pixels.<sup id="fnref:23"><a href="#fn:23" class="footnote" rel="footnote" role="doc-noteref">23</a></sup></p>
  </li>
  <li>
    <p>Screen resolutions that have been used in classic games include:<sup id="fnref:24"><a href="#fn:24" class="footnote" rel="footnote" role="doc-noteref">24</a></sup></p>

    <ul>
      <li>Video graphics array (VGA) display modes: 640 × 480,<sup id="fnref:25"><a href="#fn:25" class="footnote" rel="footnote" role="doc-noteref">25</a></sup> 320 × 240,<sup id="fnref:26"><a href="#fn:26" class="footnote" rel="footnote" role="doc-noteref">26</a></sup> 320 × 200.<sup id="fnref:27"><a href="#fn:27" class="footnote" rel="footnote" role="doc-noteref">27</a></sup></li>
      <li>4:3 aspect ratio: 640 × 480,<sup id="fnref:25:1"><a href="#fn:25" class="footnote" rel="footnote" role="doc-noteref">25</a></sup> 512 × 384,<sup id="fnref:28"><a href="#fn:28" class="footnote" rel="footnote" role="doc-noteref">28</a></sup> 400 × 300,<sup id="fnref:29"><a href="#fn:29" class="footnote" rel="footnote" role="doc-noteref">29</a></sup> 320 × 240,<sup id="fnref:26:1"><a href="#fn:26" class="footnote" rel="footnote" role="doc-noteref">26</a></sup> 256 × 192,<sup id="fnref:30"><a href="#fn:30" class="footnote" rel="footnote" role="doc-noteref">30</a></sup> 160 × 120.<sup id="fnref:31"><a href="#fn:31" class="footnote" rel="footnote" role="doc-noteref">31</a></sup></li>
      <li>Game console aspect ratios: 640 × 448,<sup id="fnref:32"><a href="#fn:32" class="footnote" rel="footnote" role="doc-noteref">32</a></sup> 320 × 224,<sup id="fnref:33"><a href="#fn:33" class="footnote" rel="footnote" role="doc-noteref">33</a></sup> 256 × 224,<sup id="fnref:34"><a href="#fn:34" class="footnote" rel="footnote" role="doc-noteref">34</a></sup> 256 × 240,<sup id="fnref:35"><a href="#fn:35" class="footnote" rel="footnote" role="doc-noteref">35</a></sup> 240 × 160,<sup id="fnref:36"><a href="#fn:36" class="footnote" rel="footnote" role="doc-noteref">36</a></sup> 160 × 144.<sup id="fnref:37"><a href="#fn:37" class="footnote" rel="footnote" role="doc-noteref">37</a></sup></li>
      <li>5:4 aspect ratio:<sup id="fnref:38"><a href="#fn:38" class="footnote" rel="footnote" role="doc-noteref">38</a></sup> 320 × 256,<sup id="fnref:39"><a href="#fn:39" class="footnote" rel="footnote" role="doc-noteref">39</a></sup> 360 × 288.<sup id="fnref:40"><a href="#fn:40" class="footnote" rel="footnote" role="doc-noteref">40</a></sup></li>
      <li>Two-color graphics: 720 × 348,<sup id="fnref:41"><a href="#fn:41" class="footnote" rel="footnote" role="doc-noteref">41</a></sup> 640 × 200,<sup id="fnref:42"><a href="#fn:42" class="footnote" rel="footnote" role="doc-noteref">42</a></sup> 512 × 342.<sup id="fnref:43"><a href="#fn:43" class="footnote" rel="footnote" role="doc-noteref">43</a></sup></li>
      <li>Enhanced Graphics Adapter aspect ratio: 640 × 350.<sup id="fnref:44"><a href="#fn:44" class="footnote" rel="footnote" role="doc-noteref">44</a></sup></li>
      <li>8:5 aspect ratio: 640 × 400,<sup id="fnref:45"><a href="#fn:45" class="footnote" rel="footnote" role="doc-noteref">45</a></sup> 320 × 200.<sup id="fnref:27:1"><a href="#fn:27" class="footnote" rel="footnote" role="doc-noteref">27</a></sup></li>
      <li>Other: 280 × 192,<sup id="fnref:46"><a href="#fn:46" class="footnote" rel="footnote" role="doc-noteref">46</a></sup> 480 × 272,<sup id="fnref:47"><a href="#fn:47" class="footnote" rel="footnote" role="doc-noteref">47</a></sup> 512 × 424, <sup id="fnref:48"><a href="#fn:48" class="footnote" rel="footnote" role="doc-noteref">48</a></sup> 400 × 240,<sup id="fnref:49"><a href="#fn:49" class="footnote" rel="footnote" role="doc-noteref">49</a></sup> 384 × 224,<sup id="fnref:50"><a href="#fn:50" class="footnote" rel="footnote" role="doc-noteref">50</a></sup> 160 × 200,<sup id="fnref:51"><a href="#fn:51" class="footnote" rel="footnote" role="doc-noteref">51</a></sup> 480 × 240.<sup id="fnref:52"><a href="#fn:52" class="footnote" rel="footnote" role="doc-noteref">52</a></sup></li>
    </ul>

    <p>This is not a complete list.  Arcade machines of the 1990s tended to vary greatly in their screen resolutions, and some game consoles, such as the SEGA Saturn or Nintendo 64, allowed games to alter the screen resolution during gameplay.</p>
  </li>
  <li>
    <p>As of early 1997, “[s]urveys indicate[d] that the great majority of [PC] users operate[d] in 640[ × ]480 resolution with 256 colors”.<sup id="fnref:53"><a href="#fn:53" class="footnote" rel="footnote" role="doc-noteref">53</a></sup></p>
  </li>
  <li>
    <p>A game can support—</p>

    <ul>
      <li>multiple sizes for the area of the screen where the game’s action is drawn, or</li>
      <li>pixel-column or -row doubling as a “quality” setting,</li>
    </ul>

    <p>or both features, without changing the size of the game’s image.  For example, the original <em>Doom</em> (1993) supported several sizes of this kind (on PC, they were 96 × 48, 128 × 64, 160 × 80, and so on up to 288 × 144, as well as 320 × 168 and 320 × 200) and optional pixel-column doubling.<sup id="fnref:54"><a href="#fn:54" class="footnote" rel="footnote" role="doc-noteref">54</a></sup></p>
  </li>
  <li>
    <p>Games within the scope of this challenge are meant to be run in a desktop window if the player’s display is 800 × 600 pixels or larger.  The same is true if the game’s resolution is 620 × 420 or smaller and the player’s display is 640 × 480.  The game may also support full-screen display.</p>
  </li>
</ul>

<p><a id="Frame_rate"></a></p>

<h4 id="frame-rate">Frame rate</h4>

<ul>
  <li>
    <p>No particular frame rate is required.<sup id="fnref:55"><a href="#fn:55" class="footnote" rel="footnote" role="doc-noteref">55</a></sup></p>
  </li>
  <li>
    <p>Modern games implementing this specification can choose to target a frame rate typical of today, such as 30, 40, or 60 frames per second.</p>
  </li>
  <li>
    <p>Game consoles for TVs were designed for how often TVs can draw their image (nearly 60 frames per second for NTSC<sup id="fnref:56"><a href="#fn:56" class="footnote" rel="footnote" role="doc-noteref">56</a></sup> and 50 for PAL<sup id="fnref:57"><a href="#fn:57" class="footnote" rel="footnote" role="doc-noteref">57</a></sup>).</p>
  </li>
  <li>
    <p><em>Doom</em> (1993) operated at 35 frames per second but could not be run at that rate (under default settings) by typical PCs of the time.<sup id="fnref:54:1"><a href="#fn:54" class="footnote" rel="footnote" role="doc-noteref">54</a></sup></p>
  </li>
  <li>
    <p>For comfort reasons, a minimum frame rate may be required for video games that offer “<a href="https://www.pcgamingwiki.com/wiki/Glossary:Native_3D"><strong>3-D vision</strong></a>” by rendering multiple views of the scene at a time, in conjunction with special glasses (for example, a SEGA Master System accessory) or a virtual-reality headset (for example, Nintendo’s Virtual Boy).  But such games were rare before 2000.</p>
  </li>
</ul>

<p><a id="3_D_graphics"></a></p>

<h4 id="d-graphics">3-D graphics</h4>

<ul>
  <li>The <em>PC 99 System Design Guide</em> sections 14.27 to 14.34 gives guidelines on 3-D graphics support for PCs to be launched in 1999.  This challenge recommends the writing of software that performs as well as hardware meeting such guidelines, except for the screen resolution, frame rate, and double buffering requirements.</li>
  <li>An application may choose to support stencil buffers, bump mapping, environment mapping, and three- or four-texture blending, but these are borderline pre-2000 graphics capabilities.</li>
  <li>For years earlier than 1999, some of the 3-D capabilities mentioned in the specification (such as texture blending) might not be typical.</li>
  <li>This specification allows for:
    <ul>
      <li>Prerendered graphics (as in <em>Space Quest 5</em>, <em>Myst</em>, or the original <em>Final Fantasy VII</em> on PlayStation [1997]), to simulate showing highly detailed imagery.</li>
      <li>Drawing a 3-D graphic as a <a href="https://blog.danielschroeder.me/blog/voxel-renderer-objects-and-animation"><strong><em>voxel mesh</em></strong></a> (formed from point samples in 3-D, rather than 2-D, called <em>voxels</em>), as long as the triangle limits are respected.</li>
    </ul>
  </li>
  <li>The following are not within the spirit of this challenge:
    <ul>
      <li>Displaying more than 20,000 triangles at a time (per frame), even for higher screen resolutions.  Most 3-D video games before 2000 displayed well fewer than that, but there may be exceptions, such as arcade games for the SEGA Model 3.</li>
      <li>Phong shading (per-pixel specular highlighting), ray-traced graphics (other than the <em>ray casting</em> technique), and path-traced graphics, which were too slow for real-time graphics in the 20th century.</li>
    </ul>
  </li>
  <li>It wasn’t until 1995 that 3-D video cards became widely available for consumer PCs.<sup id="fnref:58"><a href="#fn:58" class="footnote" rel="footnote" role="doc-noteref">58</a></sup> In 3-D video games for PCs “[i]n 1995/1996, it was not uncommon to have 30-50% of the game screen filled with polygons without textures” (according to an <a href="https://retro.swarm.cz/s3-virge-325-vx-dx-gx-gx2-series-of-early-3d-accelerators-deep-dive/"><strong>article</strong></a> that compared <em>Havoc</em> [1995] with <em>Mortal Kombat 4</em> [1997]).</li>
  <li>This specification is not centered on video games that offer “3-D vision” (see note under “Frame rate”), given how rare they were before 2000.</li>
</ul>

<p><a id="Screen_image_effects_filters"></a></p>

<h4 id="screen-image-effects-filters">Screen image effects (filters)</h4>

<ul>
  <li>Effects that modify the game screen image to emulate CRT displays<sup id="fnref:59"><a href="#fn:59" class="footnote" rel="footnote" role="doc-noteref">59</a></sup> are outside the scope of this challenge.  So are effects that <a href="https://www.pcgamingwiki.com/wiki/Glossary:Scaling"><strong>scale</strong></a> the game screen to fit the height or width of the player’s display.<sup id="fnref:60"><a href="#fn:60" class="footnote" rel="footnote" role="doc-noteref">60</a></sup> This specification assumes those effects are not in place.  A game can have those effects if it wishes, but they should be in-game settings.</li>
</ul>

<p><a id="Sounds"></a></p>

<h4 id="sounds">Sounds</h4>

<ul>
  <li>Besides the limitation on music, this specification has no further limitations on sounds.</li>
  <li>Early game consoles supported sound only through one or more <em>programmable sound generators</em>, such as square and triangle wave generators, as opposed to digitized sounds<sup id="fnref:61"><a href="#fn:61" class="footnote" rel="footnote" role="doc-noteref">61</a></sup>.  Games that choose to constrain file size may wish to implement software versions of programmable sound generators for at least some of their sounds.</li>
  <li>When digitized sounds are supported in classic games, they typically have a sample rate of 8000, 11,025, 22,050, or 44,100 Hz, are either mono or stereo, and take 8 or 16 bits per sample.<sup id="fnref:62"><a href="#fn:62" class="footnote" rel="footnote" role="doc-noteref">62</a></sup></li>
</ul>

<p><a id="Memory"></a></p>

<h4 id="memory">Memory</h4>

<ul>
  <li>This specification does not impose a limit on graphics memory use (akin to the video memory, or VRAM, of a video card).  One suggested example, given in kibibytes of graphics memory, is the screen width times screen height divided by 24, which is slightly less than 13.2 million bytes for 640 × 480 resolution. (A kibibyte is 1024 bytes.) Imposing a limit on graphics memory use does not limit the size or number of textures, 3-D models, or other graphics files a game can have.<sup id="fnref:63"><a href="#fn:63" class="footnote" rel="footnote" role="doc-noteref">63</a></sup></li>
  <li>According to “<a href="https://www.dosdays.co.uk/topics/typical_pc_per_year.php"><strong>Typical PCs Each Year</strong></a>”, the following ranges of system memory were typical for PCs sold in the specified years:<sup id="fnref:64"><a href="#fn:64" class="footnote" rel="footnote" role="doc-noteref">64</a></sup>
    <ul>
      <li>1994: 4MB to 8 MB, with more expensive PCs having 16 MB.<sup id="fnref:65"><a href="#fn:65" class="footnote" rel="footnote" role="doc-noteref">65</a></sup></li>
      <li>1997: 8MB to 32MB.<sup id="fnref:66"><a href="#fn:66" class="footnote" rel="footnote" role="doc-noteref">66</a></sup></li>
      <li>1998: 32MB to 128MB.<sup id="fnref:67"><a href="#fn:67" class="footnote" rel="footnote" role="doc-noteref">67</a></sup></li>
    </ul>
  </li>
</ul>

<p><a id="Seeking_Comments"></a></p>

<h3 id="seeking-comments">Seeking Comments</h3>

<p>As with the rest of this open-source article, <a href="https://www.reddit.com/r/retrogamedev/comments/1rl36fo/pre2000_computer_graphics_for_modern_video_games/"><strong>comments on this specification</strong></a> are welcome.  But most useful would be comments that improve or refine the specification to fit the graphics abilities of pre-2000 video games.</p>

<p>Examples are comments that give <em>measurements</em> (or references to other works that make such measurements) on the graphics capabilities 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: <em>measurements</em>, not inferences or guesses from screenshots or videos.)</p>

<p>This includes statements like the following, with references or measurements:</p>

<ul>
  <li>“Game X shows up to Y polygons at a time at Z frames per second and screen resolution W”.<sup id="fnref:68"><a href="#fn:68" class="footnote" rel="footnote" role="doc-noteref">68</a></sup></li>
  <li>“Scenes in game X have Y triangles on average”.</li>
  <li>“Game X shows no more than [16 or 256] simultaneous colors”.</li>
  <li>“Game X uses Y bytes of memory while running on Windows 98”.</li>
  <li>“Game X shows up to Y sprites at a time [at screen resolution Z]” (for 2-D games such as those built using the tool Director, then by Macromedia).</li>
  <li>The 2-D game X, from year Y, supports a <a href="https://peteroupc.github.io/graphicsapi.html#2_D_Graphics"><strong>given 2-D graphics capability</strong></a> (for example, 2-D rotations of sprites; filling ellipses with a solid color; flood filling; antialiasing of lines and shapes; translucent alpha blending; translucent sprites).</li>
  <li>The 3-D game X, from year Y, supports a <a href="https://peteroupc.github.io/graphicsapi.html#3_D_Graphics"><strong>given 3-D graphics capability</strong></a> (for example, texture mapping, Gouraud shading, bump mapping, edge antialiasing, alpha blending, texturing of most polygons in a scene, or MIP mapping).</li>
</ul>

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

<p>Statements like the following are also useful, with references:</p>

<ul>
  <li>“In year X [1999 or earlier], Y% of PC users used screen resolution Z”.</li>
  <li>In year X, a given 3-D graphics capability became typical in 3-D video games.</li>
  <li>In year X, a given 2-D graphics capability became typical in 2-D video games.</li>
  <li>“In year X [1999 or earlier], Y% of home computers in use were equipped with Z million bytes of memory”.</li>
  <li>“In year X, Y% of home PCs were equipped with 3-D video cards”.</li>
  <li>A market-share-weighted average of system memory requirements of video games in year X.</li>
  <li>On a market-share-weighted basis, X% of video games in year Y—
    <ul>
      <li>ran on [16 or 256]-color display modes, or</li>
      <li>were 3-D video games, or</li>
      <li>were played on arcade machines, or</li>
      <li>were played on PCs, or</li>
      <li>were played on game console Z.</li>
    </ul>
  </li>
</ul>

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

<ul>
  <li>“Game console X can process up to Y triangles per second”.</li>
  <li>“Video card X can render up to Y polygons per frame”.</li>
  <li>“Video card X can render up to Y pixels per second”.</li>
  <li>“Game X renders Y triangles per second”, without stating the frame rate or the screen resolution.</li>
  <li>“Game X issues Y draw calls per frame”, since a single draw call can draw one triangle or tens of thousands.</li>
  <li>“Character models in game X average Y triangles”.</li>
</ul>

<p>The following are examples of the kind of statements desired:</p>

<ul>
  <li><em>Actua Soccer</em> (<em>VR Soccer ‘96</em>) (1995) <a href="http://www-graphics.stanford.edu/~bjohanso/asoccer_stats/"><strong>averaged 776 triangles per frame</strong></a> at 640 × 480 resolution.</li>
  <li><em>Terminal Velocity</em> (1995) <a href="http://www-graphics.stanford.edu/~bjohanso/tv_stats/"><strong>averaged 498 triangles per frame</strong></a> at 640 × 480 resolution.</li>
  <li>A benchmark of <em>Quake III Arena</em> averaged about 3,250 and topped out at about 6,970 triangles per frame after back-face culling, at screen resolution 640 × 480 (Antochi et al. 2003)<sup id="fnref:69"><a href="#fn:69" class="footnote" rel="footnote" role="doc-noteref">69</a></sup>, (Antochi et al. 2004)<sup id="fnref:70"><a href="#fn:70" class="footnote" rel="footnote" role="doc-noteref">70</a></sup>.</li>
</ul>

<p><a id="Further_Reading"></a></p>

<h3 id="further-reading">Further Reading</h3>

<ul>
  <li>Abrash, M., <a href="https://github.com/jagregory/abrash-black-book"><strong><em>Michael Abrash’s Graphics Programming Black Book: Special Edition</em></strong></a>, 1997.</li>
  <li>(Akenine-)Möller, T., Haines, E., <em>Real-Time Rendering</em> (first edition), 1999.</li>
  <li>Donnelly, P., “Moving Your Game to Windows, Part III: Sound, Graphics, Installation, and Documentation”, Microsoft Developer Network, Nov. 25, 1996.</li>
  <li>Lamothe, A., <em>Black Art of 3D Game Programming</em>, Waite Group Press, 1995.</li>
  <li>Lamothe, A., <em>Tricks of the 3D Game Programming Gurus: Advanced 3D Graphics and Rasterization</em>, Sams, 2003. Published after 1999, but most of the 3-D capabilities discussed there are within the spirit of this specification.</li>
  <li>Lamothe, A., <em>Tricks of the Windows Game Programming Gurus</em>, Sams, 1999.</li>
  <li>Roca, Jordi, et al., “<a href="https://ieeexplore.ieee.org/abstract/document/4086130"><strong>Workload Characterization of 3D Games</strong></a>”, <em>2006 IEEE International Symposium on Workload Characterization</em>. IEEE, 2006.  Study on measuring certain features of 3-D games that are of interest in this specification, including triangles per frame.  See the <a href="https://github.com/attila-gpu/attila-sim"><strong><code>attila-sim</code> repository</strong></a>.</li>
  <li>Rodent, H., “Animation in Win32”, Microsoft Developer Network, Feb. 1, 1994.</li>
  <li>Thompson, N., <em>Animation Techniques in Win32</em>, Microsoft Press, 1995.</li>
</ul>

<p><a id="Building_a_Public_Domain_music_synthesis_library_and_instrument_banks"></a></p>

<h2 id="building-a-public-domain-music-synthesis-library-and-instrument-banks">Building a Public-Domain music synthesis library and instrument banks</h2>

<p>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.</p>

<ul>
  <li>A cross-platform open-source library for <em>software</em> synthesis (translation into digitized sound) of MIDI data stored in standard MIDI files (SMF, .mid), using instrument sound banks (synthesizer banks) in SoundFont 2 (.sf2), Downloadable Sounds (.dls), and in OPL2, OPL3, and other FM synthesis sound banks, and possibly also in Timidity++/UltraSound patch format (.cfg, .pat). (Similar to <em>Fluidsynth</em>, but in the public domain or under the Unlicense. Instrument sound banks are files that describe how to render MIDI instruments as sound.  In addition, the source code in the nonpublic-domain <em>foo_midi</em>, <em>libADLMIDI</em>, <em>libOPNMIDI</em>, <em>OPL3BankEditor</em>, and <em>SpessaSynth</em> may be useful here, but review their licenses first.)
    <ul>
      <li>The library should support popular loop-point conventions found in MIDI files.</li>
      <li>The library should support seeking of MIDI files such that a pause and resume function can be offered by a media player.</li>
    </ul>
  </li>
  <li>An instrument sound bank for wave-table synthesis of all instruments and percussive (drum) noises in the General MIDI System level 1 specification.
    <ul>
      <li>Instruments should correspond as closely as possible to those in that specification, but should be small in file size or be algorithmically generated.</li>
      <li>Instruments can be generated using the public-domain single-cycle wave forms found in the AdventureKid Wave Form collection, found at: <a href="https://github.com/KristofferKarlAxelEkstrand/AKWF-FREE"><strong>AKWF-FREE</strong></a>.</li>
      <li>The samples for each instrument may, but need not, be generated by an algorithm, such as one that renders the instrument’s tone in the frequency domain.  An example of this is found in <a href="https://github.com/apple/openjdk/blob/xcodejdk14-release/src/java.desktop/share/classes/com/sun/media/sound/EmergencySoundbank.java"><strong><code>com.sun.media.sound.EmergencySoundbank</code></strong></a>, which however is licensed under the GNU General Public License version 2 rather than public domain.</li>
      <li>The instrument sound bank should be in either SoundFont 2 (.sf2) or Downloadable Sounds (.dls) format. See next section on a challenge to writing a guide on sound bank development.</li>
      <li>The volume of all instruments in the sound bank should be normalized; some instruments should not sound louder than others.</li>
    </ul>
  </li>
  <li>An instrument sound bank for FM synthesis of all instruments and percussive noises in the General MIDI System level 1 specification. Instruments should correspond as closely as possible to those in that specification.</li>
</ul>

<p><a id="Other_Challenges_and_Projects"></a></p>

<h2 id="other-challenges-and-projects">Other Challenges and Projects</h2>

<p>Other challenges and projects I make to the computer community.</p>

<p><a id="Classic_desktop_wallpaper"></a></p>

<h3 id="classic-desktop-wallpaper">Classic desktop wallpaper</h3>

<p>See the “<a href="https://peteroupc.github.io/classic-wallpaper"><strong>peteroupc/classic-wallpaper</strong></a>” 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).</p>

<p><a id="Button_and_border_styles_for_classic_interfaces"></a></p>

<h3 id="button-and-border-styles-for-classic-interfaces">Button and border styles for classic interfaces</h3>

<p>See <a href="https://peteroupc.github.io/classic-wallpaper/docs/uielements.html"><strong>“Traditional User-Interface Graphics”</strong></a> 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.</p>

<p><a id="Sound_bank_development_guide"></a></p>

<h3 id="sound-bank-development-guide">Sound bank development guide</h3>

<p>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 <a href="#Building_a_Public_Domain_music_synthesis_library_and_instrument_banks"><strong>building instrument banks, earlier</strong></a>. 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.</p>

<p><a id="Guide_for_creating_3_D_models_in_the_pre_2000_style"></a></p>

<h3 id="guide-for-creating-3-d-models-in-the-pre-2000-style">Guide for creating 3-D models in the pre-2000 style</h3>

<p>Develop a guide for creating 3-D models for use in modern video games that follow the <a href="#Graphics_Challenge_for_Classic_Style_Games"><strong>specification</strong></a> given earlier on classic (pre-2000) 3-D graphics, in a similar vein to “<a href="https://threedium.io/3d-model/game-ready"><strong>Game-Ready 3D Models: Requirements, Creation, and Export</strong></a>” (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.)</p>

<p><a id="Acknowledgments"></a></p>

<h2 id="acknowledgments">Acknowledgments</h2>

<p>I acknowledge the advice of the <code>gameenginedevs</code> community on Reddit.</p>

<p><a id="License"></a></p>

<h2 id="license">License</h2>

<p>Any copyright to this page is released to the Public Domain.  In case this is not possible, this page is also licensed under <a href="https://creativecommons.org/publicdomain/zero/1.0/"><strong>Creative Commons Zero</strong></a>.</p>

<p><a id="Notes"></a></p>

<h2 id="notes">Notes</h2>

<div class="footnotes" role="doc-endnotes">
  <ol>
    <li id="fn:1">
      <p>The following are examples of a graphics library that follows the spirit, even if not the letter, of this specification: <a href="https://github.com/megamarc/Tilengine"><strong><em>Tilengine</em></strong></a>, <a href="https://github.com/rxi/kit/"><strong><em>kit</em></strong></a>, <a href="https://github.com/mattiasgustavsson/dos-like"><strong><em>DOS-like</em></strong></a>, <a href="https://github.com/raysan5/raylib"><strong><em>raylib</em>’s <code>rlsw</code> software renderer</strong></a>.  Michal Strehovský published an <a href="https://migeel.sk/blog/2024/01/02/building-a-self-contained-game-in-csharp-under-2-kilobytes/"><strong>interesting technique to create small game applications</strong></a>, and so did <a href="https://www.codeslow.com/2019/12/tiny-windows-executable-in-rust.html"><strong>Jani Peltonen</strong></a>.<br />I offer a <a href="https://gist.github.com/peteroupc/f1a5d8e45e27123b86b284271cfd802b"><strong>template for Win32 applications</strong></a> that supports 8- and 24-bit-per-pixel game images and paints finished game images using <code>StretchDIBits</code>.<br />By contrast, 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. <a href="#fnref:1" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:2">
      <p>A computer has adequate performance for classic graphics if it achieves a score of—<br />(a) 3108 or more 3D marks on the 3DMark2000 benchmark (640 × 480) when run without graphics acceleration, or<br />(b) 195 or greater on the 3DMark2000 CPU speed test.<br />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). <a href="#fnref:2" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:3">
      <p>One editor specialized for creating classic 3-D models is the open-source tool <a href="https://www.blockbench.net/"><strong><em>Blockbench</em></strong></a>. For classic 3-D scenes, there is the open-source tool <a href="https://trenchbroom.github.io/"><strong><em>Trenchbroom</em></strong></a>. <a href="#fnref:3" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:4">
      <p>This is also known as <em>visible primitives</em> or <em>visible primitives per frame</em>; in the case of polygons or triangles, this is also called <em>visible polygons (per frame)</em> or <em>visible triangles (per frame)</em>. <a href="#fnref:4" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:5">
      <p>If there is interest, this format may instead be: The red and blue components occupy 5 bits each; the green component, 6 bits. <a href="#fnref:5" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:6">
      <p><em>Quake</em> (1996) also employed <em>subdivision rasterization</em> for drawing small and relatively distant triangles whose vertices are rounded to integers, an algorithm likewise in scope here (Abrash (1997), chapter 69). <a href="#fnref:6" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:7">
      <p>Antialiasing “<a href="https://imagequalitymatters.blogspot.com/2011/01/retro-tech-analysis-virtua-racing-md-vs.html"><strong>didn’t appear in home console graphics architectures</strong></a> until the debut of the [Nintendo 64] in late 1996”. <em>Tricks of the Mac Game Programming Gurus</em> (1995) considers antialiasing among the features “unlikely” to be needed in game programming. <a href="#fnref:7" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:8">
      <p>Perspective correction accounts for distance from the viewer: closer objects appear larger.  The lack of perspective correction (as in what is called <em>affine texture mapping</em>), 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. <a href="#fnref:8" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:9">
      <p>It is being considered whether to replace these 2-D limits with one of the following alternatives:<br /><br />1. Instead of tiles, sprites, and layers, the game uses a <em>frame buffer</em> (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 <em>rendered in software</em>.  But I don’t know of a way to describe further restrictions useful for game programming in the mid- to late 1990s style.<br />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.<br />3. Same as (2), but in addition, there are no tiles or 2-D layers (all the graphics are sprites).<br /><br />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. <a href="#fnref:9" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:10">
      <p>The Neo Geo (1990) has only one 2-D layer; the rest of the graphics are sprites drawn below that layer. <a href="#fnref:10" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:11">
      <p>Translucent pixels enable <em>alpha blending</em> techniques (the mixing of one image with another).  But alpha blending was “relatively new to PC games” at the time of <em>Quake</em>’s release in 1996, according to Abrash (1997), and is practically not discussed at all in <em>Tricks of the Mac Game Programming Gurus</em> (1995). Only images with opaque and/or transparent pixels tended to be supported in early-1990s video games. <a href="#fnref:11" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:12">
      <p>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. <a href="#fnref:12" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:13">
      <p>Tile- and sprite-based graphics were in place largely because they saved memory; they were popularized by the arcade game <em>Galaxian</em>.  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.<br />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. <a href="#fnref:13" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:14">
      <p>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 <em>Return of the Obra Dinn</em> employs a two-color 800 × 450 display (378,000 total pixels) (but even so this resolution was <a href="https://forums.tigsource.com/index.php?topic=40832.msg1363742#msg1363742">“up from 640[ × ]350”</a>).<br /><br />In the Godot engine, the screen resolution corresponds to the “Viewport Width” (<code>window/size/viewport_width</code>) and “Viewport Height” (<code>window/size/viewport_height</code>) project settings.  For the Unity engine, there is advice from 2019 relating to the graphics style in <a href="https://blog.unity.com/technology/2d-pixel-perfect-how-to-set-up-your-unity-project-for-retro-8-bits-games"><strong>“8-bit”</strong></a> and <a href="https://blog.unity.com/technology/2d-pixel-perfect-how-to-set-up-your-unity-project-for-retro-16-bit-games"><strong>“16-bit”</strong></a> game consoles.  In Unreal Engine, the screen resolution apparently corresponds to <code>ResolutionSizeX</code> and <code>ResolutionSizeY</code>.  But a lighter-weight graphics engine than Unity, Unreal, or even Godot would better suit the spirit of this specification. <a href="#fnref:14" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:15">
      <p>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.<br />Standard MIDI files organize MIDI commands into up to 16 <em>channels</em>, each occupied by at most one “instrument” at a time.  Under the <em>Multimedia PC Specification</em> (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. <a href="#fnref:15" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:16">
      <p>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:<br /> (1) Segmented liquid crystal displays, of the kind found in Nintendo’s Game &amp; 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.<br />(2) Vacuum fluorescent displays, notable in user interfaces of some media player applications that resemble a “stereo rack system”. <a href="#fnref:16" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:17">
      <p>Examples are the <a href="https://dench.flatlib.jp/app/chiraks_em"><strong>Sharp MI-Zaurus</strong></a> (2000) and the many cellular phones that came with Java Micro Edition, its Mobile Information Device Profile (MIDP, <a href="https://jcp.org/en/jsr/detail?id=37"><strong>Java specification request 37</strong></a> and <a href="https://jcp.org/en/jsr/detail?id=118"><strong>JSR 118</strong></a>), and extensions (especially <a href="https://jcp.org/en/jsr/detail?id=184"><strong>JSR 184, Mobile 3D Graphics API</strong></a>). <a href="#fnref:17" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:18">
      <p>An example is <em>Loom</em> (1990). <a href="#fnref:18" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:19">
      <p>This was recommended for Macintosh games in J. McCornack et al., <em>Tricks of the Mac Game Programming Gurus</em> (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). <a href="#fnref:19" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:20">
      <p>Popular file size limit of so-called “64K intros”. <a href="#fnref:20" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:21">
      <p>MS-DOS applications are normally limited to 640 kibibytes or less of <em>conventional memory</em>, 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. <a href="#fnref:21" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:22">
      <p>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). <a href="#fnref:22" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:23">
      <p>Moreover, PC games before 2000 that required screen resolutions larger than 640 × 480 are rare, and according to PCGamingWiki they include the following games (most of which are 2-D): <em>Timon &amp; Pumbaa’s Jungle Games</em> (1995); <em>Tequila &amp; Boom Boom</em> (1995); <em>Romance of the Three Kingdoms IV: Wall of Fire</em> (1995/1996); <em>Joint Strike Fighter</em> (1997), but only when run with the Glide graphics interface; <em>Links LS: 1998 Edition</em> (1997); <em>Emergency: Fighters for Life</em> (1998); <em>Championship Manager: Season 99/00</em> (1999); <em>Heroes of Might and Magic III</em> (1999); <em>Alien Nations</em> (1999); <em>Pizza Syndicate</em>/<em>Fast Food Tycoon</em> (1999); <em>Age of Empires II: The Age of Kings</em> (1999). <a href="#fnref:23" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:24">
      <p>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 (<em>Blasphemous</em>); 400 × 225 (<em>Unsighted</em>); 480 × 270 (<em>Enter the Gungeon</em>); 320 × 180 (<em>Celeste</em>). <a href="#fnref:24" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:25">
      <p>VGA mode 12h (16 colors). <a href="#fnref:25" class="reversefootnote" role="doc-backlink">&#8617;</a> <a href="#fnref:25:1" class="reversefootnote" role="doc-backlink">&#8617;<sup>2</sup></a></p>
    </li>
    <li id="fn:26">
      <p>PlayStation (One); Nintendo 3DS lower screen; larger VGA “mode X” (256 colors). <a href="#fnref:26" class="reversefootnote" role="doc-backlink">&#8617;</a> <a href="#fnref:26:1" class="reversefootnote" role="doc-backlink">&#8617;<sup>2</sup></a></p>
    </li>
    <li id="fn:27">
      <p>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; <a href="https://blog.johnnovak.net/2022/04/15/achieving-period-correct-graphics-in-personal-computer-emulators-part-1-the-amiga"><strong>Amiga NTSC</strong></a>. <a href="#fnref:27" class="reversefootnote" role="doc-backlink">&#8617;</a> <a href="#fnref:27:1" class="reversefootnote" role="doc-backlink">&#8617;<sup>2</sup></a></p>
    </li>
    <li id="fn:28">
      <p>One commonly supported “super-VGA” mode, especially in mid-1990s gaming, and which was also recommended by the <em>PC 98 System Design Guide</em>. <a href="#fnref:28" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:29">
      <p>One low resolution recommended by the <em>PC 98 System Design Guide</em>. <a href="#fnref:29" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:30">
      <p>Nintendo DS; NEC PC-6001; SEGA Master System/SEGA Mark III; MSX; Colecovision. <a href="#fnref:30" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:31">
      <p>Rarely used VGA display mode. <a href="#fnref:31" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:32">
      <p>PlayStation 2 NTSC. <a href="#fnref:32" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:33">
      <p>SEGA Mega Drive/SEGA Genesis; Neo Geo NTSC. <a href="#fnref:33" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:34">
      <p>Effective resolution of Famicom/Nintendo Entertainment System NTSC; Super Famicom/Super Nintendo Entertainment System NTSC; minimum resolution of PC Engine/TurboGrafx 16. <a href="#fnref:34" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:35">
      <p>Nintendo Entertainment System PAL; Super Nintendo Entertainment System PAL. <a href="#fnref:35" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:36">
      <p>Game Boy Advance. <a href="#fnref:36" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:37">
      <p>Game Boy, Game Boy Color, SEGA Game Gear. <a href="#fnref:37" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:38">
      <p>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. <a href="#fnref:38" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:39">
      <p>Amiga PAL (same pixel spacing horizontally as vertically); Neo Geo PAL. <a href="#fnref:39" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:40">
      <p>PAL overscan. <a href="#fnref:40" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:41">
      <p>Hercules Graphics Card two-color. <a href="#fnref:41" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:42">
      <p>Color/Graphics Adapter (CGA) two-color; NEC PC-8801 8-color mode; Atari ST 4-color mode. <a href="#fnref:42" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:43">
      <p>12-inch classic Macintosh. <a href="#fnref:43" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:44">
      <p>16 colors. <a href="#fnref:44" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:45">
      <p>NEC PC-9801 8-color mode; Atari ST two-color. <a href="#fnref:45" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:46">
      <p>Apple II. <a href="#fnref:46" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:47">
      <p>PlayStation Portable. <a href="#fnref:47" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:48">
      <p>MSX 2. <a href="#fnref:48" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:49">
      <p>Effective resolution of Nintendo 3DS upper screen without parallax effect. <a href="#fnref:49" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:50">
      <p>Virtual Boy. <a href="#fnref:50" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:51">
      <p>One “Tandy graphics adapter” mode. <a href="#fnref:51" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:52">
      <p>Minimum resolution for “handheld PCs” (<em>Windows CE Programmer’s Guide</em>, MSDN Library, June 1998). <a href="#fnref:52" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:53">
      <p>S. Pruitt, “Frequently Asked Questions About HTML Coding for Internet Explorer 3.0”, updated Jan. 30, 1997. <a href="#fnref:53" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:54">
      <p>Fabien Sanglard, <em>Game Engine Black Book: Doom</em>. <a href="#fnref:54" class="reversefootnote" role="doc-backlink">&#8617;</a> <a href="#fnref:54:1" class="reversefootnote" role="doc-backlink">&#8617;<sup>2</sup></a></p>
    </li>
    <li id="fn:55">
      <p>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 <em>Multimedia PC Specification</em> (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 &amp; 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. <a href="#fnref:55" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:56">
      <p>Stands for the National Television Standards Committee of the Electronics Industries Association.  “NTSC” often refers to the video standard known as RS-170A. <a href="#fnref:56" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:57">
      <p>Stands for phase alternating line. <a href="#fnref:57" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:58">
      <p>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 <a href="https://retro.swarm.cz/sgi-irisvision-add-in-3d-accelerator-for-pc-1990/"><strong>introduced in 1988</strong></a>. <a href="#fnref:58" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:59">
      <p>CRT displays, or cathode-ray-tube displays, were the typical kind of computer monitors and TVs in the 1980s and 1990s. <a href="#fnref:59" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:60">
      <p>Effects to scale the game screen include so-called “pixel-art scaling algorithms” such as <code>HQX</code> and <code>2xSaI</code>, as well as bilinear or point filtering.<br />Effects to scale the game screen do not include the decoding of small videos to fit the <em>game screen</em>, 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, “<a href="https://learn.microsoft.com/en-us/previous-versions/ms969922(v=msdn.10)"><strong>Stretching 256-Color Images Using Interpolation</strong></a>”, Microsoft Developer Network, March 7, 1995.) <a href="#fnref:60" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:61">
      <p>Sound today is most commonly digitized by pulse-code modulation (PCM), and PCM-digitized sound is often stored in computer files ending in “.WAV”. <a href="#fnref:61" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:62">
      <p>The <em>Multimedia PC Specification</em> (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. <a href="#fnref:62" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:63">
      <p>PC games released in 1999 tended to require 32 million bytes of system memory.  Meanwhile, <em>Quake</em> (1996) required 8 million and recommended 16 million bytes of system memory. <a href="#fnref:63" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:64">
      <p>“MB” is ambiguous here; it often means either one million bytes or 1024 times 1024 bytes. <a href="#fnref:64" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:65">
      <p>“Typical PCs in 1994”, <a href="https://www.dosdays.co.uk/topics/1994.php."><strong>https://www.dosdays.co.uk/topics/1994.php.</strong></a> <a href="#fnref:65" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:66">
      <p>“Typical PCs in 1997”, <a href="https://www.dosdays.co.uk/topics/1997.php."><strong>https://www.dosdays.co.uk/topics/1997.php.</strong></a> <a href="#fnref:66" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:67">
      <p>“Typical PCs in 1998”, <a href="https://www.dosdays.co.uk/topics/1998.php."><strong>https://www.dosdays.co.uk/topics/1998.php.</strong></a> <a href="#fnref:67" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:68">
      <p>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:<br />(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”, <em>Microsoft Systems Journal</em> January 1999).<br />(2) “For context, <em>Quake</em> on a Pentium Pro pumped out maybe 100K triangles/second (tris/sec.) … at best” (M. Abrash, “Inside Xbox Graphics”, <em>Dr. Dobb’s Journal</em>, August 2000); to be noted here is that the game normally ran at a screen resolution of 320 × 240.<br />(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.<br />(4) The game engine for <em>SpecOps: Rangers Lead the Way</em> (1998) targeted 10,000 triangles per frame (<a href="https://www.gamedeveloper.com/design/postmortem-zombie-s-i-specops-rangers-lead-the-way-i-"><strong>“Postmortem: Zombie’s <em>SpecOps: Rangers Lead the Way</em>“</strong></a>, Jan. 31, 2000).  So did <em>Quake III Arena</em> (1999) (John Carmack .plan, Sep. 2, 1999). <a href="#fnref:68" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:69">
      <p>Antochi, Iosif, et al. “3D Graphics Benchmarks for Low-Power Architectures.” 14th Annual Workshop on Circuits, Systems and Signal Processing. 2003. <a href="#fnref:69" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:70">
      <p>Antochi, Iosif, et al., “GraalBench: a 3D graphics benchmark suite for mobile phones”, <em>ACM SIGPLAN Notices</em> 39(7), 2004. <a href="#fnref:70" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
  </ol>
</div>
</div><nav id="navigation"><ul>
<li><a href="/">Back to start site.</a>
<li><a href="https://github.com/peteroupc/peteroupc.github.io">This site's repository (source code)</a>
<li><a href="https://github.com/peteroupc/peteroupc.github.io/issues">Post an issue or comment</a></ul>

<div class="noprint">
<p>
<a href="//x.com/intent/post?text=Graphics+and+Music+Challenges+for+Classic-Style+Computer+Applications&url=https%3A%2F%2Fpeteroupc.github.io%2Fgraphics.html">Share via X (Twitter)</a>, <a href="//www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fpeteroupc.github.io%2Fgraphics.html">Share via Facebook</a>, <a href="//news.ycombinator.com/submitlink?u=https%3A%2F%2Fpeteroupc.github.io%2Fgraphics.html&t=Graphics+and+Music+Challenges+for+Classic-Style+Computer+Applications">Share via Hacker News</a>, <a href="//www.reddit.com/submit?url=https%3A%2F%2Fpeteroupc.github.io%2Fgraphics.html&title=Graphics+and+Music+Challenges+for+Classic-Style+Computer+Applications">Share via Reddit</a>
</p>
</div>
<p style='font-size:120%;font-weight:bold'><a href='https://peteroupc.github.io/graphics.pdf'>Download a PDF of this page</a></p><p>Of interest to the computer graphics and music community:</p><ul><li><a href='https://peteroupc.github.io/graphics.html'><b>Graphics for classic-style game development</b></a>.<li><a href='https://peteroupc.github.io/graphics.html#Building_a_Public_Domain_music_synthesis_library_and_instrument_banks'><b>MIDI music synthesis for classic-style games and apps</b></a>.<li><a href='https://peteroupc.github.io/classic-wallpaper'><b>Tileable wallpapers with limited colors and resolution</b></a>.<li><a href='https://peteroupc.github.io/graphicsapi.html'><b>Lean programming interfaces for classic graphics</b></a>.<li><a href='https://peteroupc.github.io/classic-wallpaper/docs/uielements.html'><b>Traditional user-interface graphics</b></a>.<li><a href='https://peteroupc.github.io/classic-wallpaper/docs/pixeltovector.html'><b>Converting images to vector graphics</b></a>.</ul><p>Open questions for math and probability experts:</p><ul><li><a href='https://peteroupc.github.io/requests.html'><b>Requests and open questions</b></a>.<li><a href='https://peteroupc.github.io/bernreq.html'><b>Open questions on the Bernoulli factory problem (the new-coins-from-old problem)</b></a>.<li><a href='https://peteroupc.github.io/requestsother.html'><b>Other open questions on probability</b></a>.<li><a href='https://peteroupc.github.io/sampling.html'><b>The sampling problem</b></a>.</ul></nav></body></html>