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.

@manco828

5 ай бұрын

👏👏👏

@ee1518

3 ай бұрын

Why 160x200 instead of 320x200? Why newer 320x200 with 16 colors Sierra games run so much slower and required a faster CPU?

@cb-gz1vl

3 ай бұрын

@@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.

@TheGreatUndergroundEmpire

27 күн бұрын

Hey, thank you very much for contributing to my favorite things of all time. I became an amateur point and click creator because of you all. You’re rock stars in my book. 🙏

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.

@HansLemurson

2 жыл бұрын

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.

@dubbynelson

2 жыл бұрын

@@HansLemurson neither of us wanted that but thanks anyway

@AlphaGarg

2 жыл бұрын

I love the "or something" at the end there

@Walczyk

2 жыл бұрын

It wouldn't be amateur, this art would be incredible if done in flash

@Echo81Rumple83

2 жыл бұрын

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?

@jones1618

2 жыл бұрын

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.

@johnnyw525

2 жыл бұрын

That is great

@kevinwallace5050

2 жыл бұрын

@@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.

@NicholasBrakespear

2 жыл бұрын

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.

@InsaneFirebat

2 жыл бұрын

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.

@trublgrl

2 жыл бұрын

​@@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.

@trublgrl

2 жыл бұрын

Why didn't you tell me this when I was a kid? I found those games infuriating.

@magnuskallas

2 жыл бұрын

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)

@eatwhaturgiven

2 жыл бұрын

I love keeping the Sierra magic alive :)

@SchlossRitter

2 жыл бұрын

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.

@psycthom

2 жыл бұрын

@@SchlossRitter Really hoping so and Quest for Glory

@paulmuaddib451

2 жыл бұрын

So many classics, it's no wonder, really.

@jamessparkman6604

2 жыл бұрын

You ever heard of the term de obsoletion well it’s a kind of a process of becoming obsolete in reverse

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.

@root42

2 жыл бұрын

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.

@elbiggus

2 жыл бұрын

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.

@root42

2 жыл бұрын

@@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.

@elbiggus

2 жыл бұрын

@@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.

@timseguine2

2 жыл бұрын

@@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.

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

2 жыл бұрын

Thanks for the clarification! That’s very informative.

@greggv8

2 жыл бұрын

@@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.

@rashidisw

2 жыл бұрын

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.

@flatfingertuning727

2 жыл бұрын

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.

@cb-gz1vl

2 жыл бұрын

Yes when we went to 320x200 we made a driver that scaled for CGA mode.

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.

@HabadzaKalfa

2 жыл бұрын

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.

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 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!

@b213videoz

2 жыл бұрын

yeah... with blocky pixels as blocky gets 🤣 (ZX-SPECTRUM had far sharper graphics back in the day of 1984-1985)

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.

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.

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.

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!

@todesziege

2 жыл бұрын

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.

@tylisirn

2 жыл бұрын

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. kzread.info/dash/bejne/qGl4taivh9W0h6Q.html

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.

I appreciate you including Manhunter: New York, and Manhunter: San Francisco. Absolutely loved those two 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.

@eviltrout

2 жыл бұрын

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!

@dave7038

2 жыл бұрын

@@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.

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.

@redmage777

2 жыл бұрын

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.

This is my first time on your channel, and your intro logo is the best thing I've ever seen.

The quality of this video is fantastic. Very entertaining and informative.

Brings me back to the 4th grade... Fond memories getting done with homework and loading up kings quest, or space quest

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 loved playing those games as a kid. Still my favourites all-time.

For me the beauty lies not within what comes out, but rather in how it works.

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!

@eviltrout

2 жыл бұрын

I know, right?

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.

@eviltrout

2 жыл бұрын

I think that would be super tough based on the flood filling of various areas but maybe it could be done.

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 :)

@eviltrout

2 жыл бұрын

Thanks! It was a bunch of work but I had fun doing it.

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!

@eviltrout

2 жыл бұрын

Thanks! I spent quite a while learning blender for that :)

You upscaled images look like simple drawings by a competent artist as preliminary work, it is pleasant to look at.

That's cool. I really wanted to see some gameplay with the higher res tbh, but really cool work

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.

damn 6 years and you return, welcome back

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!

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.

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!

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.

@eviltrout

2 жыл бұрын

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 :)

@NIMPAK1

2 жыл бұрын

@@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.

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".

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.

@markusr353

2 жыл бұрын

Agreed. A good artist would use the medium to their advantage, whether it was the the graphics or the sound generator.

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.

Shout out to Roberta and Ken Williams for creating what revolutionized graphical gameplay for that time.

This is amazing. Using these as the bases of style transfer will be beautiful

Those upscaled pictures are really pretty. It really does make me appreciate the beauty of them and the reason those graphics were so praised.

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)

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.

If you want to find something fascinating, check out how AGI did sprite reflections. There is a table that maps a sprite's direction (0-8) to a list of cells for animation, with some flags like if the animation should be mirrored horizontally. So walking left or right could be the same animations, just mirrored. Now for the interesting part: to save memory, the sprite animations are stored RLE encoded... and are never expanded in memory. The drawing routines use the RLE directly. So if a sprite is mirrored, there is a routine that will take a sprite and horizontally mirror the RLE data directly inplace over the old sprite data. If the sprite is then unmirrored, the same routine horizontally mirrors the RLE data back to the original.

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.

@anon_y_mousse

2 жыл бұрын

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.

@todesziege

2 жыл бұрын

@@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.

@anon_y_mousse

2 жыл бұрын

@@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?

So that's why each frame was drawn then colored. I just thought is was for the "Story Book" effect.

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.

Sierra and the Quest games were AMAZING so many memories

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.

So now I finally begin to understand - after about 35 years or so - why the graphics of Melbourne House adventures such as Castle of Terror and The Hobbit (on c64) had those quirky fill gaps. Thanks!

I love the level of detail you go into describing what your code does.

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.

Awesome work. I wish they will bring these games back

integrating this kind of upscaling into scummvm would be amazing!

This game was my life back in the 1980s. Rocking it on my PC Jr.

this is really awesome as a fan of the old sierra games... definitely hoping to see more videos like this

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

I'm still not sure whether or not I hallucinated a screaming fish partway through the video

This is a fantastic way to return after a 6 year hiatus.

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

This was really neat man, would love more of this.

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

very nice, your vector upscaler is really good! I like the output.

I've always wondered this, thanks so much!

Great, fun and informative video. Keep up the good work!

What a fun video and project! Thanks!

Love this stuff mate - bring on more content for sure! 😊

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!

more videos like this would be awesome. subbed!

subscribed purely because of the trout intro. LEGENDARY

I really like the techniques you've employed. Looking forward to seeing more

Very cool technique! It's fun seeing these images "remastered". Keep it up!

Dude, your intro is awesome!

Very interesting video, especially for a Sierra fan like myself. Thanks for sharing!

I had a suspicion the 160x200 was hiding things like gaps and it wouldn't work directly. I guess if it had been composed at higher resolutions there would be less upscale problems, they had some PC88 vector graphic games in 640x200 iirc. Thanks for doing this and making a video about it, this extreme compression technique that made single disk adventures possible is quite overlooked now. :)

This explains so much on how and why the games render the way they do. Thank you.

I like that after 7 years you still posted

It's amazing that you came back after 6 years of silence.

@eviltrout

2 жыл бұрын

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)

Would love to see more experiments along these lines! Subscribed in the hopes of seeing more.

Would love to see you cover how King's Quest, and like, dealt with depth and interactions with objects on the screen.

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.

@eviltrout

2 жыл бұрын

Check out my code if you get some time because I try to do this with varying levels of success.

How to fix this: Keep a data structure for all endpoints. When adding any new line, search the radius around the line's endpoint for any previous endpoints within the distance of a definable "error level". If any points are found, connect the line to the closest one that is found within error level, regardless of color. The error level radius should be ~0.99x the virtual size of what the EGA pixel would be. This can be improved further by using 2 passes. On the first pass, draw all the lines normally in memory. On the second pass, search for all endpoints that are within the error-level distance from eachother, then create a new virtual point that is the average of those points, then re-draw the whole scene by only connecting to virtual endpoints.

That had to be the most wtf opening animation/channel intro... I loved it haha!

Sierra On-Line was the only game company I ever applied to. It was back in like '93 or '94, I think. They faxed me a test. I had like an hour to write some assembly routines. My assembly was mediocre, but apparently good enough for a face-to-face interview. They offered to fly me out to the West coast for an interview, but as I did more research, I decided I wasn't interested and so declined the face-to-face. They had some cool games, though.

Awesome dude. I’m glad to see this progress.

Cool job, wouldn't mind if you shared more before/after comparisons of scenes.

Makes me think back to old NES games like Wizardry or Castlevania SotN sprites and character portraits. Where they added colors or pixels specifically to account for the CRT screen.

Fascinating! Than you for this great presentation

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.

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

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 👍

Great effort! Something I don't see being mentioned is how curves are treated. It would be nice if some lines were converted into curves.

I remember when I was a kid and played the old Siera games I would call all of them Siera because that was the big splash screen before the game :D

how loud the sine wave greensleeves was compared to your narration was definitely evil, mr trout.

Your evil trout intro got me to subscribe! :)