Difference between revisions of "GBC dual compatibility"

Revision as of 11:24, 12 May 2019

A Game Boy Color game can be designed as GBC-exclusive or as dual compatible. Dual compatible games will run on the monochrome Game Boy or Game Boy pocket system or Super Game Boy accessory. In some cases, making a game GBC-exclusive is justified. Other times, it may be perceived as unnecessarily limiting one's audience. Here are tips for deciding whether you actually need to go GBC-exclusive, and if not, how best to accommodate monochrome users.

Distinguishing species

Some game genres, particularly block puzzles, traditionally use colors to distinguish different object species, and one might encounter difficulty translating these genres to DMG. Objects that are 16x16 pixels can be drawn with different textures, but it took artists a while to figure out how to make that practical for objects smaller than that. A lot of games, such as Wario's Woods, even skipped the DMG because of the large number of species that needed to be distinguished.

Later on, however, artists figured how to squeeze distinctive outlines and textures into 8x8-pixel cells. Look at the difference from Puyo Puyo to Puyo Puyo Tsuu on Game Boy or from Puyo Puyo Tsuu on Sega Saturn to Puyo Puyo Tetris on Nintendo Switch.

Using shading and texture if at all possible also improves accessibility to the 8 percent of male gamers who are color blind. But make sure to keep the textured option available in GBC mode.

Computing

Software 3D rendering isn't too practical on GBC, but it's even less practical on monochrome with its slow CPU. DMG might be limited to the slow rendering and detail-free geometry of something like Faceball 2000. There may be other situations where double speed is needed to pull off a particular effect. But in other cases, don't feel tempted to throw more hardware at it just for, say, the convenience of using C instead of assembly language.

Work RAM

A game that requires 9K to 15K of work RAM could be made dual compatible if it is long enough to need SRAM for saving. Super Mario Land 2 and Wario Land^{[RAM map]} use most of save RAM as work RAM, leaving only a fraction for three saved campaigns.

But if a game inherently requires 16K or more work RAM, such as µCity, RAM requirements alone are a good excuse to make it GBC-exclusive. This is a city simulator played on a comparatively huge game board, all of which has to be saved to SRAM between play sessions. If ported to DMG, it might need to use 32K for the saved city and another 32K for the working copy, and SRAM chips larger than 32K aren't common.

Tile count

A game that loads 256 sprite tiles at once can load 512 background tiles on GBC but only 128 on DMG. So a game may have to include two background graphics styles in the ROM: one for color and a much simpler one for monochrome to let the sprites show through on a low-contrast STN screen.

You might be able to extend a scrolling game's tile count a little by swapping out tiles as the camera moves through the level, as in Gargoyle's Quest on GB or Haunted: Halloween '85 on NES. Or take advantage of the fact that the sprite unit can never display more than 80 distinct tiles at once and swap cels into the first 128 tiles of CHR RAM, using the other 48 for double buffering or even speculative loading. If you use an autotiler, or a map loading algorithm that changes tiles at the borders of structures based on adjacent tiles, you can have it generate simpler borders on DMG.

Frame rate

A game that runs at 60 fps on GBC may have to run at 30 fps on DMG to compensate for the slower CPU, lack of DMA to VRAM, and the slow STN screen. However, don't go too low because it'll look bad on Super Game Boy. In addition, if you run at 30 fps by moving everything twice as far each frame, make sure that characters can still make jumps at both time steps.