A tool to render and upscale Sierra adventure game background images
github.com
github.com
Stated another way, the images are full of shapes that should have color fills, but instead they're just strokes that are guaranteed to be so fat that a fill would be redundant. You also don't need to define every edge of a shape - you can define top and bottom and just let the fat strokes implicitly define left and right edges.
[1] https://docs.krita.org/en/tutorials/flat-coloring.html#color...
As it is, it just leaves a bunch of individual dots in, but those could be detected and their color spread out to make a gradient. Like near the horizon of the planet, and the skulls and bones, for example.
Of course you'd need to detect and mask out the area that the gradient applies to, since you don't want i.e. the color bleeding out past the edge of the planet into space, or into the outlines.
I think I may also be trying very hard to not use the word “mobile” here, but I have to admit it was the first thing that came to mind.
[edit: to be clear I’m not trying to say anything at all about the tech here, this was written entirely out of bafflement trying to understand my reaction to the images]
If I had to pick, I would probably choose the older version, but for the outdoor areas, and dungeons, and character portraits the new ones are visually miles ahead.
There is no “upscaling” because the art was drawn as points, lines, fills, etc to begin with. The reason it looks pixelated is because it was rendered onto a (very) low res screen.
Of course, since the files were drawn to be rendered on a low-resolution screen, the file format only allows for that same low resolution in the storage format. I e your X and Y coordinates in the file correspond to on-screen pixel coordinates.
Off the top of my head, e.g. The blade of Blackpoole (1982), The Golden Baton (1982) and Heroes of Karn (1983).
The artist clearly didn't understand vanishing points.
What do you think "stored in a vector format" means? The old art is the old art; it doesn't contain more information if you learn something about the storage format that you didn't expect.
Look at the example backgrounds. In the first, we see a tree with a round knot, presumably where a round branch fell away. There's a round hole in the center of the knot. Rendering the stored data in an inappropriate way, we can instead see an oddly polygonal tree with a bizarre +-shaped hole in it. We can also see that certain parts of the image just aren't defined, relying on the pixels to have a certain width within the image. Look at the swatches of white on the tree branches, the crenellations, the base of the tower, the little palm tree beside the banners, the grass behind the tree...
In the second image, the skull on the left is missing a tooth. In the rerendered version, the tooth is for some reason no longer missing. What was a gap in the teeth is now a tiny string of black dots, much thinner than the teeth, forming an inexplicable straight line across the teeth. What was a gash in the bone between the skulls is now two clearly unrelated thin black lines which appear to have been painted onto the bone. The lighting on the skull on the right manages to avoid casting any light on certain parts of the skull, again a problem that doesn't exist in the original art.
The third image is mostly fine. All of them have something weird going on where pixels that have a 2:1 aspect ratio in the original are rendered as perfect circles in the rerender, but the aspect ratio of the overall image doesn't change.
Or maybe it's a bug in the upscaling renderer. Or a combination of both. Either way, the second skull to the right has the tooth blacked out correctly and looks great.
In any case, for the most part the upscaling looks great. Given, as you say, the limited level of detail available in the original art, I think the improvements greatly outweigh the glitches.
The missing tooth consists of a black line painted over the (already-drawn) teeth. It is one pixel wide, and it either covers both pixels of the tooth's width due to being drawn over a pixel boundary, or it covers the lower (rightmost) half of the tooth while the upper half is covered by the strangely pointed jawline that you can see in the "upscaled" image. The "upscaler" sees that it's defined as a line and renders it at the width of a line, which ruins the artwork, but it's a faithful interpretation of the stored data if you really believe that the stored data is vector art rather than compressed pixel art.
Exactly the same thing happens with the blue lighting on the same skull's forehead. As you can clearly see by looking at the original artwork, this is blue shading over a three-dimensional roughly spherical surface. But, because the image has a low resolution, the shading is defined as three vertical lines, one pixel wide each, which just happen to paint over the edge of the skull shape. Those three lines are still present in the rerender, but it has interpreted them as lines instead of areas, which is nonsensical.
> Either way, the second skull to the right has the tooth blacked out correctly and looks great.
But that skull also looks terrible. It's covered in weird squiggles that have no image data for the space between them, because they're supposed to be wider. Look at the lower jaw, right under the teeth. Look at the blue lighting in the skull's upper right. Look at the lighting on the neck vertebrae. Look at the nasal opening.
OK, "Bug" is the wrong word. This renderer/up-scaler is using various tricks and techniques to render the image at a higher resolution than it was ever designed for. Elsewhere it's scaling up the width of a line / size of a pixel so that it looks appropriate, but for whatever reason it's missed a trick here.
> "But that skull also looks terrible."
I think your expectations are too high! You can't expect it to look as good as modern game art, but it's neat that such an old and tiny game can be made to look much sharper than it originally did.
A fatter brush would go a long way toward fixing the rendering errors, but I don't think it could do much about the blue shading on the left of the left skull being defined as three separate vertical lines when conceptually it's one spherical shadow. If you can determine the orientation of the lines at all, they're going to be wrong.
I had basically only really considered this with Flash in the 90’s, when dial-up was a thing and, similarly; raster images would cause size issues.
It’s fascinating as hell to learn that this is how these games were put together.
The target system for Sierra’s first adventures (The Wizard and the Pricess, King’s Quest et al) was the Apple II, whose floppies could take a whopping 113.75 KB per side.
Perhaps more importantly, it only had 48 kB of RAM, and a traditional full color bitmap image would have taken up a bit more than half of that, leaving very little for game logic, I/O routines, text etc. Using vector graphics was a necessity for getting several full-color screens onto one floppy.
You can read a long-form series of articles about how Ken Williams implemented this game engine at https://www.filfre.net/tag/sierra/page/8/ .
I recall the Manhunter games used AGI for some really impressive graphics (for 1988/89 anyway). Those games used lots of closeups and other cinematic angles which was also very unusual compared to Sierra’s usual flat third-person aesthetic. Maybe that’s where the skulls are from?