Re: Vaughn Cato's 3-D vector maze test from 1994

Andrew Ayers via Coco <[email protected]> Sun, 26 Apr 2026 02:13:56 -0700
Newsgroups gmane.comp.hardware.tandy.coco
Message-ID <[email protected]>
re: "He mentioned if it were a one thickness wall, you?d have to make 
two - one facing each side - else you could only see it from on 
direction. This was (back then) and is (right now) math that is way over 
my understanding."

---

Sounds like the points that make up the walls are used to compute the 
surface normal of the plane; this is detailed in many tutorials on 3D 
hidden surface removal. The points have to be defined in a particular 
"circular" order - that is, clockwise or counter-clockwise.

Then 3 of those points sequential can be used to calculate the surface 
normal, and based on that calculation you get either a positive or 
negative value. You interpret that value as whether the "plane" that 
makes up the surface is "facing" you, and if so, draw it.

IIRC, you can use various "tricks" to not have to do such calculations 
(actually, in reality, if the planes don't change orientation, you can 
pre-calc the surface normals and store them with the plane data); BSP 
mapping is one such method (one I've never found a really good 
explanation on how it works - but I might just be thick-skulled), but 
there are plenty of others (the one used in Descent is actually another 
weird one, called "portals" or something like that).

This is all pretty neat code, and looks "fast" - I haven't delved into 
it to see how or what is being used for all of the hidden surface 
removal, but I would imagine the bulk is based around the whole surface 
normal computations, plus checking if anything is "behind" the camera 
and not rendering that...but there may be other things going on (you 
could "shoot" rays from the viewpoint and see where/what planes they 
intersect with, and only render the first plane that faces you or 
something like that - certainly not a very efficient way).

There were a ton of tricks Doom and similar engines used; Duke Nukem 3D 
had it's own methods...more than a few could be adapted for the CoCo for 
decent speed as long as filled polys weren't used.

Andrew L. Ayers
Glendale, Arizona
phoenixgarage.org
github.com/andrew-ayers

On 4/23/26 9:00 AM, [email protected] wrote:

> Message: 1
> Date: Thu, 23 Apr 2026 08:38:27 -0500
> From: Allen Huffman <[email protected]>
> To: [email protected]
> Subject: Re: [Coco] Vaughn Cato's 3-D vector maze test from 1994
> Message-ID: <AD164C7A-5000-4073-BB3B-01190CE797C0-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
> Content-Type: text/plain; charset=utf-8
> 
>> On Apr 22, 2026, at 10:53?PM, Richard Goedeken via Coco <[email protected]> wrote:
>>
>> That looks cool; I like how it's not just fixed angles like Androne but can be drawn from any position.
> 
> Not only that, it appears it did not have to follow a square grid. I found some e-mails from Vaughn discussing a map editor, and he was describing how the points did not have to be arbitrary squares like the demo uses in a text file. He mentioned if it were a one thickness wall, you?d have to make two - one facing each side - else you could only see it from on direction. This was (back then) and is (right now) math that is way over my understanding.
-- 
Coco mailing list
[email protected]
http://listserv.adelphi.edu/cgi-bin/mailman/listinfo/coco