I dunno, it's pretty clear from the examples that the vector files were created with the intention of being displayed at low resolution and the high-res versions are mutilating some of the effects. For example, the skeleton's teeth and the curve on the satellite dish look right at low res but look like they were drawn by an incompetent at high res.
It looks to me like the data relies on the images using a minimum stroke width relative to the size of the rendered image. All of them display areas of white where there is no image data, because increasing the resolution caused pixels to appear in the space between strokes that, at the original resolution, were less than a pixel apart.
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.
Yeah, exactly. The other big factor is that the lines are vector but the flood fills are pixel-based, so accuracy depends very much on the width of the lines---and even the rasterization algorithm used for the lines. Add to this the issue you brought up about thick pixelated lines making many fills redundant, and you have a pretty good idea about why automated upscaling of these games will never be very satisfying. Also, the sprites in the games are not vector art, and the games depend on the sprites covering exact areas of the background imagery.
It could be nicer if it reverse engineered the speckles of different densities from the error diffusion dithering back into nice smooth continuous gradients.
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.
As others have mentioned the upscaling changes the design a bit, but I’m not mad at it. It’s like it’s from an alternate reality where Sierra went for a cartoony vibe and I feel like there were at least a few people in Sierra who would have liked to work on cartoony games.
I’m not sure what it is, but except for the spaceship image, the upscaled images look… flatter? I don’t have any attachment to these games (or pixel games in general), so it’s not a nostalgia thing, but I also can’t explain it. It feels very weird. I also can’t tell why I like the upscaled space ship, but perhaps it’s because I expect those shapes to be smooth.
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]
I'm split, I've not played the game so I only have the images provided to go off of, but for many of the photos, the old version looks massively better, much more artistic and evocative, but then for some of the images, like the crystals in Crystalgard, the new ones look so much better.
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.
The medium is so constrained the artists had little choice but to try to squeeze the most out of it for expressive ends and it dictated some of the stylistic choices. I think this sort of upscaling tends to throw that out and it's most eyepokey in static images like these. Some of the upscalers work pretty well (depending on taste) in motion, most emulators include a bunch of different ones.
I think this may be the key point, at least for what was befuddling me. Looking at the right side of the castle, the old image has a clear sense of depth while the upscaled version doesn’t
I feel like ML would have a better chance at producing a better interpretation. But training would be challenge. I guess the best bet would be a human artist. They should do the best but there would be no unanimous agreement.
From a brief glance at it, this tool seems to make high resolution renders of the vector based art in the game files.
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.
So these old adventure games had their art stored in a vector format this whole time and we’ve just been rendering it blocky and pixelated to preserve authenticity?
Someone should type this up and submit a summary as a PR since it answers just about all the obvious questions that come to mind (and thread) from the README.
You could say that. The Sierra games were a bit revolutionary in using vector graphics for the backgrounds. It meant they could fit dozens of full-color game screens on a single Apple II floppy disk, which was no small feat.
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.
There were a handful of earlier games on the C64 (and probably also the Spectrum) using "instructed formats" for rendering scenes. They were all of course in the same era of pioneering.
Off the top of my head, e.g. The blade of Blackpoole (1982), The Golden Baton (1982) and Heroes of Karn (1983).
> these old adventure games had their art stored in a vector format this whole time and we’ve just been rendering it blocky and pixelated to preserve authenticity?
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.
True, but to be fair the issue with the tooth was perhaps a minor mistake by the original artist, relying on a characteristic of the original renderer.
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 issue with the tooth isn't a bug in the renderer. That's how the image is defined. The skull's teeth are two pixels wide. Their edges are stored as vectors, with yellow fill in places.
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.
> "The issue with the tooth isn't a bug in the renderer. That's how the image is defined."
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.
It would be interesting to take this vector data and do some more sophisticated rendering on it. If this output EPS/SVG I would be tempted to load a few images into Illustrator and play around with assigning various brushes to the lines; replacing the naive line rendering with something that looks more like a slightly messy paintbrush that mostly fills the same space as a big fat EGA pixel could fix all the rendering errors you’ve noted, and look pretty.
Looks like the message for the last commit touching pic_path.rb was "can make a crappy SVG".
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.
In these particular ones, the lines-and-fills format is for compression, not resolution-independent fidelity. You couldn't fit a game's worth of backgrounds on a few-hundred-k floppy as bitmaps.
I genuinely had no idea this was the case - and yet it’s so brilliant, and pretty much necessary - considering the amount of backgrounds and details in them - for these games to have fit in the 1.44MB that a floppy disk offered.
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.
1,44 MB was the capacity of the High Density 3 1/4” disks that were introduced for the IBM PC in 1987.
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.
What game is the skeleton image from? It’s tremendously better as a painting than Sierra’s usual standard for these AGI games.
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?
It would be neat if this upscaling tech could be built in to ScummVM so that those old sierra games could be (optionally) played with upscaled graphics!
To be honest, Sierra games always looked like a child's MSPaint drawings to me. Even Maniac Mansion, which had to work with comparable technical limitations, looked more sophisticated.
