Voxel Space

Looking back even further, games like Koronis Rift did a lot with much less. Still, both are impressive and brilliant.

Technically this is not related to voxels ("volumetric pixels", so to say), which split the 3D space equally along all three axes. This is just a height map, a set of prisms, not entirely unlike a Doom map. Every prism has a regular fixed-size square base.

For 1992, this was mind-boggling though.

Off topic: The very first assignment in this game is called “oil tank holiday”: fly the chopper to unguarded oil tanks, shoot and watch them burn, and then fly home. No enemies. Just learn to fly and shoot.

I apply this in testing code. After you write some code, try to think of the absolute minimal test to prove that your code does anything at all without crashing. These are my “oil tank holiday” tests. It is always humbling to see those fail.

Is this the same algo used for Magic Carpet (1994)? The style looks very familiar, and I always wondered how they pulled it off.

https://en.wikipedia.org/wiki/Magic_Carpet_(video_game)

Reading Voxel always takes me back, way back.. I played Comanche for hours and read up on Voxel tech in various magazines of the day; so clever and easy to implement. Nice demo and thanks for the trip down memory lane.

Was this also how the flight sim that used to be hidden in EXEL.EXE had been built, I wonder.

When this was first posted I made a game with a port of this approach to AGS Engine. Nowadays AGS is much faster since we have improved a lot of things, but this wasn’t the case at the time, so I had to make a few little tricks to make the rendering work well with the engine at the time.

https://github.com/ericoporto/i_rented_a_boat

First thing that comes to my mind is the procedural generation in Rescue on Fractalus! (Behind Jaggi Lines) 1984 by LucasFilm Games which blew my mind on Atari 6502.

It's interesting that the color maps seem to have shadows "built in", so that you get a 3D bevel effect from just looking at the color map.

Previous discussion (2017): https://news.ycombinator.com/item?id=15772065

This sure brings back memories.

I remember figuring all this out as a self-taught teenager (pre-internet) with some books, a whole lot of time, and only a high-school level understanding of trigonometry. I built different versions - first in Pascal, then C, then Assembly.

Figuring out the algorithm was hard, but one of the optimizations I was most proud of was inventing (or so I thought) lookup tables to get around the slow floating point multiplication of my 16MHz 80286 CPU. I also remember "inventing" (ha!) the old bit shift + add technique.

There was something immensely satisfying about squeezing every last drop of performance out of a machine.

Nothing ever came of it. It was more or less a demo, but man did it make me feel like I accomplished something magical. I'd give anything to have a look at that source code today, but this post is the next best thing. So thanks for sharing. This made my day.

[Edit] ah ok they clarify later as a performance enhancement. I think it was pretty integral to the algorithm, but ok.

Wait why do they say painter's algorithm. Comanche and other such voxel terrain engines went front to back and never had overdraw.

I remember how groundbreaking Comanche was. Now I learned that it was a result of the programmer's experience in the medical industry (CT/MRI scanning): https://en.wikipedia.org/wiki/Voxel_Space

Obligatory link to mars.com: https://chaos.if.uj.edu.pl/~wojtek/MARS.COM/

If you render columns instead of rows you can render near-to-far without a Y-buffer and with zero overdraw. :)

[dead]

[dead]

I really love this kind of articles, so much to learn.