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.
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.
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.
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.
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.
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.
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.
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. th-cam.com/video/v5DSFvWrNWA/w-d-xo.html
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.
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.
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.
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.
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.
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
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!
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.
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.
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.
Fantastic video; well spoken, lovely relaxing voice; clear technical information and a pay off at the end. Thank you TH-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.
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.
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.
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
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!
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".
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!
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 👍
One more important difference was the the screens we had back in those days. An old CRT TV with it's analogue rendering and fuzzy image were more forgiving to the blocky graphics. Some of my old loved games from the C64 are close to unplayable when tried on a modern screen, instead of understanding what to do there are just random blocks... Oh and perhaps ones imagination were better in those days.
The two pass where the first pass connects nearby nodes after extending them a bit sounds like a good way to solve most issues. I didn't quite get while the white (I guess canvas) shows even after that. I know you're not exactly doing a two pass here though. I'd totally play the remizee version
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)
Great stuff. 🙂 I always absolutely *loved* KQ3, HQ1 (later, Q4G1), and Q4G2 & 3. Also, ya can't go wrong with "The Dig" and "Full Throttle" (Lucasarts). But once KQ6 hit the scene, I think what was most impressive to me was the new attention to progressing the storytelling in a far more complicated way, the much better music, and the voiceover work.
It would probably look weird in gameplay, but as a standalone, these remixes (well chosen term there) look pretty cool 😎 Also, as a first time viewer of this channel, that fish in the beginning threw me off guard 😂
This is great. I loved the KQ franchise. I remember seeing an article on AGI in some magazine - perhaps Dr. Dobb’s Journal? - and I was intrigued and wanted to have access to it.
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.
this is great video thanks! ive wondered how space quest was made graphically for years now. just never got around to looking and this popped into my feed. lol
Amazing work. And even having grown up on these games, honestly, I kind of dig the new look. It looks like it was drawn in marker, which is a pretty unique aesthetic. If anything, I wonder how it would look if everything was a bit chonkier to play up that aspect.
Nice. I seem to recall one Sierra emulator (or ScummVM maybe) experimented with this, and posted a few screenshots, but encountered some of the same problems as you. I thought about this problem for a while. I theorised the best way to do it was to do everything at low resolution, but to try and “reshape” the pixels by adjusting the normally square boundaries between them. You’d start out with all the pixels as a grid of squares with uniform horizontal/vertical boundaries. But then when a diagonal line goes through a pixel, you reshape the boundary so that it matches the angle of the line. The boundary should be reshaped in such a way that as the line continues through neighbouring pixels, the boundary follows continuously. (Flood fills don’t affect the boundaries at all, but because the resolution of the pixels themselves is unchanged, they work as they should.) Once you’re done, you just render all the pixels, at whatever resolution you like, but with their new boundaries.
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)
the flood-fill problem: shouldn't you be able to detect when two lines end in what would be neighboring pixels in the original, and thus not only do the flood-fill correctly, but also automatically connect those two lines, so that they're connected properly even in the upscaled version?
I was thinking the same. When plotting a line, if next pixel extending the end touches same color, then extend that line until merging the other line. Problem is the other line can be a "past" (already drawn) but also a "future" (yet to draw). Maybe not that easy to implement. I think something like of the "extend two lines straight until they meet" command in autocad. But it's more complicate than that. I already see where it wouldn't work
@@ideegeniali "Problem is the other line can be a "past" (already drawn) but also a "future" (yet to draw). Maybe not that easy to implement." Not a problem at all, the time order is irrelevant, because any time you draw any line you check both its ends against existing ones. Meaning whichever line is "next" time-wise, will close/join to the path. The time order is irrelevant. All you do is just store a 2d array of the original resolution where each cell instead of being a pixel is a list of references to lines which have either endpoint in that cell/on that pixel. Every time any new line has any endpoint in the same pixel as another line of that same color, you just add an extra line of that color between those two low-res pixels, causing an extra line connecting endpoints of those two lines in the upscaled image. Some tweaking of draw order of that extra line might be necessary, so that it draws at an appropriate time so as not to interrupt some other-colored lines going through that spot later, but I might be willing to bet even that won't be necessary.
Another approach might be to just massage the original vector instructions. Knowing what the finished scene looks like at 160×200, if you see that two lines are intended to meet, but they are coded to terminate in adjacent pixels, just alter the endpoint of one line in the instructions, so that they'll intersect exactly at any resolution.
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!"
Thanks for sharing.
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?
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.
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.
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.
I'm still not sure whether or not I hallucinated a screaming fish partway through the video
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.
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.
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.
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. th-cam.com/video/v5DSFvWrNWA/w-d-xo.html
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.
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.
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.
This is my first time on your channel, and your intro logo is the best thing I've ever seen.
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 :)
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.
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.
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
I appreciate you including Manhunter: New York, and Manhunter: San Francisco. Absolutely loved those two games.
This is incredible, gives me very strong Retro Game Mechanics vibes, especially the super clear visuals! Look forward to seeing more from you! :)
The quality of this video is fantastic. Very entertaining and informative.
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.
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
For me the beauty lies not within what comes out, but rather in how it works.
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.
damn 6 years and you return, welcome back
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 video. Came across your video and loved the way you explained everything properly without going too deep. Great pacing, too!
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.
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.
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!
I loved playing those games as a kid. Still my favourites all-time.
Oh My God! That's incredible! Please keep up the good work.
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.
So Cool!! Thank you for the love and care you showed these classic games!
I love the level of detail you go into describing what your code does.
Fantastic video; well spoken, lovely relaxing voice; clear technical information and a pay off at the end.
Thank you TH-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.
This was really neat man, would love more of this.
I was more than happy to discover this video from the "Discourse guy". Awesome.
That's cool. I really wanted to see some gameplay with the higher res tbh, but really cool work
Would love to see more experiments along these lines! Subscribed in the hopes of seeing more.
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.
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.
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
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
Love this stuff mate - bring on more content for sure! 😊
Love the work you put into this mate; well done!
I really like the techniques you've employed. Looking forward to seeing more
This explains so much on how and why the games render the way they do. Thank you.
This is amazing. Using these as the bases of style transfer will be beautiful
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.
subscribed purely because of the trout intro. LEGENDARY
You upscaled images look like simple drawings by a competent artist as preliminary work, it is pleasant to look at.
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!
Dude, your intro is awesome!
That had to be the most wtf opening animation/channel intro... I loved it haha!
this is really awesome as a fan of the old sierra games... definitely hoping to see more videos like this
This is a fantastic way to return after a 6 year hiatus.
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".
Great, fun and informative video. Keep up the good work!
I like that after 7 years you still posted
very nice, your vector upscaler is really good! I like the output.
more videos like this would be awesome. subbed!
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!
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 👍
What a fun video and project! Thanks!
Awesome work. I wish they will bring these games back
One more important difference was the the screens we had back in those days. An old CRT TV with it's analogue rendering and fuzzy image were more forgiving to the blocky graphics.
Some of my old loved games from the C64 are close to unplayable when tried on a modern screen, instead of understanding what to do there are just random blocks...
Oh and perhaps ones imagination were better in those days.
Agreed. A good artist would use the medium to their advantage, whether it was the the graphics or the sound generator.
Very interesting video, especially for a Sierra fan like myself. Thanks for sharing!
Thank you! Lots of code you did before upscaled gfx. I am impressed as I am Dinosaur from that time 👍
Awesome dude. I’m glad to see this progress.
Ok that channel animation won me over. Take the subscription lol
The two pass where the first pass connects nearby nodes after extending them a bit sounds like a good way to solve most issues. I didn't quite get while the white (I guess canvas) shows even after that. I know you're not exactly doing a two pass here though. I'd totally play the remizee version
I'd love to see more videos like this. Definitely subscribed!
Your evil trout intro got me to subscribe! :)
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)
Great stuff. 🙂 I always absolutely *loved* KQ3, HQ1 (later, Q4G1), and Q4G2 & 3. Also, ya can't go wrong with "The Dig" and "Full Throttle" (Lucasarts). But once KQ6 hit the scene, I think what was most impressive to me was the new attention to progressing the storytelling in a far more complicated way, the much better music, and the voiceover work.
I've always wondered this, thanks so much!
Thanks for the technical explanation! VERY easy to understand
It would probably look weird in gameplay, but as a standalone, these remixes (well chosen term there) look pretty cool 😎
Also, as a first time viewer of this channel, that fish in the beginning threw me off guard 😂
Really love the result. It keep the pixel art aesthetic but high res.
This is great. I loved the KQ franchise. I remember seeing an article on AGI in some magazine - perhaps Dr. Dobb’s Journal? - and I was intrigued and wanted to have access to it.
love your results - you did very well
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.
Brings me back to the 4th grade...
Fond memories getting done with homework and loading up kings quest, or space quest
Very cool technique! It's fun seeing these images "remastered". Keep it up!
Fascinating! Than you for this great presentation
this is great video thanks! ive wondered how space quest was made graphically for years now. just never got around to looking and this popped into my feed. lol
Amazing work. And even having grown up on these games, honestly, I kind of dig the new look. It looks like it was drawn in marker, which is a pretty unique aesthetic. If anything, I wonder how it would look if everything was a bit chonkier to play up that aspect.
Nice. I seem to recall one Sierra emulator (or ScummVM maybe) experimented with this, and posted a few screenshots, but encountered some of the same problems as you.
I thought about this problem for a while. I theorised the best way to do it was to do everything at low resolution, but to try and “reshape” the pixels by adjusting the normally square boundaries between them.
You’d start out with all the pixels as a grid of squares with uniform horizontal/vertical boundaries. But then when a diagonal line goes through a pixel, you reshape the boundary so that it matches the angle of the line.
The boundary should be reshaped in such a way that as the line continues through neighbouring pixels, the boundary follows continuously.
(Flood fills don’t affect the boundaries at all, but because the resolution of the pixels themselves is unchanged, they work as they should.)
Once you’re done, you just render all the pixels, at whatever resolution you like, but with their new boundaries.
Great explanation and methods to upscale!
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)
really interesting video and great effort with your upscaling. Makes me want to give it a go myself not that I think I have the patience.
Would love to see you cover how King's Quest, and like, dealt with depth and interactions with objects on the screen.
the flood-fill problem: shouldn't you be able to detect when two lines end in what would be neighboring pixels in the original, and thus not only do the flood-fill correctly, but also automatically connect those two lines, so that they're connected properly even in the upscaled version?
I was thinking the same. When plotting a line, if next pixel extending the end touches same color, then extend that line until merging the other line. Problem is the other line can be a "past" (already drawn) but also a "future" (yet to draw). Maybe not that easy to implement. I think something like of the "extend two lines straight until they meet" command in autocad. But it's more complicate than that. I already see where it wouldn't work
@@ideegeniali
"Problem is the other line can be a "past" (already drawn) but also a "future" (yet to draw). Maybe not that easy to implement."
Not a problem at all, the time order is irrelevant, because any time you draw any line you check both its ends against existing ones. Meaning whichever line is "next" time-wise, will close/join to the path. The time order is irrelevant. All you do is just store a 2d array of the original resolution where each cell instead of being a pixel is a list of references to lines which have either endpoint in that cell/on that pixel. Every time any new line has any endpoint in the same pixel as another line of that same color, you just add an extra line of that color between those two low-res pixels, causing an extra line connecting endpoints of those two lines in the upscaled image.
Some tweaking of draw order of that extra line might be necessary, so that it draws at an appropriate time so as not to interrupt some other-colored lines going through that spot later, but I might be willing to bet even that won't be necessary.
Another approach might be to just massage the original vector instructions. Knowing what the finished scene looks like at 160×200, if you see that two lines are intended to meet, but they are coded to terminate in adjacent pixels, just alter the endpoint of one line in the instructions, so that they'll intersect exactly at any resolution.
Fantastic idea and video! You got them look pretty good!