5 ms·

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 w

by Jolter 4y ago

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.

Reason077 4y ago
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?
- mseepgood 4y ago
  Yes, there's a video by the author of this tool that explains it: https://www.youtube.com/watch?v=sclZDCjUVvI https://www.youtube.com/watch?v=sclZDCjUVvI
  - pvg 4y ago
    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.
- pvg 4y ago
  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.
- Jolter 4y ago
  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.
  - daneel_w 4y ago
    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).
    - mseepgood 4y ago
      Mystery House (1980) seems to have been the first (in the adventure game genre): https://en.wikipedia.org/wiki/Mystery_House https://en.wikipedia.org/wiki/Mystery_House The artist clearly didn't understand vanishing points.
      - DonHopkins 4y ago
        It looks to me more like a rebellion against rather than a misunderstanding of vanishing points. That tree...
- thaumasiotes 4y ago
  > 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.
  - Reason077 4y ago
    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.
    - thaumasiotes 4y ago
      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.
- daneel_w 4y ago
  Some of them used a vector-like format, yes. Most of them used plain rasterized graphics.
deleted 4y ago
[deleted]
ghostly_s 4y ago
wow...certainly explains why I was failing to find the 'upscale' logic in the source!
deleted 4y ago
[deleted]
lostgame 4y ago
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.
- Jolter 4y ago
  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. 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/ https://www.filfre.net/tag/sierra/page/8/ .
  - pvg 4y ago
    140-ish K per side, more typically. The 113.75KB format was relatively short-lived.

by Jolter 4y ago

Reason077 4y ago

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?

mseepgood 4y ago
Yes, there's a video by the author of this tool that explains it: https://www.youtube.com/watch?v=sclZDCjUVvI https://www.youtube.com/watch?v=sclZDCjUVvI
- pvg 4y ago
  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.
pvg 4y ago
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.
Jolter 4y ago
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.
- daneel_w 4y ago
  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).
  - mseepgood 4y ago
    Mystery House (1980) seems to have been the first (in the adventure game genre): https://en.wikipedia.org/wiki/Mystery_House https://en.wikipedia.org/wiki/Mystery_House The artist clearly didn't understand vanishing points.
    - DonHopkins 4y ago
      It looks to me more like a rebellion against rather than a misunderstanding of vanishing points. That tree...
thaumasiotes 4y ago
> 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.
- Reason077 4y ago
  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.
  - thaumasiotes 4y ago
    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.
daneel_w 4y ago
Some of them used a vector-like format, yes. Most of them used plain rasterized graphics.

deleted 4y ago

[deleted]

ghostly_s 4y ago

wow...certainly explains why I was failing to find the 'upscale' logic in the source!

deleted 4y ago

[deleted]

lostgame 4y ago

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.

Jolter 4y ago
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. 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/ https://www.filfre.net/tag/sierra/page/8/ .
- pvg 4y ago
  140-ish K per side, more typically. The 113.75KB format was relatively short-lived.