The fluidity of the scrolling in Commander Keen 4-6 was unmatched on PC for years, even as games moved to 256-color graphics. Between Carmack's incredible technical work and Adrian Carmack's [1] art, Id had perhaps the best-looking PC platformer well into the 1990s.
[1] No relation to the more famous Carmack, but IMO the unsung master of the 16-color palette.
I'm intensely weirded out to see that all of the classic Commander Keen games were developed-and-released between December 1990 and December 1991. That is a wild pace of graphical and gameplay development.
The joke at the time was that if your machine was more than 6 months old it was obsolete. So many aspects of computers were developing at a breakneck pace it was almost impossible to keep up.
Yeah, I had a pretty new PC (my first one after heavy-heartedly switching from the beloved Amiga to the despised PC) when Doom was released, and all my friends would come over to play because it could run it full screen (older 386 and weaker 486 CPUs were not fast enough, so you had to reduce the size of the game screen and play with an ugly static border around it). Then just a few years later I installed the Quake demo and all I got to see was an error message. The PC had a pretty exotic IBM "Blue Lightning" CPU which was a "486SX3", i.e. it ran at 75 MHz internally, 25 MHz externally, and didn't have a built-in FPU - which was a requirement for Quake. So I realized it was time to upgrade to a Pentium CPU...
But also, only a few years after Wolf3D we got Toy Story in 1995, the first major CGI full feature film. Six years later in 2001 we got The Spirits Within, the first attempted full-feature photorealistic film (it hasn't aged well and it bankrupted the company at a cost of $137 million at the time). And now we live in an age where realtime graphics look better than pre-rendered CGI films from 20 years ago... which also includes Lord of the Rings come to think of it.
For comparison, a little over a month from now will be GTA 5's 10 year anniversary, and GTA 6 is still nonexistent. Who thinks the technology leap between 5 and 6 will be anything remotely like the difference between Wolf3D and Quake 3?
And somehow they managed this incredible pace of software development without modern tools like git, or probably any kind of revision control system even (RCS/CVS/ClearCase were available on Unix systems, but in the DOS world I don't think there was anything).
>> And somehow they managed this incredible pace of software development without modern tools like git, or probably any kind of revision control system even...
It's not that hard when one guy is writing the rendering code, another doing game logic, one doing artwork, one level design, and one doing sound. Nobody is really stepping on anyone's toes.
Yes, that keeps people from stepping on each others' toes, but revision control systems are really useful even for a single developer working alone, just to track changes, make changes to try something out and be able to revert easily, etc. You can do all that of course by making a bunch of ".bak files by hand, but a modern revision control system makes it much easier.
Carmack talked about how they released those first games on the Lex Friedman podcast. Having a previous framework and pipeline seemed to help get them out really quick.
Great book so far BTW. Man, Romero had an interesting/rough childhood, that's for sure.
The crazy part was also working 2 full time jobs essentially, 8 hours at softdisk then they would use those PCs at night for 8 hours to crank out their private games, also borrowing them on the weekends to get more work done.
I understand that they could work 16 hours a day, but I wouldn’t believe they can separate two businesses like that. I would have told the same thing though.
I think I'd pick Prince Of Persia, not to diminish Commander Keen a single bit but I always found PoP visuals and game dynamics unmatched for its time. I'm also getting biased for two reasons: I played PoP when I believe I was 7 years old and made a magic impression on me when I first played it and is also is my favourite platformer of all times. But of course PoP lacks of the scrolling at all which is Commander Keen's black magic.
There is a magic about the character movements in PoP. I recently replayed it—almost 30 years after I first played it. There is a fluidity in how the prince moves that is still impressive today.
On a tangent, Mechner is an incredibly talented (and in my opinion, severely underrated) game designer. "The Last Express" is a masterpiece, and wondrous in a different way.
> There is a fluidity in how the prince moves that is still impressive today.
Yes it is very impressive even today. Those tons of hours on rotoscoping paid off immensely. I haven't played "The Last Express" though I've seen some screenshots and looks a very nice game. Somehow the artwork resembles the style of Alphonse Mucha: https://en.wikipedia.org/wiki/Alphonse_Mucha
I'd say PoP is bland and stale in comparison, but that's probably because there's lots of animations going on in the background for Keen. And it is faster paced. I enjoyed PoP2 better compared to PoP. It had grander visuals, epic escape and puzzle scenes.
I think it might be hindsight, but a lot of these ‘revolutional’ developments seem kind of simple compared to a lot current development.
“Our memory is slow, so let’s redraw only things that changed” is kind of a given nowadays.
Still the optimization in 4-6 is fun. Did the whole thing in 1-3 just because of an assumption that the buffer would not wrap around, and then it did and all that work became obsolete.
Games have redrawn everything on every frame for decades, certainly since GPUs became a thing. Memory speed is definitely not a concern. 2D windowing systems used to only redraw "dirty rectangles" but that changed when they moved to GPU compositing as well.
On the other hand, of course, CPUs do have a complex system of several levels of caches, but that's not primarily because of (lack of) memory bandwidth but memory latency.
> 2D windowing systems used to only redraw "dirty rectangles" but that changed when they moved to GPU compositing as well.
For Win32 and X11 at least the damaged region (or "invalid region") approach is still there and AFAIK recently (as in a few months ago) the modesetting driver for Xorg added the ability to use the damage regions when "TearFree" is enabled (this does server-side composition to avoid tearing - it is disabled by default) to only update the of the screen that changed instead of the entire screen.
Also i remember reading some time ago about some monitors being able to use partial frame data (the monitor "shadows" the frame) so that they can support faster updates.
I think the concept can also help with slow display tech like e-ink devices.
More like after shaders became a thing, and it hardly matters when it is an application runnning on the GPU that is responsible for actually drawing.
However it is still an issue if one wants to achive maximum performance, and it is done by only sending the vertices and textures to the GPU that are actually going to be visible.
> “Our memory is slow, so let’s redraw only things that changed” is kind of a given nowadays.
Tangentially related: Android still doesn't get this. Turn on the screen refresh flashes in the developer menu and then look a your static screen and be amazed who often android draws even though nothing changed.
This is nonsense, Android always did "this". It always rerendered only damaged regions and even after switching to HW accelerated rendering, it still only rerenders changed views.
And the animation framework always just "scrolled" the view (or screen) when it could.
With modern gpu pipeline and cost of cache misses compared to CPU cycle being what they are - it's almost certainly faster to redraw a few thousand sprites no matter what than to check what changed and redraw only a subset of them.
Is there another way? I've only done WebGL, so not familiar with Vulkan/Metal/DirectX/etc. - but in my experience you're clearing the screen and re-drawing everything every tick no matter what. If only for applying post-processing effects.
Updating buffers is of course a totally separate thing, and on that side I don't think anyone updates everything every tick, usually there's some sort of scene graph that knows about dirty transforms and their children, so only those get updated..
If I recall correctly, the original Macintosh would go as far as telling the software which regions of a window had to be redrawn at any given time so the idea itself wasn't exactly new. The thing is that these optimizations required tradeoffs. Figuring out which tiles had to be updated required storing extra data and doing extra computations. Not only did you have to recognize the value of these techniques, you actually had to write the code in a way that did not slow things down (and design the levels so they would not slow things down).
They needed the same info to do clipping (on both the Mac and Windows).
I think it is more interesting that the pipeline was invalidaterect/region => getevent => event was a draw event => draw region (or part of it). The getevent would only generate draw events if nothing more important was going (keyboard/mouse input, timer, message from other app/desktop accessory). It would also prioritize top windows first so you would only get a draw event for a window at the bottom once the windows above had no more dirty areas.
If you really knew what you were doing, you could short circuit this a bit and draw in your windows outside of draw event handling.
“Our memory is fast, so let us redraw everything” is a given. Our web APIs on the other hand are incredibly slow, so let us carefully track changes in a complicated runtime (or compiler) to avoid redundantly modifying properties in a tree.
>I think it might be hindsight, but a lot of these ‘revolutional’ developments seem kind of simple compared to a lot current development.
Yes, it's you and your vaulted position of standing on the shoulders of those to whom these developments actually were ‘revolutional’. I equate the level of accomplishments from Id to be at the level of cavemen throwing rocks at the spaceship to cavemen buying insurance on TV levels of achievement.
When I developed a text-mode UI library (not using curses) with a friend in university for fun, we tested this on his actual terminal connected via serial cable. You'll notice unnecessary redraws very quickly that way. (Granted, piping the output through some throttling may have had the same effect, but there was something about writing modern code (even as students) and seeing it work on decades-old hardware :).)
In 320x200 or 320x240 VGA, you could had essentially the same trick for scrolling window over the VRAM, checkout Mode X VGA. The Allegro library had baked-in support for that, at least in the early 2000's.
Ha... look at that. Not bad at all! I wonder how many machines at the time could power through that? ;)
Talking about these little tile and scrolling tricks. Golden Axe on the Master System had to get around the sprite size limit by having the entirety of the graphics live on the background layer. This meant everything sat and moved in an 8x8 pixel grid. A neat little hack even if it made the whole thing a little chunky.
Not an original PC game, but the PC port of Caveman Ninja, VGA and also from 1991, was amazing. Smooth parallax scroll with tons of sprites in screen. It recently got a remake on Steam.
I remember writing a tile-based game for Window98 using DirectX 5. I originally implemented something similar to what is described in this article. My case was not as complex because the screen didn't scroll but large numbers of tiles could potentially need redrawing.
I ended up ripping out all of that code because when I tried to profile the cost of drawing the whole screen with my RIVA TnT card I literally couldn't measure the tiny amount of time it took.
I am glad I missed the EGA period of PC development, I never would have gotten anything done.
I was the opposite, I loved programming so low level, optimising using bitshifts instead of multiplications, writing essential code in assembly, writing 16 or 32 bits at a time (as processors developed).
Continuously learning from the scarce resources I had (books from the local library and a floppy disk with txt files).
I was too young (mid teens) / unexperienced to get anything finished but did manage smooth vertical scrolling and almost got the horizontal stuff working, double buffering a rotating 3D cube (z buffering, math, line by line polygon drawing).
Then came DirectX and you lost all touch with the machine, a rotating 3D cube was breeze, I didn't see the fun in that.
If you ignore the GPU acceleration APIs and try programming graphics the old fashioned way but on modern multi-core & SIMD machines, you can more or less still have a very similar rewarding experience.
Sure it won't compete with the performance of GPUs, but I feel like we should have a category of GPU-less PC graphics for things like the demo scene. Where you strive to deliver interesting results at modern resolutions but hamstrung by CPU-only, incentivizing exploring parallelization techniques, SIMD optimization that strongly resembles assembly coding of yesteryear, and good old fashioned cleverness.
* 'Many'-core CPU (say 8..16 relatively simple cores, eg. RISC-V)
* A good, but modest amount of RAM (eg. few dozen... few hundred MB)
* Integrated graphics, but of a conceptually simple type, eg. a plain framebuffer + _maybe_ some blitter / DMA / scrolling / hw sprite support. Simple enough that a single programmer can wrap their head around it (vs. complex 3D GPU where hardly anyone knows all its details).
* Graphics outputting to common consumer display (HDMI, DisplayPort)
* Sound & some other common I/O
Roughly Commodore Amiga level complexity (at most! simpler = better), just modern fabrication tech & faster.
This would be perfect platform for all sorts of homebrew games, hobby / retro style OSes, educational, industrial uses & more.
But doesn't exist afaik. Microcontroller usually don't have built-in graphics, too little RAM, or otherwise aren't quite it.
A step up (small SBC) and you get loooaads of peripherals, 3D GPU, firmware & associated complexity thrown in 'for free'. Nice for running full blown OS like Linux, not so nice for wrapping one's head around that hardware.
Allwinner F133
Bouffalo Lab BL808
GreenWaves GAP8
(no native video hw on this one I think? targeted at IoT edge computing)
Surely there are more (or will be :-). Problem is usually availability of suitable boards, documentation, software tools, or some combination thereof.
And these are often one-off parts. At some point it goes away, and then what to do? As opposed to being sort-of-standard platform offered by multipe vendors that one could code software ecosystem against (like for eg. Raspberry Pi).
You could of course design your own hardware. But then you quickly get into FPGA territory, design-your-own-computer project, lower clock rates, higher cost, etc. Cheap, small, highly integrated SoC much preferred here.
Maybe the Colour Maximite 2 would be interesting to both of you (don't have any personal experience with it but found it rather nice once I heard about it).
I like the idea of software rasterization as an aesthetic (in the context of games, but demos are included). Caches are larger than the system memory of the pre-GPU days. Best of all, if you can write a plot function you’re a graphics programmer!
I ended up working on software rendering (ray tracing) for film production for many years. Now I'm working for a hardware vendor, so I get to have fun with the machine way below the DirectX level.
That was a magical time to get into coding! The limitations of the hardware really made it worth learning low level wisdom.
I was trying to do similar things on a 486 with a slow supervga card. Without vga hardware scrolling tricks it couldn't even do 60fps of full redraws at 320x200 8 bit.
Even back then there was already a large gap widening between the slowest and fastest graphics cards. Between the bus widening from 8-bit > 16/32-bit, graphics cards supporting posted writes so the CPU wouldn't have to wait as much, and faster CPUs, fast systems could write a 640x480x256 screen at 300 fps or faster. In your case, you may have even either had a cached system memory buffer and DMA copy, or the drawing being done by a blitter. But even in the time of Win98, some 3D cards on the low end had really slow CPU access that barely beat an old ISA bus card.
Screen resolutions have gotten so high that there's a bit of a reversal again -- even if you can redraw an entire 4K screen at 60 fps, it's not exactly efficient. Games typically still redraw everything, but desktop compositors definitely do some optimizations, including dynamically assigning layers to hardware planes to reduce redrawn area.
I worked at a different game company in the same time frame and I invented the same technique as the second approach. I don't think it's that amazing - if you were working on it at the same time you probably would have come around to it. Just as we also made our own PWM audio driver to play sampled sounds through the PC speaker - so did everyone else it seems. The PC didn't get enough love before we were all on to the consoles. I get excited when I see demos like 8088 MPH by Hornet.
If the game went to release, would you mind sharing the title for comparison purposes? I agree most would come up with similar solutions, but I'm curious if the result feels the same to play.
On a fixed horizontal scroller idea for avoiding the full screen move / copy at the end is to amortize it while you are moving. So over many frames you build up the screen you need to reset to at the end.
> I don't think it's that amazing - if you were working on it at the same time you probably would have come around to it.
Then why there were so many 'top tier' scrolling platformers at the time that ran so choppy? While I don't think it's a hard requirement for a fun game, the level of smoothness Keen had (especially on low-end hardware like a <10MHz machine) was eye-opening at the time.
People often don't realise but it's not the invention itself which results in fame. It's the ability to commercialise and market it. There have undoubtedly been countless incredible inventions over the millennia. I myself "invented" LinkedIn a decade before it was a thing, but I never successfully commercialised it. I would estimate that most inventions were never widely known. This is why many startups begin with two people: an expert, and a business person.
So you're not wrong: this invention is perhaps nothing particularly special. What made it special was the combination of novelty, utility, and successful commercialisation.
In the excellent Masters of Doom it is explained that Keen was the Mario-like game (i.e. sideways scrolling). They offered the tech to Nintendo as an option to port Mario to the PC. Nintendo declined, thus Keen was born.
It was a vast leap for PC gaming and it opened an new era of PC gaming.
However, here is what I never quite understood, what was so different about the NES and PC tech that Nintendo had figured out to do sideways scrolling years before the PC?
EGA essentially gives you a big framebuffer. You can draw whatever arbitrary thing you want in EGA's graphics mode: lines, circles, individual pixels, whatever. That's what it's built for.
But you don't get scrolling for free. You've got to manually copy memory around and as the linked article points out, if you brute-force it you only get around 5fps because of the ISA bus' limited bandwidth.
The NES (and other 8/16bit) game systems are not built to let you draw arbitrary crap. They are built to render tiles. You define a grid of background tiles and provide a scroll offset. Sprites work similarly but they can move independently. You get all this for free at 60fps. The downside is that you can't render arbitrary stuff very easily. You have to jump through some serious hoops to e.g. paint an individual pixel somewhere.
It's not so much that Nintendo "figured it out" before IBM. IBM built a general-purpose computer and created a series of general-purpose graphics systems geared towards static graphics, giving you fine-grained control over every single pixel. If you look at an EGA card it's a beast; lots of silicon on there.
Nintendo on the other hand created a much simpler single-purpose graphics system geared toward sliding tiles around.
I recall playing this back in the day. It was super cool.
My Dad pulled it from the DEC internal file sharing service and brought it home. I long believed that it was a figment of my imagination until I heard that ID had developed a demo for Nintendo that must have gotten leaked
Wow amazing! I did not know this was available on YouTube. Thank you. It is kind of bonkers considering how well it works for a prototype that all-in-all (based on the comment by Lane Roathe) took just 48 hours to make!
I don't think it's 48h from scratch. Making the prototype for scrolling a tile map, a tile editor, etc might have taken more time. 48h sounds more like the time to capture sprites and slap them using already made tools/code.
Exactly this. Most consoles of the era were set up fundamentally to work with tightly defined graphical regimes. For the NES as an example, has almost zero ability to work with pixels or bits. It fundamentally at a hardware level deals with tiles. Sprite tiles are 8 by 8, or doublewide 8x16 if you put in some effort. You can build larger sprites by combining sprite tiles, but be careful because the hardware that processes this can only handle 8 sprites per scanline.
PC's have typically had a much more bitmapped graphical regime, where individual pixels are addressable and drawable, which better suits a general purpose computer but means you have to do some trickery if you want to get some of the polish that consoles had, and was typically slower since you didn't have dedicated hardware that spoke in those terms. on the flip side though setting up a windowing system on an NES with its hardware speaking in sprites and tiles would be a nightmare.
That is incredibly cool, but unless I'm mistaken it's not doing any windowing/arbitrary drawing. Everything is full screen, so elements can be plotted out in advance by the designer to work with sprite restrictions.
Essentially, yeah. You give it a list of pointers to background tiles and a list of pointers to sprites and tell it where you want them drawn. It then does that for you at 60fps for free.
The downside is that that's all it does. That's the whole graphics system. You can't like, paint an individual pixel.
(you can, if you treat each tile as a mini framebuffer, which is how something like the NES port of Elite is possible, but this is expensive and you only have a very small amount of processing time and a limited number of tiles)
The methods in the article emulate hardware-managed tiles (https://www.nesdev.org/wiki/PPU seems a good starting point for the NES) in software, using a frame buffer of independent pixels: the challenge is adapting a sideways scrolling game engine to look good in a completely different system's memory space and bandwidth limitations, not "figuring out how to do sideways scrolling" per se.
The Lex Friedman podcast with J. Carmack goes over all the major innovations in every game, really interesting episode, strongly advised if you have time (roughly 5 hours long)
I still rememner the time, when I knew almost every secret (or so I believed) in Commander Keen Goodbye Galaxy, and other pupils at school asking me to tell them secrets in levels they played after classes on a school computer.
Cool, but did you ever hear about and play BioMenace? Everyone always talks about Keen, but literally no one ever mentions BioMenace, which was built on the same engine as Keen. :(
BioMenace was on a computer of the parallel group (pupils were put into groups A, B, C, etc., who would have their classes separately). One of my best friends excelled at that game. I enjoyed watching him play it.
In hindsight, we were pretty lucky to have computers at that time at school. Even if old ones. Still have not found all of the games again on DOS game archives, that were on these machines.
I was always envious of the people with 1200 baud modems... I had a 300 without dialer so had to use a phone to dial the number, wait for the answer and flip a switch for the modem to take over :-)
I can understand how to scroll vertically by adjusting the frame buffer start by a scanline at a time, but it wasn't clear to me how scrolling horizontally would work without horribly shearing the framebuffer.
Now that I've thought about it a little more, I realised it's like painting a picture on the side of a cylinder. No matter where you draw the left-hand edge of the image, there's always a way to rotate the cylinder (set the CRTC_START and PEL registers) so you can see the whole thing clearly.
> I took the easy solution of when you finally did run to the edge of the screen I accepted a hitch and just copied the whole screen up.
I remember when Keen started up it would usually mention something about "VGA compatibility mode enabled", and I always wondered what that meant.
The Internet Archive's browser emulation is an excellent way to scratch a nostalgic itch over a lunch-break. If you'd like something a little more local, Commander Genius¹ is an open-source engine that plays all the Keen games (and apparently Cosmo's Cosmic Adventure, too).
I disagree. It was for kids who for some reason had access to a computer but not a Nintendo (computers cost 10x what a console costs back then, so it was usually due to strong opinions by adults about what kids should be doing). It is lacking soul compared to all the NES and Genesis games. I liked it at the time, but I recently tried it in DosBox and realized that it pales in comparison.
I think it just depended on your family's circumstances. My father was a mechanical engineer, so we naturally had a computer in the house for his work. As a child, I couldn't convince my family to splurge on a dedicated entertainment device, but it was trivial to get a hold of a copy of the shareware version of commander keen and install it on the computer.
Hopefully you still got to play a lot. I played at arcades, and at other kids' houses, and we rented an NES a couple times, including when I was recovering from getting my tonsils removed. I really liked Mario 1, Mario 3, Super Mario World, NBA Jam, Duck Hunt, Ninja Turtles on NES, Sonic, and some others I'm not thinking of right now.
I see online that there aren't a lot of negative reviews about Commander Keen (like you would find about bad movies), and I suppose it makes sense. I mean, it was still fun. I would put it below Mario 2 though, and Mario 2 was the one I would leave out of a list like the one above.
On the PC, there were a lot of great games too, but side scrolling was definitely something to play on a console.
Keen had item collecting, lots of verticality in the maps, and some backtracking IIRC. It seems like a better comparison to Metroid, than Mario.
Anyway, most games are not as good as Mario, it is a genre-defining series. I think it is not a great comparison—what does it tel you that I’m slower than Usain Bolt?
The later keen games are legitimately good platformers, even in comparison to some of the best of the genre at the time like Mario 3. The levels in keen games are enormous and way bigger than a NES could handle or even think of loading in its tiny RAM. I do agree the first few keen games are pretty luke warm compared to consoles.
I don't think they are nearly as good. Mario Bros 3 apparently inspired Keen, but Keen was always very slow-paced, because of the one-hit death system. You also needed to defeat enemies with a gun, which was less risky and fun than jumping on the head of enemies like in Mario. Ammo was also limited, which again rewarded slow and careful and boring gameplay. The slower gameplay did fit the few puzzles, but those also weren't too great. I didn't play Keen 6, but I assume it's about the same as 4 and 5.
Just à nitpick, consoles at that time didn't load levels to ram but rather the part of the level you're seeing. You could access rom as normal memory (rom banks considerations aside) so everything was already accessible (sometimes compressed)
You needed to store the state of the entire level, like what enemies are alive, what treasures have been collected, etc. and that turns into a non trivial amount of stuff to store in RAM (only about 2kb on the NES!) for large and complex levels. You can't store that stuff in ROM since it's changing as the player progresses. A PC at the time could guarantee 640k or more of RAM alone.
Like I said in another reply that's just for drawing tiles, but it has to store level state (what enemies are alive, where they're at, what items have been collected, etc.) in RAM and is severely limited to less than 2kb of data there. A DOS PC has 640kb to multiple megabytes of RAM--you can have thousands of enemies, items, etc. with tons of room to spare.
With a lot of the Apogee shareware stuff it was exactly like that, especially if you actually tried playing the registered version "other two episodes". Lots of levels that were filled up with stuff to collect and enemies to bop, but usually not a lot of experience design or specific tests of skill. Keen ranked better than average on this, especially the second trilogy.
Crystal Caves remains one that captivates people's attention though - it's very unassuming, no particularly strange gimmicks, but it has the right mix of stuff to be surprising and engaging. It even got a remaster on Steam.
I've never cared much for consoles due to their "walled garden" aspect (not user-programmable, locked down hw & sw).
PC, 80's/90's home computers: programming bits & pieces Lego style by oneself, exchanging software + knowledge with friends, exploring assembly code, coding straight to the metal & so on, is so much more rewarding + extends creativity / skillset for use later in life.
In comparison, game console is just 'dumb' appliance like a toaster or TV set top box: hit button, watch it do its 1 trick. ;-)
I implemented the second method a couple of years ago, but drawing even just the leading edge was very slow. I did it in C though and have never really mastered asm programming.
I've read it. It's a good read, I was a bit worried that there would be a ton of score settling but Romero is apparently a relentlessly positive guy. It's a bit redundant if you have read Masters of Doom unless you are interested in his (pretty damn miserable) childhood or what he's been up to after Ion Storm crashed and burned.
Surprisingly good read. Not because I thought John is going to wash dirty laundry, but you know, they went through some emotional things. His story is truly inspiring though. Very engrossing.
I always recommend "the Masters of Doom". Probably mostly accurate. Perhaps a bit exaggerated at times. But definitely a great story, and well written.
Yeah I read that and enjoyed it thoroughly. I know Jordan Mechner's journals making Prince of Persia and Karateka are supposed to be great too if people are into this type of thing, I haven't read them though:
Oh this is awesome. When I was a kid I really really attempted to write a Keen knock off (doctor who themed) on my 386 and it was ok although never really did enough level development to make it super playable. But TO THIS DAY, never knew how the heck they made it scroll so smoothly. I just ended up just jump scrolling. Figured it was some mad assembler skills, never imagined there was a hw register!
Did figure out the double buffering stuff on my own though ;)
Seems so obvious, learn something new everyday, even if it would have been more useful, say maybe ~30yrs ago ;)
Thanks, that's a shame they dropped the ball. I'd previously heard good things about Hostgator. The article was stellar as always. If you're interested in other EGA stuff, IBM made a demo called "Fantasy Land" in the mid-80s that has smooth 4-way scrolling and animated backgrounds (but it's character mode, not graphics mode): https://youtu.be/czfGt5iNuSQ?t=65
In the late 80's IBM came out with the PS/2 computer that had proprietary things like the MicroChannel bus that didn't catch on, but things like PS/2 ports that lived on for a long time.
When the early 90's were here, IBM was losing billions of dollars a year, companies like Dell and Compaq were selling more and more PC's while IBM continued to sell less and less. There were spinoffs and re-organizations, IBM still made some things like the MWave soundcard/modem, but they couldn't really compete with all the small startups making new peripherals and components. IBM was still manufacturing things in the USA, they were and old and slow and kludgy company...
IBM still “invent computer hardware” (e.g. POWER/PPC CPUs are still being developed) and have been doing it more or less ever since “computer hardware” as a concept was commercialized.
You’re probably aware that the PC itself is an IBM development, but once it because a generic platform they couldn’t turn a profit while having to compete with all the cheap clones (I.e. what we today simply call PCs).
So the second trick looks like how the background layers work on systems like NES/Master System/SNES/Genesis. Just update tiles outside of the visible range and just have the view window constantly looping around. Or am I missing something?
I mean to do that on EGA is very neat (well duh!) considering those consoles all have dedicated VPU's for this task. Just wanted to make sure I am understanding it correctly.
> The second Keen trilogy used a better trick -- just keep panning and redrawing the leading edge, letting the screen wrap around at the 64k aperture edge.
I mean, we were doing the wrap-around “trick” in 1981 on the BBC Micro - and I didn’t know it was a trick so much as in the manual. The Defender and Scramble clones on the beeb were super smooth.
The BBC Micro wraparound is designed in rather than being apparently some kind of unreliable poorly-defined accident. There's a specific bit of hardware that subtracts a specific amount if the address runs off the top of RAM, so the video memory (typically the top 10 KB or 20 KB of RAM) is effectively circular.
For single-buffered infinite scrolling, this is exactly what you want, and this is how the BBC Micro's 640 pixel wide bitmap mode scrolls nice and quickly (something you'd never manage otherwise with a 2 MHz CPU), and why there are a fair number of infinite 4-way scrolling games on the platform. It's a shame more platforms didn't have this kind of thing designed in.
Maybe it's explained in Doom Guy, but why does the author use "ATS" as the TLA for "Adaptive Tile Refresh"? I can't find any references other than this article.
Lemmings is a great game! If you haven't seen it yet, I stumbled upon a somewhat modern version / idea of Lemmings called Humanity. I've been playing it on PS5 but it's also on steam and probably others. https://store.steampowered.com/app/1581480/Humanity/
You play a spirit version of a Shiba Inu guiding humans to the exits.
[1] No relation to the more famous Carmack, but IMO the unsung master of the 16-color palette.