I was a programmer on Space Quest and various other Sierra games. About 15 in all. This brings back memories especially on how we had to cram everything on a disc since each disc was profit. Also we had limited ram. Not even 640k. The characters were cell based animations done in a tool that let us set up animations and spacing and origin points. The 3d effect was a sorting plane effect. We had a tool that you could draw a poly around (like a tree) and designate its z depth. As the character walked toward the back his z dynamically changed. The editor also designated various poly trigger zones for events like exiting a room or starting an event. When we went to 256 color pics we still kept the vector tool for triggers and other effects. The language we used was an in house clone of Small talk using polish notation for math. So it was fairly object oriented and unique for the time since c didn't have object oriented (only pascal back then). One of the benefits of the room method of game play was that 10 programmers could do say 7 rooms each and not rely on anything else to complete those rooms other than art. So we didn't have to wait for a previous room to be completed. This allowed Roberta to play say a castle scene and make requested changes without having the rest of the game in place.
@@ee1518 Because we had to pic between cga 4 color and TGA 16 color. TGA didn't exist for everyone. And yeah TGA was way slower. And CGA had horrible palette options. The only palette with black also have that yucky purple.
@@cb-gz1vl "Well, Lookee here! If it ain't Mister Look-at-me-I'm-in-EGA! Whatsamatter, monochrome not good enough for you? What's dis? 16 colors all for one little bitmapped WIMP?! Whatta waste of EGA. Har, har!"
I think its neat that the final results look like 00s amateur Flash Games. It makes sense, its all vectors. It makes you appriciate how Kings Quest and edgy stick figure games are part of a shared history. Or something.
If you want to feel old, realize that there's about as much time between Now and those classic Flash games, as there was between those and King's Quest.
I did a similar thing for The Quill at some point back in the 90s, and I had a *much* simpler method for dealing with flood fills. I'd draw both the low-res and high-res versions of lines, and whenever there was a flood fill I'd create a low-res scratch buffer, do the fill on the low-res version and duplicate the filled pixels on the scratch buffer, then do the flood fill in high-res; before plotting each high-res pixel I'd convert the high-res coordinates into their low-res equivalents (including the fractional part) and check the scratch buffer - if the point was less than about 1.5 low-res pixels from a filled point I'd draw the high-res pixel, but if it was more than that distance away I'd treat it as a boundary. This both prevented leaks and did a pretty good job of ensuring all pixels were filled (very shallow angles tended to fare worst). Admittedly this was on the Amiga so "high-res" was only 640x512 and I'm not sure if the technique would work at today's resolutions, but I can't think of any specific reason it wouldn't beyond perhaps needing to tweak the distance check value?
This is a great approach. Basically, flood fill has two parts: The flood (that looks for adjacent areas to fill) and the fill which paints the pixels. It sounds like you changed the flood part to sense borders w/ wider radius of view so it wouldn't "leak" through mere pixel-sized holes in borders. I think another way, using the given vector lines would be to bridge gaps below a certain distance and then draw filled polygons made up of lines surrounding an area, drawing the filled polygons behind the lines to give the lines precedence.
@@jones1618 yeah that was pretty much my thought when i considered this; go through it in 2 passes, creating polygons from the flood fill commands, and then re-sequencing the vector layers.
There was an unintended side effect of the drawing method in the early 80s, the object you needed to interact with was always the last object drawn and it was drawn over the completed background . So it was trivial to figure out which object to approach to progress in the game. e.g. if you needed an axe, it would pop onto the screen after the entire scene was rendered. The slow CPU clock speeds and lack of GPU made it quite obvious.
I always found it interesting how you could, across multiple generations of game engine, see the "seams" like that, giving clues to the player. For example, in later 3D titles, you could generally predict if a wall/ceiling/bit of floor was going to break, because it would be a prefab rather than level geometry, and the lighting would fall upon it differently, drawing attention to the edge of the pre-broken section (which you can also spot in real-world movies at times). Or in certain horror games, you could tell if a corpse was going to get up and attack you, because it was the only corpse with a real-time shadow.
The same could be said of early cartoons. You know the character is going to interact with something because it looks like it was added in after everything else was drawn. Usually with too much detail compared to its surroundings.
@@InsaneFirebat It's very obvious in some Hanna-Barbera cartoons where the backgrounds are painted with brushes on some kind of canvas-like medium and everything that was layered on top was inked and filled on acetate. The look of the two were very different. Scooby-Doo, for instance, had some very nice painted backgrounds, with very striking contrast to the foreground figures.
True. Also in point-and-click adventures interactive objects commonly lacked anti-aliasing. I remember Full Throttle occasionally did this trick that after interacting with a complicated render, in rare cases the whole set was redrawn afterwards.
Not going to lie, didn't understand much of the technical detail - but I'm 100% stocked to see people talking about Sierra games (I must not be the only person on a nostalgia trip)
Microsoft is acquiring Activision, who last owned the rights to Sierra, and I saw that Ken Williams commented that he had talked to a senior executive at Microsoft about possibly coming back to revive the Sierra brand, once the acquisition is secured.
This was a fantastic look at how these iconic scenes were created . Sierra did some amazing things with software engineering. Their achievements at the time were just as amazing on the development side as well as the gameplay side. AGI and later SCI were really some amazing creations, especially in that it allowed games to be more easily ported between computer systems. Seeing how you upscaled the graphics was definitely fun, though I agree with you - this is more fun as a remix than any kind of improvement. Thanks for the wonderful video!
I think it would be worthwhile to do a topology analysis of the line drawing commands. If the endpoints are in adjacent pixels in low res, then they should be drawn in a way so that they meet at a single point with a gapless join. Would fix the flood fill problem, maybe have an effect on the white dots problem, and make the line joins look better.
Came here to say exactly that. Impressive algorithm already in the video, but having topologically correct upscaled lines would indeed fix the issues. Some kind of snapping algorithm might already do the trick.
The trouble with that is if the "joined" lines don't meet at an end point you've gained nothing - in low-res a line running from 0,0 to 20,20 would touch a line drawn from 0,20 to 9,11, but if you scaled them up to 0,0-200,200 and 0,200-90,110 then unless you're drawing *super* fat lines there's going to be a gap.
@@elbiggus I disagree. There are ways like mitered lines to make them join up. It’s no easy problem, that’s for sure, but the topological information is there. And hence I think it is possible to generate a watertight outline.
@@root42 It's probably *possible* but it's far more complicated than it needs to be (see my other comment for the solution I used for a similar situation; TL;DR version, just use a couple of low-res scratch buffers to provide region information), and it's still not foolproof. Cleaning up the vectors was my first thought when I was making my attempt, but a combination of complexity of working out the geometry and the fact that there were hundreds of edge cases that needed to be accounted for (even simple things like the oddities of the original line drawing algorithm added a whole host of headaches to working out whether two lines were meant to touch) all made it way more complicated and less robust than the far simpler solution I ended up with.
@@elbiggus Hi, your proposed solution is also at its root a topology analysis, which is what I proposed. Yeah, I missed some of the complexity of the problem, but ultimately it boils down to the same thing: how do you preserve the structure of the low resolution output. All the information is there. The way I would have actually implemented my solution I would have also drawn to a scratch buffer probably anyway, with extra bookkeeping information about which pixel was drawn by which command. So I would have noticed the kissing problem anyway automatically before it became a problem. That's pretty much necessary anyway since these aren't lines, they are specifically Bresenham drawn lines(or some variant), which definitely have different properties than geometrically ideal ones. Then I could scan the buffer to find out where do introduce artificial joins in the upscaled commands. There is likely the additional complexity that you have to keep track of overdrawing pixels, but I can't imagine why it won't work, and anything that does still show up probably has a solution that can be found by looking at the scratch buffer.
Wow, this is so impressive. I grew up with King's/Space/Police Quest games, and never imagined they used vectors for the art. It makes sense for saving disk space, but also for having a z-index for every stroke and fill. They didn't have to use a transparent PNG (or equivalent filetype for the time) for the tree you could walk behind, or the many other effects like that. Just put the character at a certain z-index.I have done a lot of retro game dev work with sprite sheets and tile maps. It occurred to me to render vectors on a lo-res grid, but only as a modern technique. I never thought that's how it was done back in the day.
When playing on a contemporary computer much slower than PC AT, it was fairly obvious that Sierra's AGI game graphics were composed of lines. Changing a "room" in-game took a moment, during which it was clearly visible when backgrounds were gradually rastered on screen by adding edges first and fills later. As a kid I just didn't understand why the pictures are drawn like that. Also I found it confusing why they used such blocky squares (pixels), especially as I (incorrectly) thought that AGI games were not even available on 8-bit systems with "Lego Graphics Adapters". Nevertheless, they were great games at the time - and taught me English in passing.
The pixels weren't doubled horizontally. That was the IBM PCjr's low resolution 16 color mode. The standard IBM CGA video card also supported that mode but not officially. Apparently Sierra's programmers didn't know the tricks for accessing it for the original King's Quest or they did but didn't include it for regular CGA because some non-IBM CGA cards might not have the undocumented modes. Later Sierra games that had EGA 320x200 16 color support had far less effort expended on their CGA modes. That the original King's Quest was done so nicely is due to IBM hiring Sierra to produce a game to show off the PCjr's graphics in order to help sell the computer. Then IBM shot themselves down with the crappy chicklet keyboard. PCjr also supported a 320x200 16 color mode if the 64K RAM upgrade was installed. Tandy would almost but not quite exactly copy the PCjr enhancements to CGA. A simple hardware modification to a PCjr makes it compatible with games supporting Tandy 1000 while also keeping compatibility with all PCjr modes.
@@eviltrout the information on how to modify the PCjr video to run Tandy software is easy to find. Less easy to find is how to modify its audio to be Tandy compatible. I've seen a couple of hardware mods and a small program that can do it. PC Enterprises sold a kit for doing the audio and one for the video. The video kit was a common cheap 7400 series chip, of which only part was used, a couple pieces of wire, and the instructions. Cost $14! Once I had that it was easy to mod more PCjrs for free by pulling chips from an old and dead board. I figured someone would tell how to do the audio mod, sometime. I wasn't going to pay a bunch of money for what was likely to be a bit of wire and instructions, possibly a chip I already had. Never did find out while I still had a PCjr. I only had two games that refused to run with Tandy graphics if they couldn't have the Tandy sound. The other common hardware hack was a modification of the floppy drive circuitry to use two drives and (IIRC) give them independent motor control. I think if you just hooked up a second drive it would work but any time a drive was accessed, both drive's motors would spin. My PCjr had one of the "second story" style expansions that fit on top, holding the 2nd floppy drive and RAM to expand it to 512K. Would've been nice to have one that took it up to 640K, and the VGA and Soundblaster sidecar expansions, and a hard drive controller.
iirc, modified IBM CGA 'text mode' was 160x100 16colors, it quite inefficient video ram usages as its requires 2 bytes to represent '2' pixels on display. CGA only have 16KB or video ram afterall.
On the PCjr, the game used the 320x200 mode and doubled the pixels in the graphical part of the screen, but the text was drawn with single-width pixels. The games were designed around a virtual 160x200 screen which would be shown using either composite video pseudo-color, dithering, or PCjr graphics mode, depending upon the attached monitor and video configuration. Not sure what the Apple //c version of Kings Quest II relates to the other versions, since that screen doesn't really fit the 160x200 virtual screen concept, though perhaps treating alternating groups of 3- and 4- "raw" pixels as virtual pixels, while handling the consequent color shifts, might have been the most practical approach.
I loved playing this as a kid and having a computer that wasn't fast enough to draw the image on screen so when I entered a new room, I got to watch the game draw the scene. I didnt know what was happening at the time, but thought it was really cool.
I once tried repainting the first screen from Police Quest 2 (outside the police station) in 256 colors, using every technique I know including gradients, textures, shading, etc. It looked great. It also took over 100 hours.
Wow, I never even remotely considered that the old AGI games used vector graphics, but it makes a hell of a lot of sense now when reviewing some of the original graphics. Some of them have a very pointy & jagged look and feel which would be unusual when drawing an image pixel by pixel. I suppose that the amount of drawing commands has a direct impact on necessary disk space, which explains why King's Quest I looks far less detailed than SQ2 or Manhunt, which already seem to push the limits of the engine. Thank you for your work & the insight I gained!
More drawing commands would both increase the size on disk (and in memory), as well as increase loading times, which on a slower PC could be quite noticeable when you entered a new room.
The original PCjr release of Kings Quest even showed the drawing of the screen live instead of hidden like the later releases. It's quite fascinating to watch. ua-cam.com/video/v5DSFvWrNWA/v-deo.html
These beautiful upscales make me realize something - these scenes look like how i imagined them to look while interpreting the original graphics when playing the games as a kid. I would absolutely buy and hang prints of these upscales. They're so great.
This blows my mind. I started playing police quest with my 11 year old nephews and they actually loved it. They kept asking if we could play it every time I came over. Love seeing work that shows some of the interesting history about how these games were made.
Brings back the days of old... I grew up on the Sierra games, and never though of the ingenuity that went into cramming that data into one 360K disk. Just watching what you have does has made me want to go back and play them all again.
That's a really clever process you used to upscale the backgrounds and it's fascinating to see the results, but as you say; the originals still look better. The upscaled backgrounds end up looking like doodles made in MS Paint.
Thanks for sharing your work on this, looking at how they squeezed so much from so little is a fascinating area and your painstaking work on modern rendition is much appreciated.
That is super impressive! I had no idea they worked that way. Frankly, I wouldn't have even thought that much into it, either. Cheers, on a great video, and a super neat topic!
Thank you for explaining how early Kings Quest games were made, and how you made the upscaling algorithm work! I'd love to watch more videos like this if you think it's worth the time and effort to make them
Perhaps a better way of joining broken lines: - Render the lines in the original resolution. Use this to build a graph of which line segments are joined to which. Intersection data can be dynamically recalculated later, so no need to store this here. Only need IDs or pointers. - Render the lines in high resolution. If one of these high-res line segments doesn't touch one it expects, you can do some line segment intersection analysis to see how to extend the line for completion. Don't forget to note parallel line segments may touch in more than one spot, but may touch in exactly one or zero spots too.
I tried something similar but couldn’t make it work. If any pixel is solid next to another, they are connected, not just the ends of lines. Some are dots or previous fills too. Still, maybe someone else could make it work. The source code is there!
@@eviltrout if you are not a mathematician the easy way to do this is to draw each line in the original resolution in a different color, then inspect each pixel and compare to the 8 adjacent pixels to construct a connection list that can be used during flood fills. It is computationally and memory inefficient, but considering the screen sizes, workable. The line algorithm has to be pixel-perfect compared to the original algorithm, but that's probably easy enough.
I didn't knew these graphics were based on vectors. Now I can understand a little better why they look the way they do. I really like your custom upscaler too. It definitely look interesting.
Subbing to this channel. Really hope to watch more videos about past games and the tech behind their visuals. How you went over this with a fine toothed comb and then shared your source on github, massive props!
00:12 Dozens and dozen of arcade games back in 1984 would like to have a word with you. Dragon's Lair was released in 1983 and still holds up today. Even if you don't want to count FMV games, the Atari game I Robot was released in '84 which had Star Fox style 3D graphics. Even if you want to count only computer games, there was Elite. Pedanticness aside, genuinely great video. It looks a lot better than most other upscale methods.
I had a feeling someone would call me out on this :) It would have been more accurate to say they’re the best graphics *Id* seen or maybe amongst the best graphics around especially when you consider the clever depth rendering. But yeah, it’s super subjective :)
@@eviltrout That's fair. Plus, in terms of adventure games, it was a hug leap compared to the text-based adventures that came before it. The game's ambition and innovation should not be undermined.
Remastering old games seems to be an interesting art in and of itself. I find it interesting how an old image can be improved while maintaining the original system specs. The updated images look great!
Ooo that's so cool! It would be interesting to use direction lighting on the image too ... I'd love to see a gameplay video using some of these upscaling techniques.
The real secret here was that processing speed had advanced far enough ahead of common of data storage tech, that this would actually be a better use of resources.
It would be a pretty cool means of compressing data now. Convert everything to vector art so it takes up less space, then on the user's computer generate all the final textures and models again expanding into a giant multi-gigabyte mess. It would require some pretty sophisticated algorithmic exploration of the files, or they could try to track the artists as they make the artwork and simplify the vector data a bit.
@@anon_y_mousse There's been some experimental games that use procedurally generated textures to fit into extremely small file sizes. Not vectors, so not exactly the same, but a similar approach.
@@todesziege I'll have to look into that. Most I've seen anyone attempt was procedurally generated terrain and trees, which often look amazing and more real than what people can draw by hand. Would certainly make for a cool game engine. Set a few variables, pick a random seed and bam, a whole world in high def before your eyes. Did you ever see that German demo from like 20 years ago?
Wow very interesting. We wondered how in the world they fit those old games on a few (sometime only one) floppy disks back then! I always loved Sierra's graphics, especially the 16 color EGA in KQ4. But best of all was 256 color VGA which stunned us, and the digital sound capabilities of the Sound Blaster and Pro Audio Spectrum. Those old games were great, not only technically, but gameplay and story. We had great times
They honestly look great. Thanks to the vecror nature and your work, they just feel like the original and not some re imagining that ditches the original art style. Awesome job!
What I like about some of the old games is that you had to use your imagination to fill in the gaps (just as you would visualise a text book whilst reading it). The push for reality has it's downside (and it's not just due to how much you need for a gaming rig, lol)
I love your upscales. There’s a sort of unfulfilled retro futuristic vibe here. This is what the computer games in an 80s retrofuture setting should look like.
lol, first time viewer... The Evil Screeching Trout Intro made me chuckle...this time. I'm not sure how many times I am going to want to watch it in the future, though. :P
Having spent a lot of time playing Sierra games in my youth and now being a software engineer professionally, I appreciate this look-back at these old games and trying to upscale those old graphics.
We had some clever people around those days. Coming up with completely new and novel ways of doing things, like storing drawing commands instead of bitmaps to save space. These days too much is already handed to the developer, almost like these are the confines within which you need to work. If you want to come up with something completely new, you need to write your own game engine, which very few people will tackle.
Fantastic video; well spoken, lovely relaxing voice; clear technical information and a pay off at the end. Thank you UA-cam for recommending a video from a user who **squints** hasn't uploaded in 6 years. Subscribed, hope to see more. My friends cat does not like the Kings Quest music.
There are some old document programs that use this sort of vector approach too. The pattern I like to work with is, rather than scaling up the drawing commands themselves, scaling the "world". In the original versions, there's a 160x200 block grid that's used as targets for the vector draws. Rather than scaling the draw calls up from 0,0 -> 100,100 to 0,0 -> 300,300, we'd create a projection based on the "world" of the 160x200 grid that is then cast onto a larger canvas, even in floating point increments for spaces. It effectively rasterizes the outline for further processing since lots of vector graphics these days weren't capable of true scaling. These are NSVGs, or "Non-Scalable Vector Graphics".
i love these sorts of deep dives. i still think the most remarkable technical achievement of the time (and, arguably, ever) was Starflight: a sandbox galaxy with 270 star systems, each with procedurally generated planets on which you could land and which you could explore, plus dialogue with multiple alien races and a plot that still holds up (esp the twist at the end), squeezed into 128kb of RAM.
Nice to see someone working on this. I'm convinced that good upscaling is possible. I had been thinking about the gap problem with upscaling and reasoned that if lines in low res touched then their high res versions should be made to touch as well either by extending one of both lines till they intersect or by adding short lines to fill the gaps where two line didn't touch that should have. It would likely fix some issues but I haven't gotten round to actually trying to write renderer.
I might talk about it in a future video but I was pretty busy working at a tech company I founded. Now I’m working on a game project and want to try and build a following for marketing purposes (also it’s super fun to work on videos)
Your remixed style has a more authentic hand-drawn aesthetic to it which you could argue is actually better and more inline with the artist’s intentions than the original limitations allowed them to achieve. So, good job 👍
I was a programmer on Space Quest and various other Sierra games. About 15 in all. This brings back memories especially on how we had to cram everything on a disc since each disc was profit. Also we had limited ram. Not even 640k.
The characters were cell based animations done in a tool that let us set up animations and spacing and origin points.
The 3d effect was a sorting plane effect. We had a tool that you could draw a poly around (like a tree) and designate its z depth. As the character walked toward the back his z dynamically changed. The editor also designated various poly trigger zones for events like exiting a room or starting an event.
When we went to 256 color pics we still kept the vector tool for triggers and other effects.
The language we used was an in house clone of Small talk using polish notation for math. So it was fairly object oriented and unique for the time since c didn't have object oriented (only pascal back then). One of the benefits of the room method of game play was that 10 programmers could do say 7 rooms each and not rely on anything else to complete those rooms other than art. So we didn't have to wait for a previous room to be completed. This allowed Roberta to play say a castle scene and make requested changes without having the rest of the game in place.
👏👏👏
Why 160x200 instead of 320x200? Why newer 320x200 with 16 colors Sierra games run so much slower and required a faster CPU?
@@ee1518 Because we had to pic between cga 4 color and TGA 16 color. TGA didn't exist for everyone. And yeah TGA was way slower. And CGA had horrible palette options. The only palette with black also have that yucky purple.
@@cb-gz1vl "Well, Lookee here! If it ain't Mister Look-at-me-I'm-in-EGA! Whatsamatter, monochrome not good enough for you? What's dis? 16 colors all for one little bitmapped WIMP?! Whatta waste of EGA. Har, har!"
I think its neat that the final results look like 00s amateur Flash Games. It makes sense, its all vectors. It makes you appriciate how Kings Quest and edgy stick figure games are part of a shared history. Or something.
If you want to feel old, realize that there's about as much time between Now and those classic Flash games, as there was between those and King's Quest.
@@HansLemurson neither of us wanted that but thanks anyway
I love the "or something" at the end there
It wouldn't be amateur, this art would be incredible if done in flash
Have you tried playing Peasant's Quest by Videlectrix?
I did a similar thing for The Quill at some point back in the 90s, and I had a *much* simpler method for dealing with flood fills. I'd draw both the low-res and high-res versions of lines, and whenever there was a flood fill I'd create a low-res scratch buffer, do the fill on the low-res version and duplicate the filled pixels on the scratch buffer, then do the flood fill in high-res; before plotting each high-res pixel I'd convert the high-res coordinates into their low-res equivalents (including the fractional part) and check the scratch buffer - if the point was less than about 1.5 low-res pixels from a filled point I'd draw the high-res pixel, but if it was more than that distance away I'd treat it as a boundary. This both prevented leaks and did a pretty good job of ensuring all pixels were filled (very shallow angles tended to fare worst). Admittedly this was on the Amiga so "high-res" was only 640x512 and I'm not sure if the technique would work at today's resolutions, but I can't think of any specific reason it wouldn't beyond perhaps needing to tweak the distance check value?
This is a great approach. Basically, flood fill has two parts: The flood (that looks for adjacent areas to fill) and the fill which paints the pixels. It sounds like you changed the flood part to sense borders w/ wider radius of view so it wouldn't "leak" through mere pixel-sized holes in borders.
I think another way, using the given vector lines would be to bridge gaps below a certain distance and then draw filled polygons made up of lines surrounding an area, drawing the filled polygons behind the lines to give the lines precedence.
That is great
@@jones1618 yeah that was pretty much my thought when i considered this; go through it in 2 passes, creating polygons from the flood fill commands, and then re-sequencing the vector layers.
There was an unintended side effect of the drawing method in the early 80s, the object you needed to interact with was always the last object drawn and it was drawn over the completed background . So it was trivial to figure out which object to approach to progress in the game. e.g. if you needed an axe, it would pop onto the screen after the entire scene was rendered. The slow CPU clock speeds and lack of GPU made it quite obvious.
I always found it interesting how you could, across multiple generations of game engine, see the "seams" like that, giving clues to the player. For example, in later 3D titles, you could generally predict if a wall/ceiling/bit of floor was going to break, because it would be a prefab rather than level geometry, and the lighting would fall upon it differently, drawing attention to the edge of the pre-broken section (which you can also spot in real-world movies at times). Or in certain horror games, you could tell if a corpse was going to get up and attack you, because it was the only corpse with a real-time shadow.
The same could be said of early cartoons. You know the character is going to interact with something because it looks like it was added in after everything else was drawn. Usually with too much detail compared to its surroundings.
@@InsaneFirebat It's very obvious in some Hanna-Barbera cartoons where the backgrounds are painted with brushes on some kind of canvas-like medium and everything that was layered on top was inked and filled on acetate. The look of the two were very different. Scooby-Doo, for instance, had some very nice painted backgrounds, with very striking contrast to the foreground figures.
Why didn't you tell me this when I was a kid? I found those games infuriating.
True. Also in point-and-click adventures interactive objects commonly lacked anti-aliasing. I remember Full Throttle occasionally did this trick that after interacting with a complicated render, in rare cases the whole set was redrawn afterwards.
Not going to lie, didn't understand much of the technical detail - but I'm 100% stocked to see people talking about Sierra games (I must not be the only person on a nostalgia trip)
I love keeping the Sierra magic alive :)
Microsoft is acquiring Activision, who last owned the rights to Sierra, and I saw that Ken Williams commented that he had talked to a senior executive at Microsoft about possibly coming back to revive the Sierra brand, once the acquisition is secured.
@@SchlossRitter Really hoping so and Quest for Glory
So many classics, it's no wonder, really.
You ever heard of the term de obsoletion well it’s a kind of a process of becoming obsolete in reverse
This was a fantastic look at how these iconic scenes were created . Sierra did some amazing things with software engineering. Their achievements at the time were just as amazing on the development side as well as the gameplay side. AGI and later SCI were really some amazing creations, especially in that it allowed games to be more easily ported between computer systems. Seeing how you upscaled the graphics was definitely fun, though I agree with you - this is more fun as a remix than any kind of improvement. Thanks for the wonderful video!
yeah... with blocky pixels as blocky gets 🤣 (ZX-SPECTRUM had far sharper graphics back in the day of 1984-1985)
I think it would be worthwhile to do a topology analysis of the line drawing commands. If the endpoints are in adjacent pixels in low res, then they should be drawn in a way so that they meet at a single point with a gapless join. Would fix the flood fill problem, maybe have an effect on the white dots problem, and make the line joins look better.
Came here to say exactly that. Impressive algorithm already in the video, but having topologically correct upscaled lines would indeed fix the issues. Some kind of snapping algorithm might already do the trick.
The trouble with that is if the "joined" lines don't meet at an end point you've gained nothing - in low-res a line running from 0,0 to 20,20 would touch a line drawn from 0,20 to 9,11, but if you scaled them up to 0,0-200,200 and 0,200-90,110 then unless you're drawing *super* fat lines there's going to be a gap.
@@elbiggus I disagree. There are ways like mitered lines to make them join up. It’s no easy problem, that’s for sure, but the topological information is there. And hence I think it is possible to generate a watertight outline.
@@root42 It's probably *possible* but it's far more complicated than it needs to be (see my other comment for the solution I used for a similar situation; TL;DR version, just use a couple of low-res scratch buffers to provide region information), and it's still not foolproof. Cleaning up the vectors was my first thought when I was making my attempt, but a combination of complexity of working out the geometry and the fact that there were hundreds of edge cases that needed to be accounted for (even simple things like the oddities of the original line drawing algorithm added a whole host of headaches to working out whether two lines were meant to touch) all made it way more complicated and less robust than the far simpler solution I ended up with.
@@elbiggus Hi, your proposed solution is also at its root a topology analysis, which is what I proposed. Yeah, I missed some of the complexity of the problem, but ultimately it boils down to the same thing: how do you preserve the structure of the low resolution output. All the information is there.
The way I would have actually implemented my solution I would have also drawn to a scratch buffer probably anyway, with extra bookkeeping information about which pixel was drawn by which command. So I would have noticed the kissing problem anyway automatically before it became a problem. That's pretty much necessary anyway since these aren't lines, they are specifically Bresenham drawn lines(or some variant), which definitely have different properties than geometrically ideal ones.
Then I could scan the buffer to find out where do introduce artificial joins in the upscaled commands. There is likely the additional complexity that you have to keep track of overdrawing pixels, but I can't imagine why it won't work, and anything that does still show up probably has a solution that can be found by looking at the scratch buffer.
Wow, this is so impressive. I grew up with King's/Space/Police Quest games, and never imagined they used vectors for the art. It makes sense for saving disk space, but also for having a z-index for every stroke and fill. They didn't have to use a transparent PNG (or equivalent filetype for the time) for the tree you could walk behind, or the many other effects like that. Just put the character at a certain z-index.I have done a lot of retro game dev work with sprite sheets and tile maps. It occurred to me to render vectors on a lo-res grid, but only as a modern technique. I never thought that's how it was done back in the day.
When playing on a contemporary computer much slower than PC AT, it was fairly obvious that Sierra's AGI game graphics were composed of lines. Changing a "room" in-game took a moment, during which it was clearly visible when backgrounds were gradually rastered on screen by adding edges first and fills later.
As a kid I just didn't understand why the pictures are drawn like that. Also I found it confusing why they used such blocky squares (pixels), especially as I (incorrectly) thought that AGI games were not even available on 8-bit systems with "Lego Graphics Adapters".
Nevertheless, they were great games at the time - and taught me English in passing.
The pixels weren't doubled horizontally. That was the IBM PCjr's low resolution 16 color mode. The standard IBM CGA video card also supported that mode but not officially. Apparently Sierra's programmers didn't know the tricks for accessing it for the original King's Quest or they did but didn't include it for regular CGA because some non-IBM CGA cards might not have the undocumented modes. Later Sierra games that had EGA 320x200 16 color support had far less effort expended on their CGA modes.
That the original King's Quest was done so nicely is due to IBM hiring Sierra to produce a game to show off the PCjr's graphics in order to help sell the computer. Then IBM shot themselves down with the crappy chicklet keyboard.
PCjr also supported a 320x200 16 color mode if the 64K RAM upgrade was installed. Tandy would almost but not quite exactly copy the PCjr enhancements to CGA. A simple hardware modification to a PCjr makes it compatible with games supporting Tandy 1000 while also keeping compatibility with all PCjr modes.
Thanks for the clarification! That’s very informative.
@@eviltrout the information on how to modify the PCjr video to run Tandy software is easy to find. Less easy to find is how to modify its audio to be Tandy compatible. I've seen a couple of hardware mods and a small program that can do it. PC Enterprises sold a kit for doing the audio and one for the video. The video kit was a common cheap 7400 series chip, of which only part was used, a couple pieces of wire, and the instructions. Cost $14! Once I had that it was easy to mod more PCjrs for free by pulling chips from an old and dead board. I figured someone would tell how to do the audio mod, sometime. I wasn't going to pay a bunch of money for what was likely to be a bit of wire and instructions, possibly a chip I already had. Never did find out while I still had a PCjr. I only had two games that refused to run with Tandy graphics if they couldn't have the Tandy sound. The other common hardware hack was a modification of the floppy drive circuitry to use two drives and (IIRC) give them independent motor control. I think if you just hooked up a second drive it would work but any time a drive was accessed, both drive's motors would spin.
My PCjr had one of the "second story" style expansions that fit on top, holding the 2nd floppy drive and RAM to expand it to 512K. Would've been nice to have one that took it up to 640K, and the VGA and Soundblaster sidecar expansions, and a hard drive controller.
iirc, modified IBM CGA 'text mode' was 160x100 16colors, it quite inefficient video ram usages as its requires 2 bytes to represent '2' pixels on display. CGA only have 16KB or video ram afterall.
On the PCjr, the game used the 320x200 mode and doubled the pixels in the graphical part of the screen, but the text was drawn with single-width pixels. The games were designed around a virtual 160x200 screen which would be shown using either composite video pseudo-color, dithering, or PCjr graphics mode, depending upon the attached monitor and video configuration. Not sure what the Apple //c version of Kings Quest II relates to the other versions, since that screen doesn't really fit the 160x200 virtual screen concept, though perhaps treating alternating groups of 3- and 4- "raw" pixels as virtual pixels, while handling the consequent color shifts, might have been the most practical approach.
Yes when we went to 320x200 we made a driver that scaled for CGA mode.
I loved playing this as a kid and having a computer that wasn't fast enough to draw the image on screen so when I entered a new room, I got to watch the game draw the scene. I didnt know what was happening at the time, but thought it was really cool.
I once tried repainting the first screen from Police Quest 2 (outside the police station) in 256 colors, using every technique I know including gradients, textures, shading, etc.
It looked great. It also took over 100 hours.
Wow, I never even remotely considered that the old AGI games used vector graphics, but it makes a hell of a lot of sense now when reviewing some of the original graphics. Some of them have a very pointy & jagged look and feel which would be unusual when drawing an image pixel by pixel. I suppose that the amount of drawing commands has a direct impact on necessary disk space, which explains why King's Quest I looks far less detailed than SQ2 or Manhunt, which already seem to push the limits of the engine.
Thank you for your work & the insight I gained!
More drawing commands would both increase the size on disk (and in memory), as well as increase loading times, which on a slower PC could be quite noticeable when you entered a new room.
The original PCjr release of Kings Quest even showed the drawing of the screen live instead of hidden like the later releases. It's quite fascinating to watch. ua-cam.com/video/v5DSFvWrNWA/v-deo.html
These beautiful upscales make me realize something - these scenes look like how i imagined them to look while interpreting the original graphics when playing the games as a kid. I would absolutely buy and hang prints of these upscales. They're so great.
This blows my mind. I started playing police quest with my 11 year old nephews and they actually loved it. They kept asking if we could play it every time I came over. Love seeing work that shows some of the interesting history about how these games were made.
Brings back the days of old... I grew up on the Sierra games, and never though of the ingenuity that went into cramming that data into one 360K disk. Just watching what you have does has made me want to go back and play them all again.
That's a really clever process you used to upscale the backgrounds and it's fascinating to see the results, but as you say; the originals still look better. The upscaled backgrounds end up looking like doodles made in MS Paint.
It's the16-colors that were used, they are what was readily available on early versions of MS Paint.
Thanks for sharing your work on this, looking at how they squeezed so much from so little is a fascinating area and your painstaking work on modern rendition is much appreciated.
The quality of this video is fantastic. Very entertaining and informative.
I appreciate you including Manhunter: New York, and Manhunter: San Francisco. Absolutely loved those two games.
This is my first time on your channel, and your intro logo is the best thing I've ever seen.
That is super impressive! I had no idea they worked that way. Frankly, I wouldn't have even thought that much into it, either.
Cheers, on a great video, and a super neat topic!
I know, right?
Awesome work! It’s very cool to see the old vector-based data exploited in this way. I know it’s not perfect but it shows big potential :)
Thanks! It was a bunch of work but I had fun doing it.
For me the beauty lies not within what comes out, but rather in how it works.
I loved playing those games as a kid. Still my favourites all-time.
Thank you for explaining how early Kings Quest games were made, and how you made the upscaling algorithm work! I'd love to watch more videos like this if you think it's worth the time and effort to make them
This is incredible, gives me very strong Retro Game Mechanics vibes, especially the super clear visuals! Look forward to seeing more from you! :)
That intro is hysterical, like a throwback to early 2010s youtube. This was a great video, keep it up!
Thanks! I spent quite a while learning blender for that :)
Oh My God! That's incredible! Please keep up the good work.
So Cool!! Thank you for the love and care you showed these classic games!
Perhaps a better way of joining broken lines:
- Render the lines in the original resolution. Use this to build a graph of which line segments are joined to which. Intersection data can be dynamically recalculated later, so no need to store this here. Only need IDs or pointers.
- Render the lines in high resolution. If one of these high-res line segments doesn't touch one it expects, you can do some line segment intersection analysis to see how to extend the line for completion. Don't forget to note parallel line segments may touch in more than one spot, but may touch in exactly one or zero spots too.
I tried something similar but couldn’t make it work. If any pixel is solid next to another, they are connected, not just the ends of lines. Some are dots or previous fills too. Still, maybe someone else could make it work. The source code is there!
@@eviltrout if you are not a mathematician the easy way to do this is to draw each line in the original resolution in a different color, then inspect each pixel and compare to the 8 adjacent pixels to construct a connection list that can be used during flood fills. It is computationally and memory inefficient, but considering the screen sizes, workable.
The line algorithm has to be pixel-perfect compared to the original algorithm, but that's probably easy enough.
Great video. Came across your video and loved the way you explained everything properly without going too deep. Great pacing, too!
I was more than happy to discover this video from the "Discourse guy". Awesome.
This is amazing. Using these as the bases of style transfer will be beautiful
damn 6 years and you return, welcome back
I didn't knew these graphics were based on vectors. Now I can understand a little better why they look the way they do.
I really like your custom upscaler too. It definitely look interesting.
Brings me back to the 4th grade...
Fond memories getting done with homework and loading up kings quest, or space quest
That's cool. I really wanted to see some gameplay with the higher res tbh, but really cool work
You upscaled images look like simple drawings by a competent artist as preliminary work, it is pleasant to look at.
this is really awesome as a fan of the old sierra games... definitely hoping to see more videos like this
This was really neat man, would love more of this.
Loved this too much, the final sequence of images had me smirking and going "whoa whoa holup" and subscribe. This is tickling too many itches
I love the level of detail you go into describing what your code does.
Awesome work. I wish they will bring these games back
This explains so much on how and why the games render the way they do. Thank you.
I really like the techniques you've employed. Looking forward to seeing more
Subbing to this channel. Really hope to watch more videos about past games and the tech behind their visuals. How you went over this with a fine toothed comb and then shared your source on github, massive props!
What a fun video and project! Thanks!
00:12 Dozens and dozen of arcade games back in 1984 would like to have a word with you. Dragon's Lair was released in 1983 and still holds up today. Even if you don't want to count FMV games, the Atari game I Robot was released in '84 which had Star Fox style 3D graphics. Even if you want to count only computer games, there was Elite.
Pedanticness aside, genuinely great video. It looks a lot better than most other upscale methods.
I had a feeling someone would call me out on this :) It would have been more accurate to say they’re the best graphics *Id* seen or maybe amongst the best graphics around especially when you consider the clever depth rendering. But yeah, it’s super subjective :)
@@eviltrout That's fair. Plus, in terms of adventure games, it was a hug leap compared to the text-based adventures that came before it. The game's ambition and innovation should not be undermined.
Those upscaled pictures are really pretty. It really does make me appreciate the beauty of them and the reason those graphics were so praised.
Great, fun and informative video. Keep up the good work!
Awesome video. Sierra is a huge player in video game history. In years to come and I mean YEARS they will be remember as Trail Blazers.
I've always wondered this, thanks so much!
Love this stuff mate - bring on more content for sure! 😊
more videos like this would be awesome. subbed!
very nice, your vector upscaler is really good! I like the output.
Remastering old games seems to be an interesting art in and of itself. I find it interesting how an old image can be improved while maintaining the original system specs. The updated images look great!
Shout out to Roberta and Ken Williams for creating what revolutionized graphical gameplay for that time.
subscribed purely because of the trout intro. LEGENDARY
Very interesting video, especially for a Sierra fan like myself. Thanks for sharing!
Ooo that's so cool! It would be interesting to use direction lighting on the image too ... I'd love to see a gameplay video using some of these upscaling techniques.
I think that would be super tough based on the flood filling of various areas but maybe it could be done.
Awesome dude. I’m glad to see this progress.
The real secret here was that processing speed had advanced far enough ahead of common of data storage tech, that this would actually be a better use of resources.
It would be a pretty cool means of compressing data now. Convert everything to vector art so it takes up less space, then on the user's computer generate all the final textures and models again expanding into a giant multi-gigabyte mess. It would require some pretty sophisticated algorithmic exploration of the files, or they could try to track the artists as they make the artwork and simplify the vector data a bit.
@@anon_y_mousse There's been some experimental games that use procedurally generated textures to fit into extremely small file sizes. Not vectors, so not exactly the same, but a similar approach.
@@todesziege I'll have to look into that. Most I've seen anyone attempt was procedurally generated terrain and trees, which often look amazing and more real than what people can draw by hand. Would certainly make for a cool game engine. Set a few variables, pick a random seed and bam, a whole world in high def before your eyes. Did you ever see that German demo from like 20 years ago?
Wow very interesting. We wondered how in the world they fit those old games on a few (sometime only one) floppy disks back then!
I always loved Sierra's graphics, especially the 16 color EGA in KQ4. But best of all was 256 color VGA which stunned us, and the digital sound capabilities of the Sound Blaster and Pro Audio Spectrum. Those old games were great, not only technically, but gameplay and story. We had great times
They honestly look great. Thanks to the vecror nature and your work, they just feel like the original and not some re imagining that ditches the original art style.
Awesome job!
Would love to see more experiments along these lines! Subscribed in the hopes of seeing more.
Dude, your intro is awesome!
Fascinating! Than you for this great presentation
What I like about some of the old games is that you had to use your imagination to fill in the gaps (just as you would visualise a text book whilst reading it). The push for reality has it's downside (and it's not just due to how much you need for a gaming rig, lol)
I love your upscales. There’s a sort of unfulfilled retro futuristic vibe here. This is what the computer games in an 80s retrofuture setting should look like.
lol, first time viewer...
The Evil Screeching Trout Intro made me chuckle...this time. I'm not sure how many times I am going to want to watch it in the future, though. :P
integrating this kind of upscaling into scummvm would be amazing!
Love the work you put into this mate; well done!
Very cool technique! It's fun seeing these images "remastered". Keep it up!
Thanks for the technical explanation! VERY easy to understand
love your results - you did very well
This is a fantastic way to return after a 6 year hiatus.
Sierra and the Quest games were AMAZING so many memories
Having spent a lot of time playing Sierra games in my youth and now being a software engineer professionally, I appreciate this look-back at these old games and trying to upscale those old graphics.
We had some clever people around those days. Coming up with completely new and novel ways of doing things, like storing drawing commands instead of bitmaps to save space. These days too much is already handed to the developer, almost like these are the confines within which you need to work. If you want to come up with something completely new, you need to write your own game engine, which very few people will tackle.
Fantastic video; well spoken, lovely relaxing voice; clear technical information and a pay off at the end.
Thank you UA-cam for recommending a video from a user who **squints** hasn't uploaded in 6 years.
Subscribed, hope to see more.
My friends cat does not like the Kings Quest music.
Your evil trout intro got me to subscribe! :)
Great explanation and methods to upscale!
I like that after 7 years you still posted
thanks dude! brought back some fun memories
There are some old document programs that use this sort of vector approach too. The pattern I like to work with is, rather than scaling up the drawing commands themselves, scaling the "world". In the original versions, there's a 160x200 block grid that's used as targets for the vector draws. Rather than scaling the draw calls up from 0,0 -> 100,100 to 0,0 -> 300,300, we'd create a projection based on the "world" of the 160x200 grid that is then cast onto a larger canvas, even in floating point increments for spaces. It effectively rasterizes the outline for further processing since lots of vector graphics these days weren't capable of true scaling. These are NSVGs, or "Non-Scalable Vector Graphics".
Ok that channel animation won me over. Take the subscription lol
i love these sorts of deep dives. i still think the most remarkable technical achievement of the time (and, arguably, ever) was Starflight: a sandbox galaxy with 270 star systems, each with procedurally generated planets on which you could land and which you could explore, plus dialogue with multiple alien races and a plot that still holds up (esp the twist at the end), squeezed into 128kb of RAM.
Thanks for the video! I didn't know that about King's Quest, but it makes alot of sense.
Nice to see someone working on this. I'm convinced that good upscaling is possible. I had been thinking about the gap problem with upscaling and reasoned that if lines in low res touched then their high res versions should be made to touch as well either by extending one of both lines till they intersect or by adding short lines to fill the gaps where two line didn't touch that should have. It would likely fix some issues but I haven't gotten round to actually trying to write renderer.
Check out my code if you get some time because I try to do this with varying levels of success.
I'd love to see more videos like this. Definitely subscribed!
Thank you! Lots of code you did before upscaled gfx. I am impressed as I am Dinosaur from that time 👍
This game was my life back in the 1980s. Rocking it on my PC Jr.
Beautifully done
It's amazing that you came back after 6 years of silence.
I might talk about it in a future video but I was pretty busy working at a tech company I founded. Now I’m working on a game project and want to try and build a following for marketing purposes (also it’s super fun to work on videos)
That had to be the most wtf opening animation/channel intro... I loved it haha!
Bravo! Really enjoyed this!
Really love the result. It keep the pixel art aesthetic but high res.
Your remixed style has a more authentic hand-drawn aesthetic to it which you could argue is actually better and more inline with the artist’s intentions than the original limitations allowed them to achieve. So, good job 👍
I learned something new today.
Really cool video!