Terrain rendering algorithm in less than 20 lines of code

Couldn't agree more with you.

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.

Always amazes me this is overlooked, especially for graphical projects. Why leave it out, do they not want to show off what they made??

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

After seeing 'mars.com' I decided to write write a game using that terrain algorithm. I never finished the game, but here is a video of one of my tests: https://www.facebook.com/magoghm/videos/10153819968108735/Uz...

Here's a video of it in action, for those unfamiliar, the poster had also included a link to its location at Pouet https://youtu.be/_zSjpIyMt0k

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.

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 imagine it would be very sad, when you then realise how many wasted cycles our CPUs are doing versus those days.

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

In those days games came with hefty manuals. I particularly remember learning the rudiments of flying a helicopter from Gunship's manual.

You can see for yourself on this PDF, starting on page 38:

http://www.simwarrior.com/gunship/utilities/GSManUK.pdf

Edit: this is Comanche's manual:

http://www.starehry.eu/download/simulation/docs/Comanche-Man...

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.

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

https://www.digitalcombatsimulator.com/en/newsletters/newsle...

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.

https://frankdenneman.nl/2015/02/19/memory-deep-dive-memory-...

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:

https://www.gamedev.net/articles/programming/graphics/s-buff...

http://www.hugi.scene.org/online/coding/hugi%2016%20-%20co3d...

https://mikro.naprvyraz.sk/docs/Coding/2/SBUFF2.TXT

http://www.cs.uoi.gr/~fudos/sbuffer.pdf

I’m sure there are even better techniques now, but I haven’t followed them.

Aha, I've been following your main account but didn't know this one existed. Definitely impressive!

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.

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

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

Even drawing front-to-back you don't need the y-buffer, if you switch the loops: for x ... for y ...

Another trick I now remember was to interpolate the color values on such a y-segment, to reduce the pixelated look.

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.

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.

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.

i've had major Magic Carpet vibes.

Me too, I spent countless hours playing flight sims since the 48K days, including Comanche.

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!

Used a Logitech Wingman 3D... Win10 doesn't even recognize it as a device.

Low priority to find a current flight stick.

Also dwitter.net

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!

Terragen is still going strong but it's been about 15 years since I played with it.

I remember it taking about an hour per 800x600 frame, and then we got a new computer and it only took 3-4 minutes per frame.

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.

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.

Draw distance can be as high as you want, you just need a big enough map.

I'll have to check out some of the old issues, I thought it was more of an industry magazine and not covering algorithms or coding.

Archive.org has most (all?) issues in a collection: https://archive.org/details/game_developer_magazine

Same here. Does this only work with firefox? Edit - nope doesn't work at all. Same with the 'distance' slider.

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.

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.

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.

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

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

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

Judging by the downvotes I’ve really rubbed a lot of people up the wrong way.