I was a programmer on Space Quest and various other Sierra games. About 15 in all. This brings back memories especially on how we had to cram everything on a disc since each disc was profit. Also we had limited ram. Not even 640k. The characters were cell based animations done in a tool that let us set up animations and spacing and origin points. The 3d effect was a sorting plane effect. We had a tool that you could draw a poly around (like a tree) and designate its z depth. As the character walked toward the back his z dynamically changed. The editor also designated various poly trigger zones for events like exiting a room or starting an event. When we went to 256 color pics we still kept the vector tool for triggers and other effects. The language we used was an in house clone of Small talk using polish notation for math. So it was fairly object oriented and unique for the time since c didn't have object oriented (only pascal back then). One of the benefits of the room method of game play was that 10 programmers could do say 7 rooms each and not rely on anything else to complete those rooms other than art. So we didn't have to wait for a previous room to be completed. This allowed Roberta to play say a castle scene and make requested changes without having the rest of the game in place.
@@ee1518 Because we had to pic between cga 4 color and TGA 16 color. TGA didn't exist for everyone. And yeah TGA was way slower. And CGA had horrible palette options. The only palette with black also have that yucky purple.
@@cb-gz1vl "Well, Lookee here! If it ain't Mister Look-at-me-I'm-in-EGA! Whatsamatter, monochrome not good enough for you? What's dis? 16 colors all for one little bitmapped WIMP?! Whatta waste of EGA. Har, har!"
I think its neat that the final results look like 00s amateur Flash Games. It makes sense, its all vectors. It makes you appriciate how Kings Quest and edgy stick figure games are part of a shared history. Or something.
If you want to feel old, realize that there's about as much time between Now and those classic Flash games, as there was between those and King's Quest.
I did a similar thing for The Quill at some point back in the 90s, and I had a *much* simpler method for dealing with flood fills. I'd draw both the low-res and high-res versions of lines, and whenever there was a flood fill I'd create a low-res scratch buffer, do the fill on the low-res version and duplicate the filled pixels on the scratch buffer, then do the flood fill in high-res; before plotting each high-res pixel I'd convert the high-res coordinates into their low-res equivalents (including the fractional part) and check the scratch buffer - if the point was less than about 1.5 low-res pixels from a filled point I'd draw the high-res pixel, but if it was more than that distance away I'd treat it as a boundary. This both prevented leaks and did a pretty good job of ensuring all pixels were filled (very shallow angles tended to fare worst). Admittedly this was on the Amiga so "high-res" was only 640x512 and I'm not sure if the technique would work at today's resolutions, but I can't think of any specific reason it wouldn't beyond perhaps needing to tweak the distance check value?
This is a great approach. Basically, flood fill has two parts: The flood (that looks for adjacent areas to fill) and the fill which paints the pixels. It sounds like you changed the flood part to sense borders w/ wider radius of view so it wouldn't "leak" through mere pixel-sized holes in borders. I think another way, using the given vector lines would be to bridge gaps below a certain distance and then draw filled polygons made up of lines surrounding an area, drawing the filled polygons behind the lines to give the lines precedence.
@@jones1618 yeah that was pretty much my thought when i considered this; go through it in 2 passes, creating polygons from the flood fill commands, and then re-sequencing the vector layers.
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.
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!
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.
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.
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. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-v5DSFvWrNWA.html
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.
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.
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.
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.
The real secret here was that processing speed had advanced far enough ahead of common of data storage tech, that this would actually be a better use of resources.
It would be a pretty cool means of compressing data now. Convert everything to vector art so it takes up less space, then on the user's computer generate all the final textures and models again expanding into a giant multi-gigabyte mess. It would require some pretty sophisticated algorithmic exploration of the files, or they could try to track the artists as they make the artwork and simplify the vector data a bit.
@@anon_y_mousse There's been some experimental games that use procedurally generated textures to fit into extremely small file sizes. Not vectors, so not exactly the same, but a similar approach.
@@todesziege I'll have to look into that. Most I've seen anyone attempt was procedurally generated terrain and trees, which often look amazing and more real than what people can draw by hand. Would certainly make for a cool game engine. Set a few variables, pick a random seed and bam, a whole world in high def before your eyes. Did you ever see that German demo from like 20 years ago?
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!
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.
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.
You ask "Best graphics" - Honestly - Minecraft. Hear me out. I get pushing live computing to the maximum is a significant task. I acknowledge the difficulties and obstacles. But graphics to me, is art. Like game development itself; an artform. Minecraft to me is like Picasso. I think we can always make things complicated and difficult. But to make something simple, and give it so much value, as Minecraft did. I've seen many many simple games like Minecraft; none of which seem to hit that sweet spot of game feel. I just think, Minecraft is so underestimated when you say graphics. Because in the end, it's really not about how compute intensive it is, but how it makes us feel. I can easily just do `while(true)` for a pixel and it's the most computational pixel in existence. However! Let's be real. There's quite a feat in making astonishing visual graphics. Fourth dimensions or mimicking the real world. A lot of hard work goes into these abstract but yet "simple" concepts. So yes. I think Minecraft comes on top, in terms of graphics. Not necessarily topping in visual art style. There I think Metal Gear Solid V is probably one of my favourites.
We had some clever people around those days. Coming up with completely new and novel ways of doing things, like storing drawing commands instead of bitmaps to save space. These days too much is already handed to the developer, almost like these are the confines within which you need to work. If you want to come up with something completely new, you need to write your own game engine, which very few people will tackle.
Very interesting work, I enjoyed and upvoted the video. I gotta say though, the only way to upscale these graphics is with nearest neighbor / hard edges. Everything else looks bad imo. I despise (hard word) when games use crappy algorithms like XBR, that being said, I think your method looks less bad. Thx for your 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.
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.
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 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
Very cool technical work here. But yes, the old pixelated art has a special quality to it; what gets lost in a lot of upscaling and remastering is that what you couldn't see by virtue of the low resolution was implied and enhanced by human perception. A low-resolution pixelated image is impressionistic - where an upscaled version with clean lines comes across as merely primitive. I think a logical final pass for a "remaster" of these visuals would be to actually add an extra filter that would reduce clarity somehow, to restore that hazy impressionistic vibe.
Great piece of work though yes, I'm very much of the opinion that the charm of the original graphics is the artists working with what they had, such that each pixel placement counts, and upscaling breaks that. Kind of like how that stupid soap opera mode on modern tv's does all this technological whizzbang to ultimately make a beautiful film look like a cheap soap opera.
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 was cool! I knew they weren't storing images (because back when I was trying to be a freelance game designer, I was using similar draw commands in my game attempts), and I figured it could scale up (since I was doing mine in a "high res" 480x360 [or some weird resolution like that, I forget the specifics, though it definitely wasn't 640x480 yet.]) But it was neat seeing it scaled up, and would love to see a workable, playable AGI engine like this, maybe to use with SCUMMVM or DOSBox.
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.
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
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.
Very well done. I appreciated how you refined your algo until satisfactory results. Reminds me of "another world" game: LoRes vector graphics. There the original author then published a HiRes version like 20 years later the original. Also reminds myself tinkering with commodore128 basic V7 drawing commands DRAW (straight lines) and PAINT (fill). I would sketch on squared paper, then transfer to a basic program, when i was 8 years old and enjoy my computer using it as an "etch a sketch" basically.
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.
If you play the games on an original PCjr/Tandy 1000 or an emulator set to replicate the slow speed of the 8088 you can really see the "painting" in action. I was always impressed by that as a kid (albeit less so when I had to backtrack across several screens and it had to load everything in every time.)
What if you did three render passes: first calculates the fill boundary lines, making them a bit longer on each end, and not actually drawing them. Then run the color fills. Then draw chunky lines at actual size. It would essentially look like your doing all the fills first, and putting the nice lines on top.
wouldn't there be edge cases where extending lines might create new regions? Say there is an horizontal line and two other lines that touch each other just below the horizontal one. They might be extended so as to create a new triangular region between the trhee lines
@@user-sl6gn1ss8p yeah probably, but you could easily turn the dial on that setting to find a sweet spot. Likely no solution will be 100%, but we can find a good tradeoff between effort vs how effective it is.
Can it also handle the final AGI games like Kings Quest IV and Leisure Suit Larry? Those really pushed it and had the best graphics (within the agi limitations obviously)
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
It's quite interesting how an upscale of such an old game can make it somewhat look worse. They give off a "drawing in paint" sort of feel when the original doesn't (perhaps due to it's pixelated nature).
If I was an artist of anything and I found out that after 30 years somebody does something with my work (even making it worse, but this was not that case), I would be happier than anybody :)
I didn't know Sierra's early games has vector graphics. Thanks for the info! Upscaled images looks bad as expected but I agree it worth trying just for curiosity.
Really fun! I just implemented a sierra style vector animation recently, great to see this technique was used before. Excellent video overall but just an fyi that intro music was a little extra loud. I tend to find digital or squarish tones sound louder than the waveform would have you believe.
They sound just as loud as the waveform would make you believe if you know that square waves have considerably more energy than sine waves. :-) And yeah, it busted out my ears, too. I had to turn the volume down when the music came on, even though the start of the video was at a comfortable level.
I love this. I do agree that the originals are art, and your work isn't really an "upgrade". But I love the project, and I had no idea these games used vector graphics. How cool is that?!
This was very cool. I wish it was longer and went into more detail, but consider me a subscriber. I can't help but wonder if some sort of edge detection would help you fill-in those open polygons....though you'd need to somehow categorize the edges into discreet objects....(don't ask me how! :) ) Now, you need to talk about how reluctant Sierra was to move to dithered 16-color graphics (because they couldn't compress them) and what their final solution was to be able to compress those dithered areas in the late- (but pre-VGA) era. I have my suspicions on how they would have approached it but I'd be super interested in any research you did on that!
Cool stuff! I'm currently working with SCI0 using vector graphics to make a game. Do your tools work for SCI0 or only AGI? It could be fun to see how some of my backgrounds look with this technique 🙂
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".
In 3D printing you have a similar problem. You need to "fill" the 3D object because in STL file you don't have the solid, but the surface enclosing the solid. You only have the triangles enclosing the solid and they may not precisely overlap. If there's a small gap you'd spill out and fill entire space. There's a piece of software, netfab, that repairs STL files prior to 3D print and guesses how to solve gaps caused by incomplete overlapping and closes those gap and saves a repaired STL files that has no such gaps. I wonder what algo netfab uses and if it can be modified for 2D instead of 3D
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.
Recent 2 player game it's in a Christmas type wonderland.. Called something like ? 2 of us ? Or similar but is the most beautiful game I have ever seen and it looks like a pixar movie ! GTARDR excellent but still not as pretty as the other
My fave graphics, as they let a child's mind fill in the blanks. It was a participatory experience when I was 12. Games now spoon feed every excruciating detail that it feels less a creative experience to play. I might just be being nostalgic though.
I think on source graphic data they used the trick to stay one pixel short instead of overlapping A LOT, to save precious plotting time by saving the time to plot an extra pixel twice each time. So it's a major problem to deal with and not a sporadic one.
Ages ago will wright of sim city/the sims commented about floppy to cd rom. He said "it went from how do we get everything we want to do in this tiny space (floppy). To how can we possibly fill up one of these things, it doesn't seem possible (cdrom).
You should reach out to Ken and Roberta. I'm sure they'd be very interested in this tech assuming they still have the rights to republish some of their classics (which might not be the case)
Hi, first of all. A cool video. I found it by chance/the algorithm. I learned much and I'm curious of "how old games are working" all time. I had another idea to fix the gap-problem, but I'm not sure if its working. This is a guess: I have not tried it by myself (yet): Clamp ALL the polygon vertices (line endpoints) to be exact multiples of your upscaling factor (the clamp algorithm needs to be deterministic). Means: If you scale the rendering resolution up by five, ALL rendering vertices need to be multiples of five (5, 10 ,150, whatever; but not 6,4, 11, 153 .. you'll get the point). In other words, a pixel can effectively move in multiples of 5, nothing different. This way, you kind of keep the original resolution, but for the actual rendering (bresenham algorithm, etc.), you take advantage of the higher resolition. The downside of this approach would be (in theory), that animations would not become "finer", they keep their blockyness.
