The technique can detect the intersection point of a (fixed size, axially aligned) moving bounding box and a hull defined as a BSP tree. In this sense it is rather limited compared to newer methods but it works rather well and the implementation is pretty robust, and fast enough for the primitive hardware of the day.
Hello, video creator here. This is indeed the actual code, and it is written in QuakeC, a language created specifically for the game logic in Quake. The part I'm not sure about is why the creators wanted to add in extra side beams at all.
I love this write-up, especially the interactive diagrams at the end. My vid doesn't go into as much detail on the actual circuit design, but like the article it uses a bunch of BCD ripple-carry adders. For output I use standard 7-segment decoders. As noted in the comments there are faster ways to do logic in Quake which I overlooked in my research, but to my knowledge noone has made a circuit this large before. I've put the source code on github for anyone that wants to take a deeper look: https://github.com/matthewearl/q1logic/
Author here, I intersect the view frustum with the light's sphere of influence (and also take into account PVS info) so it still includes lights that are reachable by one bounce. Technically this means I might omit two bounce reflections but in practice this doesn't appear to be a problem.
Correct, it wouldn't be hard to take the best known strategy and implement it perfectly. Aside from the two points you mention, it also serves as a precursor to applying RL to real levels in which we may not be so sure about the optimal strategy.
It's the Quake 1 physics, not QW. I haven't looked at the QW physics in detail, but I think the main difference is that there's a single frame of ground friction applied between every jump, which ends up making a difference to the optimal techniques.
I skipped the variable frame rate out of this write-up in an attempt to keep things simple by leaving the GIF composing to an external program (ImageMagick). In an earlier iteration I did in fact create a version of the GIF with frame duration proportional to the real time:
The speed is relatively consistent except for the early frames (where pictures were taken at twice the rate of later on) and where frames were dropped due to missing data or alignment failure. Here's a version of the animation where frame duration is proportional to the real time between the frames: