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