A bitmap is the term for how computers see a picture. It's a grid of squares of various colors, used like a mosaic to form an image. Just open up any picture in an editing program, and zoom it past 4x size, and you'll see the squares.
Of course that's just the form of it. The picture file, whether it be jpeg, bmp, gif, png, etc., has to remember the color for each square in each position. This can actually take a lot of memory if it's not compressed. In an uncompressed picture file, the size is the total number of squares times the color depth. Let's say you have a picture with a resolution of 100x100, and a color depth of 1 byte. We'll get to color depth in a moment, but here we have 10,000 squares times 1, so that picture file will take up just over 10 kilobytes. That's not much, but that's just one picture. Video games have a hell of a lot more. Just 100 such pictures at once would take up 1 megabyte, the entire amount of Video RAM on the Playstation. That wouldn't even allow room for the frame buffer.
Before we discuss how that is handled, let's look at color depth. This is how many different colors a picture can have. It's just the same as having a box with 16 different colored crayons, 64 different crayons, or 100 different crayons. More colors mean more detail. The number of colors depends on how many bits per square, one color per bit combination. Thus a 1 bit color depth is just two colors (usually black and white). An 8 bit color depth is 256, and a 24 bit color depth has just over 16 million colors. But since the bit size matters, not the total colors, a 24 bit picture is just 3 times larger than an 8 bit one.
But just that increase enough can matter with games, since again a lot of pictures are handled at once. Having all the pictures be 24 bit, means only a third as many can fit as 8 bit pictures.
Without compression, it's a matter of carefully choosing between space and detail. With compression, there is a lot more leeway. The most common form of compression is to drop data for squares the same color as another. So if you have 100 brick red squares, the file will just count one (but put the others back when the file is visualized).
With "lossless" compression, only the exact same duplicates are dropped, to preserve every last detail. That is how png and gif files work. This works with pictures with smaller color depth, since there likely to be more exact duplicates to drop.
With "lossy" compression, they don't have to be exact, but it does mean the exact color is lost, and detail isn't as fine. But with higher color depth files, it's the best way to get the picture to a reasonable size. If you were wondering what a jpg (or jpeg, which is the same thing) is, it's a lossy compression format.
Now how does this relate to video game graphics? Virtually everything visual on a computer is a picture of some form. Either it's stored as a file and made visible by a program, or it's created from the program itself (known as rendering). Even the letters in this text are pictures rendered by your web browser. So it is with video games. Every sprite is a picture. Every texture in 3D graphics is a picture. So they all follow the same size and detail rules of all other picture files.
Pre-3D, most console and some computer systems had a set of hardware-based sprites. The system had a fixed number of available sprites, and those sprites had a fixed size. The relative abilities of 2D consoles was often tied to how many hardware sprites it could generate. More, bigger sprites generally meant games more visually close to their arcade counterparts. Often, hardware sprites are capable of being re-assigned as the console generates a picture on screen from top to bottom via a process called sprite multiplexing.
Now it should be noted that polygons are not pictures. Technically, they are invisible (usually). It's the pictures wrapped around the polygons that are visible. These are known as textures.
How this relates to sprite-based graphics is pretty simple. Since every object is a picture, the game developers have to figure out where to place each picture for any situation. Let's take the sprite for the player character. Technically, the character's sprite is a whole series of pictures that are shown one at a time to create animation. But they have to be loaded in the RAM all at once, in order to accommodate all the actions and reactions. Room naturally has to be made for the sprites for the area and the enemies.
The size of the area, and the number of enemies, affects how much detail the player character will have. If you have a game like Castlevania, the detail of Simon Belmont is pretty low. Since you have large areas with a lot of enemies, each enemy is not that detailed. If the game is Street Fighter II, you just have two characters, and a background barely two screens wide (anyone in the background is just part of that picture). So you have tons of detail in all of those.
When it comes to 3D graphics, it's a lot more complicated. You not only have textures over the polygon objects, but shading and mapping to add further depth to the textures, and effects like shadows and lighting.
Those will be covered in their own pages.
