5
\$\begingroup\$

I am not a game dev here but have a few queries. I was recently playing a game called "The messenger" where you move from 8bit to 16bit when travelling through time. So whenever we are in future the graphics and the sound turned to 16 bit and in the present the graphics were 8bit.

Now my query is regarding the 8bit/16bit sound and graphics? What do they exactly mean?

I read about the canvas size when making a pixel art game tends to be 8*8/16*16/32*32/64*64 which directly means the number of pixels in a sprite, so if there are more pixels we can have more detailed sprites and animations.

For music, I read that it represents the number of instrument choices that you have when creating music.

Do you consider these explanations to be correct?

\$\endgroup\$
4
\$\begingroup\$

When people talk about 8bit graphic and sound vs. 16bit graphics and sound in the context of retro-game aesthetics, then they often talk about the graphic and sound capabilities of gaming consoles and PCs of the 8bit generation vs. those of the 16bit generation.

The main contenders of the 8bit generation were the Sega Master System and the Nintendo Entertainment System (NES). The 16bit generation were the Sega Mega Drive (Sega Genesis in North America) and the Nintendo Super-NES.

The hardware capabilities of those consoles were different, so there is no clear-cut definition of 8bit or 16bit. But in contrary to the answer by DHarding they did not support full 8bit or 16 bit color depth. The hardware of that time only offered a reduced color palette. Further, developers had to choose a limited palette of those visible on the screen at once and an even smaller palette per unique spirite.

Conosle Colors Colors per screen Colors per sprite
NES 54 25 4
Master System 64 32 16
SNES 32768 256 16
Mega Drive 512 61 16

These palette restrictions were a main driver behind the visual aesthetics of the games of that time. They resulted in typical stylistic choices of that time:

  • Environments using a single dominant color, because complimentary colors would have used up too many of the colors per screen.
  • Or alternatively, environments which were more colorful, but with a lot of "flat" colors and little shading.
  • Sprites with even more limited color palettes.
  • Palette swapping. Some of these systems were able to switch out palettes of sprites on the fly. This didn't just allow to reuse sprites for different game entities by simply changing their color. It also allowed to create some neat (for that time) animation effects based on color-cycling without requiring to add the sprite data for all animation phases.
  • Dithering to mix colors and to do brightness gradients (which actually looked a lot better on old CRT TVs than it looks on modern LED screens).

The screen resolutions of those consoles were actually all the same: 256 x 240 in Europe and 256x224 in North-America. Why? Because that was the resolution of TV sets of that time. It just wouldn't have been possible to go higher without requiring to sell a dedicated monitor with the gaming system. Yet modern retro-games aiming for a 16bit aesthetic often tend to use higher resolutions than those aiming for an 8bit aesthetic.

When it comes to audio capabilities it becomes even more confusing than with graphics, due to the very different ways the consoles of that time created sound. But in general the consoles only had very limited capabilities for playing pre-recorded digital audio (like all the sound you hear in games of today). There just wasn't enough storage space for that. They instead synthesized music and sound effects right on the device. They usually had a limited number of oscillators on board with a limited number of settings. The technical details of synthesizers are not my area of expertise, but you can definitely hear the difference in audio between the two generations. The 8bit generation was a lot more dominated by beeps and buzzes, while the 16bit generation could produce sounds which sort of sounded like modern synths, occasionally even real instruments and a few games even managed to get halfway decent voice samples out of that hardware.

Music produced today under the restrictions of 8bit and 16bit hardware is often called "chiptune". But you don't need to use old audio hardware for making chiptune music, because modern digital audio workstations are capable of replicating those sounds pretty faithfully.

\$\endgroup\$
3
  • \$\begingroup\$ Can you link to a source for the table of colour values for the different consoles? It might be handy for folks who want to read more on the topic. \$\endgroup\$
    – DMGregory
    Aug 12 '21 at 12:47
  • 1
    \$\begingroup\$ @DMGregory I took all of that information from the respective Wikipedia articles on those consoles. I added the links to the table. \$\endgroup\$
    – Philipp
    Aug 12 '21 at 13:00
  • \$\begingroup\$ Because that was the resolution of TV sets of that time. More specifically, it’s half the “vertical resolution” of NTSC/PAL as to avoid dealing with interlacing. The horizontal resolution was 256 because it’s a nice round number (for programmers); Analog television doesn’t have a concept of “horizontal resolution”. \$\endgroup\$
    – Cole Tobin
    Aug 18 '21 at 21:36
0
\$\begingroup\$

I agree that the developer is referring to storage classes. Wider (more bits in the storage class) storage class’s make it possible to store larger objects or finer detail.

In the example below I use a wave file format to represent the storage class. I am much more familiar with rendering graphics (Video) but have a sound class in my game as well. It plays wave files that I pass to it without regard to fidelity. I give an example from that class below.

In general, 8Bit and 16Bit represent storage classes such as the following BYTE is 8Bit = 2^8 or 256 colors WORD is 16Bit = 2^16 or 65,536 colors

If what you are saying is correct about transitioning to a higher number of bits as the game progresses, then the developer is rendering graphics (or can) with a higher number of colors (also called higher resolution).

For example, the initial storage class would be BYTE then transition to WORD. I would not code this way in practice however, since a WORD is two BYTEs, and I could code 1 BYTE of storage in a WORD and then later store a full word. This would be simpler and would not require changing the underlying storage class for an object.

With regard to sounds, I will leave an example of a storage class that I use in practice. The PCMWAVEFORMAT to represent a wave object, which is represented by the following data structure. Again, here you can see the usage of the WORD to buffer sound, were a WORD is 2 BYTES

typedef struct pcmwaveformat_tag { WAVEFORMAT wf; WORD wBitsPerSample; } PCMWAVEFORMAT, *PPCMWAVEFORMAT, *NPPCMWAVEFORMAT, *LPPCMWAVEFORMAT;

A little research on these storage classes would help to clarify this final example.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ The question author wrote that they are "not a game dev". I doubt that they can understand the second half of this answer. \$\endgroup\$
    – Philipp
    Aug 12 '21 at 10:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .