Menu
About me Kontakt

Eviltrout took a closer look at the impact of graphics in gaming, specifically how King’s Quest from 1984 changed perceptions of video game graphics. He mentions that nowadays players often refer to titles like Cyberpunk 2077 or Ratchet & Clank Rift Apart as examples of games with amazing graphics. However, back in the 80s, King’s Quest stood out with its incredible 16-color backgrounds and animations. The game was published by Sierra Online and was marketed as a 3D animated adventure, which was revolutionary at the time.

He also discussed the data storage methods used in the game, which were groundbreaking. King’s Quest used the Adventure Game Interpreter (AGI) engine with a resolution of 160x200. By utilizing vector graphics, the game managed to fit all its components onto a single floppy disk, something unheard of. Sierra employed a technique of storing drawing commands instead of individual pixels, which significantly reduced the required memory space.

Eviltrout further explored how to enhance the graphics handled by AGI. He wrote a Ruby program to extract backgrounds from King’s Quest 2 into PNG files with the best compression settings. He compared these graphics data to the data stored in the game, finding that the AGI data was on average half the size of the PNG equivalent. However, it wasn't just about size: vector graphics allow for retaining excellent quality even when scaling up the image.

One of the major challenges Eviltrout faced was color filling at the high resolution mentioned. He talked about using the algorithm known as

Toggle timeline summary

  • 00:00 Introduction asking about the game with the best graphics.
  • 00:04 Mentioning modern games with impressive graphics.
  • 00:09 Recalling King's Quest as a revolutionary game in 1984.
  • 00:30 Describing the jaw-dropping graphics of King's Quest.
  • 00:43 Explaining how King's Quest was marketed as a 3D experience.
  • 01:00 Reflecting on the game's data efficiency on floppy disk.
  • 01:28 Discussing the use of the AGI engine in King's Quest.
  • 01:45 Calculating data requirements for the game's rooms.
  • 01:53 Explaining innovative vector graphics usage by Sierra.
  • 02:26 Comparing the size of AGI data to modern PNG files.
  • 02:31 Discussing the benefits of vector graphics, including scalability.
  • 02:58 Explaining the pixel-filling method used in the game.
  • 03:37 Introducing a method to render high-resolution backgrounds.
  • 04:27 Noting improvements in visual quality and addressing pixel gaps.
  • 04:40 Utilizing ImageMagick for image de-noising.
  • 04:47 Acknowledging that the rendering approach is not perfect.
  • 05:01 Discussing the preservation of original game art versus remixes.
  • 05:23 Pointing viewers to the GitHub source code for further exploration.
  • 05:27 Encouragement to like and subscribe for more content.

Transcription

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.