Voxel Space: Comanche's terrain rendering in less than 20 lines of code (2020)

It's really nice when something sells itself in being written in less than X lines of code and it's actually nice/simple code rather than weirdly abbreviated/overly dense stuff.

Don't remember the details but when I was coding on Outcast, the voxel engine was quite sophisticated there. Many optimisations were done to avoid multplications, divisions, use MIP maps, improvce CPU pipelining, etc. So although you can do something in 20 lines of code, there's much more to do to achieve a decent frame rate on old computers... But nice demo anyway (and for proper credits, I didn't write the voxel engine of Outcast, I was sitting in the same room of the dude who optimized it, and he was really good at that... fond memories !)

(2017), not (2020), see <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15772065" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15772065</a>

In the Comanche GIF, the viewport tilts when the aircraft turns. Is anything special going on here, or is it simply a rotation of the projection? If it&#x27;s just a rotation, what extra work does the engine need to do to fill in any gaps from the lines that will no longer be neatly aligned to pixels, like they would be when it&#x27;s flat?

The web demo was a lot of fun on my iPhone. I’m always frustrated by a lack of good arcade flying games with somewhere realistic pitch, roll and yaw controls. Everything feels like driving a car rather than flying.

I remember this game, the graphics were amazing, but the enemies were deterministic, i.e. if you restart a mission, the enemy copter always came from the same angle at the exact x seconds&#x2F;minutes after the start.

I don&#x27;t think in Comanche they painted back to front, or at least I hope they didn&#x27;t. It&#x27;s best to render front to back, tracking the highest (in screen space) pixel you have drawn, and as you move further back, only drawing lines from that height. That &quot;max height&quot; is a zbuffer of sorts for each ray. [edit: I just read further down and they mention this]<p>Also, you want to render each ray&#x2F;vertical screen line one at a time, rather than running each single step of the ray for all rays&#x2F;vertical lines.<p>Once you are rendering each ray at once, it&#x27;s easy to do a circular rather than flat projection, which feels a lot more stable when you rotate and admits higher fields of view without distortion.

NovaLogic’s voxel work was really something else at the time, it was even partially used for their Delta Force games which is how they could have such huge maps and extremely long terrain draw distances in an era when games had to fog everything a short distance away from the camera or box you into corridors in order not to have to draw so many polygons.<p>This was released in 1999&#x2F;2000 <a href="https:&#x2F;&#x2F;youtu.be&#x2F;kxkSM6_F39g" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;kxkSM6_F39g</a><p>Sadly voxel hardware acceleration was never really a thing and in the early 2000’s GPUs started leapfrogging a head of CPUs so much that you basically had to switch to polygons to get any decent performance.

The helicopter game about the helicopter that never was† :-)<p>† In mass production.

Novalogic patent... That is probably also used on the F-22 lighting 2. The game could run comfortably on a pentium mmx at 200mhz. But I can&#x27;t understand how transformations other than rotation on the vertical axis can be performed.<p>Edit: Small analysis on some screenshots... Mountains on the horizon look very polygonal on F-22. I&#x27;m not sure it uses the same technology.

Great funny project!<p>But I can&#x27;t get a local copy to run. I am not a web developer. Could anybody help me?<p>I cloned it from Github. But it doesn&#x27;t seem to load the height maps from disk. What makes sense because websites are not allowed to access files, right?

This is a very compelling result considering the lack of complexity.<p>I wonder how far you could take this with some additional layers on top of height map and color.

I suspect this could be done in reverse, for a profitable speedup.<p>So that is to say, by following the painter&#x27;s algorithm (far to close), we draw a lot of pixels over and over again. If the closer terrain is rendered first (reverse painter&#x27;s algorithm), fewer pixels have to be filled for the farther terrain. In some cases, none at all.<p>The basic premise is this: an element of the color&#x2F;height map which is farther from the viewer will never occlude an element which is closer, regardless of its relative height, and regardless of the perspective projection. The elements of the map are colored, vertical columns. A column farther from the viewer cannot occlude a closer column.<p>Suppose our task is to render exactly two arbitrary elements into an empty frame buffer. We can confidently render the closer one first, and then render the farther one, painting the &quot;pillar&quot; from top to bottom, until we are about to hit a pixel which has already been colored. All those early breaks out of the column-painting loops can be expected show a marked speedup.<p>I&#x27;d be surprised if the 1992 game didn&#x27;t do it that way; they were squeezing every cycle they could get out of 386 and 486 boxes.

Ah I remember when it came out, it was very impressive. It needed a very hefty 486 if I remember well, so I couldn&#x27;t play it.<p>Years later, when I got a more powerful box, I tried playing it again, but the game speed was proportional to cpu speed I think so it was unplayable...<p>I should give it another go in dosbox!

I remember buying Comanche again years after it was released. But it was unplayable. The fuel depletion rate was somehow proportional to CPU speed, so on my (relatively) faster computer, the helicopter would run out of gas just a couple minutes into the level.

Very interesting. Does anyone know if Magic Carpet by Bullfrog used a similar technique for rendering its terrain?

I think that the code could make one change to get rid of the additional height array. It just needs to flip the nested loops. Walk along the height field for each vertical line on the screen (2d line walk through the height field image) and keep track of the projected height at each step. Draw only the the difference between the previous projected height and the new projected height if the later is higher.

It&#x27;s even better than that flight sim that was embedded in Excel

I loved this game and played it a lot as a kid.

20 lines of code is a lie though

I recall it also used 386 protected mode as you had to boot it from floppy, which was probably the first for a commercial game.<p>This and F15 were amazing games of the time. I bought the full thrustmaster setup for these.