Usage of Today's Technology in Creating Authentic '8-Bit' and '1

Home , Game Gear, Jake Kaufman, Karaoke, M2 (game developer), Master System, Mode 7

CALIFORNIA STATE UNIVERSITY, NORTHRIDGE

Renegade Drive: Usage of Today’s Technology in Creating Authentic ‘8-bit’ and

‘16-bit’ Video Game Experiences

A thesis submitted in partial fulfillment of the requirements

For the degree of

Master of Science in Computer Science

Christian Guillermo Bowles

December 2017

ii The thesis of Christian Guillermo Bowles is approved:

______

Prof. Caleb Owens Date

______

Dr. Robert McIlhenny Date

______

Dr. Li Liu, Chair Date

California State University, Northridge

iii Acknowledgements

The author wishes to thank the following individuals and organizations for their contributions and support towards this thesis project:

• Doris Chaney

• Dr. G. Michael Barnes

• Dr. Richard Covington

• Dr. Peter Gabrovsky

• Dr. Ani Nahapetian

• Lauren X. Pham

• Chase Bethea

• Caleb Andrews

• Sean Velasco

• Ian Flood

• Nick Wozniak

• David D’Angelo

• Shannon Hatakeda

• Jake Kaufman

• CSUN Game Development Club

• Animation Student League of Northridge

• CSUN Anime Club

• Yacht Club Games

• Mint Potion TV

iv Table of Contents

Signature Page iii

Acknowledgements iv

List of Figures x

List of Tables xiv

Abstract xv

Introduction 1

Chapter 1: Hardware Limitations of the Nintendo Entertainment System 3

• Screen Resolution 3

• Tile Patterns 4

• Layers 4

• Sprites 6

• Palettes 7

• Audio 8

• Input 10

Chapter 2: Hardware Limitations of the Sega Master System 12

• Screen Resolution 12

• Tile Patterns 13

• Layers 14

• Sprites 15

• Palettes 15

• Audio 16

• Input 17 v Chapter 3: Hardware Limitations of the Nintendo Game Boy 18

• Screen Resolution 18

• Tile Patterns 19

• Layers 20

• Sprites 21

• Palettes 22

• Super Game Boy 23

• Game Boy Color 25

• Audio 32

• Input 33

Chapter 4: Hardware Limitations of the Sega Game Gear 34

• Screen Resolution 34

• Tile Patterns 35

• Layers 35

• Sprites 36

• Palettes 37

• Audio 38

• Input 39

Chapter 5: Hardware Limitations of the Super Nintendo 40

• Screen Resolution 40

• Dynamic Memory Allocation 41

• Tile Patterns 42

• Layers 44 vi • Sprites 45

• Palettes 46

• Graphical Modes 47

• Additional Graphical Effects 54

• Expansion Chips 61

• Audio 63

• Input 64

• Hardware Extensions and Other Similar Systems 65

Chapter 6: Hardware Limitations of the Sega Genesis 70

• Screen Resolution 70

• Dynamic Memory Allocation 72

• Tile Patterns 72

• Layers 73

• Sprites 76

• Palettes 78

• Additional Hardware Features 80

• Expansion Chips 81

• Audio 82

• Input 83

• Hardware Extensions and Other Similar Systems 85

Chapter 7: Comparing the Hardware Limitations of Each System 90

• Screen Resolution 90

• Tile Patterns 92 vii • Layers 94

• Sprites 97

• Palettes 100

• Audio 103

• Input 104

Chapter 8: Shovel Knight – An example of a Retro-Styled Video Game 107

• Screen Resolution 108

• Tile Patterns 109

• Layers 110

• Sprites 111

• Palettes 112

• Audio 113

• Input 114

Chapter 9: Renegade Drive Software Design 115

• Screen Resolution 116

• Tile Patterns 117

• Layers 118

• Sprites 119

• Palettes 120

• Audio 121

• Input 122

Chapter 10: Renegade Drive Implementation 123

• GameMaker Studio 123 viii • Project File Structure 124

• Tech Demos Produced Using Renegade Drive 125

• Video Games Produced Using Renegade Drive 127

• Future Renegade Drive Development 128

Conclusion 129

References 130

ix List of Figures

1.1 The Nintendo Entertainment System 3

1.2 Screenshot from Super Mario Bros. 3 4

1.3 Screenshot from Super Mario Bros. 3 (only layers) 5

1.4 Screenshot from Super Mario Bros. 3 (only sprites) 6

1.5 6-bit color spectrums 8

1.6 The Famicom Disk System 10

1.7 The NES and Famicom controllers 11

2.1 The Sega Master System 12

2.2 Screenshot from Sonic Chaos (the Master System version) 13

2.3 The Master System controller 17

3.1 The Nintendo Game Boy 18

3.2 Screenshot from Super Mario Land 2 19

3.3 The Super Game Boy 23

3.4 Screenshot from Donkey Kong (the Super Game Boy version) 24

3.5 The Game Boy Color 25

3.6 Screenshots from Kirby’s Dream Land 27

3.7 Screenshots from Pokémon Red Version 28

3.8 Screenshots from Pokémon Gold Version 29

3.9 Screenshots from Mega Man X-Treme 30

3.10 Screenshots from Shantae 31

3.11 Two Game Boys connected via the Game Link Cable 33

4.1 The Sega Game Gear 34

x 4.2 Screenshot from Sonic Chaos (the Game Gear version) 35

4.3 Two Game Gears connected via the Gear-to-Gear Cable 39

5.1 The Super Nintendo Entertainment System 40

5.2 SNES color entries organized as color palettes 46

5.3 Screenshot from Super Mario World 48

5.4 Screenshot from Tetris Attack 49

5.5 Title screen from Super Mario All-Stars 51

5.6 Screenshot from Seiken Densetsu 3 52

5.7 Screenshot from F-Zero 54

5.8 Screenshots from Final Fantasy IV 55

5.9 Screenshot from R.P.M. Racing 56

5.10 Screenshot from Kirby’s Dream Land 3 57

5.11 Screenshot from Mega Man 7 58

5.12 SNES color arithmetic operation examples 59

5.13 Screenshot from EarthBound 60

5.14 SNES visibility region examples 60

5.15 Screenshot from Super Metroid 61

5.16 Screenshots from Star Fox and Mega Man X2 62

5.17 The SNES controller 64

5.18 Concept art of the SNES-CD 65

5.19 Screenshot from Super Mario Advance 66

5.20 Cutscene from Mario vs. Donkey Kong 67

5.21 The Game Boy Advance and Game Boy Advance SP 68

xi 5.22 The Nintendo DS and Nintendo DSi 69

6.1 The Sega Genesis 70

6.2 Screenshots from Sonic the Hedgehog and 71

Mega Man: The Wily Wars

6.3 Screenshot from Sonic & Knuckles 75

6.4 Screenshots from Sonic the Hedgehog 3 79

6.5 Screenshot from Sonic the Hedgehog 2 80

6.6 Screenshot from Virtua Racing 81

6.7 The three-button Genesis controller 83

6.8 The six-button Genesis controller 84

6.9 The Sega CD attached to the Sega Genesis 85

6.10 The Sega 32X attached to the Sega Genesis 86

6.11 The NEC PC-9801 and SNK Neo Geo 87

6.12 Screenshots from Touhou Gensoukyou: Lotus Land Story and 88

Madou Monogatari 2

6.13 Screenshot from Metal Slug: Super Vehicle-001 89

7.1 Different shade possibilities for the color red 102

8.1 Shovel Knight poster 107

8.2 Screenshot from Shovel Knight 108

8.3 Palette-cycling example 113

9.1 Renegade Drive logo 115

10.1 The current GameMaker Studio logo 123

10.2 GameMaker Studio project example 124

xii 10.3 Screenshots from the Graphics Demo and Input Demo 126

10.4 Screenshot from Floatie’s Block Ball 127

10.5 Screenshot from Disco Dog Discord 128

xiii List of Tables

7.1 List of screen resolution limitations 90

7.2 List of tile pattern limitations 92

7.3 List of layer limitations 94

7.4 List of layer tile attributes 96

7.5 List of sprite limitations 97

7.6 List of sprite attributes 98

7.7 List of palette limitations 100

7.8 List of audio limitations 103

7.9 List of input limitations 104

7.10 Recommended inputs as implemented on keyboards and 105

controllers

9.1 List of Renegade Drive palette specifications 120

xiv Abstract

Renegade Drive

Usage of Today’s Technology in Creating Authentic ‘8-bit’ and ‘16-bit’ Video

Game Experiences

Christian Guillermo Bowles

Master of Science in Computer Science

Imagine being able to travel 20 to 30 years back in time and creating brand new ‘8-bit’ or ’16-bit’ video games. This thesis introduces Renegade Drive, a set of technical software design specifications that serve as guidelines for the creators of modern day retro-styled ‘8-bit’ and ‘16-bit’ video games to abide by throughout development. The project was conceived by analyzing the hardware design limitations of ‘8-bit’ and ‘16-bit’ video game systems that were released between the mid-1980s to the mid-1990s. Renegade Drive shows how to bring the same aesthetic look and feel of video games from decades past into modern day video game projects. With Renegade Drive, the possibility of producing a nostalgic retro gaming experience will become a reality, with no time travel necessary. This thesis also reviews the pros and cons of each analyzed video game system’s features, as well as Renegade Drive’s implementation into code as source files for a modern day 2D video game engine.

xv Introduction

In the year 1985, the Nintendo Entertainment System was released in

America, where it became a commercial success [1]. The appeal of its ‘8-bit’ video games amongst consumers came from their simplistic 2D graphics and hardware-generated audio. However, game developers had to struggle with a difficult architecture in which to create content for.

As time went on, newer video game systems with higher fidelities of 2D graphics and audio were released. The Sega Genesis and Super Nintendo

Entertainment System were two such examples of ‘16-bit’ consoles [2]. Each one featured more sophisticated architectures for developers, resulting in more colorful and engaging games. The rivalry of 2D video game development between these two systems became infamously known as the first “Console War” [3].

In 1996 however, Nintendo released the Nintendo 64, a console that emphasized 3D graphics in games [1]. Game development companies followed suit, and producing 3D video games became the new standard, effectively abandoning 2D graphics.

It has been approximately 20 years since that transition occurred. 2D video games have recently re-emerged from smaller development groups, and their target audiences include gamers nostalgic for the “glory days” of the past [4]. In order to capitalize off of this market, this thesis proposes Renegade Drive – a set of technical design limitations with which video game developers can use in order to create modern computer games that function identically to the retro-styled console games from 20 to 30 years ago.

1 This project will involve researching the technical hardware limitations of the North American video game systems (both console and handheld) that were released by Nintendo and Sega between the years of 1985 to 1991.

• Nintendo Entertainment System (1985)

• Sega Master System (1986)

• Nintendo Game Boy (1989)

• Sega Game Gear (1991)

• Super Nintendo Entertainment System (1991)

• Sega Genesis (1989)

During each system’s analysis, their graphics (screen resolution, tile patterns, layers, sprites & palettes), audio and input limitations will be covered, as well as the unique hardware-related features that each one had to offer.

Once analyzed, the hardware design limitations from each category will be compared system-by-system, as well as compared with modern day game design.

A recently released video game that functions like a retro video game will also be analyzed in order to contrast the many possible retro game design approaches.

From here, new software design limitations will be conceived, based upon the comparisons and contrasts made. They will be divided into variations based on time periods, each with different graphical and audio aesthetics. They will also be implemented into code as source files for a modern day 2D game engine. By following these limitations, developers will be able create marketable 2D video games that deliver the same aesthetic look and feel as video games from decades past, but with modern day conveniences and design choices integrated into them.

2 Chapter 1: Hardware Limitations of the Nintendo Entertainment System

Figure 1.1 – The Nintendo Entertainment System. Credit: Nintendo.

The Nintendo Entertainment System (abbreviated as NES) is an 8-bit video game console that was first released by Nintendo in North America during

October 1985 [5]. It was originally released in Japan during July 1983 under the name “Family Computer” (abbreviated as Famicom or FC) [6].

Screen Resolution

The NES had a resolution of 256 pixels wide and 240 pixels tall.

However, most televisions at the time only ever displayed the middle 224 rows of pixels, effectively making the visibility 256x224 [7]. Within the display resolution was three types of graphics: base colors, layers and sprites. Base colors always consisted of a single color that served as the background. Layers consisted of tiles

(8x8 pixels in size) arranged into uniform grids, and drawn in front of base colors.

Sprites consisted of one or two tiles (8x8 or 8x16 pixels respectively) that could independently move around to anywhere on screen and could be drawn in front of layers or behind them.

Figure 1.2 – Screenshot from Super Mario Bros. 3. Credit: Nintendo.

Tile Patterns

The NES’s 8x8 tiles were capable of displaying 16-byte tile patterns that were stored in the system’s VRAM (video random access memory). This memory was 8,192 bytes in size, which meant that there was room for 512 tile patterns [8].

However, layer tiles and 8x8 sprites could each display only 1 of 256 tile patterns at any given time. This meant that layers could only utilize the top half or bottom half of VRAM for patterns, with all sprites utilizing the other half. The only exception to this was 8x16 sprites, which displayed two back-to-back tile patterns from all 512 (256 choices total).

Layers

For the NES, only one layer could be displayed on screen. It could be made up of tiles in the arrangements of 32x30, 64x30 or 32x60, depending on whether the layer needed to perform horizontal or vertical scrolling [9]. Each of

4 these tiles had a 1-byte pattern index and a 2-bit palette index. However, the 2-bit palette index was shared amongst four tiles [10]. This meant that layers could be

1,024 bytes or 2,048 bytes in size (with 4 and 8 unused bytes, respectively).

The layer was displayed on screen by 240 horizontal scanlines (each 256 pixels in width) that rendered a portion of it from an x/y coordinate offset. These scanlines could collectively move horizontally or vertically and could wrap around the layer horizontally or vertically. By changing the x offsets between scanline renders, they could move independently of each other horizontally in order to give off the illusion of parallax scrolling (for example, slow-moving clouds with fast-moving grass beneath them) [11]. Games released late into the system’s lifetime featured enhancement chips that even allowed for scanlines to move independently of each other vertically in order to display two views on the screen at once (for example, a scrolling stage with a static HUD below it).

Figure 1.3 – Screenshot from Super Mario Bros. 3, displaying only the layer. Credit: Nintendo.

5 Sprites

For the NES, a maximum of 64 sprites could ever be present at once (256 bytes total). All sprites could be either 1 or 2 tile patterns in size (8x8 or 8x16 pixels respectively), which meant that a maximum of 64 or 128 sprite tile patterns could ever be present at once. However, only 8 sprites (or sprite patterns) could be displayed horizontally without the infamous “flicker” effect occurring, where 9 or more did not always display at once on screen. Each sprite was four bytes long and featured an x offset, a y offset, a pattern index (each with values between 0 to

255), a 2-bit palette index, a single bit for determining horizontal flipping, a single bit for determining vertical flipping & a single bit for draw priority, which determined whether the sprite was drawn in front of the layer or behind it [12].

Each sprite was drawn on screen based on its position within the sprite array. (For example, sprite 0 was rendered before sprite 1, and so on.)

Figure 1.4 – Screenshot from Super Mario Bros. 3, displaying only the sprites. Credit: Nintendo.

6 Palettes

The tile patterns for sprites and layer tiles could display up to 3 different colors, as well as transparency for displaying anything underneath. This was done by having all 64 pixels in a tile pattern represented as one of four index numbers:

0 through 3. All four indices correlated to a palette of colors that filled in the tile pattern, resulting in the image on screen (with index 0 always representing transparency). For layers, 2x2 sections of tiles shared the same palette, while the patterns (one or two) of a given sprite shared the same palette.

The NES had eight palettes, with four for layers to use, and four for sprites to use. As an example, four sprites could each have a different palette assigned to them, thus collectively displaying 12 unique colors. To add to this, a layer could have four quadrants of tiles, each using different palettes – also collectively displaying 12 unique colors [13]. All together, this meant that the NES was capable of displaying a maximum of 25 colors at any given time: 1 background color, 12 layer colors (where each 3 belonged to 1 of 4 palettes) and 12 sprite colors (where each 3 belonged to 1 of 4 palettes).

Each palette held 3 out of 56 color values (1 byte each), which came from a YPBPR color space. (Technically 64 values, but 8 of them are redundant [13].)

At the time, it was more conventional for hardware to use an RGB spectrum to represent color values. An example of such a spectrum is the 6-bit RGB color space, which allocated 2 bits to the red green and blue channels. As a result, each channel had 4 possibilities, which when multiplied out, allowed for 64 possible color values. Other RGB spectrum variations include 9-bit (512 colors), 12-bit

7 (4,096 colors), 15-bit (32,768 colors), 18-bit (262,144 colors), 21-bit (2,097,152 colors) and 24-bit (16,777,216 colors).

However, the most critical downside for hardware using RGB spectrums at the time was the illegal pirating of software – in which color values could be easily modified in order to “create” new software with different looking colors.

For this reason, Nintendo chose to utilize a 6-bit YPBPR color space instead of a 6- bit RGB color space for its NES hardware. As a result, 25 out of 56 colors could potentially be achieved at any one time on the NES, yielding a color display percentage of 44.6%.

Figure 1.5 – The NES’s 6-bit YPBPR spectrum (top) vs. the standard 6-bit RGB spectrum (bottom).

Audio

The NES was capable of playing five hardware-generated mono audio channels at any given time. This included two channels for square wave samples, one for triangle wave samples, one for noise wave samples, and one for pulse- code modulation samples [14]. These channels played at a rate of 22,050 Hz. Both music tracks and sound effects were fed into these channels from proprietary track sheet audio files. Rather than WAV or MP3 files, which are very large in size and 8 consist of raw audio sample data, Nintendo’s track sheet files were very light in size and consisted of arranged notes that were generated by the system’s audio channels at runtime.

However, both music tracks and sound effects had to compete for audio generation within the channels. For example, if a music track was playing notes on the triangle channel and a suddenly executed sound effect also used the triangle channel, then the music track notes were cancelled out and the sound effect notes were played instead. Once the sound effect finished, the music track notes continued playing on the channel just as before. Furthermore, it was not possible to play either multiple sound effects at once or multiple music tracks at once. For example, if a sound effect was playing, and suddenly interrupted by another (the same type or different), then the current one terminated and the new one began playing in its place.

The Japanese version of the NES (the Famicom) supported a number of audio extensions that added upon the system’s audio chip (the Ricoh 2A03 for

NTSC region systems and the Ricoh 2A07 for PAL region systems). These additions were done through the usage of memory expansion chips embedded on cartridges. When utilized, these chips allowed for additional channels of audio to play during a game’s runtime, effectively expanding the audio capabilities of the game. The most famous of these chips was Konami’s VRC6 chip, which provided two additional square wave channels and a saw tooth wave channel, bringing the total number of possible audio channels for a game up to 8 [15]. The Japan- exclusive Famicom Disk System, (an add-on to the Famicom that played disk-

9 based games instead of cartridge-based games) utilized the Ricoh 2C33, which provided an additional channel of wavetable-modulated audio to be played during runtime [16]. Other examples of embedded audio-enhancing chips include

Konami’s VRC7 chip, Namco’s N163 chip and Sunsoft’s 5B chip.

Figure 1.6 – The Famicom Disk System. Credit: Nintendo.

Input

The NES utilized a controller that had 8 inputs: a D-pad (Up, Down, Left

& Right) and four buttons (A, B, Start & Select) [5]. The D-pad was used for movement in games, where it was not possible to press Left and Right simultaneously, as well as Up and Down. However, Left or Right could be pressed in combination with Up or Down, allowing for 1 of 8 directional inputs on the D-pad. The A and B buttons were used for action inputs in games, while the Start and Select buttons were used for non-action inputs. 10 Because the NES was marketed as a two-player gaming console, up to two controllers could be connected to the system. But unlike the NES, whose controllers could be disconnected from the system, the Famicom’s controllers were hardwired and could not be disconnected. In addition to this, the Famicom’s second controller lacked the Start and Select buttons, making them exclusive to the first controller [6]. Instead, a microphone was built into the second controller, which allowed games to utilize audio-sensitive functions, such as karaoke.

Figure 1.7 – The NES controller (top) and the Famicom controllers (bottom). Credit: Nintendo.

11 Chapter 2: Hardware Limitations of the Sega Master System

Figure 2.1 – The Sega Master System. Credit: Sega.

The Sega Master System (abbreviated as Master System or MS) is an 8-bit video game console that was first released by Sega in North America during

September 1986 [17]. It was originally released in Japan during October 1985 under the name “Sega Mark III” (abbreviated as Mark III or Mk3) [18].

Screen Resolution

The Master System had a resolution of 256 pixels wide and 240 pixels tall.

Like the NES, most televisions at the time only displayed 224 rows of pixels, making the visibility 256x224. However, the majority of Master System games only utilized the middle 192 rows of pixels (256x192), with empty borders above and below the display [19]. Also like the NES, the Master System had three types of graphics within its display resolution: base colors, layers and sprites. Base colors consisted of a single background color, layers consisted of 8x8 tiles arranged into uniform grids, and sprites consisted of one or two 8x8 tiles that could independently move around to anywhere on screen.

Figure 2.2 – Screenshot from Sonic Chaos (the Master System version). Credit: Sega.

Tile Patterns

The Master System’s 8x8 tiles were capable of displaying 32-byte tile patterns that were stored in the system’s VRAM. This memory was 16,384 bytes in size and was used to store tile patterns, the layer & sprites [19]. Tile patterns were allocated 14,336 bytes, the layer was allocated 1,792 bytes and sprites were allocated 256 bytes. This meant that there was room for 448 tile patterns.

Layer tiles could each display 1 of 512 tile patterns at any given time, which included the 448 normal patterns and 64 “glitched” patterns, which were actually just the layer and sprite data in memory [19]. (Because layers and sprites changed values in memory frequently, these glitched patterns changed in appearance frequently as well.) Sprites, on the other hand, could only utilize half of this memory, based on an offset index (usually 0 or 192). As such, 8x8 sprites could each display 1 of 256 tile patterns at any given time (normal or glitched), while 8x16 sprites displayed two back-to-back tile patterns from the same selection of 256 (128 choices total).

13 Layers

For the Master System, only one layer could be displayed on screen. It could be made up of tiles in the arrangements of 32x28 (if the display resolution was 256x192) or 32x32 (if the display resolution was 256x224 or 256x240) [19].

In the case of the latter, additional memory in VRAM was required for the layer, reducing the number of available tile patterns down to 440. Each layer tile was two bytes long and featured a 9-bit pattern index, a 1-bit palette index, a single bit for determining horizontal flipping, a single bit for determining vertical flipping

& a single bit for draw priority, which determined whether the layer tile appeared in front of sprites or behind them. This approach was opposite of the NES, which instead gave sprites draw priority in relation to layer tiles. It’s also worth mentioning that NES layer tiles lacked horizontal and vertical flip bits.

The layer was displayed on screen by 192, 224 or 240 scanlines

(depending on the display resolution, and each 256 pixels in width) that rendered a portion of it from an x/y coordinate offset [19]. These scanlines could collectively move horizontally or vertically and could wrap around the layer horizontally or vertically. By changing the x offsets between scanline renders, they could move independently of each other horizontally in order to give off the illusion of parallax scrolling.

Unlike NES games, none of the Master System’s games ever had memory expansion chips embedded in their cartridges. As such, Master System scanlines never moved independently of each other vertically, which meant that effects such as dual views on screen were never implemented within Master system games.

14 Sprites

For the Master System, a maximum of 64 sprites could ever be present at once (256 bytes total). All sprites could be either 1 or 2 tile patterns in size (8x8 or 8x16 pixels respectively), which meant that a maximum of 64 or 128 sprite tile patterns could ever be present at once [19]. Like the NES, only 8 sprites (or sprite patterns) could be displayed horizontally without the same flicker effect occurring, where 9 or more did not always display at once. But unlike the NES, the Master System featured a “zoom” mode that doubled the pixels of all sprites on screen. When enabled, an 8x8 sprite displayed as 16x16, and an 8x16 sprite displayed as 16x32.

Each sprite was four bytes long and featured an x offset, a y offset, a pattern index & an unused byte (each with values between 0 to 255) [19]. Like the

NES, each sprite was drawn on screen based on its position within the sprite array. But unlike the NES, each sprite did not have bits for palettes, horizontal flipping, vertical flipping or draw priority. This meant that games had to utilize two separate patterns for left or right character movement.

Palettes

The tile patterns for sprites and layer tiles could display up to 15 different colors, as well as transparency [19]. This was a massive upgrade from the NES’s relatively small range of 3 colors plus transparency. Once again, this was done by having all 64 pixels in a tile pattern represented as one of sixteen index numbers:

0 through 15. Each index correlated to a palette of colors that filled in the pattern, resulting in the image on screen (with index 0 always representing transparency).

15 Each layer tile had its own palette, while the patterns (one or two) of a given sprite shared the same palette.

The tradeoff for tiles being able to feature a wider range of colors was that they had to utilize fewer palettes. The Master System had two palettes, where layers could utilize either one, but sprites could only use the second [19].

Whenever a layer tile used the second palette, the background color beneath it changed to the palette’s color at index 0. All together, this meant that the Master

System was capable of displaying a maximum of 32 colors at any given time: 2 background colors, 15 layer colors and 15 sprite colors.

Each palette held 16 of 64 color values (1 byte each), which came from a

6-bit RGB color space [19]. Unlike the NES, these color values had red, green and blue components that could hold values ranging from 0 to 3. As a result, 32 of

64 colors could potentially be achieved at any one time on the Master System, yielding a color display percentage of 50%.

To extend color output, the Master System was capable utilizing of mid- frame palette swapping – a technique where the color palettes used to render a scanline could be modified before rendering the next scanline via direct memory access (DMA) [20]. When using it, all 32 colors could be changed between scanline renderings, allowing the entire color space to be displayed on screen, yielding a color display percentage of 100%.

Audio

The Master System was capable of playing four hardware-generated mono audio channels at any given time. This included three channels for synthesized

16 waves samples (achieved via programmable sound generation, or PSG) and one channel for noise wave samples [21]. They were produced by the SN76489 audio chip and played at a rate of 22,050 Hz. Like the NES, both music tracks and sound effects were fed into these channels from lightweight proprietary track sheet audio files. Also like the NES, these files had to compete with one another for audio generation within the channels. It was also not possible to play either multiple sound effects at once or multiple music tracks at once. Doing so caused the current one to terminate before the new one began playing.

Input

The Master System utilized a controller that had 6 inputs: a D-pad (Up,

Down, Left & Right) and two buttons (1 & 2) [22]. The D-pad could be pressed in

1 of 8 directions at any time, functioning just like the NES’s D-pad. The 1 and 2 buttons were used for action inputs in games, also functioning just like the NES’s

A and B buttons respectively. In addition, up to two controllers could be connected to the system for two-player games. However, this input’s flaw was that a Pause button on the console had to be pressed in order to pause gameplay.

Figure 2.3 – The Master System controller. Credit: Sega.

17 Chapter 3: Hardware Limitations of the Nintendo Game Boy

Figure 3.1 – The Nintendo Game Boy. Credit: Nintendo.

The Nintendo Game Boy (abbreviated as Game Boy or GB) is an 8-bit video game handheld that was first released by Nintendo in North America during

July 1989. It was originally released in Japan during April 1989 [23]. The Game

Boy eventually grew to include a series of other gaming devices, including the

Super Game Boy (which played Game Boy games on a television) and the Game

Boy Color (which played Game Boy games in color).

Screen Resolution

The Game Boy (as well as the Game Boy Color) had a resolution of 160 pixels wide and 144 pixels tall [24]. An LCD screen built into the device served as the display, with the original system having an adjustable contrast. Within the display resolution was three types of graphics: base colors, layers and sprites.

Base colors consisted of a single background color, layers consisted of 8x8 tiles arranged into uniform grids, and sprites consisted of one or two 8x8 tiles that could independently move around to anywhere on screen.

Figure 3.2 – Screenshot from Super Mario Land 2. Credit: Nintendo.

Tile Patterns

The Game Boy’s 8x8 tiles were capable of displaying 16-byte patterns that were stored in the system’s VRAM. This memory was 6,144 bytes in size, which meant that there was room for 384 tile patterns [24]. 8x8 sprites utilized tile patterns from indices 0 to 255 (256 choices total), while 8x16 sprites utilized two back-to-back tile patterns from indices 0 to 255 (128 choices total). Layer tiles utilized tile patterns from indices 128 to 383 (256 choices total). Under certain settings however, the scrollable layer could instead use the sprite tile patterns and therefore access indices 0 to 255.

The Game Boy Color doubled this memory size for its system-exclusive games, bringing the tile pattern count up to 768 [24]. With this, 8x8 sprites could utilize additional tile patterns from indices 384 to 639 (512 choices total), while

8x16 sprites could utilize additional back-to-back tile patterns from indices 384 to

639 (256 choices total). Likewise, layers could utilize additional tile patterns from indices 512 to 767 (512 choices total) or from indices 384 to 639 (if the scrollable layer was using the sprite tile patterns). As a result, tile patterns from indices 128 to 255 (and 512 to 639 on the Game Boy Color) were accessible by any graphic.

19 Layers

For the Game Boy, two layers could be displayed on screen. The first layer was utilized for scrolling and was known as the “background”. The second layer was utilized for the static display of information and was known as the

“window” [24]. The window was an optional layer that could be positioned anywhere over the background when displayed on screen. Window tiles always appeared in front of background tiles, with transparent window pixels completely overriding opaque background pixels.

Both layers were made up of tiles in the arrangement of 32x32. Each of these tiles had a 1-byte pattern index, which meant that layers were 1,024 bytes in size and 2,048 bytes total [24]. Like with tile patterns, the Game Boy Color doubled the size of layers for its system exclusive games, giving each layer tile an additional byte for attributes. These included an additional bit for the pattern index (making it 9-bit), a 3-bit palette index, a single bit for determining horizontal flipping, a single bit for determining vertical flipping and a single bit for draw priority (which overruled any sprite’s draw priority).

The background layer was displayed on screen by 144 scanlines (160 pixels in width) that rendered a portion of it from an x/y coordinate offset. These scanlines could collectively move horizontally or vertically and could wrap around the layer horizontally or vertically [24]. By changing the x/y offsets between scanline renders, they could move independently of each other horizontally or vertically in order to produce parallax effects such as moving clouds or rippling water respectively. The background layer was always rendered

20 first, with the window layer rendered on top of it, as specified from an x/y window position. Unlike the background layer, the window layer could not be scrolled, wrapped around or distorted – either horizontally or vertically.

Sprites

For the Game Boy, a maximum of 40 sprites could ever be present at once

(160 bytes total). All sprites could be either 1 or 2 tile patterns in size (8x8 or

8x16 pixels respectively), which meant that a maximum of 40 or 80 sprite tile patterns could ever be present at once [24]. Unlike the previous systems, up to 10 sprites (or sprite patterns) could be displayed horizontally without the flicker effect occurring, where 11 or more did not always display at once.

Each sprite was four bytes long and featured an x offset, a y offset, a pattern index (each with values between 0 to 255), a 1-bit palette index, a single bit for determining horizontal flipping, a single bit for determining vertical flipping & a single bit for draw priority, which determined whether the sprite was drawn in front of both layers or behind them (but not between them) [24].

Sprites from Game Boy Color games utilized the four remaining bits: an additional bit for the pattern index (making it 9-bit) and a 3-bit palette index that replaced the previous 1-bit palette [24]. Interestingly enough, sprites from Game

Boy Color games compatible with the original Game Boy could hold data for both palette indices. The 1-bit indices were used when played on the original Game

Boy and the 3-bit indices were used when played on the Game Boy Color.

Unlike the NES and Master System, each sprite was drawn on screen based on its x position [24]. For example, a sprite at x position 3 will appear

21 above a sprite at x position 7. If sprites had the same x position, then their position in the sprite array was used to determine the draw order instead. However, Game

Boy Color games abandoned this method of priority and relied solely on sprite array positions for their sprite draw orders.

Palettes

Like the NES, the tile patterns for sprites and layer tiles could display up to 3 different colors, as well as transparency [24]. This was done by having all 64 pixels in a tile pattern represented as one of four index numbers: 0 through 3. All four indices correlated to a palette of colors that filled in the tile pattern, resulting in the image on screen (with index 0 always representing transparency). Each layer tile had its own palette, while the patterns (one or two) of a given sprite shared the same palette. However, the number of palettes used by both assets (as well as the size of the color space they utilized) was different based on whether a game was being played on the original Game Boy, the Super Game Boy or the

Game Boy Color.

The original Game Boy had three palettes, with only one for both layers to use and two for all sprites to use [24]. Even though this meant that 10 unique colors could be displayed (1 background color, 3 layer colors and 6 sprite colors), each of them had to come from one of four 2-bit color values. The original Game

Boy featured light-green, green, dark-green and black, while the first revision of the system (the Game Boy Pocket) featured white, light-gray, dark-gray and black

[25]. As a result, only 4 colors could ever be displayed at any time on either of these systems, yielding a color display percentage of 100%.

22 Super Game Boy

Figure 3.3 – The Super Game Boy. Credit: Nintendo.

The Super Game Boy (released in 1994 and abbreviated as SGB) was an accessory that could be inserted into the SNES, which effectively allowed Game

Boy games to be played via the console [26]. The television became the display and the SNES controller became the input. As a result, a new type of Game Boy game was made: ones with graphical (and in some cases, gameplay and audio) support for the Super Game Boy.

When run, Game Boy games rendered their displays like they would on a normal Game Boy. The Super Game Boy then replaced the four monochromatic values with color values from its own palettes before showing the display on screen [24]. This effectively gave color to Game Boy games while keeping the graphics identical to the original system.

Original Game Boy games could have their entire screen recolored by using 1 of 32 palettes from the system, or from a custom selected palette instead

[26]. Each palette contained 4 of 32,768 color values (2 bytes each), which came from the SNES’s 15-bit RGB color space [27]. Super Game Boy enhanced games 23 on the other hand could have different portions of their screen recolored by different palettes. Every 8x8 pixel region on the display (360 total) had the ability to independently use 1 of 4 palettes programmed in the game, as well as a background color [24]. Each palette contained 3 of 32,768 color values, which effectively allowed for 13 colors to be displayed on screen at once.

In addition to re-coloring the screen, the Super Game Boy added a border around the native 160x144 screen resolution that made it match the SNES’s

256x224 screen resolution [24]. Original Game Boy games displayed 1 of 9 borders from the system (or a custom drawn border) during gameplay, while

Super Game Boy enhanced games displayed their own game-specific borders

[28]. These borders utilized four of the SNES’s palettes (each containing 15 colors), and could even utilize SNES-based sprites for screensaver animations. As a result, the Super Game Boy was capable of displaying a maximum of 73 colors

(12 display, 60 border and 1 background) out of 32,768 total (0.22%).

Figure 3.4 – Screenshot from Donkey Kong (the Super Game Boy version). Credit: Nintendo.

24 Game Boy Color

Figure 3.5 – The Game Boy Color. Credit: Nintendo.

The Game Boy Color (released in 1998 and abbreviated as GBC) was the successor to the original Game Boy [29]. This handheld system was capable of playing all Game Boy games in color, but in a completely different method from the Super Game Boy. Instead of coloring the values of an already rendered display, it colored the values within the palettes before the display was rendered.

In total, there were five types of Game Boy games: those intended for GB

(but not SGB or GBC), those intended for GB & SGB (but not GBC), those with support for all three systems, those with support for GB & GBC (but not SGB), and those which could only be played on GBC exclusively [29].

When run on the Game Boy Color, original Game Boy games (with or without SGB support) had the monochrome values from their three palettes and background color replaced with 12 color values (2 bytes each). Two of these values had to be transparent at all times, which meant that original Game Boy

Games displayed up to 10 colors when played on the Game Boy Color. Like the

25 Super Game Boy, these colors came from 1 of 12 color schemes built into the system, with certain games using certain ones by default [29]. But unlike the

Super Game Boy, color schemes could only be chosen when the system was turned on by pressing specific button combinations during the boot screen, and could not be changed once the boot screen finished. Custom selected color schemes were also not possible on the Game Boy Color.

Game Boy Color enhanced games on the other hand abandoned the original three palettes and background color. Instead, they utilized sixteen new palettes, with eight for layers to use and eight for sprites to use. Each palette held

4 of 32,768 color values (2 bytes each), which came from a 15-bit RGB color space [24]. Just like on the Master System, color index 0 allowed layer tiles to change the background color beneath them. In total, the Game Boy Color was capable of displaying a maximum of 56 colors (8 background colors, 24 layers colors and 24 sprite colors) out of 32,768 total (0.17%).

In terms of graphics, there were no significant differences between GBC games with backwards compatibility and GBC exclusive games. However, the latter made use of twice the amount of memory for layers & tile patterns than previous Game Boy systems could handle, and therefore could not be played on them [24]. As a solution, Game Boy Color games that did not utilize the additional GBC memory could be played on any Game Boy system.

The following screenshots feature the five types of Game Boy games being played on each of the three Game Boy systems. Together, they demonstrate all of the graphical color differences within the library of Game Boy games.

Figure 3.6 – Screenshots from Kirby’s Dream Land, an original Game Boy game, as played on the

Game Boy (top), Super Game Boy (middle) and Game Boy Color (bottom). Credit: Nintendo.

Figure 3.7 – Screenshots from Pokémon Red Version, a Game Boy game with enhanced support

for the Super Game Boy but not the Game Boy Color, as played on the Game Boy (top), Super

Game Boy (middle) and Game Boy Color (bottom). Credit: Nintendo.

Figure 3.8 – Screenshots from Pokémon Gold Version, a Game Boy game with enhanced support for both the Super Game Boy and the Game Boy Color, as played on the Game Boy (top), Super

Game Boy (middle) and Game Boy Color (bottom). Credit: Nintendo.

Figure 3.9 – Screenshots from Mega Man X-Treme, a Game Boy game with enhanced support for the Game Boy Color but not the Super Game Boy, as played on the Game Boy (top), Super Game

Boy (middle) and Game Boy Color (bottom). Credit: Capcom.

Figure 3.10 – Screenshots from Shantae, a Game Boy game that can only function properly on the

Game Boy Color, as played on the Game Boy (top), Super Game Boy (middle) and Game Boy

Color (bottom). Notice how the game detects which Game Boy system is in use and appropriately

displays an error message on the unsupported systems. Credit: WayForward.

31 Audio

The Game Boy systems were capable of playing four hardware-generated stereo audio channels at any given time. This included two channels for pulse wave samples, one for noise wave samples, and one for pulse-code modulation samples [24]. These channels were produced by the system’s Sharp LR35902

CPU chip and played at various rates (usually 22,050 Hz on average) [30].

By default, the Game Boy and Game Boy Color systems output audio through a built-in mono speaker. However, headphones could be inserted into the systems, where stereo audio was output through the left and right ear buds [24].

Stereo effects were produced in each individual audio channel by changing the values in 2 specific bits for output: one for the left side and the other for the right side. Doing so made different notes from the same audio channel play through different sides. Games also output their audio in stereo when run on the Super

Game Boy. Super Game Boy enhanced games could even play SNES audio files, which were played on the SNES’s sound chip directly. However, due to a hardware bug, games that ran on the Super Game Boy played audio at a frequency that was 2.4% higher than when run on Game Boy or Game Boy Color.

Like the NES and Master System, both music tracks and sound effects were fed into the Game Boy’s channels from proprietary track sheet audio files.

These files had to compete with one another for audio generation within the four channels, just like those from the previous systems [24]. It was also not possible to play multiples of either sound effects or music tracks at once. Doing so caused the current one to terminate before the new one began playing.

32 Input

The Game Boy and Game Boy Color had controls built into their systems just underneath the display. They utilized the same 8 inputs at the NES controller: a D-pad (Up, Down, Left & Right) and four buttons (A, B, Start & Select) [23].

The D-pad could also be pressed in 1 of 8 directions at any time, just like on the

NES. The Super Game Boy relied on an SNES controller, which featured all of the same inputs, plus 4 additional buttons (X, Y, L & R). These were used to access the Super Game Boy’s menus for controlling palettes and borders [26].

For multiplayer gameplay, two players could use two separate Game Boys

(and games) to play with each other. These systems (with the exception of the original Super Game Boy) communicated with one another via the Game Link

Cable peripheral, which connected two Game Boys together in order for them to transfer data between cartridges [24]. As a result, two players could engage in either competitive or cooperative types of gameplay, depending on the game used.

Figure 3.11 – Two Game Boys connected via the Game Link Cable. Credit: Nintendo.

Other forms of multiplayer for the Game Boy included the Game Boy

Color’s infrared ports (in which two systems could communicate with each other via wireless infrared technology) and the Super Game Boy’s two-controller mode

(which allowed for a traditional one-system two-player experience) [24].

33 Chapter 4: Hardware Limitations of the Sega Game Gear

Figure 4.1 – The Sega Game Gear. Credit: Sega.

The Sega Game Gear (abbreviated as Game Gear or GG) is an 8-bit video game handheld that was first released by Sega in North America during April

1991. It was originally released in Japan during October 1990 [31]. The system was designed to be a portable Master System, with both being completely identical in many technical regards. However, the Game Gear features a smaller screen resolution (160x144), more vibrant colors (4,096 total), stereo audio output via headphones, and a Start button for easier gameplay pausing.

Screen Resolution

The Game Gear had a resolution of 160 pixels wide and 144 pixels tall

[31]. A full-color LCD screen built into the device served as the display. Within the display resolution was three types of graphics: base colors, layers and sprites.

Figure 4.2 – Screenshot from Sonic Chaos (the Game Gear version). Credit: Sega.

Tile Patterns

Like the Master System, the Game Gear’s 8x8 tiles were capable of displaying 32-byte tile patterns that were stored in the system’s VRAM. This memory was 16,384 bytes in size and was used to store tile patterns, the layer & sprites [19]. Tile patterns were allocated 14,336 bytes, the layer was allocated

1,792 bytes and sprites were allocated 256 bytes. This meant that there was room for 448 tile patterns.

Also like the Master System, layer tiles could each display 1 of 512 tile patterns at any given time, which included 448 normal patterns and 64 glitched patterns (which consisted of layer and sprite data in memory) [19]. Sprites utilized half of this memory based on an offset index, such as 0 or 192. As such, 8x8 sprites could each display 1 of 256 tile patterns at any given time (normal or glitched), while 8x16 sprites displayed two back-to-back tile patterns from the same selection of 256 (128 choices total).

Layers

For the Game Gear, only one layer could be displayed on screen. Unlike the Master System, it could only be made up of tiles in the arrangement of 32x28,

35 as the Game Gear only utilized one display resolution [19]. Each layer tile was two bytes long and featured a 9-bit pattern index, a 1-bit palette index, a single bit for determining horizontal flipping, a single bit for determining vertical flipping

& a single bit for draw priority, which determined whether the layer tile appeared in front of sprites or behind them.

The layer was displayed on screen by 144 scanlines (each 160 pixels in width) that rendered a portion of it from an x/y coordinate offset [19]. Like their

Master System counterparts, these scanlines could collectively move horizontally or vertically and could wrap around the layer horizontally or vertically. By changing the x offsets between scanline renders, they could move independently of each other horizontally, but not vertically.

Sprites

For the Game Gear, a maximum of 64 sprites could ever be present at once (256 bytes total). Like the Master System, all sprites could be either 1 or 2 tile patterns in size (8x8 or 8x16 pixels respectively), which meant that a maximum of 64 or 128 sprite tile patterns could ever be present at once [19]. Like the Master System, only 8 sprites (or sprite patterns) could be displayed horizontally without the flicker effect occurring, where 9 or more did not always display at once. The Game Gear also featured the Master System’s zoom mode that doubled the pixels of all sprites on screen. When enabled, an 8x8 sprite displayed as 16x16, and an 8x16 sprite displayed as 16x32.

Each sprite was four bytes long and featured an x offset, a y offset, a pattern index & an unused byte (each with values between 0 to 255) [19]. Like the

36 Master System, each sprite was drawn on screen based on its position within the sprite array. Also like the Master System, each sprite did not have bits for palettes, horizontal flipping, vertical flipping or draw priority.

Palettes

Like the Master System, the tile patterns for sprites and layer tiles could display up to 15 different colors, as well as transparency [19]. This was done by having all 64 pixels in a tile pattern represented as one of sixteen index numbers:

0 through 15. Each index correlated to a palette of colors that filled in the tile pattern, resulting in the image on screen (with index 0 always representing transparency). Each layer tile had its own palette, while the patterns (one or two) of a given sprite shared the same palette.

And like the Master System, the Game Gear had two palettes, where layers could utilize either one, but sprites could only use the second [19].

Whenever a layer tile used the second palette, the background color beneath it changed to the palette’s color at index 0. All together this meant that the Game

Gear was capable of displaying a maximum of 32 colors at any given time: 2 background colors, 15 layer colors and 15 sprite colors.

But unlike the Master System, each palette held 16 of 4,096 color values

(2 bytes each), which came from a 12-bit RGB color space [19]. This was seen as an unprecedented achievement in handheld video game hardware at the time, especially when compared to the original Game Boy’s four monochrome colors.

As a result, 32 of 4,096 colors could potentially be achieved at any one time on the Game Gear, yielding a color display percentage of 0.78%.

37 The Game Gear was also capable of utilizing the Master System’s mid- frame palette swapping, which allowed all 32 colors to be changed between scanline renderings via DMA [20]. When using it, the entire color space could be displayed on screen, yielding a color display percentage of 100%.

Audio

The Game Gear was capable of playing four hardware-generated stereo audio channels at any given time. This included the same channels as the Master

System: three for synthesized wave samples and one channel for noise wave samples [21]. They were produced by a stereo-enhanced SN76489 audio chip and played at a rate of 22,050 Hz. Stereo-enhanced, because unlike the Master

System, the Game Gear was capable of outputting stereo audio.

By default, the Game Gear output audio through a built-in mono speaker.

However, headphones could be inserted into the system, where stereo audio was output through the left and right ear buds. Stereo effects were produced in each individual audio channel by changing the values in 2 specific bits for output: one for the left side and the other for the right side. Doing so made different notes from the same audio channel play through different sides [21].

Like the Master System, both music tracks and sound effects were fed into these channels from proprietary track sheet audio files. These files had to compete with one another for audio generation within the channels, just like those from the previous systems [21]. It was also not possible to play either multiple sound effects at once or multiple music tracks at once. Doing so caused the current one to terminate before the new one began playing.

38 Input

The Game Gear had controls built into the system, placed on the left and right sides of the screen. They utilized 7 inputs, including the same 6 as the

Master System controller. To the left of the screen was a D-pad (Up, Down, Left

& Right), and to the right of the screen was three buttons (A, B & Start) [31]. Like the Master System, the D-pad could be pressed in 1 of 8 directions at any time.

But unlike the Master System, the newly added Start button functioned both as a menu confirmation button and as a gameplay pausing button.

For multiplayer gameplay, two players could use two separate Game

Gears (and games) to play with each other. These systems communicated with one another via the Gear-to-Gear Cable peripheral, which connected two Game

Gears together in order for them to transfer data between cartridges (functioning the exact same way as the Game Boy’s Game Link Cable) [32]. As a result, two players could engage in either competitive or cooperative types of gameplay, depending on the game used.

Figure 4.3 – Two Game Gears connected via the Gear-to-Gear Cable. Credit: Sega. 39 Chapter 5: Hardware Limitations of the Super Nintendo

Figure 5.1 – The Super Nintendo Entertainment System. Credit: Nintendo.

The Super Nintendo Entertainment System (abbreviated as Super

Nintendo, Super NES or SNES) is a 16-bit video game console that was first released by Nintendo in North America during August 1991. It was originally released in Japan during November 1990 under the name “Super Family

Computer” (abbreviated as Super Famicom or SFC) [33].

Screen Resolution

The SNES had a resolution of 256 pixels wide and 240 pixels tall.

However, most games only utilized 224 rows of pixels, as game developers had learned the lessons of screen clipping from televisions at the time, which could only display 224 rows of pixels [7]. As a result, this effectively gave the SNES a visibility of 256x224 pixels [34]. Within the display resolution was three types of graphics: base colors, layers and sprites. Base colors consisted of a single background color. Layers consisted of tiles (8x8 or 16x16 pixels in size) arranged

40 in uniform grids, which were drawn in a specific order on top of one another.

Lastly, sprites consisted of tiles (between 8x8 to 64x64 pixels in size) that could move independently from each other, as well as the layers [27]. Sprites could also be drawn between any of the layers, which gave them a greater depth perception not possible with previous systems.

When a layer or sprite’s tile size was larger than 8x8 (where more than one 8x8 tile pattern was in use), a layer tile or sprite’s attributes synchronously affected all of its corresponding tile patterns (in the same fashion as 8x16 sprites from the 8-bit systems). But unlike those previous systems, where all sprites on screen had to use the same size (all 8x8 or all 8x16), the SNES’s layers and sprites were each capable of having independent tile sizes from one another. The only restriction in this regard was that all sprites could only choose from 2 of the

4 possible sizes at any given time: 8x8 & 16x16, 8x8 & 32x32, 8x8 & 64x64,

16x16 & 32x32, 16x16 & 64x64 or 32x32 & 64x64 [27].

Dynamic Memory Allocation

Unlike previous systems, which had a static portion in memory dedicated to tile patterns and layers, the SNES dynamically allocated memory to both types of data within it’s VRAM, which was 65,536 bytes long [27]. This was accomplished by partitioning off different sections of VRAM to either asset, where they became small chunks of data known as segments. Tile pattern segments were 8,192 bytes long (8 segments at most) and layer segments were

2,048 bytes long (32 segments at most) [35]. Sprites (544 bytes long) and palettes

(512 bytes long) were allocated in memory elsewhere.

41 Tile Patterns

The SNES’s 8x8 tiles could display 1 of 3 types of tile patterns: 2 bits per pixel, 4 bits per pixel or 8 bits per pixel [36]. Tile patterns with 2 bits per pixel (2- bpp) were 16 bytes long and could display 3 colors (plus transparency), with each pixel having an index number from 0 to 3. Tile pattern segments could hold 512 of them. Tile patterns with 4 bits per pixel (4-bpp) were 32 bytes long and could display 15 colors (plus transparency), with each pixel having an index number from 0 to 15. Tile pattern segments could hold 256 of them. Lastly, tile patterns with 8 bits per pixel (8-bpp) were 64 bytes long and could display 255 colors

(plus transparency), with each pixel having an index number from 0 to 255. Tile pattern segments could hold 128 of them.

Layers read tile patterns from 1 of 8 positions in VRAM where tile pattern segments could be stored. Their tiles utilized 1 of the 3 tile pattern types based on what graphical mode the SNES was currently using [34]. Even though each one could display 1 of 1,024 tile patterns at any given time, the actual limit was based on the maximum capacity of its current tile pattern type (512, 256 or 128). Going over this limit caused memory errors to occur during runtime.

In addition, if a layer read multiple layer segments as a tile pattern segment (or read part of a tile pattern segment as a layer segment), its tiles would appear glitched on screen [27]. The same would happen if a layer read a tile pattern segment with the wrong bits per pixel. For example, if a 4-bpp layer used a 2-bpp tile pattern segment, its tiles would display two tile patterns merged together. Likewise, if a 2-bpp layer used a 4-bpp tile pattern segment, its tiles

42 would display halves of tile patterns. For these reasons, SNES game developers had to be very cautious when allocating tile pattern segments (and layer segments) for layers to read, as the possibility for graphical errors was always likely.

Sprites on the other hand could only ever be 4 bits per pixel. Each one displayed 15 different colors and transparency. To accommodate for this, all sprites collectively read from two back-to-back tile pattern segments in VRAM

(0+1, 2+3, 4+5 or 6+7). As such, a sprite tile could access 1 of 512 tile patterns at any given time [27]. But just like layers, sprites that read layer segments, 2-bpp tile pattern segments or 8-bpp tile pattern segments as 4-bpp tile pattern segments appeared glitched on screen. This meant that developers had to be just as cautious when allocating tile pattern segments to sprites as they were with layers.

For sprites and layer tiles that were larger than 8x8, their tile patterns came from adjacent index positions (granted one visualized tile pattern segments as matrices with 16 patterns per row). On previous systems, an 8x16 sprite consisted of patterns from index+0 and index+1, with its index possibilities divided by 2.

But on the SNES, a 16x16 pixel sprite or layer tile consisted of 4 patterns (2x2) from index+0, index+1, index+16 and index+17, with its index possibilities not divided [27]. Large index positions wrapped around the current pattern segment both horizontally and vertically. For example, a 16x16 tile with index 255 used patterns at indices 255, 240, 15 and 0. (In the case of sprites however, multiple tile patterns could only come from one of its two available tile pattern segments.)

These principles of adjacent accessibility also worked with sprites that were

32x32 pixels (16 patterns as 4x4) and 64x64 pixels (64 patterns as 8x8).

43 Layers

Layer segments (also known as tile maps) consisted of tiles arranged as

32x32. This made them 256x256 pixels in a layer’s 8x8 mode and 512x512 pixels in a layer’s 16x16 mode [37]. Either way, layer segments utilized 1,024 layer tiles. Each one was two bytes long and featured a 10-bit pattern index, a 3-bit palette index, a single bit for determining horizontal flipping, a single bit for determining vertical flipping & a single bit for draw priority, which helped in determining the order that layer tiles were drawn on screen with [35].

Each layer could be made up of layer segments in the arrangements of

1x1, 2x1, 1x2 or 2x2, which translated into tiles in the arrangements of 32x32,

64x32, 32x64 or 64x64 respectively [37]. Layers using one layer segment could read from 1 of 32 positions in VRAM where layer segments could be stored [35].

As such, layers using two layer segments (index+0 and index+1) could only read from 1 of 16 positions, while layers using four layer segments (index+0, index+1, index+2 and index+3) could only read from 1 of 8 positions.

Layers were displayed on screen by 224 (or 240) scanlines each (256 pixels in width) that rendered a portion of each one from their x/y coordinate offsets. These scanlines could collectively move horizontally or vertically and could wrap around a layer horizontally or vertically. By changing the x/y offsets between scanline renders, they could move independently of each other horizontally or vertically in order to produce parallax effects. [27]

When drawing layers on screen, scanlines from lower layers were rendered first, followed by scanlines from higher layers, going in order from layer

44 4 to layer 1 [34]. Between layers 1 and 2, tiles with draw priority were drawn on top of tiles without draw priority. (For example, a tile from layer 2 with draw priority was drawn over a tile from layer 1 without draw priority.) The same applied between layers 3 and 4. However, tiles from layers 3 and 4 with draw priority were drawn underneath tiles from layers 1 and 2 without draw priority.

The only exception to this was tiles from layer 3 with draw priority when HUD mode was enabled, which made them appear above all other tiles.

Sprites

For the SNES, a maximum of 128 sprites could ever be present at once

(544 bytes total). Unlike previous systems, each sprite could be 1x1, 2x2, 4x4 or

8x8 tile patterns in size (8x8, 16x16, 32x32 or 64x64 pixels respectively), where only two sprite sizes could be present on screen [38]. Despite the ability for 128 sprites of 64x64 pixels to produce 8,192 sprite tile patterns, a maximum of 986 sprite tile patterns could ever be present at once. This was because only 32 sprites

(or 34 sprite patterns) could be displayed horizontally without them being cut off from displaying [39]. There was also no flicker effect on the SNES, as excessive sprites or sprite patterns were simply clipped off from displaying on screen.

Each sprite was 34 bits long (4 bytes & 2 bits) and featured a 9-bit x offset

(with values between 0 to 511), an 8-bit y offset (with values between 0 to 255), a

9-bit pattern index (where the 9th bit determined which tile pattern segment to read from), a 3-bit palette index, a single bit for determining horizontal flipping, a singe bit for determining vertical flipping, a 2-bit draw priority (which, in addition to the current graphic mode, determined which layer tiles the sprite appeared

45 between when drawn on screen) & a single bit for determining the sprite’s current size, based on the 2 that were enabled out of the 4 sizes total [39]. These attributes were stored in two separate tables, with the first one being 512 bytes and the second one being 32 bytes.

Palettes

The SNES held 256 colors in memory, each containing 1 of 32,768 color values (2 bytes each), which came from a 15-bit RGB color space [40].

Background colors always utilized color entry 0, and sprites always utilized color entries 128 to 255. As such, each sprite could use 1 of 8 palettes, each containing

15 colors (plus transparency), effectively giving them 120 colors to work with.

Layer palettes however varied depending upon the bits per pixel of the layers that referenced them. Tiles from 2-bpp layers used 1 of 8 palettes, each containing 3 colors (plus transparency), giving their layers 24 colors to work with

(entries 1 through 31). Tiles from 4-bpp layers used 1 of 8 palettes, each containing 15 colors (plus transparency), giving their layers 120 colors to work with (entries 1 through 127). Lastly, tiles from 8-bpp layers used 1 palette that contained all 255 colors (plus transparency) for their layers to work with (entries

1 through 255), which included the same colors that sprites used [40].

Figure 5.2 – SNES color entries organized as color palettes.

46 Like the Master System and Game Gear, the SNES was also capable of utilizing mid-frame palette swapping, which allowed all 256 colors to be changed between scanline renderings via horizontal direct memory access (HDMA) [41].

When using it, the entire color space could be displayed on screen, yielding a color display percentage of 100%.

Graphical Modes

The most important pieces of SNES graphics information are the properties of its layers: the number of them to display on screen, the bits per pixel for each of them, the number of color entries they used, their unique graphical effects, and their color display percentages. These properties were determined by the SNES’s eight graphical modes (labeled as modes 0 through 7) [34].

Mode 0 utilized four layers [34]. Each one was 2 bits per pixel and used their own 8 palettes of 24 colors [40]. The first layer was assigned color entries 0 to 31, the second layer was assigned color entries 32 to 63, the third layer was assigned color entries 64 to 95, and the fourth layer was assigned color entries 96 to 127. In total, mode 0 could output a maximum of 217 colors (1 background color, 96 layer colors and 120 sprite colors) out of 32,768 total (0.66%). However, very few games used mode 0, as its color output was identical to that of the NES, which developers at the time wanted to move away from. As a result, mode 0 was mostly used for the introduction sequences of a few games.

Mode 1 utilized three layers. The first & second layers were 4 bits per pixel and shared the same 8 palettes of 120 colors (entries 0 through 127). The third layer was 2 bits per pixel and used its own 8 palettes of 24 colors (entries 0

47 through 31) [34]. The first layer was typically used as a game’s midground that scrolled as the playable character navigated through it, with the second layer as the background that scrolled at a slower rate. The third layer was typically used as either a static HUD that overlaid the other two layers, or as an additional less- detailed background that was placed behind the other two layers. (There was a value in memory that controlled the display order of this particular layer.) In total, mode 1 could output a maximum of 241 colors (1 background color, 120 layer colors and 120 sprite colors) out of 32,768 total (0.74%). Unlike mode 0, the vast majority of SNES games used mode 1. It was simple for developers to comprehend, it made great use of the SNES’s wide color capacities, and it was able to produce visually effective background scrolling effects.

Figure 5.3 – Screenshot from Super Mario World, which ran in mode 1. Credit: Nintendo.

Mode 2 utilized two layers. Both were 4 bits per pixel and shared the same

8 palettes of 120 colors (entries 0 through 127). This mode was exactly like mode

1, but without the third 2-bpp layer. In its place was a segment of memory that

48 could be used to assign additional x/y offsets to each of the tiles in either layer

[34]. With it, layer tiles could move independently on screen from one another horizontally and/or vertically. In total, mode 2 could output the same maximum number of colors as mode 1 (241 of 32,768).

Figure 5.4 – Screenshot from Tetris Attack, which ran in mode 2. Credit: Nintendo.

Mode 3 utilized two layers. The first layer was 8 bits per pixel and used all color entries as its palette. The second layer was 4 bits per pixel and used 8 palettes of 120 colors (entries 0 through 127). Alternately, layer 0 could abandon the palette colors and utilize “direct color” mode, where 1-byte pixels referenced color values from an 8-bit RGB color space [34]. These 8-bit color values had 3 bits each for red and green values, but only 2 bits for blue values. (This choice was made because it’s more difficult for the human eye to discriminate shades of blue than shades of red or green [42].) A tile’s unused 3-bit palette index could be recycled as extra bits for the RGB values, thus allowing the usage of an 11-bit color space. All of the 8-bit and 11-bit RGB values could be potentially

49 represented within the SNES’s normal 15-bit color space. However, direct color value 0 represented transparency instead of pure black (0, 0, 0). (Assigning pure black to color entry 0 for the background was the only way to make it appear.)

Mode 3 was typically used for title screens that featured very intricate and detailed illustrations. When using all color entries, it could output a maximum of

256 colors (1 background color, 120 standard layer colors, 15 additional layer colors and 120 sprite colors) out of 32,768 total (0.78%). When using 8-bit color values, mode 3 could output a maximum of 496 colors (1 background color, 255 direct colors, 120 layer colors and 120 sprite colors) out of 32,768 total (1.51%).

Lastly, when using 11-bit color values, mode 3 could output a maximum of 2,288 colors (1 background color, 2,047 direct colors, 120 layer colors and 120 sprite colors) out of 32,768 total (6.98%).

Mode 4 utilized two layers. The first layer was 8 bits per pixel and used all color entries as its palette. The second layer was 2 bits per pixel and used 8 palettes of 24 colors (entries 0 through 31). This mode was exactly like mode 3, with all of its 8-bit/11-bit direct color capabilities, but with the second layer being

2-bpp instead of 4-bpp [34]. It also featured mode 2’s additional x/y tile offset capabilities and allowed layer tiles to move independently on screen from one another either horizontally or vertically (but not both at the same time).

Mode 4 was also typically used for title screens that featured very intricate and detailed illustrations. When using all color entries, it could output the same maximum number of colors as mode 3 (256 of 32,768). When using 8-bit color values, mode 4 could output a maximum of 400 colors (1 background color, 255

50 direct colors, 24 layer colors and 120 sprite colors) out of 32,768 total (1.22%).

Lastly, when using 11-bit color values, mode 4 could output a maximum of 2,192 colors (1 background color, 2,047 direct colors, 24 layer colors and 120 sprite colors) out of 32,768 total (6.69%).

Figure 5.5 – Title screen from Super Mario All-Stars, which ran in mode 3. Credit: Nintendo.

Mode 5 utilized two layers. The first layer was 4 bits per pixel and used 8 palettes of 120 colors (entries 0 through 127). The second layer was 2 bits per pixel and used 8 palettes of 24 colors (entries 0 through 31) [34]. In this mode, the screen’s width and height could be doubled, resulting in native resolutions of

512x224, 256x448, 512x448, 512x240, 256x480 or 512x480 [43][44]. As such, sprites had their pixel resolutions magnified, with 1x1 sprite pixels increasing to either 2x2 or 2x1. 8x8 layer tiles were also increased to 16x8 whenever the screen width was 512 pixels. In total, mode 5 could output the same maximum number of colors as modes 1 and 2 (241 of 32,768). However, very few games used mode

5 due to the “squished” display of pixels from the high screen resolutions.

51 Mode 6 utilized just one layer. It was 4 bits per pixel and used 8 palettes of 120 colors (entries 0 through 127). This mode was exactly like mode 5, with all of its capabilities for high screen resolution, but without the second 2-bpp layer

[34]. Instead, it was able to utilize the same additional x/y tile offset capabilities from modes 2 and 4. In total, mode 6 could output the same maximum number of colors as modes 1, 2 and 5 (241 of 32,768).

Figure 5.6 – Screenshot from Seiken Densetsu 3, which ran in mode 5. Credit: Square.

Mode 7 was entirely different from all previous graphic modes. There was just one layer, which could be scaled and rotated [45]. As such, it was treated like a 3-dimensional plane, which allowed SNES games to feature entirely new types of gameplay mechanics. For this reason, the term “mode 7” is widely used by game developers when describing pseudo-3D graphical effects in general. 52 Mode 7 was implemented by having the top half of VRAM dedicated to the layer and its tile patterns: 16,384 bytes for the former and 16,384 bytes for the latter [27]. The layer consisted of 128x128 tiles (1024x1024 pixels). Each layer tile was 1 byte long and did not have a palette index, horizontal/vertical flipping or draw priority. Instead, they only referenced 1 of 256 tile patterns. These 8x8 patterns were 64 bytes in size, with each byte representing a pixel’s color. These colors came from either the 256 color entries, or directly from the 8-bit RGB color space. (No 11-bit color space capabilities, unfortunately.)

Mode 7 did not affect sprite memory or palette memory. However, sprites could only utilize segments from the bottom half of VRAM for their tile patterns

(4+5 or 6+7). There was also a variation of mode 7 that allowed each pixel from every tile pattern the ability to be drawn in front of or behind sprites with draw priority values of 1 [34]. As a drawback however, every pixel was limited to only using color entries 0 through 127 (and not a direct color space).

Just as layer x/y offsets and color palettes could be changed mid-frame, a game’s graphical mode could also be changed between scanline renderings via

HDMA [34]. While it was possible to use this technique to switch between any of the 8 modes, SNES game developers most commonly used it in conjunction with mode 7. For example, the top half of a game’s display could feature a flat mode 1 layer, while the bottom half could feature a scaled mode 7 layer, effectively portraying a distant horizon on screen.

When using the color entries, mode 7 could output the same maximum number of colors as modes 3 and 4 (256 of 32,768). When using 8-bit color

53 values, mode 7 could output a maximum of 376 colors (1 background color, 255 direct colors and 120 sprite colors) out of 32,768 total (1.15%). Lastly, when using the draw priority variation, mode 7 could output a maximum of 248 colors

(1 background color, 120 standard layer colors, 7 additional layer colors and 120 sprite colors) out of 32,768 total (0.76%).

Figure 5.7 – Screenshot from F-Zero, which ran in mode 7. Credit: Nintendo.

Advanced Graphical Effects

The SNES was capable of a wide variety of graphical rendering manipulations. Some of these effects enhanced the 2D visual elements of games, while others portrayed 3D visuals in a 2D environment. For starters, the SNES had a visibility variable that was used for fade in/fade out screen transitions [43].

This variable had 17 possible values (from clear output to pure black) that were color-subtracted onto the display’s pixels before it was rendered. This transition effect was also useful when large amounts of layer data needed to be loaded into memory without any visual bugs appearing on screen.

54 The SNES also had a mosaic feature that could blur layers when rendering them on screen. The effect involved taking a square region of a layer (anywhere from 1x1 pixel to 16x16 pixels), taking the top-left pixel’s color and filling it into all other pixels within the square [43]. This region-filling procedure was repeated both horizontally and vertically, even when using odd number values (such as 3x3 pixels). Any layer could have the mosaic effect performed on it, but all that participated had to share the same square regions [46].

Figure 5.8 – Screenshots from Final Fantasy IV using fade and mosaic effects. Credit: Square.

Like previous systems, the SNES sequentially rendered all scanlines (0, 1,

2, etc.) on every frame by default. However, it could alternately output twice the number of scanlines via horizontal interlacing, where even numbered ones (0, 2,

4, etc.) rendered on one frame, followed by odd numbered ones (1, 3, 5, etc.) on the next frame, and so forth [47]. When enabled in modes 5 and 6, different halves of the rows of pixels were output to different scanlines each frame. But when enabled in the other modes, all rows of pixels were output to different scanlines each frame [43][44]. However, because this effect caused the screen to render half as fast as everything else, motion blur occurred when it was enabled. 55

Figure 5.9 – Screenshot from R.P.M. Racing, which ran in 512x448 resolution. Credit: Blizzard.

Whenever rendering occurred, layers and sprites were each placed into one of two buffers: the “main-screen” or the “sub-screen”. This meant that the

SNES actually rendered two screens every frame. These buffers were then compared with each other (one pixel at a time) in order to determine the actual output to render on screen [48]. However, aside from pixel comparisons, these buffers were also capable of allowing for translucency effects on screen.

The dual buffers could be used for translucency via vertical interlacing

(also known as “pseudo high resolution”) in all modes except 5 and 6 (which instead used “true high resolution”). In using this effect, the display’s width was increased from 256 to 512, with the main-screen magnified by 2 in order to fill it horizontally. The sub-screen on the other hand kept its width of 256 and was 56 displayed on odd columns within the display (1, 3, 5, etc.). This allowed the main- screen (normally covered up by the sub-screen) to always be visible on even columns within the display (0, 2, 4, etc.), which produced a vertical interlace

[43][44]. Despite the extremely wide 512x224 resolution, most televisions from the time squished the width down to match a 4:3 ratio (or in the case of 256x224, stretched the width up). As a result of this squishing, pixels blended into one another, which created a “pseudo color-averaged” translucency on screen.

Figure 5.10 – Screenshot from Kirby’s Dream Land 3 as seen via a native display (top), a non-

interlaced display (bottom left), and a television display (bottom right). Credit: Nintendo. 57 The dual buffers could also be used for translucency via color arithmetic.

In using this effect, the sub-screen’s pixels tinted the main-screen’s pixels, therefore appearing translucent when rendered [48]. Layers, sprites and the background color could individually choose whether or not to have all of their pixels participate in the color arithmetic. (A layer could even be part of both buffers in order to perform color arithmetic on itself.) Whenever the sub-screen was empty, a fixed color value could be used instead in order to accomplish a translucency effect over the entire main-screen. It’s also worth noting that sprites could only utilize translucency if they were using sprite palettes 4 through 7, and that no two sprites could be translucent over one another.

Figure 5.11 – Screenshot from Mega Man 7 using color arithmetic translucency. Credit: Capcom.

Rather than using alpha values to determine the opacity of the sub-screen, the SNES relied on 1 of 4 operations between red, green and blue shades: color addition, color subtraction, color averaging or color fractioning [48]. Given a main-screen pixel’s color value (R, G, B) and a sub-screen pixel’s color value at

58 the same x/y position (r, g, b), the rendered pixel’s color value was computed based on the formula of the color arithmetic operation currently in use:

• Color addition: (R + r, G + g, B + b)

• Color subtraction: (R – r, G – g, B – b)

• Color averaging: ([R + r] / 2, [G + g] / 2, [B + b] / 2)

• Color fractioning: ([R – r] / 2, [G – g] / 2, [B – b] / 2)

The resulting red, green and blue shades were always clipped between 0 and 31, even if their results went above or below this range. In addition, the sub- screen’s “fixed” color value was only capable of utilizing color addition or color subtraction, with the other two operations having unintended results.

The following figure demonstrates the outcomes of each color arithmetic operation. The magenta color (31, 0, 31) represents a main-screen pixel, and the brown color (15, 15, 0) represents a sub-screen pixel. From left to right, color addition results in (31, 15, 31), color subtraction results in (16, 0, 31), color averaging results in (23, 7, 15), and color fractioning results in (8, 0, 15).

Figure 5.12 – An example of the SNES’s color arithmetic operations for translucency.

Finally, the SNES provided two dynamic regions for visibility effects.

These regions (referred to as “windows”) consisted of left and right boundaries that could be changed for each scanline via HDMA [49]. By utilizing a set of hardware registers, they were able to masks portions of any layer (or of all sprites collectively) with either transparency or a solid color [44]. As such, these regions 59 allowed layers to appear on screen as non-rectangular shapes (such as circles or diamonds), which was useful for transitional effects like circular zoom-outs.

Figure 5.13 – Screenshot from EarthBound using a circular zoom-out. Credit: Nintendo.

The five screens from the following figure demonstrate how this effect was accomplished. The first screen represents both regions, with red pixels for region A only, blue pixels for region B only, magenta pixels for regions A & B, green pixels for neither region and black pixels for the left & right boundaries of each region. From these 4 possibilities, the SNES used 1 of 4 comparison operations in order to determine visibility: “and”, “or”, “exclusive or” or “not exclusive or” [44]. The second through fifth screens represent these results respectively, with orange pixels for visibility and purple pixels for invisibility.

Figure 5.14 – Five screens demonstrating how visibility regions worked on the SNES.

60 Combining these visibility regions with the dual buffer translucency operations allowed the sub-screen’s fixed color to be rendered on screen as a translucent shape (either rectangular or non-rectangular) [44]. Unlike the color spaces for palettes or direct color, the fixed color’s range of values encompassed

31 shades of 7 colors (white, red, yellow, green, cyan, blue & magenta) and black, for a total of 218 values. When opaque, the fixed color displayed above all pixels within the visibility regions. But when translucent (via color addition or color subtraction), the fixed color tinted all pixels within the visibility regions.

(However, the only fixed color that was incapable of tinting was black.)

Figure 5.15 – Screenshot from Super Metroid using fixed color translucency. Credit: Nintendo.

Expansion Chips

Like the NES, many SNES games featured additional chips embedded within their cartridges that expanded their memory capabilities, as well as their processing capabilities. Unlike the NES, whose expansion chips were primarily focused on expanding audio channel output, the SNES’s expansion chips were

61 primarily focused on expanding graphical capabilities. Four examples of these expansion chips include the Super FX, DSP, SA1 and CX4 chips [50].

The Super FX chip allowed for 3-dimensional graphics by rendering polygonal figures directly to a layer, pixel by pixel, without the usage of tiles or tile patterns [50]. It was featured in games such as Star Fox and Yoshi’s Island.

The DSP chip allowed for vector-based computations, which enabled objects to utilize three-dimensional coordinates within two-dimensional spaces

[50]. It was featured in games such as Super Mario Kart and Pilotwings.

The SA1 chip allowed for CPU instructions to be processed at 10.74 MHz

(as opposed to the standard 3.58 MHz) as well as memory-mapping capabilities that could render additional graphics (beyond the existing layers) on screen [50].

It was featured in games such as Kirby Super Star and Super Mario RPG.

Lastly, the CX4 chip allowed for wireframe entities to display on screen by utilizing trigonometric coordinate operations [50]. It was featured in games such as Mega Man X2 and Mega Man X3.

Figure 5.16 – Screenshots from Star Fox using the Super FX chip’s polygonal layer (left, credit:

Nintendo) and Mega Man X2 using the CX4 chip’s wireframe entities (right, credit: Capcom). 62 Audio

The SNES was capable of playing eight sample-based stereo audio channels at any given time. Unlike previous systems, which only played hardware-generated audio, the instrument a channels used at any given time came from pre-recorded audio that could be played back at different pitches, based upon the notes that were fed into it [51]. This audio could range anywhere from voice samples, to actual instruments, and could also have a variety of reverberation effects applied to it during playback (such as an “echo” effect).

These channels played at a rate of 32,000 Hz and were run on the Sony SPC-700: an audio sub-processor chip that ran independently from the rest of the system.

Both music tracks and sound effects were fed into these channels from proprietary track sheet audio files. Unlike previous systems, whose audio files only consisted of notes and were lightweight, SNES audio files consisted of two portions: the notes and the sampled instrument audio [52]. By default, sampled audio tends to be very heavy in memory. To combat the issue, the SNES imposed a 65,536 byte restriction on its audio files, which often lead to the sampled instruments being compressed or reduced in quality [51]. Despite its vivid soundscape, SNES audio tended to sound very quiet, hollow and dull in comparison to other systems, whose audio tended to sound loud, clear and crisp.

Because the system had 8 channels for playback, music tracks & sound effects could use different channels and not compete with one another like in previous systems. (For example, a music track could use 5 channels and a sound effect could use 3 channels.) However, starting a new music track or sound effect

63 still overrode a currently playing music track or sound effect respectively. In addition, each channel could create its own stereo effects by panning the volume of each output (for example, 80% on the left side and 20% on the right side) [51].

This was different from the Game Boy and Game Gear, where two 1-bit values were what determined audio playback for their left and right outputs.

Input

The SNES utilized an ergonomic controller that had 12 inputs: a D-pad

(Up, Down, Left & Right), six face buttons (A, B, X, Y, Start & Select) and two shoulder buttons (L & R) [33]. While the original 8 inputs functioned like they did on NES and Game Boy, the additional X, Y, L and R buttons allowed games to feature more engaging input. The shoulder buttons also allowed players to use their index fingers on the controller, as opposed to just their thumbs. Like the

NES, up to two controllers could be connected to the system, with most games utilizing both for two-player experiences. (Certain games supported more than two players, but required special equipment in order to connect more controllers.)

Figure 5.17 – The SNES controller. Credit: Nintendo.

64 Hardware Extensions and Other Similar Systems

The SNES never had any hardware extensions released for it. However, there was one in development in 1991 that ended up being cancelled: the Super

Nintendo Entertainment System CD (or SNES-CD). It would have been a peripheral that connected to the bottom of the system and played games stored on

CD-ROMs [53]. The advantages of using CD-ROMs instead of cartridges for games at the time included the ability to play CD-quality audio tracks (at a rate of

44,100 Hz), as well as the ability to display full motion videos (FMVs), both of which would have provided games with more cinematic experiences.

The project began development in partnership between Nintendo and

Sony, but was ultimately cancelled by Nintendo due to creative and financial reasons [53]. Sony went on to take its work from the project, continued developing it further, and eventually released it as a brand new console: the Sony

PlayStation [54]. Its release paved the path for Sony’s entrance into the video game industry, effectively making them Nintendo’s fiercest rival to date.

Figure 5.18 – Concept art for what the SNES-CD could have looked like. Credit: Nintendo. 65 A system that was similar in design to the SNES was Nintendo’s Game

Boy Advance (abbreviated as GBA). This handheld system (released in 2001) was the successor of the Game Boy Color [55]. It featured a screen resolution of

240x160 pixels (far less than the SNES’s 256x224) and displayed graphics in one of two ways: the traditional tile mode or the direct bitmap mode [56].

Using the tile mode, the GBA utilized tile patterns (8x8 pixels in size), layers, sprites and palettes – each worked the exact same way as they did on the

SNES, but with additional features. Up to 4 layers and 128 sprites could be on screen, each one capable of performing scaling, rotation, mosaic effects & alpha blending, and each capable of using 4-bpp or 8-bpp tile patterns [57][58]. Layers could be between 128x128 to 1024x1024 pixels and sprites could be between 8x8 to 64x64 pixels. The system had 512 colors in memory: 256 for layers and 256 for sprites [56]. Each color held 1 of 32,768 color values, which came from a 15-bit

RGB color space. 4-bpp graphics used 1 of 16 palettes, each containing 15 colors

(plus transparency), while 8-bpp graphics used all 255 colors (plus transparency).

In total, the GBA’s tile mode could display 511 colors maximum (1.56%).

Figure 5.19 – Screenshot from Super Mario Advance, which ran in tile mode. Credit: Nintendo.

66 Using the bitmap mode, the GBA completely discarded tile patterns and layers. Instead, pixels from the 240x160 display contained their own color values and were collectively known as bitmaps. The mode featured three display variations: one 240x160 bitmap using 15-bpp direct colors, two 240x160 bitmaps using 8-bpp palette indices, and two 160x128 bitmaps using 15-bpp direct colors

[59]. 8-bpp color values could use all 255 layer colors (plus transparency), while

15-bpp color values featured 5 bits for red, green & blue, with 32,768 choices total. In addition, the background color was used to occupy vacant pixels, and only one bitmap could visible on screen. Sprites still used tile patterns & palettes and displayed on top of (or behind) bitmaps like they normally did with layers. In total, the GBA’s bitmap mode could display all 32,768 colors maximum (100%).

Figure 5.20 – Cutscene from Mario vs. Donkey Kong using bitmap mode. Credit: Nintendo.

The Game Boy Advance was capable of playing six audio channels: four mono channels from the original Game Boy and two new sample-based stereo channels [60]. The sample-based channels worked similarly to those from the

SNES in that they played recorded audio at different pitches. However, the maximum rate they could play at was 22,050 Hz, with many on average playing at

67 lower rates (such as 11,025 Hz). In addition, all audio ran on the system’s main

CPU, and not a dedicated sound chip, which resulted in poor sound quality.

The Game Boy Advance utilized 10 inputs that were built into the system:

Up, Down, Left, Right, A, B, Start, Select, L and R, omitting the SNES’s X and Y buttons [55]. For multiplayer gameplay, two to four players could use multiple systems (and games) to play with each other, all connected together with one to three Game Boy Advance Link Cables. Later games even utilized wireless adapters that allowed up to forty players within a 10-foot radius to play together.

Four models of the GBA were produced: the original system, the Game

Boy Advance SP (with either a backlit screen or a frontlit screen), the Game Boy

Player (which played games on a TV via the Nintendo GameCube) and the Game

Boy Micro. All of them (except the latter) could play games from previous Game

Boy systems, where they would run as if played on a Game Boy Color [55].

While many saw the Game Boy Advance as an evolution of the SNES in terms of graphical capabilities, it was ultimately considered inferior to its predecessor on the basis of having a smaller screen resolution, poor sound quality, fewer buttons, and a poorly lit display on the original system.

Figure 5.21 – The Game Boy Advance (left) and Game Boy Advance SP (right). Credit: Nintendo. 68 Another system that was similar in design to the SNES was the Nintendo

DS. Unlike its predecessor (the Game Boy Advance), many saw the Nintendo DS as being more on par with the SNES. This handheld system (released in 2004) featured two screens (both 256x192 pixels in resolution), with the bottom screen having touch capabilities [61][62]. Its graphical capabilities surpassed both the

Game Boy Advance and SNES, being able to display multiple layers, sprites and

3D polygonal shapes at once. It even utilized an 18-bit RGB color space, allowing for 262,144 color values. The system’s audio processor was similar to the

SNES’s, in that it played files with notes and sampled instruments across multiple channels [63]. In addition, it also featured all 12 of the SNES’s buttons for inputs.

The system used wireless technology for local multiplayer experiences, as well as global multiplayer experiences (via Wi-Fi connectivity). It also utilized a home menu, which served as the main user interface when turning the system on.

Other models of the system produced include the Nintendo DS Lite, the

Nintendo DSi and the Nintendo DSi XL [61]. The latter two improved the home menu’s interface & Wi-Fi compatibility range, added camera functionality & raw audio playback, and allowed for data to be saved onto removable SD cards [64].

Figure 5.22 – The Nintendo DS (left) and Nintendo DSi (right). Credit: Nintendo. 69 Chapter 6: Hardware Limitations of the Sega Genesis

Figure 6.1 – The Sega Genesis. Credit: Sega.

The Sega Genesis (abbreviated as Genesis) is a 16-bit video game console that was first released by Sega in North America during August 1989. It was originally released in Japan during October 1988 under the name “Sega Mega

Drive” (abbreviated as Mega Drive or MD) [65].

Screen Resolution

The Genesis had a resolution of 320 pixels wide and 240 pixels tall.

However, like the SNES, most games only utilized 224 rows of pixels, due to screen clipping from televisions at the time. As a result, this effectively gave the

Genesis a visibility of 320x224 pixels [65]. In addition, certain games utilized alternate resolutions of 256x224 and 256x240. These widths were respectively classified as “40-column resolution” and “32-column resolution” due to the number of 8x8 tile columns that each could display on screen at once.

Within the display resolution was three types of graphics: base colors, layers and sprites. Base colors consisted of a single background color. Layers

70 consisted of 8x8 tiles arranged into uniform grids, which were drawn in a specific order on top of one another. Lastly, sprites consisted of tiles (between 8x8 to

32x32 pixels in size) that could move independently from each other, as well as the layers [65]. Sprites could also be drawn at certain positions between layers, giving them a perception of depth similar to that of sprites from the SNES.

Figure 6.2 – Screenshots from Sonic the Hedgehog (top, credit: Sega) using 40-column resolution,

and Mega Man: The Wily Wars (bottom, credit: Capcom) using 32-column resolution. 71 Dynamic Memory Allocation

Like the SNES, the Genesis dynamically allocated memory to tile patterns, layers and sprites within its VRAM (65,536 bytes long), which was accomplished by partitioning each asset into data segments [66]. In addition, horizontal scroll offset data was also dynamically allocated within VRAM. This was advantageous for the Genesis, as previous systems had to manipulate offset values between scanline renders in order to achieve the same effect. Like the previous systems however, palettes (128 bytes long) were allocated in memory elsewhere.

Tile Patterns

Unlike the SNES (whose tile patterns could be 2-bpp, 4-bpp or 8-bpp), all

Genesis tile patterns were 4-bpp (32 bytes long) and could display up to 15 different colors (plus transparency), with pixels represented by index numbers ranging from 0 to 15 [66]. Although a theoretical maximum of 2,048 tile patterns could be held in VRAM at any given time, the realistic average in a game was around 1,700 or 1,800. (VRAM had to account for the other assets as well.)

Fortunately, both sprites and layer tiles could reference any of the 2,048 pattern indices, therefore eliminating the need for tile pattern segments in VRAM.

However, just as with previous systems, if a layer’s tiles read non-pattern data for their tile patterns (or if a layer read non-tile data for its tiles), then that layer’s tiles would appear glitched on screen [66]. As such, Genesis game developers had to be just as cautious as SNES game developers when it came to allocating tile pattern data (and tile data) for their layers to read, as the possibility for graphical errors was just as likely on the Genesis as it was on the SNES.

72 Layers

For the Genesis, three layers could be displayed on screen. The first & second were “plane” layers, and the third was a “window” layer [66]. The first plane layer was typically used as a game’s midground that scrolled as the playable character navigated through it, with the second plane layer as the background that scrolled at a slower rate. The window layer was typically used for the static display of information. It worked the exact same way as the Game Boy’s window layer – as an optional layer that could be positioned anywhere over the first plane layer when displayed on screen. Window layer tiles always appeared in front of the first plane layer’s tiles, with transparent pixels from the window layer completely overriding opaque pixels from the first plane layer.

Plane layers could be one of three sizes: small (2,048 bytes), medium

(4,096 bytes) or large (8,192 bytes) [65]. Small plane layers consisted of 1,024 tiles arranged as 32x32 (256x256 pixels). Medium plane layers consisted of 2,048 tiles arranged as 64x32 or 32x64 (512x256 or 256x512 pixels). Lastly, large plane layers consisted of 4,096 tiles arranged as 64x64, 128x32 or 32x128 (512x512,

1,024x256 or 256x1,024 pixels). Plane layer segments occupied VRAM in 1 of 8 locations, even if their size was less than 8,192 bytes [66].

Window layers could be one of two sizes: small (2,048 bytes) or medium

(4,096 bytes) [65]. Small window layers consisted of 1,024 tiles arranged as

32x32 (256x256 pixels). Likewise, medium window layers consisted of 2,048 tiles arranged as 64x32 (512x256 pixels). Window layer segments occupied

VRAM in 1 of 32 locations (small) or 1 of 16 locations (medium) [66]. Plane and

73 window layers that had a width of 256 pixels only displayed properly in 32- column resolution, as the right 64 pixel columns duplicated the left 64 pixel columns whenever they were mistakenly displayed in 40-column resolution.

Each layer tile was two bytes long and featured an 11-bit pattern index, a

2-bit palette index, a single bit for determining horizontal flipping, a single bit for determining vertical flipping & a single bit for draw priority, which helped in determining the order that layer tiles were drawn on screen with [67].

Plane layers were displayed on screen by 224 (or 240) scanlines each (320 pixels wide in 40-column resolution and 256 pixels wide in 32-column resolution) that rendered a portion of each one from their x/y coordinate offsets combined with their horizontal scroll offsets. These 448 (or 480) offsets were 896 bytes total

(or 960) and occupied VRAM as 1 of 64 horizontal scroll data segments [66][67].

Because these segments were 1,024 bytes long, the extra 128 bytes (or 64) were typically occupied by additional tile patterns for layer tiles or sprites to use.

A plane layer’s scanlines could collectively move horizontally or vertically and could wrap around the layer horizontally or vertically [67]. Because the Genesis utilized scroll offsets for independent horizontal movement of its scanlines (or 8-pixel rows of tiles), changing an x offset between scanline renders was no longer necessary like it was on previous systems. However, y offsets could still be changed between scanline renders for vertical independent movement, ultimately allowing for parallax scrolling effects in either direction.

The plane layers were always rendered first, with the window layer rendered on top of the first plane layer, as specified from an x/y window position. Unlike the

74 plane layers, the window layer could not be scrolled, wrapped around or distorted, either horizontally or vertically [66].

In addition to horizontal scanlines, the Genesis featured 40 vertical column offsets (80 bytes total) that made 16-pixel columns of tiles within either plane layer appear at different positions from one another, essentially functioning like vertical scanlines [66][67]. While similar to the SNES’s graphical modes 2, 4 and 6 (where each layer tile had an independent x/y offset), all tiles in a 16-pixel column used the same y offset. Using horizontal scanline offsets and vertical column offsets at the same time lead to interesting graphical effects on screen.

Figure 6.3 – Screenshot from Sonic & Knuckles using vertical column offsets. Credit: Sega.

When drawing layers on screen, scanlines from each layer were rendered in an order that started with the second plane layer, followed by the first plane layer, and the window layer last. However, tiles with draw priority were drawn on top of tiles without draw priority [66]. (For example, a second plane layer tile with draw priority was drawn over a window layer tile without draw priority.)

75 Sprites

For the Genesis, the maximum number of sprites that could be simultaneously on screen (as well as simultaneously horizontal) depended upon the current screen width. In 32-column resolution, a maximum of 64 sprites (512 bytes total) could be on screen at once, with 16 sprites (or 32 sprite patterns) at most per horizontal line. All of them occupied VRAM as 1 of 128 sprite segments

(512 bytes total). In 40-column resolution however, a maximum of 80 sprites (640 bytes total) could be on screen at once, with 20 sprites (or 40 sprite patterns) at most per horizontal line. All of them occupied VRAM as 1 of 64 sprite segments

(1,024 bytes total) [65][66]. (These segments had 384 extra bytes available, which were typically occupied by additional tile patterns for layer tiles or sprites to use.)

And like layers, if sprites read non-pattern data for their patterns (or non-attribute data for their attributes), they would appear glitched on screen. As such, Genesis game developers had to be just as cautious when it came to allocating pattern data

(and attribute data) for sprites, as they had to be when allocating data for layers.

Each sprite was eight bytes long and featured a 10-bit x offset, a 10-bit y offset (each with values between 0 to 1,023), an 11-bit pattern index, a 2-bit palette index, a single bit for determining horizontal flipping, a single bit for determining vertical flipping & a single bit for draw priority, which determined whether the sprite appeared in front of plane layer tiles without draw priority (but behind all window layer tiles and plane layer tiles with draw priority), or in front of all plane layer tiles and window layer tiles without draw priority (but behind window layer tiles with draw priority) [67].

76 In addition to these standard attributes were new ones exclusive to Genesis sprites. Unlike previous systems, which had strict limits for sprite sizes on screen, the width and height of each Genesis sprite could individually be 1, 2, 3 or 4 tile patterns in length (8, 16, 24 or 32 pixels respectively) [67]. This meant that each

Genesis sprite could be 1 of 16 possible sizes, ranging from 1 tile pattern (8x8 pixels) to 16 tile patterns arranged as 4x4 (32x32 pixels) [66]. This also meant that a maximum of 1,280 sprite patterns could be on screen at once in 40-column resolution, and 1,024 sprite patterns in 32-column resolution. [65]. But unlike the

SNES, whose sprites read multiple tile patterns in VRAM via horizontal/vertical adjacency, Genesis sprites read multiple tile patterns sequentially. They were then displayed in an order that went from top to bottom followed by left to right. In addition, the Genesis offered a “zoom” mode that doubled the pixels of all sprites on screen (just like the Master System and Game Gear). When enabled, an 8x8 sprite displayed as 16x16, and a 32x32 sprite displayed as 64x64.

Sprites on the Genesis also utilized a one-directional linked list for their draw order. Sprites from previously covered systems were stored in arrays where their draw order was based upon their index positions (0, 1, 2… N). However, in order to get overlapping sprites to appear in a desired fashion, they had to be switched around in the array. Because this procedure was time consuming,

Genesis sprites had a 7-bit value that was used to point to the next sprite in the list to draw, regardless of its array position [65]. Index 0 always went first, followed by the index it pointed to, and so on, until the last sprite pointed to 0. As a result, index positions were never an issue when it came to drawing Genesis sprites.

77 Palettes

The Genesis had four palettes, each with 15 colors plus transparency.

Combining these colors with the base color effectively gave the Genesis a total of

61 colors to work with on screen [66]. Each color was able to hold 1 of 512 color values (2 bytes each), which came from a 9-bit RGB color space. Unlike most of the previous systems, which partitioned half of their palettes for layers and the other half for sprites, the Genesis allowed both types of graphics to share any of the four palettes. This allowed games to feature more discrete forms of gameplay, where a sprite could disguise itself as part of a layer in order to trick the player.

By default, the Genesis had a color display percentage of 11.9%.

However, there were two methods for extending the color capabilities of the Genesis. The first method was known as “shadow/highlight mode”, where colors on screen were tinted to appear darker or brighter [66]. The shadow effect cut a color’s RGB values by half, making it appear darker on screen. The highlight effect did the same thing, but went on to color-add half of the maximum

RGB value onto it, thus making it appear brighter on screen. These techniques effectively increased the color space to 1,407 values (512*3 – 64*2 – 1) with a maximum of 183 colors (61*3) capable of being displayed on screen, yielding a color display percentage of 13.0%. Despite the color increase, very few Genesis games utilized these effects. Doing so required the manipulation of layer tile draw priorities in order for graphics to appear brighter or darker. In addition, sprites using the 4th palette’s 15th and 16th colors scarified pixel visibility in order to highlight or shadow (respectively) any pixels beneath them on screen.

78 The second method for extending color capabilities was mid-frame palette swapping, which allowed all 61 colors to be changed between scanline renderings via DMA [20][65]. (This technique was also possible on the Master System,

Game Gear and SNES.) When using it, the entire color space could be displayed on screen, yielding a color display percentage of 100%.

The most common usage of mid-frame palette swapping in Genesis games was for water-themed stages, where a scrollable vertical position was used to represent water. The system’s color values were normal for scanlines above the position, but changed for scanlines below the position. This allowed all graphics

“submerged in water” to have their colors tinted when displayed on screen.

While it was possible to combine the shadow/highlight mode with mid- frame palette swapping, no known Genesis game ever made use of both techniques at the same time. However, theoretically utilizing both at the same time in a game could result in all 1,407 shadow/highlight colors being able to display on screen, also yielding a color display percentage of 100%.

Figure 6.4 – Screenshots from Sonic the Hedgehog 3 using mid-frame palette swapping. Notice

how the colors are different above and below a given position on screen. Credit: Sega. 79 Additional Hardware Features

The Genesis was capable of a few interesting hardware features. Like the

SNES, it could output twice the normal amount of scanlines via horizontal interlacing, where even ones rendered on one frame, followed by odd ones on the next frame, etc. [47]. When enabled, screen resolutions of 320x448, 256x448,

320x480 or 256x480 could be used, where different halves of the rows of pixels were output to different scanlines each frame. Likewise for normal resolutions, all rows of pixels were output to different scanlines each frame [65][66]. However, like the SNES, motion blur occurred when the effect was enabled.

Figure 6.5 – Screenshot from Sonic the Hedgehog 2 using horizontal interlacing. Credit: Sega.

A feature that was unique to the Genesis was “lock-on technology”, which allowed a game to read another game’s ROM data and combine it with its own in order to form an entirely new game [68]. Only one Genesis game ever made use of this feature – Sonic & Knuckles – with its cartridge having a slot on the top for

80 other cartridges to mount onto. Once both cartridges were connected and inserted into the Genesis, a different game played upon booting up the system.

Another feature unique to the Genesis was “blast processing” (a marketing term used for the system’s high-speed memory bandwidth), which was capable of processing graphic data much faster than the SNES [20]. However, late-life SNES games with embedded enhancement chips were able to produce graphic data processing bandwidths that were equivalent to the Genesis’s bandwidth.

Expansion Chips

Unlike the NES and SNES, the Genesis did not feature a wide variety of enhancement chips within its game cartridges. However, the most well known chip was the Sega Virtua Processor (SVP), which allowed for 3-dimensional graphics by rendering polygonal figures directly to a layer, pixel by pixel, without the usage of tiles or tile patterns [69]. It produced results that were equivalent to

Nintendo’s Super FX chip, but was only used within one game – Virtua Racing.

Figure 6.6 – Screenshot from Virtua Racing using the SVP chip’s polygonal layer. Credit: Sega.

81 Audio

The Genesis was capable of playing ten hardware-generated audio channels at any given time. These channels came from two different audio chips that were utilized simultaneously by the system: the Yamaha YM2612 and the

SN76489. The YM2612 provided six stereo channels (mono via A/V output) for wave samples generated by frequency modulation (FM) synthesis [70]. Each channel had its own FM operators, which meant that each could sound like a different instrument when playing a track. The third channel could play at a frequency different from the others, and the sixth channel could instead play sample-based audio (much like the SNES), which most games used to play recorded voice samples. The SN76489 (previously used in the Master System and

Game Gear) provided four mono channels: three for programmatically generated wave samples (PSG) and one for noise wave samples [71]. Collectively, both sound chips played audio back at a rate of 22,050 Hz.

Both music tracks and sound effects were fed into these channels from proprietary track sheet audio files, which consisted of notes for each channel (as well as sampled audio in certain cases). Because the system had 10 channels across both sound chips, music tracks and sound effects used different ones without competing with one another for playback. However, starting a new music track or sound effect still overrode a currently playing music track or sound effect respectively. In addition, when listening to audio via headphones inserted into the system, each YM2612 channel could individually produce stereo effects by panning the volume of each output (just like the SNES’s audio channels) [67].

82 Input

The Genesis utilized a C-shaped controller that had 8 inputs: a D-pad (Up,

Down, Left & Right) and four buttons (A, B, C & Start) [72]. The D-pad could be pressed in 1 of 8 directions at any time, just like with the previous systems. The four buttons also functioned identically to the NES’s four buttons, with A, B &

Start being the same and C replacing Select as an additional action button. But unlike the NES, whose buttons read right-to-left, the Genesis’s buttons read left- to-right. Also unlike the NES, whose controller was uncomfortable when held for a long time, the Genesis controller was designed to be comfortable when held for long durations. Up to two controllers could be connected to the system, with most games utilizing both for two-player experiences (just like the NES, Master System and SNES). Also like the SNES, certain games supported more than two players, but required special equipment in order to connect more controllers [73].

Figure 6.7 – The three-button Genesis controller. Credit: Sega.

83 In 1993 (five years into the system’s lifespan), a second Genesis controller was released. It was known as the “six-button” control pad and replaced the previous “three-button” control pad as the de-facto Genesis input device [74].

This controller added four additional buttons: X, Y, Z and Mode (located on the controller’s right shoulder). This brought the system’s total number of inputs up to 12, which matched with the SNES’s inputs. Genesis games released during and after 1993 were able to use the X, Y, Z and Mode buttons as additional inputs.

However, only a few ever made use of them. In addition, most Genesis games released before 1993 were natively compatible with the six-button control pad.

However, some were not. Pressing Mode during the system’s startup reverted the controller to a three-button input mode, which gave it full compatibility with all

Genesis games. Furthermore, the six-button control pad used a more ergonomic shape, in comparison to the three-button control pad’s awkward C-shape.

Figure 6.8 – The six-button Genesis controller. Credit: Sega.

84 Hardware Extensions and Other Similar Systems

The Genesis had two hardware extensions released for it during its commercial lifetime – the Sega CD and the Sega 32X.

The Sega CD (known as the Mega-CD in Japan) was released in 1992 as a peripheral that connected to the bottom of the Genesis and played games stored on CD-ROMs [75]. This enabled the system to run games that could play CD- quality audio tracks (or sample-based audio channels) at a rate of 44,100 Hz, and could display full motion videos (FMVs). These were advantages that CD-ROMs had over cartridges, as they provided games with more cinematic experiences.

Unlike Nintendo’s ill-fated SNES-CD, the Sega CD was both developed and commercially released by Sega. Second models of the Genesis and Sega CD were also released later in 1993, both offering sleeker and smaller designs [75].

Despite its technical advancements, the Sega CD never took off in popularity due to having an expensive selling price and being outclassed by CD hardware from rival companies [76]. As a result, Sega discontinued marketing the peripheral in

1994 and began working on its second hardware extension for the Genesis.

Figure 6.9 – The 1st model of the Sega CD attached to the 1st model of the Sega Genesis (left) and the 2nd model of the Sega CD attached to the 2nd model of the Sega Genesis (right). Credit: Sega.

85 The Sega 32X (known as the Sega Super 32X in Japan) was released in

1994 as a peripheral that connected to the top of the Genesis through its cartridge slot and played 32-bit cartridge games that were capable of advanced graphical effects (similar to those from the SNES) [77]. This enabled the system to run games that could utilize a 15-bit RGB color space of 32,768 values (along with capabilities that allowed the entire color space to be displayed on screen at once), that could utilize scaling, rotation & alpha blending for layers & sprites, that could render polygonal figures to the screen without needing expansion chips, and that could play two additional stereo channels of pulse-width modulated audio.

Despite occupying the system’s cartridge slot, Genesis games could still be played in the Sega 32X’s cartridge slot [77]. A few games even utilized both the Sega CD and Sega 32X simultaneously when running. However, despite its technical advances, the Sega 32X ended up being a commercial failure [78]. This happened because it was developed alongside the Sega Saturn, which was Sega’s

32-bit console with full 3D graphics [79]. Each was released less than a year apart from one another, which resulted in poor sales for both products.

Figure 6.10 – The Sega 32X attached to the Sega Genesis (left) and both the Sega 32X & Sega CD

simultaneously attached to the Sega Genesis (right). Credit: Sega.

86 Other systems worth mentioning are the PC-98 (a series of 16-bit

Japanese-exclusive computers from NEC that could play video games) and the

Neo Geo (a 16-bit console from SNK) [80][81]. Both were similar to the Genesis in terms of audio output. Early PC-98 computers used the Yamaha YM2203 sound chip, which consisted of six channels: three stereo channels using FM synthesis, and three mono channels using a variation of PSG called software sound generation (SSG) [82]. Later PC-98 computers used the Yamaha YM2608 sound chip, which consisted of sixteen channels: six stereo channels using FM synthesis, three mono channels using SSG, one stereo channel for sampled audio, and six stereo channels for rhythm tones pre-recorded onto the chip [83]. The Neo

Geo used the Yamaha YM2610 sound chip, which consisted of fifteen channels: four stereo channels using FM synthesis, three mono channels using SSG, one mono channel for noise generation, and seven stereo channels for sampled audio

(six at a rate of 18,500 Hz and one between 1,800 to 55,500 Hz) [84]. These sound chips played music tracks and sound effects that were identical to the ones played by the Genesis’s combined YM2612 and SN76489 sound chips.

Figure 6.11 – The NEC PC-9801 (left, credit: NEC) and SNK Neo Geo (right, credit: SNK).

87 In terms of graphics, PC-98 games were not similar to Genesis games.

Most of them utilized a screen resolution of 640x400 and displayed only 16 colors on screen from a 12-bit RGB color space of 4,096 values (0.39%) [80]. To compensate for the lack of colors, the graphics of many PC-98 games utilized dithering effects, where pixels of different colors used various types of checkerboard patterns in order to appear as separate “blended” colors on screen.

Figure 6.12 – Screenshots from Touhou Gensoukyou: Lotus Land Story (top, credit: ZUN) and

Madou Monogatari 2 (bottom, credit: Compile), both of which were games for the PC-98.

88 Neo Geo games on the other hand were similar (if not better) to Genesis games in terms of graphics. The system’s screen resolution was 320x224 (same as the Genesis) and could display a maximum of 8,192 colors on screen from a range of 65,536 values (12.5%) [81]. These color values came from two separate 15-bit

RGB color spaces, with one having slightly brighter colors than the other [85].

The 16th bit of a color value determined which color space it came from.

Despite these advantages in color, the Neo Geo was not popular as a home console, as it was extremely expensive to purchase in comparison to the SNES and Genesis [81]. Instead, the system gained popularity as an arcade cabinet, where it was featured in countless arcades throughout the early 1990s. Many popular Neo Geo games were available to play on these cabinets (which consisted of actual Neo Geo hardware and controls). Certain games even utilized memory cards that saved game progress, which allowed players to resume playing them again at a later time and on a different Neo Geo cabinet (or console).

Figure 6.13 – Screenshot from Metal Slug: Super Vehicle-001, a Neo Geo game. Credit: SNK.

89 Chapter 7: Comparing the Hardware Limitations of Each System

Given the technical hardware design limitations from the six Nintendo and

Sega systems covered, they will now be compared to one another based on the categories of graphics (screen resolution, tile patterns, layers, sprites & palettes), audio and input. Each category will also be compared with modern day game design approaches in order to accommodate for future video game development.

Screen Resolution

Width Height Ratio Systems used in (NTSC / PAL) (NTSC / PAL) 160 144 10:9 Game Boy, Game Gear 256 224 / 240 8:7 / 16:15 NES, Master System, SNES, Genesis 256 448 / 480 4:7 / 8:15 SNES and Genesis (2x height) 320 224 / 240 10:7 / 4:3 Genesis (widescreen) 320 448 / 480 5:7 / 2:3 Genesis (widescreen and 2x height) 512 224 / 240 16:7 / 32:15 SNES (2x width) 512 448 / 480 8:7 / 16:15 SNES (2x width and 2x height) Table 7.1 – List of screen resolution limitations.

The two most prominent television standards from the 1980s and 1990s were NTSC (North America/Japan) and PAL (Europe/Australia). For video game consoles, NTSC televisions displayed 224 scanlines (or 448 interlaced scanlines) and PAL televisions displayed 240 scanlines (or 480 interlaced scanlines) [7].

Each of these scanlines displayed a certain number of pixels that appeared horizontally stretched in order to fill up television screen aspect ratios. By default, the pixels from scanlines of the console systems were stretched by approximately

25% on television screens. As an alternative, certain Sega Genesis games output a

90 higher number of pixels per scanline in order to avoid horizontal pixel stretching.

Fortunately, the handheld systems didn’t have to worry about this issue, as each one used LCD screens in order to display square pixels.

As of the present day, the NTSC & PAL television standards have both been retired and replaced with new international television standards that have their screen pixels stay at the same height, regardless of region. Modern displays also no longer use screen ratios of 4:3, but instead use wider ratios, such as 16:9 or 16:10 [86]. In addition, modern video games now use screen resolutions that magnify to fit almost any display, regardless of the display’s screen ratio.

In designing a retro game, it is best to keep the screen resolution as close to those from the classic systems, while also accommodating the aspect ratios of modern displays. For example, if one were to magnify a 320x240 image into a

1600x900 display, the new resolution would be 1200x900, with extra space on the left and right of the display. The image could then be stretched by 33.33% in order to fill up the entire display. However, stretched images have never looked good on displays – not even those from the classic video game consoles.

The solution is to use a larger width than those of the classic systems, while also using their same height (240 pixels). It is also best to have the width and height result in a 15:9 aspect ratio, as this can be adjusted slightly in order to fit 16:9 or 16:10 displays. Therefore, a screen resolution of 400x240 pixels is ideal when creating modern day retro-styled video games. As a result, this resolution allows games to feature as much gameplay on screen as possible, while also being similar in size to the resolutions of classic video games.

91 Tile Patterns

System Total Layer Patterns Sprite Tile Patterns Patterns NES 512 256 (top or bottom) 256 (8x8, top or bottom) or 512 (8x16) Master System 512 512 (448 intentional and 256 (specified & Game Gear 64 garbage) anywhere) Game Boy 384 256 (0-255 or 128-383) 256 (0-255) Game Boy 768 512 (0-255 & 384-639 or 512 (0-255 & 384-639) Color 128-383 & 512-767) SNES N/A 512 (one 2-bpp segment), 512 (two 4-bpp (used VRAM 256 (one 4-bpp segment), segments at once) data segments) 128 (one 8-bpp segment), 256 (mode 7) Genesis 2,048 2,048 (intentional and 2,048 (intentional and garbage) garbage) Table 7.2 – List of tile pattern limitations.

Unlike screen resolutions, the number of tile patterns held in memory was not consistent across the classic systems. The 16-bit systems generally held more patterns in memory than the 8-bit systems, but at the drawback of non-pattern data being able to appear on screen as glitched images.

Another difference was the availability of tile patterns for assets to use.

The 8-bit systems tended to split tile patterns into two groups, such that layers and sprites used separate halves. The 16-bit systems lifted this restriction, with the

SNES partitioning tile patterns into data segments that layers or sprites could use.

In this case, tile pattern segments were all the same size, with the number of tile patterns in a segment depending on the bits per pixel of the asset accessing it. For

92 example, if a layer switched from being 2-bpp to 8-bpp, then the number of possible tile pattern indices for its tiles was reduced down to 25%.

In designing a retro game, it is best to keep tile pattern memory management as simple as possible. As such, the usage of assets with multiple bits per pixel is unnecessary, as it is easiest when assets keep to a uniform bpp. It is also unnecessary for non-pattern data to be displayed on screen, as this was never an intended graphical effect of classic games. However, having layers and sprites restricted to a finite number of tile patterns at one time is an essential aesthetic of retro games. As such, the usage of tile pattern segments is essential. Layers should be able to access tile pattern segments, with each layer tile accessing its tile patterns. Likewise, sprites should be able to access tile patterns within tile pattern segments. As a result of this design choice, animation can be produced in one of two ways. Layers & sprites can change their tile pattern segments, or layer tiles & sprites can change their tile patterns within tile pattern segments.

The size of a tile pattern segment is determined by the number of tile patterns it holds, the bits per pixel of the tile patterns, and the resolution of the tile patterns. Layers and sprites should be able to utilize tile pattern segments that always hold the same number of tile patterns. The bits per pixel of the tile patterns should stay the same in a game, but their resolution should be changeable. This design choice results in games utilizing tile pattern segments of different sizes, which is based on whether the tile patterns are 8x8, 16x16, 24x24 or 32x32 pixels in size. It also allows graphics the ability to potentially change their current size in a game by first changing their current tile pattern segment.

93 Layers

System Number Layer Tile Colors per Palettes of Size Size Tile per Tile Layers (tiles) (pixels) NES 1 32x30, 8x8 3 4 64x30, 32x60 Master System & 1 32x30, 8x8 16 2 Game Gear 32x32 Game Boy 2 32x32 8x8 3 1 (GB), 4 (SGB) Game Boy Color 2 32x32 8x8 4 8 SNES (modes 0 4 (m0), 32x32, 8x8, 3 (m0-1, 4-5), 8 (m0-6), through 6) 3 (m1), 64x32, 16x16 15 (m1-3, 5-6), 1 (m3-4) 2 (m2-5), 32x64, 255 (m3-4) 1 (m6) 64x64

SNES (mode 7) 1 128x128 8x8 127, 255 1 Genesis 3 32x32, 8x8 15 4 64x32, 128x32, 32x64, 64x64, 32x128 Table 7.3 – List of layer limitations.

Not only did the number of layers that could be simultaneously displayed on screen vary between the 8-bit and 16-bit systems, it also played a critical role in defining the aesthetic look of each system. Systems with only one layer on screen are instantly recognizable as “8-bit” due to the fact that their backgrounds

& foregrounds shared the same layers, and thus scrolled at the same rate. 94 However, these systems had difficulty when it came to displaying game-relevant information on screen. The information had to exist as either a series of sprites that were statically placed on screen, or within a portion of the layer that was kept static by scanline programming tricks.

Likewise, systems with multiple layers on screen are instantly recognizable as “16-bit”, due to the fact that their backgrounds & foregrounds used individual layers, and thus scrolled independently of one another. Having multiple layers also meant that displaying game-relevant information was no longer an issue. One of the layers could display all of the game information and never scroll, while the other layers could do all of the necessary stage scrolling.

In designing a retro game, the number of scrollable layers should be based on whether it is meant to portray 8-bit or 16-bit aesthetics. An additional static layer should also be included (regardless of aesthetic) for the sole purpose of displaying game information. Unlike the static window layers from the Game Boy and Genesis, the transparent portions of this layer should be able to show opaque pixels from the layers beneath it.

Another design difference should be in how layers manage the tiles from scrollable stages. On classic systems, tiles from a stage were loaded in and out of layers as the screen wrapped around them. In modern game design however, it is more efficient to have all stage tiles loaded into layers. These tiles are then kept active, but only within a scrollable rectangular region, which effectively keeps small portions of each layer in memory during gameplay. As such, the x/y offsets for sprites should be in relation to the top-left of stages, and not the screen.

95 System Pattern Palette Horizontal Vertical Draw Index Index Flipping Flipping Priority NES 8-bit 2-bit (shared none none none with 4 tiles) Master System 9-bit 1-bit 1-bit 1-bit 1-bit & Game Gear Game Boy 8-bit none none none none Game Boy 9-bit 3-bit 1-bit 1-bit 1-bit Color SNES (modes 10-bit (max), 3-bit 1-bit 1-bit 1-bit 0 through 6) 9-bit (2-bpp), 8-bit (4-bpp), 7-bit (8-bpp) SNES 8-bit none none none none (mode 7) Genesis 11-bit 2-bit 1-bit 1-bit 1-bit Table 7.4 – List of layer tile attributes.

The attributes of layer tiles were fairly consistent amongst the classic systems (with the exceptions of the NES, Game Boy and mode 7 of the SNES).

Each featured a pattern index, a palette index, a bit for horizontal flipping, a bit for vertical flipping, and a bit for draw priority.

In designing a retro game, it is best to keep the first four attributes, but to discard the draw priority. Its original purpose was to draw layer tiles in front of or behind sprites. However, sprites also have a draw priority for drawing themselves in front of or behind layer tiles. If a system features multiple layers, it is best to leave draw priority exclusively for sprites. Replacing it should be a bit for individual tile visibility, which can be useful for invisibility effects on screen.

96 Sprites

System Number of Sprites per Sprite Size Colors Palettes per Sprites Row (pixels) per Sprite Sprite NES 64 8 8x8, 8x16 3 4 Master 64 8 8x8, 8x16 15 1 System & Game Gear Game 40 10 8x8, 8x16 3 1 (GB), Boy 2 (GBC-mc), 4 (SGB) Game 40 10 8x8, 8x16 3 8 Boy Color SNES 128 32 8x8, 16x16, 15 8 32x32, 64x64 Genesis 80 (40-CR), 20 (40-CR), 8x8, 16x8, 15 4 64 (32-CR) 16 (32-CR) 24x8, 32x8, 8x16, 16x16, 24x16, 32x16, 8x24, 16x24, 24x24, 32x24, 8x32, 16x32, 24x32, 32x32 Table 7.5 – List of sprite limitations.

Like layers, the maximum number of possible sprites on screen played a critical role in defining the differences between 8-bit and 16-bit aesthetics. Most of the 8-bit systems could only use between 40 to 64 sprites, with 8 to 10 simultaneously horizontal. The 16-bit systems on the other hand increased these 97 amounts, being able to use between 80 to 128 sprites, with 20 to 32 simultaneously horizontal. In the event that too many sprites were simultaneously horizontal, one of two things would happen. On the 8-bit systems, a flickering effect occurred, where all of the sprites in a row took turns being visible between different frames. On the 16-bit systems however, excessive sprites from either the left or right sides of the screen were never rendered.

System X/Y Pattern Palette H/V Draw Other Offsets Index Index Flipping Priority NES 8-bit (x), 8-bit 2-bit 1-bit (h), 1-bit none 8-bit (y) 1-bit (v) Master 8-bit (x), 8-bit none none none none System 8-bit (y) & Game Gear Game 8-bit (x), 8-bit 1-bit 1-bit (h), 1-bit none Boy 8-bit (y) 1-bit (v) Game 8-bit (x), 9-bit 3-bit 1-bit (h), 1-bit none Boy 8-bit (y) 1-bit (v) Color SNES 9-bit (x), 9-bit 3-bit 1-bit (h), 2-bit 1-bit (size) 8-bit (y) 1-bit (v) Genesis 10-bit (x), 11-bit 2-bit 1-bit (h), 1-bit 2-bit (x size), 10-bit (y) 1-bit (v) 2-bit (y size), 7-bit (order) Table 7.6 – List of sprite attributes.

Sprite attributes were fairly consistent amongst the classic systems (with the exceptions of the Master System and Game Gear). Each featured an x offset, a y offset (both of which determined their locations on screen), a pattern index, a

98 palette index, a bit for horizontal flipping, a bit for vertical flipping, and a bit for draw priority (in relation to layers). The 16-bit systems included additional attributes that allowed individual sprites to change their pixel size by determining how many tile patterns to use. Sprites on the SNES could choose from 1 of 2 sizes

(which came from 2 of 4 pre-determined sizes), while sprites on the Genesis could choose from 1 of 16 sizes. In comparison, the 8-bit systems forced all of their sprites to use 1 of 2 uniform sizes. Sprites on the Genesis also featured a draw order attribute that was utilized as part of a one directional linked list for drawing sprites on screen. This was different from other systems, where their sprite drawing orders were determined by the positions of sprites within sprite arrays.

In designing a retro game, the maximum number of sprites on screen should be based on whether it is meant to portray 8-bit or 16-bit aesthetics (with less for the former and more for the latter). It is also best to discard the limit on sprites per row. Having sprites clipped off screen was never an intended graphical effect, but rather a hardware rendering limitation. Fortunately, modern GPU libraries (OpenGL, DirectX, etc.) can use draw ordering to render all 2D graphics on screen without any hardware issues occurring. As such, all sprites should be visible on screen when simultaneously horizontal.

In addition, sprite attributes should consist of an x/y offset, tile pattern segment index, tile pattern index, palette index, h/v flipping, draw priority and visibility. However, x/y offsets should be in relation to the top-left of stages, sprite sizes should be determined by tile pattern segments, and two draw priorities should be used: one in relation to layers and one in relation to other sprites.

99 Palettes

System Maximum Colors on Screen Total Color Color Display Values Percentage NES 25 (1 base + 8x3 palette) 56 44.6% Master System 32 (2 base + 2x15 palette) 64 50% Game Boy 4 (1 base + 3x3 palette, but 4 100% each displayed 1 of 4 colors) Super Game Boy 73 (1 base + 4x3 palette + 32,768 0.22% 4x15 border) Game Boy Color 56 (8 base + 16x3 palette) 32,768 0.17% Game Gear 32 (2 base + 2x15 palette) 4,096 0.78% SNES (mode 0) 217 (1 base + 32x3 palette + 32,768 0.66% 8x15 palette) SNES (modes 1, 241 (1 base + 16x15 palette) 32,768 0.74% 2, 5 and 6) SNES (modes 3, 256 (1 base + 1x255 palette) 32,768 0.78% 4 and 7) SNES (8-bit 496 (1 base + 16x15 palette + 32,768 1.51% direct color) 255 color space) SNES (11-bit 2,288 (1 base + 16x15 palette 32,768 6.98% direct color) + 2,047 color space) Genesis 61 (1 base + 4x15 palette) 512 11.9% Table 7.7 – List of palette limitations.

Color played the largest role in defining the differences between 8-bit and

16-bit aesthetics. This was measured from the classic systems based on their maximum number of displayable colors, the size of their color spaces, and their color display percentages. Factors that played an important role in computing these measurements included their base colors, their palettes (layer & sprite) and the values (color & transparency) within their palettes. 100 Systems generally had one base color that served as the background.

However, certain systems (Master System, Game Gear and Game Boy Color) were able to display multiple base colors on screen. They could even be changed via mid-frame palette swapping in order to display color gradients.

Palettes held 3 to 15 (or in rare cases, 255) colors that were used to fill in the non-zero indices of tile patterns. The 16-bit systems generally had a larger number of palettes than the 8-bit systems. However, most systems split this number in half for layer tiles and sprites to separately use. Both types of graphics could change their colors by either switching palettes, or by switching the colors in their current palette (which affected other graphics using the same palette).

Direct color modes from the SNES even allowed colors from color spaces to appear alongside colors from palettes, which further increased the color output.

In most systems (except the NES and Game Boy), the color space was determined by the amount of bits required for the red, green and blue shade possibilities in a color value, with each portion being equal. This meant that having 4 possibilities per shade resulted in 64 possible colors in a color space, while having 32 possibilities per shade resulted in 32,768 possible colors.

In designing a retro game, the number of available palettes (as well as the number of colors each one holds) should be based on whether it is meant to portray 8-bit or 16-bit aesthetics (with less for the former and more for the latter).

These palettes should be split evenly, with one half for layers to use and the other half for sprites to use. There should also be only one base color (for default pixel display) and no usage of direct color (as it defeats the purpose of color palettes).

101 The color space should also function identically to that of the classic systems, where even portions of red/green/blue shade possibilities determine color values, and the number of possibilities is based on whether a game portrays 8-bit or 16-bit aesthetics. However, one hallmark of games from classic systems was their ability to clearly distinguish different colors on screen, with very little shade gradation ever visible. As such, the number of shade possibilities should be determined by even numbers (4, 6, 8), instead of by powers of two (4, 8, 16).

In the following figure, each row consists of different shade possibilities for the color red. It is easy to distinguish the colors when there are 4 or 6 shades.

But it becomes much harder to distinguish when there are 14 or 16 shades. (Keep in mind that the SNES used 32 shade possibilities for its color values.)

Figure 7.1 – Different shade possibilities for the color red.

102 Audio

System Sound Chip Channels Contents Playback Rate NES Ricoh 2A03 (NTSC), 5 Mono 2 Square, 22,050 Hz Ricoh 2A07 (PAL) 1 Triangle, 1 Noise, 1 DPCM Master SN76489 4 Mono 3 PSG, 22,050 Hz System 1 Noise Game Boy Sharp LR35902 4 Stereo 2 Square, 22,050 Hz 1 Noise, 1 DPCM Game Gear SN76489 (w/ stereo) 4 Stereo 3 PSG, 22,050 Hz 1 Noise SNES Sony SPC-700 8 Stereo 8 Sampled 32,000 Hz Genesis Yamaha YM2612 10 (6 Stereo 6 FM Synth, 22,050 Hz and SN76489 and 4 Mono) 3 PSG, 1 Noise Table 7.8 – List of audio limitations.

Unlike graphics, video game audio is not an easily quantifiable category.

Classic systems used different sound chips, each of which produced unique audio styles for the music tracks and sound effects of their games. However, one consistent limitation across most systems was that only one music track or sound effect could play at a time. When a new one was executed, its notes overrode the notes of the one that was currently being played.

In designing a retro game, it is best to follow the audio standards of classic systems by all of their specifications. For games meant to portray 8-bit aesthetics, it is best to have them sound exactly like a game from the NES, Master System, 103 Game Boy or Game Gear. Likewise, for games meant to portray 16-bit aesthetics, it is best to have them sound exactly like a game from the SNES or Genesis.

Despite this, games should be able to play music tracks and sound effects simultaneously (regardless of aesthetic). Only one of each should play at a time, where one that is newly executed still cancels out one that is currently playing.

Input

Inputs NES Game Master Game SNES Genesis Genesis Boy System Gear (3-button) (6-button) D-pad ✓ ✓ ✓ ✓ ✓ ✓ ✓ (↑ ↓ ← →) Start ✓ ✓ ✓ (Pause) ✓ ✓ ✓ ✓ Select ✓ ✓ ✓ ✓ (Mode) A ✓ ✓ ✓ (1) ✓ (1) ✓ ✓ ✓ B ✓ ✓ ✓ (2) ✓ (2) ✓ ✓ ✓ C ✓ ✓ X ✓ ✓ Y ✓ ✓ Z ✓ L ✓ R ✓ Total: 8 8 7 7 12 8 12 Table 7.9 – List of input limitations.

Like audio, controller input varied a lot from system to system. The 8-bit systems generally utilized 7 or 8 inputs, while the 16-bit systems generally utilized 12 inputs. This increase was made in order to allow new games to be more engaging for players than the ones from previous systems. Most inputs were

104 easily accessible, such as the D-pad, A, B, X & Y for thumbs, and L & R for index fingers. However, some inputs were difficult to access, such as Start &

Select, which were usually placed in the middle of controllers. It was also difficult to memorize the 3x2 button layout of the Genesis’s six-button controller, as it was very easy to mistake the face buttons for one another.

In designing a retro game, it is best to use 10 inputs, regardless of a game’s intended aesthetic. This includes the D-pad (Up, Down, Left & Right), four face buttons (A, B, X & Y) and two shoulder buttons (L & R). The following table shows how these inputs match up when implemented on a keyboard, a Sony

PlayStation controller or a Microsoft Xbox controller. By default, these inputs have a 1:1 implementation on Nintendo system controllers.

Recommended Keyboards Sony PlayStation Microsoft Xbox (Nintendo) controllers controllers Up Up arrow Up (digital/analog) Up (digital/analog) Down Down arrow Down (digital/analog) Down (digital/analog) Left Left arrow Left (digital/analog) Left (digital/analog) Right Right arrow Right (digital/analog) Right (digital/analog) A button X key ○ button A button B button Z key X button B button X button S key △ button X button Y button A key □ button Y button L button Q key L1 button LB button R button W key R1 button RB button Table 7.10 – Recommended inputs as implemented on keyboards and controllers.

Modern day controllers lack the traditional Start and Select buttons as part of an effort to phase out their usage, with certain face buttons taking over their

105 pausing/confirming functionalities [87]. To this end, an additional “Start” button should be included in games, having the same effect as X (in terms of pausing games) and A (in terms of confirming menu options). This additional button should be implemented as the Enter key on keyboards, the Plus button on

Nintendo controllers, the Options button on Sony controllers and the Menu button on Microsoft controllers.

In addition to the D-pad, modern day controllers also utilize dual analog sticks for additional movement in games. To this end, the four directional inputs should be mapped to both the D-pad and the left analog stick. This will allow players the freedom to use whichever one they want for gameplay, based on what they feel comfortable using in other games.

For input customization, only A, B, X, Y, L and R should be mappable to any of the six buttons on a modern day controller. In addition, all 10 of the inputs

(not counting Start) should be mappable to the alphanumeric keys, arrow keys and certain symbol keys (- + [ ] ; ‘ , . /) on a keyboard. This will allow players using keyboards the freedom to utilize whichever input scheme they prefer, including the popular WASD layout. Input device customizations should also be saved into a single file that can be read from whenever a game is launched.

Furthermore, games should be able to support multiple connected input devices in order to allow players the freedom to use whichever one they prefer.

They should also support keyboard shortcut commands that allow players the functional abilities to toggle between full-screen/native resolutions, reset the game, save screenshots of the game, and exit out of the game.

106 Chapter 8: Shovel Knight – An example of a Retro-Styled Video Game

Figure 8.1 – Shovel Knight poster. Credit: Yacht Club Games.

Shovel Knight is a 2D side-scrolling platformer video game that was developed and published by Yacht Club Games. The game was funded from a successful Kickstarter campaign in 2013, where it would go on to initially release on the Nintendo Wii U, Nintendo 3DS and PC in June 2014 as a digitally downloadable game [88]. After its initial success, the game was released digitally on the Sony PlayStation 3/4/Vita & Microsoft Xbox One in April 2015, released physically on all aforementioned systems in October 2015, and released digitally once again for the Nintendo Switch in March 2017.

Shovel Knight is just one example of the modern day retro-styled video games currently being produced. However, it has gone on to become one of the most popular and financially successful games of this production style.

107 The design process on Shovel Knight began by posing the question:

“What if development for the NES never stopped? How would an 8-bit game feel and play if developed today?” [89]. Shovel Knight was designed to be a modern video game that looked and felt like an NES game, without actually being an NES game. There are many technical aspects of the game that share similarities to games released on the NES, while other technical aspects are completely different for the sake of delivering modern day gaming conveniences.

Figure 8.2 – Screenshot from Shovel Knight. Credit: Yacht Club Games.

Screen Resolution

While NES games used a 256x240 pixel resolution, Shovel Knight instead used a 400x240 pixel resolution for its display. Both used the same height, but different widths. This design choice was made as an addition that allowed for

“extra room in level design for puzzles, objects, and breathing room” [89]. It was also made in order to accommodate for modern widescreen display ratios (16:9,

15:9 and 16:10). But rather than using a nearest-neighbor form of magnification

108 like most retro-styled games (where colors remained solid in all pixels), Shovel

Knight instead used a bicubic form of magnification, where colors blended with one another in pixels on the screen resolution that lacked a 1:1 correlation with the native resolution. The magnification factor was also the same horizontally and vertically. For example, when output to a 1920x1080 display, the game’s resolution increased to 1800x1080 (4.5 times), with empty space on the sides.

Tile Patterns

Shovel Knight implemented tile patterns in an entirely different format than the classic systems. Rather than using data segments, the game used image files, with a given number of tile patterns drawn within the image on a grid, both horizontally and vertically. There was no limit regarding the size of the tile patterns or how many of them could be stored in an image file, which meant that the files could be as large or small in size as desired [90]. There was also no limit on how many of these image files could be in use at one time. Even though all tile patterns could potentially be displayed at once, the developers chose to impose their own self-limitation on the number of tile pattern image files in use at one time, as a means of making the game feel like a limited NES game.

Not only were image files containing multiple tile patterns used for the game’s layers, they were also used for the game’s sprites. With this in mind, the number of tile patterns that layers and sprites could use for animation was limited, just like the graphics from classic systems. It is also important to note that all of these image files used colored pixels in order to represent indexed positions that were recolored by different palettes during the game’s runtime [89].

109 Layers

Unlike NES games, which could only utilize one layer, Shovel Knight was capable of utilizing as many layers as possible. Once again, the developers imposed a self-limitation of keeping to around 5 or 6 layers per stage at most [89].

This included a layer for the interactive foreground, a layer for the static display of game information, and the remaining layers for various portions of the non- interactive background. Like most NES games, Shovel Knight’s layer movement was exclusively horizontal or exclusively vertical, but never both at once.

However, unlike NES games, which produced parallax movement effects by scrolling horizontal rows of the same layer at different rates, Shovel Knight produced parallax movement effects by scrolling each of the background layers

(along with the foreground layer) at different rates.

As an example, while the foreground layer scrolled normally as the playable character moved through it, each of the background layers scrolled at slower rates, with the background of the closest depth scrolling half as fast as the foreground, and the background of the farthest depth scrolling the slowest. Even though this technique was introduced in games for the SNES and Genesis, the developers’ justification to this design choice was that it “felt like the next technological step the NES would make so it didn’t feel out of place to us” [89].

Another difference involves the size of layer tiles. For NES games, a

16x16 pixel graphic within a scrollable layer used four 8x8 tiles arranged as 2x2.

Having multiples of this graphic in a layer meant that the same 2x2 tile patterns had to be placed at each occurrence. But unlike NES games, Shovel Knight’s

110 layer tiles were 16x16 (with its HUD layer tiles remaining at 8x8) [89]. This choice was made in order to make level design more efficient. As such, a 16x16 pixel graphic within one of Shovel Knight’s scrollable layers only used one tile, which effectively reduced the amount of tile placement in layers down to 25%.

The reason why the static HUD layer used 8x8 tiles was because their tile patterns consisted of text, which is generally meant to be small in order to display dialogue and information on screen. One benefit of having the HUD as its own layer was the ability for sprites to be drawn in front of or behind it for gameplay purposes [89]. In addition to abiding by a grid layout, the HUD’s layer tiles were also able to utilize x/y offsets in order to be spaced out, which was used for centering text on screen that contained odd numbers of characters.

Because Shovel Knight was a game with side-scrolling stages, memory management of its layer tiles was achieved via rectangular regions of active tiles.

Upon starting a stage, all of its tiles were loaded into each of the layers. From here, the camera followed the playable character as they moved around the stage.

Layer tiles within a rectangular region around the camera were kept active in memory, while layer tiles outside of the rectangular region were kept inactive.

Sprites

Also unlike NES games, which could only feature a limited number of sprites on screen at once, Shovel Knight was capable of utilizing as many sprites on screen as possible. The developers “kept the sprite count as low as [they] could, but … did not sweat the exact numbers” [89]. This also meant that there was no restriction on the number of sprites per row – all of them could be

111 simultaneously horizontal. As a result, Shovel Knight lacks the sprite flickering effect that was present in most NES games. The developers felt that the effect was more detrimental than nostalgic, and thus ignored it during development.

Both sprites and layer tiles had individual attributes. While each of these graphics shared the same general ones (x/y offset, pattern index, palette index, h/v flipping and draw priority), they were also capable of having their own unique attributes. This was made possible due to the game being written in the C++ coding language, which allowed for object-oriented programming as a means of developing sprites and layer tiles [91]. This also meant that the objects representing these graphics utilized inheritance and polymorphism techniques for their attribute data management. This was a significant difference from NES games, where their sprite attribute memory was finite and limited.

Palettes

Shovel Knight used the same 56 colors that NES games used, as well as four additional ones. These colors (dark purple, dark red, dim beige and light brown) were added in order for the game to “display [gradients of] hues” that were “underrepresented” on the NES [89]. This meant that Shovel Knight used 60 colors total. Unlike the NES, which limited the number of colors a graphic could use, Shovel Knight allowed each of its sprites and layer tiles the ability to use as many colors from its color space as necessary. Even though this meant that they could potentially display all 60 colors, the developers generally gave each one 4 or 5 colors to work with, as well as transparency. As a result of this design choice,

Shovel Knight had a color display percentage of 100%.

112 In order to enforce the game’s color values, every graphic’s pixels relied upon 256 color indices (of which only 5 or 6 were generally used). As such, these indices were filled in by the colors within palettes that were assigned to graphics.

Every graphic’s palette was unique from one another (including duplicates of the same palette), which was a stark contrast from the uniform palettes that NES graphics used. This design choice was made because “the headache to make one palette work [for multiple graphics did not] benefit gameplay” [89]. Shovel

Knight’s sprites and layer tiles could therefore cycle through different palettes in order to portray damage or explosion effects. The only drawback to this method was that the colors within a palette could not be changed – a different palette had to be used if one or more colors within a graphic needed to be changed.

Figure 8.3 – Palette-cycling used to signify damage done to an enemy. Credit: Yacht Club Games.

Audio

Unlike graphics, the audio in Shovel Knight strictly followed the NES’s audio standards when it was composed [89]. The only major difference from NES games was that it utilized the 3 mono channels provided by the Japan-exclusive

VRC6 expansion chip, in addition to to the 5 mono channels provided by the standard 2A03 sound chip. However, of the 8 channels available, only 7 of them

113 were utilized by music tracks and sound effects, as the pulse-code modulation channel went unused throughout the entire soundtrack.

Another difference was that the audio in Shovel Knight got played using raw audio files (composed via Famitracker), as opposed to the track-sheet audio files used in NES games [89]. This gave the developers an easier time in terms of programming the audio cues, but at the cost of having the game turn out far larger in size than that of the average NES game. Also unlike NES games, Shovel

Knight’s music tracks and sound effects did not compete for playback. All audio files were able to simultaneously play at any time (including duplicates of the same audio file). This was utilized in order to play multiple audio files at once as a means of sounding like a single sound effect – a technique inauthentic to the

NES’s audio hardware, but much nicer to listen to overall.

Input

Shovel Knight’s controls relied upon 11 inputs: a D-pad (Up, Down, Left

& Right), a jump button, a weapon button, a sub-weapon button, an inventory menu button, a pause menu button and two buttons for cycling between sub- weapons [92]. Despite being different from NES games (which only relied upon 8 inputs), Shovel Knight’s gameplay primarily revolved around the usage of the jump and weapon buttons in order to feel like controlling the NES’s A and B buttons respectively. The game’s inputs were mapped to work on Nintendo, Sony

& Microsoft controllers (as well as computer keyboards), and could also be customized on any of them. Furthermore, because Shovel Knight featured two- player gameplay modes, it supported up to two input devices connected at once.

114 Chapter 9: Renegade Drive Software Design

Thus far, this thesis has researched the technical hardware limitations of the six video game systems that were released by Nintendo and Sega between the years of 1985 to 1991. Each system was analyzed based on their graphics (screen resolution, tile patterns, layers, sprites & palettes), audio and input limitations.

Each of the limitations were then separated by category and compared to one another – not just system-by-system, but also against modern day game design principles. In addition to these comparisons, Shovel Knight (a retro-styled video game) was also analyzed as an example of how it is possible to create a modern video game with 8-bit or 16-bit aesthetics.

It is now time to conceive of new design specifications based upon all of the comparisons and analyses that have been conducted thus far. Therefore, this thesis proposes Renegade Drive: software design limitations that will allow game developers to create authentic 8-bit and 16-bit video game experiences.

Figure 9.1 – Renegade Drive logo.

Renegade Drive’s core purpose is to allow video game developers the ability to capitalize off of the newly emerging market for retro 2D video games.

Instead of explicitly being a video game engine, Renegade Drive is a set of technical design specifications that serve as guidelines for game developers to abide by throughout the production of video games that are intended to look, feel and function identically to the ones that were produced 20 to 30 years ago.

115 Rather than duplicating the hardware limitations of the older systems,

Renegade Drive’s software design limitations act as their theoretical rival competitors. Imagine if there had been a console successfully competing against the NES or Master System in the mid 1980s, against the Genesis in the late

1980s/early 1990s, or against the SNES in the mid 1990s? As a response to this question, Renegade Drive’s specifications consist of three variations (referred to as ‘modes’), each based upon the aesthetic look and feel of video games from specific time periods in gaming history.

“Renegade Drive Mode 1” is for games that look and feel like they were made between 1985 to 1988 – an era defined by the simplistic 2D graphics of the

NES and Master System. “Renegade Drive Mode 2” is for games that look and feel like they were made between 1989 to 1992 – an era defined by the Genesis, its more detailed 2D graphics, and its impressive scrolling effects. Lastly,

“Renegade Drive Mode 3” is for games that look and feel like they were made between 1993 to 1996 – an era defined by the SNES, its advanced 2D graphics, and the rendering techniques it used to make graphics appear on screen as though they were three-dimensional.

Screen Resolution

The native screen resolution for Renegade Drive games is 400x240 pixels, regardless of their modes. It can magnify full-screen on displays with 16:9, 15:9 or 16:10 aspect ratios using nearest-neighbor scaling (where magnified pixels are solid in uneven rows and columns), as opposed to bicubic scaling (where magnified pixels blend into one another in uneven rows and columns).

116 Tile Patterns

Tile pattern segments manifest in Renegade Drive games as tileset images.

Each one contains 256 tile patterns (in the arrangement of 16x16) and comes in one of four possible sizes: 128x128 pixels (which contains 8x8 pixel tile patterns),

256x256 pixels (which contains 16x16 pixel tile patterns), 384x384 pixels (which contains 24x24 pixel tile patterns) and 512x512 pixels (which contains 32x32 pixel tile patterns).

Tile patterns are represented as gray scale images within tilesets, with 24- bit gray scale colors acting as index numbers. Each color uses the same 8-bit values for its red, green and blue portions, thus causing them to appear gray.

However, these colors are not displayed during a game’s runtime, but are instead filled in with palette colors when rendered on screen. Games running in Mode 1 use four possible gray scale values (0, 85, 170, 255), which act as palette indices

0-4 when divided by 85. Games running in Mode 2 use eight possible gray scale values (0, 36, 72 … 180, 216, 252), which act as palette indices 0-7 when divided by 36. Lastly, games running in Mode 3 use sixteen possible gray scale values (0,

7, 34 … 221, 238, 255), which act as palette indices 0-15 when divided by 17.

Both sprites and layers can access tilesets. Games running in Mode 1 can have up to 6 tilesets in use at one time. Games running in Mode 2 can have up to

7 tilesets in use at one time. Lastly, games running in Mode 3 can have up to 8 tilesets in use at one time. In addition, sprites and layer tiles utilize custom rectangular masks for in-game collision detection with one another. However, these are stored in images files that are separate from tilesets.

117 Layers

Renegade Drive games running in Mode 1 use two layers: a scrollable midground and a static HUD. Games running in Mode 2 use three layers: the same two as before, plus a scrollable background. Lastly, games running in Mode

3 use four layers: the same three as before, plus a scrollable foreground.

Scrollable layers can contain tiles in widths of 25, 50, 75 or 100, and in heights of

15, 30, 45 or 60. This results in 16 possible sizes, with the minimum being 375 tiles arranged as 25x15 (or one screen size) and the maximum being 6,000 tiles arranged as 100x60 (or sixteen screen sizes). Static HUD layers on the other hand do not scroll, and therefore always contain 1,500 tiles arranged as 50x30 (or one screen size). The size of tiles is always 16x16 pixels for scrollable layers and 8x8 pixels for static HUD layers. (Both layer sizes & tile sizes are permanent and cannot be changed during a game’s runtime, even when switching tilesets.)

Each layer has draw priority over the one beneath it, going in the order of background (3), midground (2), foreground (1) and HUD (0). Once rendered, all of them are displayed on screen by a camera (400x240 pixels in size). Each layer can use uniform, row-specific and column-specific x/y offsets to distort their tiles horizontally and/or vertically in order to replicate scanline distortion effects, albeit not perfectly. (Tile-specific shaders might be able to better replicate these effects, but more research still needs to be done in this specific category.) In addition to these x/y tile offsets, layers hold information regarding their tileset index and visibility. Likewise, layer tiles hold information regarding their tile pattern index, palette index, horizontal/vertical flipping and visibility.

118 Sprites

Renegade Drive games running in Mode 1 are able to display a maximum of 64 sprites on screen at once. Games running in Mode 2 are able to display a maximum of 96 sprites on screen at once. Lastly, games running in Mode 3 are able to display a maximum of 128 sprites on screen at once. Sprites hold information regarding their x/y offset, tileset index, tile pattern index, palette index, horizontal/vertical flipping, visibility, as well as two draw priorities: one for drawing them on top of one another, and one for drawing them between layers. Sprites are able to have individual sizes of 8x8, 16x16, 24x24 or 32x32 pixels (based on the sizes of their tilesets and tile patterns), which they can change by switching tilesets of different sizes. Their x/y offsets are in relation to the top- left corners of stages, and not the screen. Also, their “layer” draw priority is more significant for rendering than their “sprite” draw priority.

In addition, sprites and layers from games running in Mode 3 are capable of advanced graphical techniques similar to those from the SNES and Game Boy

Advance. Each sprite and layer is able to perform a variation of the mosaic effect, where a sub-region (1x1, 2x2, 4x4, 8x8, 16x16 or 32x32 pixels in size) is filled in with the color averaging of its opaque pixels. Each sprite and layer is also able to scale and rotate on screen, as well as perform color translucency via cumulative color addition, color subtraction or color averaging. Furthermore, the foreground layer can display single-color shapes (circular zoom-outs, diamonds, etc.) by manipulating 480 left/right boundaries (2 for each line of pixels) via AND, OR,

XOR or NXOR comparison operations.

119 Palettes

All Renegade Drive games utilize one base color, regardless of their modes. However, games running in Mode 1 use colors consisting of 4 shade possibilities, resulting in a color space of 64. They also use 8 palettes (half for layers and half for sprites), each holding 3 colors (plus transparency), resulting in a maximum of 25 colors on screen, at a color display percentage of 39.1%. Games running in Mode 2 use colors consisting of 6 shade possibilities, resulting in a color space of 216. They also use 12 palettes, each holding 7 colors (plus transparency), resulting in a maximum of 85 colors on screen, at a color display percentage of 39.4%. Lastly, games running in Mode 3 use colors consisting of 8 shade possibilities, resulting in a color space of 512. They also use 16 palettes, each holding 15 colors (plus transparency), resulting in a maximum of 241 colors on screen, at a color display percentage of 47.1%.

Mode Palettes Color Maximum Colors Color Display Indices On Screen Space Percentage 1 8 (4 * 2) 3 (4 – 1) 25 (1 + (8 * 3)) 64 (43) 39.1% 2 12 (6 * 2) 7 (8 – 1) 85 (1 + (12 * 7)) 216 (63) 39.4% 3 16 (8 * 2) 15 (16 – 1) 241 (1 + (16 * 15)) 512 (83) 47.1% Table 9.1 – List of Renegade Drive palette specifications.

In addition, each palette (and the base color) has its own red/green/blue tint values. The red, green and blue shades of all colors within a palette can each be color-added or color-subtracted in order to produce fade-in or fade-out effects on screen. (These tint values also work in sync with Mode 3’s advanced graphical effects.) As such, mid-frame palette swapping effects can be replicated on screen by utilizing different layer and sprite palettes, as well as their tint values. 120 Audio

Renegade Drive games running in Mode 1 have their audio files composed in accordance with the standards of the NES’s 2A03 sound chip. Games running in Mode 2 have their audio files composed in accordance with the standards of the

Genesis’s YM2612+SN76489 sound chips. Lastly, games running in Mode 3 have their audio files composed in accordance with the standards of the SNES’s

SPC-700 sound chip. However, there are a few exceptions. Mode 1 games only use 4 of the 5 mono channels: 2 square, 1 triangle and 1 noise, with DPCM abandoned. A lot of NES games did not use this channel, as it involved utilizing size-intense audio samples for instruments like drums. Mode 2 games only use 6 of the 10 channels: 3 stereo FM synthesis and 3 mono PSG (with one of the FM synthesis channels capable of playing sampled audio). This technically makes them sound like PC-98 games, as their audio used only 6 channels and sounded very similar to Genesis audio, despite the different number of channels used in each system. Lastly, mode 3 games use all 8 stereo channels of sampled audio.

However, the instruments used are not compressed in size, which allows them to produce higher quality audio than that of the SNES’s instruments.

Music tracks and sound effects are played at runtime via raw file formats

(WAV, OGG, M4A, etc.) for efficient playback manipulation. As such, each audio file features individual attributes such as volume, looping and pitch control.

Each one is also sampled at a rate of 44,100 Hz. In addition, music tracks and sound effects are able to play simultaneously, but only one of each at a time, with newly executed ones cancelling out those that are currently playing.

121 Input

Renegade Drive games utilize 10 inputs, regardless of their modes. These include a D-pad (Up, Down, Left & Right), four face buttons (A, B, X & Y) and two shoulder buttons (L & R). However, Mode 1 games have their gameplay focus around two face buttons (A & B), Mode 2 games have their gameplay focus around either three face buttons (A, B & Y) or two face buttons & two shoulder buttons (A, B, L & R), and Mode 3 games have their gameplay focus around all six buttons (A, B, X, Y, L & R). Games also utilize an additional 11th input (the

Start button) that performs the same menu confirmation functions as the A button, and the same gameplay pausing functions as the X button.

These inputs have default mapping configurations for keyboards, as well as Nintendo, Sony and Microsoft controllers. In addition, the four movement inputs are mapped to both the D-pad and the left analog stick on controllers

(allowing players to use whichever), but at the cost not being customizable.

Fortunately, all six buttons can be custom mapped on controllers. As for keyboards, all 10 standard inputs can be custom mapped to almost any key.

If multiple input devices are connected while a game is running, players can use whichever one they want to play with. Each input device’s mapping can be individually customized, all of which are saved into a game’s input configuration file, which is kept separate from its save data file. In addition to the game inputs are keyboard shortcut commands. These include the abilities to toggle between full-screen or native resolutions, reset the game, save screenshots of the game as PNG files, and exit out of the game.

122 Chapter 10: Renegade Drive Implementation

The previous chapter established and detailed the specifications of

Renegade Drive. This chapter now depicts the implementation of these software design limitations into abstract-level code that integrates with a modern day 2D game engine in order to develop retro-styled video games. While Renegade

Drive’s implementation into code is currently an ongoing work in progress, we will demonstrate some examples of what has already been produced: two technical demos and two small-scale video games.

GameMaker Studio

Figure 10.1 – The current GameMaker Studio logo. Credit: YoYo Games.

GameMaker Studio is a resource-based game engine that was developed and released by YoYo Games [93]. It is capable of producing 2D graphics and is designed to be user-friendly, thus allowing for rapid game development. Code for its games is written using GML – a custom programming language that was also created by YoYo Games. GameMaker Studio is the game engine that Renegade

Drive is currently being implemented within. The decision to choose GameMaker

Studio over other 2D game engines (such as Unity) was due to its projects’ resource-based organization. Scripts, shaders, graphics, audio & objects are each distinguishable and can easily be arranged via folder hierarchies. 123 Project File Structure

Figure 10.2 – A GameMaker Studio project open within the IDE. Credit: YoYo Games.

GameMaker Studio video game projects have their assets organized by folders. ‘Sprites’ consist of individual graphics, animations and collision hit- boxes. ‘Sounds’ consist of all audio files (music tracks and sound effects), as well as their playback preferences (looping, volume, etc.). ‘Backgrounds’ consists of tileset graphics and their individual properties (horizontal/vertical tile sizes, etc.).

‘Scripts’ consist of code functions that can be called upon during runtime. They can have parameters passed into them and can contain local variables, both of which in order to make their computations more efficient. ‘Shaders’ consist of code files (written in OpenGL’s GLSL shader language) that provide coloring to graphics via vertex and particle shading techniques. ‘Objects’ are the entities that exist within a running game. They contain properties, variables, function calls &

124 events, and can manifest as virtually anything – sprites, layers, audio engines, game logic, etc. ‘Rooms’ are the playfields that objects reside within. Games can only execute one room at a time, so they can be seen as the different stages or scenes within a game. Lastly, ‘Macros’ consist of a game’s constant values, which can be accessed at any point within code.

Renegade Drive manifests as a series of scripts, shaders, macros and inheritable objects that can be copy-pasted from one GameMaker Studio project to another. These include abstract layer & sprite objects, room controlling objects, audio playback objects, input handling objects, graphics & color objects, palette

& tint shaders, and helper scripts for tasks such as initializing variables, computing color math, etc. Helper scripts can be accessed from any point within code, and abstract objects can be inherited by any game specific objects. For example, when a game’s character object inherits Renegade Drive’s abstract sprite object, it is provided with all of the variables and methods needed for it to function properly at runtime. As a result, Renegade Drive resources handle all of the technical limitations within a GameMaker Studio project, while also providing a solid foundation for retro-styled video games to be developed on top of.

Tech Demos Produced Using Renegade Drive

The technical demos produced that utilize the Renegade Drive resources include a “Graphics Demo” and an “Input Demo”. The Graphics Demo showcases the sprite, layer and palette manipulation capabilities of Renegade Drive. It uses a shader to fill in sprites and layer tiles with their palettes, tints and colors (as well as to fill in the screen’s base color). It also showcases the manipulation of sprite

125 and layer tile attributes, including draw priority, pattern index, palette index, horizontal/vertical flipping and x/y offset. The Input Demo on the other hand showcases a visual feedback of the keys or buttons pressed on an input device

(keyboard, controller, etc.), as well as the handling of keyboard shortcuts.

Figure 10.3 – Screenshots from the Graphics Demo (top) and Input Demo (bottom).

126 Video Games Produced Using Renegade Drive

The small-scale video games produced that utilize the Renegade Drive resources include “Floatie’s Block Ball” and “Disco Dog Discord”. Floatie’s

Block Ball was developed in October 2016 as part of the “GB Jam 5”, an online global game jam hosted by Itch.io [94]. The game is a block-breaking puzzle game that was designed to fit within the limitations of a Game Boy game. This meant having to use a screen size of 160x144, four monochrome colors, and eight inputs at most. Fortunately, this particular video game project was made possible due to Renegade Drive, albeit with a couple of modified design values in order to accommodate the Game Boy limitations. Upon submission to the GB Jam 5, the game received a positive reception and was favorably reviewed online [95].

Figure 10.4 – Screenshot from Floatie’s Block Ball.

Disco Dog Discord on the other hand was developed in November 2016 as part of the CSUN Game Development Club’s 48-hour Game Jam for the Fall

2016 semester. The game is a mathematical logic-deducing puzzle game that takes gameplay inspirations from Minesweeper and Sudoku. It was also designed to fit within the limitations of an NES game, which meant having to use a screen size of 256x240, 25 colors total, and eight inputs at most. Just like Floatie’s Block

127 Ball, Disco Dog Discord was made possible due to Renegade Drive, albeit with a couple of modified design values in order to accommodate the NES limitations.

Upon submission to the 48-hour Game Jam, the game received a positive reception and was awarded “best gameplay”.

Figure 10.5 – Screenshot from Disco Dog Discord.

Future Renegade Drive Development

There are still many features and aspects to the Renegade Drive implementation that need to be developed and/or modified further. Some examples of these include camera scrolling & layer offset movement, file input/output functionality for reading & writing a game’s save data, and object movement & the ordering of their subsequent collision detections. With more time and effort invested into development, Renegade Drive’s implementation will soon be completed. Once finished, it will then go on to serve as the backbone to creative and ambitious new video game projects in the years ahead.

128 Conclusion

In the year 2017, the demand for retro-styled video games is at an all-time high. Consumers want to relive their nostalgic experiences from classic video games released decades ago – a desire motivated in part by modern escapism.

They yearn for the aesthetic look and feel of those games’ simplistic graphics, audio and gameplay designs. However, they also want to recreate these experiences in the form of new video games – ones that keep the same look and feel, yet deliver new content and fresh gameplay at the same time [4].

Given all of the research and development that has gone into this project, the key for Renegade Drive’s success is its ability to deliver on the demands of nostalgia-driven consumers. The video games produced that abide by its specifications satisfy the needs of its players, regardless of their intended aesthetics (mid 80s, late 80s/early 90s, mid 90s, etc.) or their genre of gameplay

(platformer, puzzle, racing, sports, etc.).

Renegade Drive’s success also comes from its efficiency as a technical resource for game designers and their retro-styled video game development projects. It serves these projects by acting as a seamless bridge between the old styles of game content creation and modern day game production pipelines, which produces quality retro-styled game development results.

But ultimately, Renegade Drive will be considered a successful project once game developers begin using it to create marketable 2D video games that deliver the same aesthetic look and feel as classic Nintendo and Sega games, but with modern day conveniences and design choices integrated into them.

129 References

[1] Wolf, Mark JP. “The Video Game Explosion: A History from PONG to

PlayStation and Beyond.” ABC-CLIO, 2008.

[2] Schilling, Melissa A. "Technological Leapfrogging: Lessons from the US

Video Game Console Industry." California Management Review 45.3 (2003): 6-

32.

[3] Kelion, Leo. “Sega v Nintendo: Sonic, Mario and the 1990’s Console War.”

BBC News (2014): http://www.bbc.com/news/technology-27373587 (Retrieved

8/27/17)

[4] Dinsdale, Ryan. “Bill Trinen Discusses Why 2D Games are Making a

Comeback.” Gamnesia (2015): http://www.gamnesia.com/news/bill-trinen- discusses-why-2d-games-are-making-a-comeback (Retrieved 8/27/17)

[5] “Nintendo Entertainment System.” Super Mario Wiki: https://www.mariowiki.com/Nintendo_Entertainment_System (Retrieved 9/16/17)

[6] “Family Computer.” Super Mario Wiki: https://www.mariowiki.com/Family_Computer (Retrieved 9/16/17)

130 [7] “Overscan.” Nesdev Wiki: https://wiki.nesdev.com/w/index.php/Overscan

(Retrieved 8/27/17)

[8] “PPU pattern tables.” Nesdev Wiki: https://wiki.nesdev.com/w/index.php/PPU_pattern_tables (Retrieved 8/27/17)

[9] “PPU nametables.” Nesdev Wiki: https://wiki.nesdev.com/w/index.php/PPU_nametables (Retrieved 8/27/17)

[10] “PPU attribute tables.” Nesdev Wiki: https://wiki.nesdev.com/w/index.php/PPU_attribute_tables (Retrieved 8/27/17)

[11] “PPU rendering.” Nesdev Wiki: https://wiki.nesdev.com/w/index.php/PPU_rendering (Retrieved 8/27/17)

[12] “PPU OAM.” Nesdev Wiki: https://wiki.nesdev.com/w/index.php/PPU_OAM (Retrieved 8/27/17)

[13] “PPU palettes.” Nesdev Wiki: https://wiki.nesdev.com/w/index.php/PPU_palettes (Retrieved 8/27/17)

[14] “APU.” Nesdev Wiki: https://wiki.nesdev.com/w/index.php/APU (Retrieved

8/27/17)

131

[15] “VRC6.” Nesdev Wiki: https://wiki.nesdev.com/w/index.php/VRC6

(Retrieved 8/27/17)

[16] “FDS audio.” Nesdev Wiki: https://wiki.nesdev.com/w/index.php/FDS_audio (Retrieved 8/27/17)

[17] “Sega Master System.” Sega Retro: http://segaretro.org/Sega_Master_System

(Retrieved 8/27/17)

[18] “Sega Mark III.” Sega Retro: http://segaretro.org/Sega_Mark_III (Retrieved

8/27/17)

[19] MacDonald, Charles. “Sega Master System VDP documentation.” SMS

Power (2002): http://www.smspower.org/uploads/Development/msvdp-

20021112.txt (Retrieved 8/30/17)

[20] “Blast processing.” Sega Retro: https://segaretro.org/Blast_processing

(Retrieved 8/30/17)

[21] “SN76489.” SMS Power: http://www.smspower.org/Development/SN76489

(Retrieved 8/30/17)

132 [22] “Control Pad (Master System).” Sega Retro: http://segaretro.org/Control_Pad_(Master_System) (Retrieved 8/30/17)

[23] “Game Boy.” Super Mario Wiki: https://www.mariowiki.com/Game_Boy

(Retrieved 8/30/17)

[24] Fayzullin, Marat, et al. “Everything You Always Wanted to Know About

GAMEBOY.” BGB: http://bgb.bircd.org/pandocs.htm (Retrieved 8/31/17)

[25] “Game Boy Pocket.” Game Boy Wiki: http://gameboy.wikia.com/wiki/Game_Boy_Pocket (Retrieved 9/11/17)

[26] “Super Game Boy.” Super Mario Wiki: https://www.mariowiki.com/Super_Game_Boy (Retrieved 9/11/17)

[27] Piepgrass, David. “Qwertie’s SNES Documentation.” Emu-Docs.org (1998): https://emu-docs.org/Super%20NES/General/snesdoc.html (Retrieved 9/11/17)

[28] Pug Hoof Gaming. “THE Super Game Boy Guide – Part 1 of 3: The Super

Game Boy – A Complete Super Game Boy Review.” YouTube (2016): https://www.youtube.com/watch?v=uaeLY441Fwc (Retrieved 9/11/17)

133 [29] “Game Boy Color.” Super Mario Wiki: https://www.mariowiki.com/Game_Boy_Color (Retrieved 9/11/17)

[30] “The Nintendo® Game Boy™, Part 1: The Intel 8080 and the Zilog Z80.”

RealBoy (2013): https://realboyemulator.wordpress.com/2013/01/01/the- nintendo-game-boy-1/ (Retrieved 9/12/17)

[31] “Sega Game Gear.” Sega Retro: http://segaretro.org/Sega_Game_Gear

(Retrieved 9/12/17)

[32] “Gear-to-Gear Cable.” Sega Retro: http://segaretro.org/Gear-to-Gear_Cable

(Retrieved 9/13/17)

[33] “Super Nintendo Entertainment System.” Super Mario Wiki: https://www.mariowiki.com/Super_Nintendo_Entertainment_System (Retrieved

9/16/17)

[34] “Backgrounds.” SNES Development: https://wiki.superfamicom.org/snes/show/Backgrounds (Retrieved 9/16/17)

[35] Oosterhout, Michiel. “Tiles.” Michielvoo GitHub: https://github.com/michielvoo/SNES/wiki/Tiles (Retrieved 9/16/17)

134 [36] Oosterhout, Michiel. “Characters.” Michielvoo GitHub: https://github.com/michielvoo/SNES/wiki/Characters (Retrieved 9/16/17)

[37] Oosterhout, Michiel. “Backgrounds” Michielvoo GitHub: https://github.com/michielvoo/SNES/wiki/Background (Retrieved 9/17/17)

[38] Oosterhout, Michiel. “Sprites.” Michielvoo GitHub: https://github.com/michielvoo/SNES/wiki/Sprites (Retrieved 9/17/17)

[39] “Sprites.” SNES Development: https://wiki.superfamicom.org/snes/show/Sprites (Retrieved 9/17/17)

[40] “Palettes.” SNES Development: https://wiki.superfamicom.org/snes/show/Palettes (Retrieved 9/17/17)

[41] “Grog’s Guide to DMA and HDMA on the SNES.” SNES Development: https://wiki.superfamicom.org/snes/show/Grog%27s+Guide+to+DMA+and+HD

MA+on+the+SNES (Retrieved 9/17/17)

[42] MacDonald, Fiona. “Humans didn’t even see the colour blue until modern times, research suggests.” ScienceAlert (2015): https://www.sciencealert.com/humans-couldn-t-even-see-the-colour-blue-until- modern-times-research-suggests (Retrieved 9/17/17)

135

[43] Korth, Martin. “Fullsnes – Nocash SNES Specs.” Nocash Funware Overview

(2012): http://problemkaputt.de/fullsnes.htm (Retrieved 9/17/17)

[44] “Registers.” SNES Development: https://wiki.superfamicom.org/snes/show/Registers (Retrieved 9/19/17)

[45] “Mode 7 – Scaling.” SNES Development: https://wiki.superfamicom.org/snes/show/Mode+7+-+Scaling (Retrieved 9/17/17)

[46] “Rendering the Screen.” SNES Development: https://wiki.superfamicom.org/snes/show/Rendering+the+Screen (Retrieved

9/18/17)

[47] Sudhakaran, Sareesh. “What are Progressive Frames, Interlaced Frames and the Field Rate?” Wolfcrow: http://wolfcrow.com/blog/understanding- terminology-progressive-frames-interlaced-frames-and-the-field-rate/ (Retrieved

9/17/17)

[48] “Transparency.” SNES Development: https://wiki.superfamicom.org/snes/show/Transparency (Retrieved 9/18/17)

136 [49] “Windows.” SNES Development: https://wiki.superfamicom.org/snes/show/Windows (Retrieved 9/19/17)

[50] “List of Super NES enhancement chips.” Revolvy: https://www.revolvy.com/main/index.php?s=List%20of%20Super%20NES%20e nhancement%20chips (Retrieved 9/19/17)

[51] “SPC700 Reference.” SNES Development: https://wiki.superfamicom.org/snes/show/SPC700+Reference (Retrieved 9/20/17)

[52] “Nintendo Music Format (N–SPC).” SNES Development: https://wiki.superfamicom.org/snes/show/Nintendo+Music+Format+%28N-

SPC%29 (Retrieved 9/20/17)

[53] Hayward, Andrew. “The Nintendo PlayStation is the coolest console never released.” TechRadar (2017): http://www.techradar.com/news/gaming/the- nintendo-playstation-is-the-coolest-console-never-released-1327988 (Retrieved

9/20/17)

[54] “PlayStation (Platform).” Giant Bomb: https://www.giantbomb.com/playstation/3045-22/ (Retrieved 9/20/17)

137 [55] “Game Boy Advance.” Super Mario Wiki: https://www.mariowiki.com/Game_Boy_Advance (Retrieved 9/20/17)

[56] “Tonc: GBA Hardware.” Coranac: https://www.coranac.com/tonc/text/hardware.htm (Retrieved 9/20/17)

[57] “8. Regular sprites.” Coranac: https://www.coranac.com/tonc/text/regobj.htm

(Retrieved 9/20/17)

[58] “9. Regular tiled backgrounds.” Coranac: https://www.coranac.com/tonc/text/regbg.htm (Retrieved 9/20/17)

[59] “5. The Bitmap modes (mode 3, 4, 5).” Coranac: https://www.coranac.com/tonc/text/bitmaps.htm (Retrieved 9/20/17)

[60] “18. Beep! GBA sound introduction.” Coranac: https://www.coranac.com/tonc/text/sndsqr.htm (Retrieved 9/20/17)

[61] “Nintendo DS.” Super Mario Wiki: https://www.mariowiki.com/Nintendo_DS (Retrieved 9/20/17)

[62] Harris, Craig. “Nintendo DS Specs.” IGN (2004): http://www.ign.com/articles/2004/09/21/nintendo-ds-specs (Retrieved 9/20/17)

138

[63] “Nintendo DS File Formats.” Romhacking.net: http://www.romhacking.net/documents/%5B469%5Dnds_formats.htm#Sounds

(Retrieved 9/20/17)

[64] “Nintendo DSi.” Super Mario Wiki: https://www.mariowiki.com/Nintendo_DSi (Retrieved 9/20/17)

[65] “Sega Mega Drive.” Sega Retro: http://segaretro.org/Sega_Mega_Drive

(Retrieved 9/20/17)

[66] “VDP.” Mega Drive Wiki: http://md.squee.co/VDP (Retrieved 9/21/17)

[67] MacDonald, Charles. “Sega Genesis VDP Documentation.” Emu-Docs.org

(2000): https://emudocs.org/Genesis/Graphics/genvdp.txt (Retrieved 9/21/17)

[68] “Lock-On Technology.” Sega Retro: http://segaretro.org/Lock-

On_Technology (Retrieved 9/23/17)

[69] “Sega Virtua Processor.” Sega Retro: http://segaretro.org/Sega_Mega_Drive_cartridges#Sega_Virtua_Processor

(Retrieved 9/23/17)

139 [70] “YM2612.” Sega Retro: http://segaretro.org/YM2612 (Retrieved 9/24/17)

[71] “SN76489.” Sega Retro: http://segaretro.org/SN76489 (Retrieved 9/24/17)

[72] “Control Pad (Mega Drive).” Sega Retro: http://segaretro.org/Control_Pad_(Mega_Drive) (Retrieved 9/24/17)

[73] “Team Player.” Sega Retro: http://segaretro.org/Team_Player (Retrieved

9/24/17)

[74] “Six Button Control Pad (Mega Drive).” Sega Retro: http://segaretro.org/Six_Button_Control_Pad_(Mega_Drive) (Retrieved 9/24/17)

[75] “Sega Mega-CD.” Sega Retro: http://segaretro.org/Sega_Mega-CD

(Retrieved 9/24/17)

[76] “History of the Sega Mega-CD.” Sega Retro: http://segaretro.org/History_of_the_Sega_Mega-CD (Retrieved 9/24/17)

[77] “Sega 32X.” Sega Retro: http://segaretro.org/Sega_32X (Retrieved 9/24/17)

[78] “History of the Sega 32X.” Sega Retro: http://segaretro.org/History_of_the_Sega_32X (Retrieved 9/24/17)

140

[79] “Sega Saturn.” Sega Retro: http://segaretro.org/Sega_Saturn (Retrieved

9/24/17)

[80] “NEC PC-9801.” Giant Bomb: https://www.giantbomb.com/nec-pc-

9801/3045-112/ (Retrieved 9/24/17)

[81] “Neo Geo (Platform).” Giant Bomb: https://www.giantbomb.com/neogeo/3045-25/ (Retrieved 9/24/17)

[82] “YM2203 FM Operator Type-N (OPN).” Edward D-Tech: http://www.dtech.lv/files_ym/ym2203.pdf (Retrieved 9/24/17)

[83] Nemesis. “YM2608 OPNA Application Manual.” Hacking Cult (2008): http://nemesis.hacking- cult.org/MegaDrive/Documentation/YM2608J%20Translated.PDF (Retrieved

9/24/17)

[84] “YM2610 Datasheet.” Edward D-Tech: http://www.dtech.lv/files_ym/ym2610.pdf (Retrieved 9/24/17)

[85] “Colors.” NeoGeo Development Wiki: https://wiki.neogeodev.org/index.php?title=Colors (Retrieved 9/24/17)

141

[86] Neagu, Codrut. “Screen resolution? Aspect ratio? What do 720p, 1080p,

QHD, 4K and 8K mean?” Digital Citizen (2016): http://www.digitalcitizen.life/what-screen-resolution-or-aspect-ratio-what-do-

720p-1080i-1080p-mean (Retrieved 9/3/17)

[87] Narcisse, Evan. “Goodbye, “Start” Button. We’ll Miss You.” Kotaku (2013): http://kotaku.com/goodbye-start-button-well-miss-you-1469942492 (Retrieved

9/3/17)

[88] “Shovel Knight: Shovel of Hope Press Kit.” Yacht Club Games (2014): http://yachtclubgames.com/shovel-knight-of-hope-press-kit/ (Retrieved 9/3/17)

[89] D’Angelo, David. “Breaking the NES for Shovel Knight.” Gamasutra

(2014): http://www.gamasutra.com/blogs/DavidDAngelo/20140625/219383/Breaking_the

_NES_for_Shovel_Knight.php (Retrieved 9/3/17)

[90] Williams, Mike. “Talking Shop: Shovel Knight’s Pixel Artist.”

GamesIndustry.biz (2013): http://www.gamesindustry.biz/articles/2013-04-10- talking-shop-shovel-knights-pixel-artist (Retrieved 9/3/17)

142 [91] Yacht Club Games Twitter (2013): https://twitter.com/yachtclubgames/status/321086757150027778 (Retrieved

9/4/17)

[92] “Recommended Controllers.” Yacht Club Games (2014): http://yachtclubgames.com/controllers/ (Retrieved 9/4/17)

[93] Grubb, Jeff. “GameMaker Studio creators look back at 17 years of development.” Venture Beat (2017): https://venturebeat.com/2017/09/03/gamemaker-studio-creators-look-back-at-17- years-of-development/ (Retrieved 9/4/17)

[94] “GB Jam 5.” Itch.io (2016): https://itch.io/jam/gbjam-5 (Retrieved 9/6/17)

[95] Hadley, Jupiter. “Juni Plays Indie Games: ALL THE INDIE GAMES [GB

Jam 5] [Part 14]” YouTube (2016): https://www.youtube.com/watch?v=22CUmMthbu8 (Retrieved 9/6/17)

143