How Oldschool Graphics Worked

I thought this was pretty cool The guys that coded those old games we loved were really talented and had to hang around the hardware pretty much the whole time.

https://youtu.be/Tfh0ytz8S0k

 

Ahh, I remember making graphics on graph paper. That's not how I remember it though.

Let me think, for an 8X8 tile we had columns numbered 1 2 4 8...128, umm left to right I think.
So like this;
128 64 32 16 8 4 2 1
0 0 0 0 0 0 0 0 - 1
0 0 0 0 0 0 0 0 - 2
0 0 0 0 0 0 0 0 - 3
0 1 1 1 1 1 1 0 - 4
0 0 0 0 0 0 0 0 - 5
0 0 0 0 0 0 0 0 - 6
0 0 0 0 0 0 0 0 - 7
0 0 0 0 0 0 0 0 - 8

Each row in a tile is 8 bits or 1 byte, so with 8 rows, each tile is 8 bytes or 8 pokes into your memory.
Your pokes are in decimal values 0 to 255, so in row 4 we add up the column values (64,32,16,8,4,2) makes 126.
So to put that in memory address 51234, the command is poke 51234,126

 

I watched the whole thing like the day it was posted and found it interesting. I watched it again And am not understanding one part.

How does dividing the screen into cells allow for more colors than black and white in the background/foreground dynamics?

 

Memory and 8 bit limitations. As I said before, each cell or tile or character (whatever you want to call them) are 8 bytes or 8 rows or 8 bits.
For single color mode, a bit is on or off, 1 or 0. You could look at it as two colors, zero is background and one is the character graphic.

For multi color mode, you are allowed 3 colors plus the background. As mentioned in the video, your sacrifice half your resolution for the extra colors. How this works is in the binary. Each row of 8 pixels is still 8 bits but pixels are paired horizontally so it's really like you only have 4 pixels to draw with. The binary for multi-color needs to use two bits instead of one.

The binary values for the 3 colors + background are:
00 - background
01 - color 1
10 - color 2 (there are only 10 types of people, those who understand binary and those who don't)
11 - color 3

An 8 bit row of 4 colors:
00112233 (numbers represent colors not binary)
00011011 (actual binary code)
27 decimal value of the memory byte.

 

I am referring to the cells that can be only 2 colors per cell, what he refers to as "color cells", such as what is displayed in the artwork of the house, not multi color mode.

I'm not following how by breaking the screen into cells it allows for colors other than black and white, I'll assume it resides in the binary though.

 

Oh, there is a bitmap background color mode where you assign BG colors tile by tile over the screen. Where zero is always your BG color in the graphical data, but depending on the screen location, that BG color is different.

 

tbh im not sure exactly. all the different systems have their own quirky way. I know the NES used a 6502 variant CPU but it still wouldnt be much like C64 because the rest of the hardware is different (in particular the PPU which generates CPU interrupts and also has its own address space that more of less dictates how and when code has to run). Theres no operating system to abstract the hardware, so programming it was very bare metal.

I know that the NES used palette tables, and many effects were implemented by modifying the pallete rather than the sprites. In Legend of Zelda when you get the (i think red ring) and it turns links outfit red some other things in the game change color too.

some number of bits representing a pixel in the sprite would be used as an offset to a pointer into the palette table and the value at that location in memory would be seen. If you change the values in the palette table you can get more colors, but you can still only have the same number of colors per sprite at one time. games could use some very hackish tricks though im sure to make it seem like these limitations had been circumvented by twiddling bits at precise times.

never tried programming a NES but if I did I think I'd be happy if I could just get a dot drawn on the screen that you could move around with the controller ...

 

Yes, lots of tricks needed to be implemented to get more colors on the screen or certain areas. 64 used shared pallets. Back to the multicolor mode, I think colors 1 and 2 were common among all characters or sprites and color 3 was unique while BG color zero is controlled completely differently. Lots of 64 and NES games had a very monochromatic look to them when they wanted to use up the limited pallet for shade coloring. Then there were crafty programmers who could code the graphic tiles and color pallets to swap very quickly generating the illusion of more colors than were possible. Same as swapping sprites to get more animated characters on the screen. Many 64 and NES games will have chunks of sprites disappearing when there is too much activity.

 

Ya games were quite awesome then for sure!!