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.
Also shameless self promotion - if you're interested in 4D collision detection (and rendering, and rigid body physics), I've made a semi-tutorial-style repo here:
Nice to see you here, I’m a big fan of your videos! I did some work on Q3 mapping tools for mac back in the day and always been very interested in everything quake related.
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 think your guess seems plausible, although maybe it was simply an effort to widen the beam to better match the graphics? The lightning effect is rather wide and it may have been surprising for the player if the hitbox ended up too narrow.
I haven't played Quake in the better part of 20 years so I can't comment from first hand experience, but judging by your top-down view at around 41 seconds, the single beam visually seems to intersect with a bunch of enemies while not dealing any damage (probably as a combination of narrow hitboxes on both the beam and the enemies).
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:
