Jak działały grafiki w klasycznych grach od Sierra (film, 6m)

If I were to ask you what game has the best graphics, what would you say? Cyberpunk 2077 comes to mind, or maybe Ratchet & Clank Rift Apart. Back in 1984 though, there was no contest. It was King's Quest. It might be hard to appreciate it, but these graphics were jaw-dropping. Look at those 16-color backgrounds. Look at those alligators chomping. Those flags undulating briskly in the wind. Incredible. This game was marketed as a 3D animated adventure by its publisher, Sierra Online. Look at the depth effect here as I walk behind a tree. And now in front of the tree. Incredible. King's Quest fit all these environments, plus all game text, animations, and sound, on one floppy disk. How the heck did they do that? And, as a side effect of the technique they used, could they look sharper? Let's find out. Let's talk about data usage. King's Quest was Sierra's first game to use the Adventure Game Interpreter, or AGI engine. The game's had a resolution of 160x200 in 16 colors, although each pixel was doubled horizontally so you had a wider and nicer looking picture. That's 16k per room in the game, and there's roughly 75 rooms. If you do the math, that's over 1.2 megabytes, and much more data than could fit on the standard 360k floppy disks of the time. To get around this, Sierra used vector graphics. Instead of storing individual pixels, they stored a series of drawing commands, which the AGI engine then followed to recreate the image. You can think of this like using a modern SVG format instead of PNG. How well did it work? Well, to find out, I wrote a Ruby program to extract every background from King's Quest 2. I saved each one as a PNG file with the best compression settings and stripped them of all metadata. I then compared them to the data stored on disk in the game. On average, the AGI data was half the size of the PNG equivalent. That's not bad for a 38-year-old game engine. Vector drawing isn't just about being smaller, though. It also has the ability to scale up without losing quality like bitmaps do. This all made me wonder, could I use the same drawing commands to render the images in a higher resolution? Most of the drawing commands in AGI are for straight lines. Those scale in Antialias really nicely in high definition. I found they look even nicer if you make them chonky. Since the original games had to keep the lines quite thick compared to their backgrounds. This is where things get complicated. Instead of using filled-in polygons like modern vector drawing formats, Sierra use what we call a flood fill. This means they pick a pixel on the screen and say, okay, color in all your neighbors, and keep doing this until there's no more pixels to fill in. The fill needs to be pixel accurate to 160 by 100. And once we upscale our lines to be sharper, they no longer meet up where they should. There's these tiny little gaps. The fills escape and paint in the wrong areas of the screen. I had an idea for how to fix this. I could render a low resolution version of the background first, and whenever I filled in an area, remember what pixels I touched in a bitmap. When it was time to render the high resolution one, I could reference that bitmap. This had all the colors in the right places, but it looked kind of bad. In many places we end up filling much less than we should. Like this tree, where things look blocky. I tried to use an algorithm called the marching squares to reduce the blockiness. It didn't help much. Instead of blocks, I had these tiny little triangles, so I threw away that approach. I decided to try expanding the bitmap by one pixel. The idea here was that most of the time fills don't escape, so let's bias towards filling too much. This was starting to look better, especially when applying the thick lines again. I started to notice that some objects had bigger gaps than I expected between their pixels. In 160 by 200, you get end lines right next to each other, and they'd connect, but in high resolution it looks bad, like on this rock. I ended up adding a phase to my program to review every pixel that had a neighboring one, and connect them if needed. This worked pretty well, and the rock looks much better. The next thing that bothered me was these tiny white pixels around the edges of things, like the cliff. I just couldn't seem to get rid of them. I ended up investigating a tool, ImageMagick, and its ability to de-noise by using connected components in the image. It does a pretty good job of removing those specks. I was finally in a place where I was reasonably happy with the output. My approach is obviously not perfect, but if you compare it to how old games are traditionally upscaled, I think it looks pretty good. Now, I should add that some people say that old game art should not be changed, and the game should be preserved as is. And to be honest, I agree. These games were never designed to be rendered at this resolution, and the artists took advantage of that lack of fidelity in their initial designs. Instead of thinking of these images as upgrades, I'd prefer to think of them as remixes. Some of them might make you appreciate details you missed in the original, or maybe you'll find them pleasing to look at on their own. The full source code to my high-resolution AGI renderer is available on GitHub, so feel free to remix it yourself as much as you want. I'll leave a link below. If you enjoyed this video, please like and subscribe. If enough people do, I'll try to make more videos like it.

Menu

Jak działały grafiki w klasycznych grach od Sierra (film, 6m)

Toggle timeline summary

Transcription