
How “oldschool” graphics worked [video] - brk
https://www.youtube.com/watch?v=Tfh0ytz8S0k&feature=youtu.be
======
raldi
In the Legend of Zelda, the envirvonment's color rules were even more strict:
You could use one palette for _all_ the tiles at the screen's edge or one tile
away, and a second palette for _all_ the tiles in the middle.

That's the reason, if you zoom in on the water in this screenshot, you'll see
that the edge of the lake has brown sparkles, and the inner lake has green
ones:

[https://skoce.files.wordpress.com/2011/03/legendzelda-35.png](https://skoce.files.wordpress.com/2011/03/legendzelda-35.png)

~~~
Drakim
Note though, that this extra restriction isn't a technical limitation of the
NES, rather, it's a choice by the developers of Legend of Zelda for the
purpose of shrinking the amount of bytes needed for each "screen" of the
world.

By doing this, you only needed to store 2 palettes per "screen", rather than
16 tiles x 11 tiles = 176 palettes per "screen".

~~~
geon
A clever hack! It exploits the tendency of each screen to have impassable
obstacles (rocks, trees, walls) around the 4 edges of the screen, with
optional openings. By using a separate palette for the middle area, the screen
as a whole looks more colorful.

------
sp332
I've always had a lot of respect for Woz's color hack on the Apple, which will
apparently be covered in a later part. But I didn't see IBM PC hacks on the
list, so here's an overview of old & new tricks to get colors out of an old
CGA card. [http://8088mph.blogspot.com/2015/04/cga-in-1024-colors-
new-m...](http://8088mph.blogspot.com/2015/04/cga-in-1024-colors-new-mode-
illustrated.html)

~~~
acomjean
Apple //e graphics were weird from what I remember.

Highres (hgr) 7 colors though 2 whites, 2 blacks purple, green, blue and
orange. Certain colors next to each other caused weirdness I think thats why 2
black/white colors.

You could dump the video memory to disk though and load it back. Kind of like
a modern screenshot with no compression. the disks couldn't hold a lot of
images though made young me frustrated trying to make a graphical adventure. I
did a maze game with the 16 color low res graphics..

You could directly manipulate the graphics with the poke command (push values
into memory).

"call 62454" inexplicable changed the whole screen to the current color. You
could have fun with a loop though the 7 colors.

good times

~~~
ddingus
Yep. There were two whites and two blacks due to the pixel shift triggered by
the high bit of the screen memory byte.

Unlike most every other machine, the Apple 8 bit computers offered 7 pixels
per byte, with the high order bit shifting those just a little bit.

That shift presented the two sets of colors.

At the pixel clock of the Apple, artifacting basically offered a 4 color
display. Two pixels on = white, two pixels off = black, and 01, 10 patterns
were color.

With the pixel shift, the Apple 8 bit computers offered up a 6 color display.
While the two blacks and whites seem redundant, they are actually necessary to
get bit patterns lined up precisely, or to avoid additional color artifacts
along some image boundaries.

~~~
rbanffy
And thus the Apple II is the only computer that was ever capable of shifting
something half-a-pixel to the left.

Note: The Apple /// could probably do that too.

~~~
ddingus
I think it could.

That little shift ended up being double high resolution in the later //e
machines.

:)

Apple video is a total hack through and through.

------
Avshalom
As a companion piece I recommend Fuck the Super Game Boy
[http://loveconquersallgam.es/post/2350461718/fuck-the-
super-...](http://loveconquersallgam.es/post/2350461718/fuck-the-super-game-
boy-introduction)

~~~
cokernel
I thought this was certainly interesting as a companion piece (for a decidedly
different era of graphics). I can't know this for sure, but I suspect a brief
summary of the article -- in particular, an indication that it's not merely
lambasting the Super Game Boy -- would have been helpful for folks who were
turned off by the article's title.

~~~
coldpie
Yes, the title is extremely unfortunate for such an interesting piece of
technical history :(

------
tcas
Very cool, undersampling of color still exists in modern codecs, if you see
something like YUV420 that means there's 2 chroma (color) pixels for every 4
luminance (brightness) pixels:

[http://i.stack.imgur.com/U7hxZ.png](http://i.stack.imgur.com/U7hxZ.png)

Since our eyes are more preceptive to detail rather than absolute color, you
can lower your bitrate without perceived video quality.

~~~
gilgoomesh
A lot of these "rules" with color use some broad generalizations. When you
work with video compression a lot, you start training yourself to see color
differently and the illusions begin to fall apart.

For me: I really don't enjoy looking at 4:2:0 or 4:1:1 chroma subsampling
(4:2:2 usually doesn't cause problems)

4:2:0 sort of works for live scenes which don't typically have sharp chroma
boundaries but when you see solid red/blue graphics superimposed over a scene,
the blocky bleed of color across the scene is like knives in my eyes.

~~~
theandrewbailey
> but when you see solid red/blue graphics superimposed over a scene, the
> blocky bleed of color across the scene is like knives in my eyes.

I still wonder why that happens to red, mostly because it looks like someone's
bleeding everywhere. I don't seem to notice it for green or blue. At first I
thought it was the downsampling, but it has to be something else (a
combination, maybe?), since JPEG seems to handle downsampled red comparatively
better when highly compressed. Right now, I just think it's a flaw in H.264,
it's encoders and/or decoders.

~~~
gilgoomesh
Bleed definitely happens with blue too but since solid blue chrominance is
less common in graphics (graphics tend to use brighter sky/azure/royal blue)
whereas solid red is quite common.

But bleed won't happen with green because green is basically the luminance
channel in YCbCr/YUV. This means that green runs at full sample resolution
compared to red and blue which run at 50% to 25% resolution (depending on
subsampling).

------
bbarn
This guy's videos are great. Just got sucked into a youtube hole for an hour.

~~~
petercooper
Not the same era but if you like that, you might also love this dude:
[https://www.youtube.com/watch?v=HQYsFshbkYw](https://www.youtube.com/watch?v=HQYsFshbkYw)

------
famousactress
Total tangent but the color cells reminded me of Fair Isle knitting, in which
some of the most colorful knitted sweaters you've likely seen are done using
only two colors on any given row.
[https://en.wikipedia.org/wiki/Fair_Isle_(technique)](https://en.wikipedia.org/wiki/Fair_Isle_\(technique\))

------
cromwellian
Wow, I love this. The graph-paper sprite design thing brought back a flood of
memories from the mid 80s, as that's exactly how I learned to make sprites.

~~~
brk
Me too :)

I remember programming custom characters into my 9-pin IBM ProPrinter so that
I could print certain logos and symbols directly as characters. It was the
same layout on graph paper and convert to binary format. I think that was how
I was first introduced to binary in general.

------
richardjdare
It's interesting how the colour palettes of those old computers went a long
way to define their character. I was an Amstrad CPC owner, and its games
tended to have a bright, saturated look whereas C64 games always looked a bit
brown and washed-out to me[1]. Later on, as an Amiga owner I was always a
little jealous of the SNES for the quality of its colours.

It would be cool to see a video on Amiga graphics and the crazy things you can
do with bitplanes and copper lists.

[1] check out these shots of Trantor on different 8bit platforms. You can tell
straight away which one is CPC or C64
([http://frgcb.blogspot.co.uk/2014/09/trantor-last-
stormtroope...](http://frgcb.blogspot.co.uk/2014/09/trantor-last-stormtrooper-
go-1987.html))

------
nogridbag
Great video. Is there any reason why the color cells had to be split into an
even grid? It seems like if the API allowed the software developers to define
custom grids on the fly (perhaps with different scenes or levels), it would
open up lots of creativity (though I suppose that would also use some memory).

~~~
egypturnash
The c64's default video mode was a 40x24 grid of 8x8 monospaced text
characters. The video chip was designed around this: each scanline it would
look at the characters occupying the current row, then use that plus how many
times it'd displayed that row as an index into the 1k of character ROM to pull
out the appropriate byte, and display its individual bits as pixels.

You could also tell the video chip to look somewhere in RAM for these
character definitions. Maybe just to replace the standard font with something
cooler; maybe some of your font would contain little 8x8 building blocks you
could use to make bigger images. Most games would build their backgrounds this
way - you'd only have so much variation available, but you also only had to
move about 900 bytes around to scroll the screen, rather than 8k. Which sounds
like nothing to a modern machine but was a serious difference for a 1mhz
computer.

The bitmap mode jiggled with this a little, and ignored the 'look at the
characters on this row' part in favor of just stepping through an 8k chunk of
RAM over the course of the display. (Well, the multicolor bitmap mode looked
at the characters in the row as well, but used them for color data rather than
an index to the character map.)

If you want to know about this in more detail then try firing up a c64
emulator and going through the 'graphics' chapter of the c64 Programmer's
Reference Guide:
[http://www.commodore.ca/manuals/c64_programmers_reference/c6...](http://www.commodore.ca/manuals/c64_programmers_reference/c64-programmers_reference_guide-03-programming_graphics.pdf)

I'm not sure the acronym "API" even existed at this point in time. I sure
never heard it when I was fooling around with 6502 assembly.

tl;dr: severely limited hardware, programmed right on the bare metal. API?
What's that?

~~~
panic
_The video chip was designed around this: each scanline it would look at the
characters occupying the current row, then use that plus how many times it 'd
displayed that row as an index into the 1k of character ROM to pull out the
appropriate byte, and display its individual bits as pixels._

The C64 reads the current characters every 8 scanlines, not each scanline
(well, you can get it to read on arbitrary scanlines by manipulating the
vertical scroll register, but that's beside the point here). Due to the way
the C64's data bus works, the main processor has to stop executing
instructions while the graphics chip reads the character data.

You have to account for this if you're trying to synchronize code to
particular scanlines -- on the scanlines where character data is read, you'll
only get 23 cycles instead of the usual 63 (on a PAL machine, at least). For
even more info, see [http://www.zimmers.net/cbmpics/cbm/c64/vic-
ii.txt](http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt)

~~~
egypturnash
Yeah, I should have been more clear on that. I didn't feel like explaining the
care and feeding of badlines. _grin_

------
dizzyviolet
Ha. This took me back to being 8 years old again. My mom loved/hated the fact
that her kids had graph paper ALL OVER the house because we were building
sprites for games on the C64.

Boy, assembly was a bitch at first.

------
kzhahou
Wonderful production value and nice presentation. Looking forward to more of
these.

------
CSMastermind
It's worth noting that when he says the NES had a limit of 64 sprites the
limit is 64 per screen not 64 total. Each being 8x8 pixels in size. There was
another limitation though, you could only have 8 sprites displayed on the same
horizontal line (scanline). Games got around this by "flickering" the sprites
so it would appear that more were displayed at once.﻿

------
mozumder
One thing about computer graphics is that full color didn't really exist for
the average computer until the mid 90's. During the 80's, full color 24-bit
graphics were strictly the domain of workstations and high-end Macs with
24-bit graphics cards.

The average computer couldn't display a proper 24-bit photo until about when
Windows 95 came out...

------
snake_plissken
Wow that was a pretty cool video. I have a lot of respect and admiration for
the guys and gals who worked on these things back in the day.

But I am lost on the math part about the color cells. Why does each color cell
only need 1 byte? If each cell is 8 bits wide and 8 bits deep, wouldn't that
be 8 bytes?

~~~
kragen
You need one byte for the colors (4 bits to specify each of foreground and
background) and 8 bytes for the on/off; if you have 1000 cells, then you need
9000 bytes in total.

Another common thing to do, especially on machines just a little bit earlier,
was to use one byte for the colors, one byte for a glyph identifier, and then
put the 8 bytes per glyph somewhere else, maybe ROM, which was way cheaper
than RAM. You could only have 256 distinct glyphs on the screen at a time, and
maybe you couldn't even reprogram them, but you could do quite a bit of useful
graphics inside those constraints. Text especially, obviously. And you could
do it with a lot less memory.

Nonprogrammable fonts were mostly just idiocy, because a quad-input NAND gate
would have been sufficient to distinguish a 16-glyph RAM area from the ROM,
and 128 bytes of RAM would have been sufficient for 16 8×8 glyphs; also, 5×8
glyphs were actually pretty common at the time. In the VT-52 and ADM-3A era,
you had a good excuse; by the time of the VT-100 and H-19, it was just dumb.
For better or worse, the less-idiotic Apple and Commodore mostly swept those
pointlessly-crippled devices aside.

------
ErikRogneby
I hardly ever subscribe to youtube channels, but I clicked it as soon as I
finished watching part one.

------
profinger
This was very awesome!! Thank you!

------
huuu
Very cool! I wonder if the rise of isometric games have something to do with
the pixel down scaling. Isometric games do make use of the 'horizontal
pixels'.

------
userbinator
This is very similar to some of the tricks used in text mode[1] to give
"pseudographics". You can basically view each grid square as a character
position, and the definition of the tiles as a font.

[1] [https://en.wikipedia.org/wiki/VGA-
compatible_text_mode#Fonts](https://en.wikipedia.org/wiki/VGA-
compatible_text_mode#Fonts)

------
mhd
I really need to play around with some of the more bizarre graphics hardware
systems, as my junior nerd years were more D&D-centered than fiddling around
with my C64, and compared to weird 8-bit systems, forcing the VGA card to
switch to planar mode seems positively pedestrian...

------
romaniv
I wish modern computers had some reasonably efficient APIs for doing pixel-
level screen buffer stuff in a straightforward way. Without using pixel
shaders on polygons and other hacks.

~~~
zenojevski
Why not Canvas?

~~~
romaniv
Canvas does exactly what I'm talking about, but for my purposes I would prefer
something that works outside of a browser.

------
ddingus
This is well produced and fun to watch. Great memories, thank you.

------
abhishek44
Now this just shows complexity of Metal Slug, mortal combat trilogy and SF :)

------
shmerl
Pretty good overview! Thanks for posting.

------
jimmaswell
Much like almost any video that's a person talking to the viewer, this would
be much better as an article. The average reading speed seems to be about 300
WPM while average talking speed is 110-150, along with talking generally being
less information-dense because of filler words and repetition. There is the
option of increasing the video's speed at least.

~~~
backprojection
Plus you can listen to or watch the video while doing otherwise mindless stuff
like household chores.

~~~
jimmaswell
That edge-case doesn't justify video over text in general

~~~
wingerlang
That is not an edge case by any stretch of the imagination. Most, if not all,
people I know have videos playing while doing other stuff.

~~~
jimmaswell
I've never done that or seen anyone do it, personally

~~~
wingerlang
I guess my most such cases are watching a video an browsing at the same time.
Or cooking food/cleaning while watching videos. Not once have you done that? I
find that odd, but each to their own.

