What are the limitations of retro consoles? [closed]

Question

I'm interested in creating a retro look for a game, and I'm currently in the process of deciding just how retro (which generation/console). What would make it easier would be if there was some sort of wiki/document on the limitations of each console, such as maximum number of colours total, maximum per sprite, number of layers, max tiles, max tile size, sprite size, etc., etc.. Take the Game Boy for example. 4 colours, yes, and I can find the screen resolution too. But what about all the other limitations?

So if anyone knows any good resources, it would be a huge help. I find that the freedom that today's generation of computers and consoles provides is a little too much, in that I can just keep adding more and more to it, and I'll never finish. I'd love to set a limit, and do the best I can within that limit.

Answer 1

Most of these details are implicit in the hardware specifications for the consoles and the design of their hardware interaction APIs. This information is typically available in the programming guides for the relevant consoles, however those guides are under NDA and the closest you will be able to get is through documentation made available by reverse-engineering (itself a bit of a legal grey area) -- these discuss things like RAM bank count and size, the latency involved in bank-switching and when you can do it (for example, during a vertical retrace blank or not), et cetera.

Fortunately the limitations you seem to be after are some of the more obvious, graphics-related ones. For example, a common limitation of early consoles like the GameBoy and NES was that they supported a fixed (small) number of sprites per line -- the hardware would only blit so many, and if you had too many they just vanished. This would manifest itself as "flickering" of some sprites on the screen when the game view got crowded.

Some of the few resources available include the NESDev wiki, this article on sprites on Wikipedia (which includes statistics on the various capabilities of older hardware-based sprite systems like the GameBoy, NES, et cetera).

Answer 2

Consoles usually has a lot of different modes, for example the DS can have 4 colours, 16 or 256 (maybe even 16-bits, I don't remember). Those were used because of cartridge memory footprint (a smaller game costed less to fabricate), of blit speed and memory footprint.

There were also a lot of techniques like the scanline interrupt, to overcome those limitations (number of sprites included).

As it seems you want to go for looks, just check out graphics from old games and pick your choice, then check resolution and colour depth of that particular game and go for it.

Answer 3

Using the SNES as an example:

8x8 or 16x16 pixel tiles are limited to 16 colors each. The colors may come from one of eight palettes. The tilemaps, containing these tiles, are limited to either 256x256, 512x256, or 256x512 pixels. Within the tilemap, you can use the same tile with a different palette. There was also support for 2 or 4 color background layers to reduce the memory used by the tiles.

The SNES had up to four tilemap layers, depending on the graphics mode used. The display order of the tilemap could be controlled in software.

Sprites are limited to power of two combinations from 8x8 to 64x64. (ie 8x8, 8x16, 32x64 64x64, etc.). Each sprite is limited to 16 colors from a separate set of eight palettes.

One of the neat features of the SNES (and many other 16 bit consoles), is the ability to change display properties per scanline. The background color could be changed, or the tilemap scrolled left or right on each scanline. This is used to create a gradient sky without violating the 16 color limit, or create a wavy image.

I applied the above limitations to my MIT licensed Super Play game engine.