I oftentimes don't know if asking for screenshots is appropriate as I have no idea what's the software is about; so, whenever there are screenshots, I get a sense of relief.
I also remember 'mars.com', that I guess I found on some bbs, which was basically just the terrain renderer you could roam about in a very basic heightmap that was coloured to resemble mars. I think I saw that before comanche, and it was fast on fairly mediocre pc back then.
I don't know if it is just me and the appeal to the stuff I grew up with, but I find the style of the visual artefacts a lot more appealing than in many more modern rendering techniques. Perhaps it is just the simplicity of it.
For anyone wondering what he means by /fast/. mars.com ran at 30+ fps on a 12MHZ 286 with a slow VGA video card. I still remember being impressed by how smooth it was. It was fast fast fast.
> I find the style of the visual artefacts a lot more appealing than in many more modern rendering techniques. Perhaps it is just the simplicity of it
Looking at the visual artefacts in question, it appears that the big chunks of pixels (the ones closer to the POV) are not regularly aligned on screen, but rather disseminated around, which I guess improves the render quite a bit by giving it a somewhat "fuzzier", more organic look.
Maybe this irregularity is a side effect of the algorithm itself, and not something done on purpose?
mars.exe has only a size of 5.6kB. When you disassemble the code you realize that most of the code consists of just massive loop unrolling. It would have fitted in 2kB easily.
I don't know why you get that message. The content is set to 'public'. I just tested it on another computer, without login into Facebook, and it worked fine.
I wonder at the speed of this on a modern machine vs an assembly version running in dos on a 1992 machine. A benchmark of interpreted code on a modern OS + machine vs bare metal native code written in the 1992 style on an old machine would be interesting.
I remember when Comanche came out... the 1990s were like the Heyday of flight sim games and Comanche was mind-blowing at the time as a teen. They were my favorite by far type of game. At some point it feels like they really died out. There were a lot of games that had a happy medium of fun vs realistic/complex back then.
At some point the # of flight sim type games plummeted and the ones that stuck around bifurcated into hyper-realistic to the point they are a time suck (cause you could be using an actual real flight sim for real flight training) or they are hopelessly unrealistic and no fun compared to the old stuff.
Not sure but I might disagree with the author about Comanche being 3 years ahead of it's time. It might have been closer to 5 years ahead of it's time. You didn't get stuff that really blew it away till hardware acceleration became prevalent, but by that time 3D FPS games were demolishing the flight sim market.
Didn't they just?
Microprose and Digital Integration in particular were the masters back then for this stuff - I remember the Project Stealth Fighter (C64, ZX Spectrum in around 1987) and then the Tornado (PC) manuals with particular fondness, covering laser guided toss bombing and all sorts of stuff.
I'm amazed to discover that Tornado has gone open source and is still being modded by people: http://www.moodurian.com/
Those cycles enable much higher level operations. Still tons of wasted effort, but hopefully development time for the same complexity is significantly reduced.
I think you just proved the point.
If we didn't have this high level, easy-to-produce abstraction... you wouldn't have even heard of slack and electron.
Yet it enabled people to create something a lot of people use :)
There were many (and much better IMO) instant message multiplatform apps before Electron.
The problem isn’t JavaScript, which these days is remarkably fast. It’s that every app loads almost an entire OS in order to run. Process isolation, layout engine, text rendering, 2D/3D graphics, audio…
GPU cycles are what is precious now. The idea that we basically run a whole program on each pixel, on 4K displays, at 60fps nowadays is just mindboggling.
At that time I was in high school, trying to figure out with some friends how to render things in my Turbo Pascal program. At the time we did not have internet, so we were left to figure out how these techniques worked.
We knew how to project things in 3D and rotation worked well, but rendering more than a few points would bring the CPU to a halt. At one point we read about texturing, but there again, how could the huge levels of Wolfenstein 3d be rendered on modest CPUs? Surely it was not drawing all the sorted triangles over each other each frame? There was not enough resources for that!
Then one of us had internet access, printed two pages that explained raycasting. "Ohhhhh! That's how! rendering per column!"
And yes, Comanche was very highly regarded by people interested in 3D rendering. It was said to be coded entirely in assembly (was it true?) which to me at the time felt really impressive.
The Comanche terrain as depicted (I never played the game) reminds me very much of VistaPro, which (as I look it up) came out in 1991. But that wasn't interactive...
> At some point the # of flight sim type games plummeted and the ones that stuck around bifurcated into hyper-realistic to the point they are a time suck (cause you could be using an actual real flight sim for real flight training) or they are hopelessly unrealistic and no fun compared to the old stuff.
The following info might be of interest:
The company behind Digital Combat Simulator (DCS World), which is the hardest of hard core military flight Sims, recently announced Modern Air Combat (MAC) which I believe is aiming for the level of fun vs realism you mentioned.
"Over the past year, a massive amount of work has gone into Modern Air Combat in order to make it a AAA title. During this period, we have also expanded the scope and features of the product substantially. This has led to us push back its release date to 2020.
Modern Air Combat will not be a DCS World product, but rather a new series for us that focuses more on action, gameplay, and a shallowing learning curve."
When I was working on Return to Dark Castle about 10 years ago, I did some tests with fast-ish Macs from that time. We were drawing the game in 16 bit color in RAM as layers of 32x32 pixel tiles and then uploading the resulting PixMap to the GPU as a texture (long story, that was due to starting work on the game in the 90s before OS X even came out). That ran several hundred fps even then. I did some other tests setting each pixel of a 640x480x32 bit buffer in RAM to a random color and then uploading that as a texture, and I believe I got over 1,000 fps on my mid 2011 2.3 GHz i5 Mac Mini with a 1333 MHz DDR3 bus. I feel like it uploaded at 2,000 or 4,000 fps if I didn't change any pixels in RAM, but am not positive. That's with an Intel Graphics 3000, not even a real video card.
Ok 1333 MHz DDR3 runs at 10,600 MB/s. A 640x480 32 bit color image takes up 640 * 480 * 4 = 1.17 MB. So the mini should get just over 9,000 fps with perfectly optimized code. I’m not sure if it’s possible to get there through OpenGL though, without direct access to the metal.
We just don’t see this kind of speed today in practice because it's really easy to fall off the fast path with renderers like OpenGL and not realize it. So people get used to always thinking in terms of 60 or 120 or 240 fps and don't even realize that memory busses and video cards are orders of magnitude faster than that. Figure roughly a factor of 4 slower for hand-rolled blitter innermost loops, and we're probably looking at rendering Comanche at between 1,000 and 10,000 fps on a typical i7 computer today.
All of this is why I was never really fond of the direction that 3D rendering went after video cards arrived around 1997. Shaders are cool and everything (even though they took 10 years to go mainstream), but it's a very specialized discipline and my brain is too old to keep up with it all now. I'd much rather have a multicore CPU with a wide bus (or better yet, multiple narrow busses) and no cache, where the GPU is ordinary RAM, and write blitters by hand. With 100,000 fps we could do some pretty wild stuff with voxels.
I've completely given up on all that though, as the world went a different direction. It will keep doubling down on the branch it's on (SIMD with specialized and proprietary shaders running through Unity or Unreal) and completely ignore the rest of the tree of possibilities like ray tracing and ray casting. Which is fine. But this is probably why my heart fell out of game programming, to be completely honest.
I did build a gaming PC with an NVIDIA GeForce RTX 2070 video card, but have yet to play around with the ray tracing stuff.
In another universe, span buffering (s-buffering) would have been a fast way to render scenes as strips of scan lines. I'm having trouble finding the original article, but maybe these will help:
A bit of self-promo, but for those interested I also am using a variation of this algorithm powered by compute shaders. See https://twitter.com/voxelquest. If you scroll down a bit, you can even see versions using the maps from Comanche shown in this demo. :)
(Also, thank you @s-macke, your github page taught me the fundamentals of the algorithm - previously I had only seen Ken Silverman's post on wave surfing, which was not nearly as clear).
The 20 lines mentioned in the headline refer to the render algorithm itself, not including all the code for map loading, input handling, line drawing and html/css. Basically the lines 51 to 71 in your code.
Sure, my code is only a demonstration that you can fit everything in <100 lines. I remember that there were some sceptics in older HN discussions on this topic... :)
Again, thank you very much for all your education reverse engineering works!
There were also tricks to extend this simple rendering algorithm to allow limited rotations around the other two axes, to look up / down slightly (just move everything up / down; also implemented in the demo here) and to "lean" when steering left / right (just move everything up / down proportional to the distance from the center of the screen; not implemented in the demo here, but visible in the 1992 NovaLogic Comanche example GIF).
There were Turbo Pascal versions of this on websites in the 90s I think, but it seems they were lost.
Indeed, look up / down is very simple implemented. Just alter the horizon line position. This works for the human eye for small deviations such as ±20°, but will lead to perspective distortions for higher angles.
> There were Turbo Pascal versions of this on websites in the 90s I think, but it seems they were lost.
You can still find a lot of this old code if you dig for it; lot's of it can be found on various SIMTEL MS-DOS ftp archive sites, for instance. I also think the textfiles site has some of it. Also archive.org might have some of it.
Take a look around using google and such: "ftp msdos source code" etc - you'll find plenty to be sure (and even if you don't find what you're looking for, you're sure to find stuff you weren't expecting!)
A short article titled "Voxel Landscapes 2D and 3D By Scout/C-Lous" described most of the tricks, but I can't find the text anywhere. A similar article by the same author on another topic I found here https://github.com/ggnkua/Atari_ST_Sources/blob/master/Docs/...
@s-macke very cool article, it brings me back. :) Thanks for the write up.
Regarding speeding it up & drawing front-to-back, didn’t some games do a back-to-front with some kind of bounds on how far down they draw? That way you get speed up without needing the y-buffer memory. I remember that in some games you could sometimes see cracks in the terrain, and I’m guessing from my faded memory that it was bounding the vertical draw. Not entirely sure if I’m remembering seeing cracks in sprite-drawn terrain though.
I was also wondering about the “Rotation” animated gif example, some extra mountains show up on the right side in the 360 spin for a couple of frames while the camera is passing the far end of the river, just before the pyramid comes into view. Is that just a bug, or is it something about the algorithm that’s tricky to fix?
> That way you get speed up without needing the y-buffer memory.
I mean, the "Y-buffer" memory is just one integer per column, pretty trivial even for a software rasterizer on an early 90s machine with a limited cache hierarchy. Pretty much any algorithm that has overdraw will lose to that. That's why this technique was so popular in the nineties—what Doom did was just a generalization of this idea to allow multiple sparse pixel spans per column instead of just one. (For comparison, Z-buffer bandwidth is expensive because it's an extra 16/24/32 bits per pixel, which can double your fill rate requirements.)
Oh yeah, you’re totally right, please chalk that up to pre-coffee brain fart, I wasn’t thinking about the size and stupidly assumed it was on the same order as z-buffer.
Indeed, switching the loops is valid and might or might not give you an additional speedup. I had hoped, that someone figures this out :-).
However I think in order to understand the basic algorithm the way in the readme is the better one.
Do you know of referenceable pseudocode (or real code) for that somewhere? I've tried modifying your code to switch the loops, but it always comes out garbled; clearly I'm messing up somewhere in the refactoring process, but I don't have enough experience with this algorithm to figure out where!
Such good points and so obvious (now that you said them) that first I really want to retract my comment and second now I feel like coding up a terrain generator today. Duh, Doom did (famously) switch the loops for similar reasons!
The rotation artifacts you see are a result of the very simple algorithm and the property of the viewing triangle. It renders objects that are farther away when they are near the border of the viewing screen.
In the pseudo code in the readme just calculate the (square) distance between pleft and p and don't draw the line if the distance is larger than a given threshold. But this is not very efficient.
When you switch the loops this will be easier because this check can be done in the outer loop.
But I would suggest to experiment with some fog effect first.
Turns out it can be made quite efficient with a little effort put into arithmetic power reduction. In the outer loop, it is possible to calculate a `dr` value from the existing `dx` and `dy`. Then you just increment the radius traveled at the same time as `px` and `py`, and replace the inner loop condition that puts a bound on `z` with a new condition that puts a bound on the radius.
That fixes the rotation artifacts, and then makes it really easy to add a distance-based fog effect to hide the cut-off where new terrain comes into view as well.
This was a very pleasant read and brought back fond memories of the days of Novalogic Commanche and the followup Commanche 3D, which was one of my favoured network games back in the day - many a Friday afternoon spent blasting co-workers out of the sky ..
Voxels are a pretty neat graphics technology. For the fans of such style, Voxatron (from Lexaloffle, the PICO8 crew) is a pretty great environment for experimenting with the subject - its a fun game, but also a neat design/experimentation environment as well... https://www.lexaloffle.com/voxatron.php
Also brought to mind Vista and VistaPro scenery generation / terrain rendering programs. Used to play with them a lot to produce pictures. Terragen is the only program I know of in that space these days.
This is the first thing that came to mind for me too! I loved VistaPro so much. I got a copy in one of those old programming books you used to buy with the CDs. It also came with PolyRay and some old-school VRML tutorials.
I had VistaPro with the Mars maps on my Amiga 2000 and 1200 back in the early 90s; I should dig those machines out someday (no idea if the floppies still work, tho - I have tons of Fred Fish stuff, too)...
Same. I find it amazing about how much can be achieved with so little. Even more so now that games require computing power that rivals the supercomputers humans had when these games were released.
Another World (Out Of This World) featured a couple of days ago hightlights this also, imho.
And fun, I had plenty while playing these games. Increasing computing power improves immersion and realism, which certainly improves the entertainment; but the fun? Not obvious to me.
Comanche 4 is one of the first games my dad bought me and I loved it a lot. After years of playing it, I was disappointed to learn then that the actual Comanche helicopter program was cancelled.
Anyways, it seems new Comanche game is on the way!
Brings back memories of playing Novalogic Comanche with a Logitech WingMan Extreme. It was an amazing experience at the time. That game was really far ahead of its time.
I really like the animations that illustrate how the algorithms render the final result.
Is that a gameport or USB device? Looks like there are a bunch of adapters out there which will allow legacy gameport sticks/pads to represent themselves as modern xinput controllers.
This is the kind of 3d engines I was making as a teen. The way it works is that you iterate over x screen-space, get a "ray"/"slice", then you iterate over z camera-space (goes inward) using that ray. From there, you have what it takes to sample a heightmap. Draw a vertical line. There is plenty of room for optimizations and it's very good for learning to code.
It seems like this code would be fairly easy to add to a simple 2.5D raycaster (either a cube variant like the old Wolfenstein, or something more advanced like Doom/Doom 2) to give some variation (or more "natural" stuff) for indoor/"outdoor" scenes.
It really isn't much different from floor/ceiling rendering code.
Something else I was thinking was if you flipped it upside down (and kept the current view), you could render "caves"; heck, it probably wouldn't take much effort to mod the current code to achieve this.
Somewhere I have code to a voxel rendering engine someone made in QBasic; they posted a demo of it on youtube, but never posted the code - I got in contact with them, and they sent me a copy of the code. The interesting thing they did, though, was add voxel rendering of "buildings" - you could easily go inside spaces and outside, all voxel rendered, and it was fast (for QB code).
Note - I know about Ken Silverman's voxel and other 3D engines he did in QB (and posted his old code), prior to Duke Nukem 3D - but this wasn't that code; it was completely original...
Anyhow - this is a great little "3D" engine; I'm glad it was posted!
I was just wondering what other metrics are there for code other than 'lines of code'
Cus I could write some stuff in one line of code. But that one line would be horrendously unmaintainable.
What metrics are there for maintainability (the most important aspect of code imo)
If there was a hard measure you could put on granularity for example.. Instead of saying hey I wrote this in 10 lines, you'd say hey I wrote this with 90 fleeborps of granularity! its super-maintainable!
ps. Not meant as a sly criticism of this. I have not even looked at the code. Just the 'lines of code' in the title sparked that thought. This thing is awesome! Just a few days ago I was chcking out Commanche Maximum overkill videos.. in 1992 that was mindblowing!
Fantastic description of how voxel rendering works with a really great illustration, I had no idea it was that "simple". I remember the Comanche game mentioned in the README, it was amzaing graphically for the time!
The way the slices render in the image examples reminded me of TerraGen and setting my computer to render a simple animation overnight while I slept, and hoping it didn't crash.
I remember playing with TerraGen back when the original programmer of it was coding it in VB5 and 6 - it was so amazing to see back then, it's too bad the VB source code wasn't ever released.
Ever since I played Comanche, I've been asking myself the same thing. I guess they had some real elevation maps and pictures as a base and then made manual changes to add periodicity and color. A half-manual and half-algorithmic approach.
How many more lines do you need if you want to capture the natural “roughness”, but you also want to guarantee some plateaus, such a for building on in a simulation game?
Or, to put that another way: what does the code in Sim City 2000’s terrain generator look like? Because it’s almost just doing this, but then it has that one extra thing...
Sim City is 2000 is isometric, it doesn't have perspective. You just need to overlay 2d bitmaps of the prerendered tiles and assets on top, drawn back to front, bottom to top.
I recently implemented the painters algorithm in a modern-ish way: using atomic ops in a compute shader. That's one of the rendering techniques for the terrain in https://github.com/kvark/vange-rs
I was confused by this too. Clicking and dragging with the mouse (or at least touchpad) works for navigation. The HTML canvas element key events aren't working (maybe they worked . in older browsers). There is an open PR that hooks window events instead (I made similar edits locally that make it work). https://github.com/s-macke/VoxelSpace/pull/13. The distance rendering works once you move and force a redraw.
All these “X in less than Y lines of code” efforts strike me as fundamentally misguided because they seem to confuse succinct notation (short code) with efficient computation. To whit: there’s absolutely nothing preventing anybody whipping together a de facto DSL wherein one can call a single render_terrain( ) function and get the task done with a single token, particularly in today’s environment of dime-a-dozen new programming languages.
Since the article is written in a generic programming language, not a DSL, and has the math derivation and notes on performance, maybe you got confused about what this is? It’s not code golf, it’s demonstrating that this algorithm for terrain rendering is fundamentally expressable in a small amount of code.
> To whit: there’s absolutely nothing preventing anybody whipping together a de facto DSL
That’s true, but that’s not what happened here, the author did not write a DSL, so this is not a valid example of your first sentence. As such, your phrase ‘to whit’ is misused, the phrase is synonymous with ‘specifically’. Also just FYI it’s spelled ‘to wit’.
> All these “X in less than Y lines of code” efforts strike me as fundamentally misguided because they seem to confuse succinct notation (short code) with efficient computation.
I've never seen any comment about any of them which confused the brevity for computational efficiency, so I don't think that's an issue at all, and don't know where you got that idea.
> To whit: there’s absolutely nothing preventing anybody whipping together a de facto DSL wherein one can call a single render_terrain( ) function and get the task done with a single token
Sure, but they don't, because that's usually not interesting. Leveraging and demonstrating ways to do a task with small amounts of code using tools that are available but flexible enough that they can be applied to other tasks or variations of the task that are not identical, OTOH, is interesting and useful, and tends to be what people do in these things.
I think any piece of code falls on a spectrum, somewhere between "software engineering" (efficient, well documented, etc) and "art" (interesting to look at in some way, someone had fun making it, etc).
The two ends of the spectrum serve completely different purposes but I think both deserve to be appreciated! Just for different reasons. This post (IMO) veers pretty close to the "art" side of the spectrum, so it doesn't make much sense to talk about its efficiency.
> To whit: there’s absolutely nothing preventing anybody whipping together a de facto DSL wherein one can call a single render_terrain( ) function and get the task done with a single token
Yeah they could. But it's not a competition and would anybody care if they did?
I don’t think anyone is saying they are particularly computationally efficient. It’s just an extra limitation to make the process of writing the code more fun. It’s just for entertainment.
Downvotes always feel pretty harsh, but it helped me a lot to realize that downvotes are usually impersonal. Think about downvotes as symmetric with upvotes; upvotes don’t need justification, and they are given for a wide variety of reasons. Same with downvotes.
In any case, I find it best to start by assuming not that people are getting rubbed the wrong way, but that I actually wrote something incorrect and didn’t know it. The primary reason downvotes are given is for information that is either incorrect or irrelevant to the thread. Without passing judgement or being upset, it is safe to say your top comment is incorrect about this article, and thus irrelevant here.
I realize that justifying downvotes or continuing to talk on a thread that’s gone south doesn’t necessarily make you feel any better, but I honestly hope that helps. These things have helped me in the past.
I didn’t mean to come across as ‘complaing’ about downvotes, just as I didn’t mean to offend anybody with my comment (which admittedly was rather generic and probably not a specific response to the posted article, rather something I’d been meaning to get off my chest for a while).
I just hope I didn’t come across as dismissive, because that wasn’t my intention.
People weren't offended by your comment, it was just ignorant. 8 of these 20 lines are comments, so it is not code golf, just a very simple algorithm that anyone can read and understand. If you wish to not get down voted in the future you should probably try to read and understand things before commenting.
Thanks for your feedback, I think my comment history can stand as testament to the fact that broadly speaking I generally know what I’m talking about.
As for your charge of ignorance, that’s your call to make, but you seem to be missing the point I was trying to make (and which I obviously articulated very poorly), namely that code length and complexity is an interaction between both the algorithm being encoded and the formalism into which it is being encoded (programming language).
Code length correlates with complexity if you don't go out of your way to game it, so it is still a valid way to say "this renderer is really simple and cool!".
