Shooting Through Walls: Unraveling the Code Behind Quake's Lightning Gun Bug
Вставка
- Опубліковано 1 чер 2024
- A slightly speculative look at how Quake's lightning gun can be used to kill distant enemies.
Check out Connor from @quakespeedrunsexplained's counterpart video here • How Speedrunners Uncov...
Snippet at the start taken from @Muty's 11:42 world record (current at the time of writing): • Quake Speedrun in 11:4...
Thanks to the Quake Mapping and Quake Speedrunning discords for help researching this vid.
Support: www.buymeacoffee.com/mattsram...
Mastodon: mastodon.cloud/@mattsramblings/
00:00 Introduction
00:23 The (possible) problem
01:12 The (incorrect) solution
02:40 Consequences
03:44 QSE vid teaser - Ігри
Watch Quake Speedruns Explained's counterpart video which covers the backstory of this technique here! ua-cam.com/video/zfY96tAqmdI/v-deo.html
The main takeaway is: if you're developing a game it's a good idea to make invisible entities that can interact with other entities actually visible while debugging. It would be obvious that something is wrong if the two invisible rays were shown
surely such a small change doesn't need testing, because nothing will go wrong...
@@O5MO Nothing could possiply go wrong.
@@O5MO What's funny is, they made the change with the intention to make the lightning gun more powerful, but due to the bug it's not actually more powerful like 99% of the time apparently. Perhaps it's a cognitive bias, that when you think you buffed something and then playtest it, you feel like the weapon is stronger even when it isn't
Or just write unit tests and the time spent writing them will pay off massively.
This is why, in the distant future, archeologists will see random commented print functions in my Python code.
Surely even with both of the fixes demonstrated, there is still a bug here with how the vector is normalised before it is projected onto the XY plane. Shouldn't the vector be projected first to ensure that the normalized vector is actually length 1 on the XY plane.
Yep I think you're right! Three bugs for the price of one
I really love your in-engine visualizations.
There's actually a third bug in that function (albeit not abusable): we should normalize _after_ setting Z to 0, otherwise the sidebeams get closer when looking up or down
I'm a terrible programmer who has never stuck to any one language long enough to be proficient and recently I've been playing around in Quake as a hobby, I found this video very funny as I also have misused normalize and had brief moments of forgetting to set temporary variables haha
cool video, love the visualizations! Learning programming would be so much easier if there were teachers like you with visuals prepared.
The rays either side of the main beam may have been an attempt to make long distance shots more likely to connect. Most players were in 320x240 with ball mice - at that resolution and with a low mouse DPI, an apparent hit could easily be a miss even if one tick of the mouse were small enough to hit the mark - especially given the 'lightning' closer to the gun can overlap the stream in the distance.
I played a lot of deathmatch - consensus was lighting was a mid-range corridor weapon, bad long range given you're mostly missing the target and just 'scanning' across it - maybe the 'fixed' code would have elevated it above the nailgun!
Actually, around the game's release, it was more likely they would be using only the keyboard - so that kind of assistance was even more necessary.
fair, but this implies we weren't hitting awesome shots in the 90's, we were :) also we were in 640 x480 for the most part, 320 was crazy even back then. (I had 160hz in 800 x 600 on cs 1.6 years later too! CRT's werent that shit man)
Its crazy how theres not one but TWO bugs in the small snippet of code!
I came here from quakespeedrunsexplained.
There is actually one more bug in the code, although it's irrelevant because of the other ones.
Let's say the assignment of the normalization and the swap bugs were corrected, the offset would still be wrong, because the vector is first normalized and then the z-component is subtracted. That means that the xy-components do not form a unit vector. The higher or lower you aim, the closer the beams will come together.
Correct would be to first eliminate the z-component and then normalize.
Modifying weapon behaviour was probably the main thing people did to try and learn some QuakeC. I remember changing the nailgun to a hitscan machine gun. Lot's of people in the 90s (including me) probably looked at the code and did not notice the bug.
As a game designer my guess is that they wanted to use three beams instead of one to make it easier and more rewarding to hit enemies. The electric beam also does visually not appear like just a thin line, it's more like a tube, but a tube collision detection is much more resource heavy than collision detection with three lines.
There is a somewhat similar bug with Team Fortress (1, for Quake) sentry guns - it also doesn't normalize properly, but the difference with this bug is that the vector p2 that is passed to the traceline() ends up having really giant magnitude instead (magnitude squared IIRC). Thus sentry rounds have no scatter, despite authors trying to make it like a super-fast single barrel shutgun.
An another bug is that a sentry shoots from the top of its head, and, when its target is on the same height level, it shoots at the enemy's top of the head (height 56 from floor level). Thus when both bugs combined, a shot's outcome depends on a sentry and its target absolute positions, by the means of floating point accuracy and rounding errors, rather than PRNG.
Yeah, they're equivalent to a Grunt's shotgun, 4 pellets and 1/10 spread instead of 1/25. They don't normalize at all in the original code, I've normalized it and after some tests they felt so much weaker even on medium distances... I ended up reverting back lol.
@@rfalcetti Also a funny side-effect of non-normalization is that visual effects of 'misses' are misplaced, appearing at seemingly random positions on the map.
This explains why I miss the toilet with my own beams sometimes.
What a relief it isn’t my fault.
Hate when I aim too far off the x-axis and the neighbor finds a puddle in his kitchen.
Now that you know how it works, please aim your relief in the toilet
@@StraightOuttaJarhois you just need to find the correct angle to pee in their toilet.
Judging by the model of the weapon, I would guess that the original plan was to have three beams firing out from the start (not as a fix for shooting multiple, but just intended from the start to make it more effective/require less precision back when people couldn't aim or used keyboards only).
And I can imagine they scrapped the three beams idea for performance or to reduce the visual clutter, but didn't want to make it feel less accurate.
I would bet that the level they set up to test it also happened to have the enemies aligned on the Y axis (so the player was facing down X), hiding the issue to some degree. Seems like it would be difficult for this to slip by testing otherwise, or perhaps they just didn't test this in isolation and never noticed it wasn't working.
Even though ive been coding for years with vectors and 3d graphics, vectors are sometimes the most painful god damn thing in the world. I swear the first thing i do with vectors in every program i use is make a proper vector arrow display function (like the one in the vid) because without it its just tooth pullingley tedious
working with vectors in plain C without operator overloading is especially painful
(hides dual quaternions under the table) yeah those damn vectors.. dot product? it sounds like an 80s new-wave band. My grandad didn't need a dot product, he'd solve everything by cutting up circles of paper like a real programmer.
Yeah i exercise, i do the cross product all the time
@@TU7OV It is ineffectient to use C++ here, and operator ooverload may hide bugs. If would go the opposite way, and instead do all operations in place (basicly how you would do it in assmbly, but multidimsional). Not only does this avoid the dreadfull return and allocation of a temporary structure (that vectorize() does here on assembly level), it can also be more efficient, as the highlevel function is responsible for allocating providing space (typically on the stack).
operator overloading doesn’t hide any bugs that calling functions can’t hide. what benefit to you gain by making your equations correspond less well to the math? Also if you think the return and allocation of temporary structures is actually an issue here, you don’t know very much about compilers :P
It's good to see two Quake themed UA-cam channels supporting each other. Carry on such great work!
Would love a tiny comment by John Carmack on this *feature*
😂
New video and as always excellent, you disassemble the code bit by bit. Thank you and you and Connor found a great topic! 😊
I love this! Do you mind if I show it in my game programming class?
Hey, glad you like it! Yes, please do use it if you think it'll be useful.
What a bug!
If QuakeC compiler had some warnings ("builtin-function normalize return value not used") this would have been catched. Why this was not found during deathmatch (especially 1on1) puzzles me.
> especially in 1-on-1
in those cases, you're almost always trying to aim at the one enemy, so you'd never notice there were other invisible beams.
@@mengmao5033 True. On the other hand, if in 1-on-1 somebody misses you but still you get hurt, you know it was not some other player behind your back. The bug could have been found during mutiplayer deathmatch where someone is hiding in a small room to await a item respawn but is suddently hit by that invisible beam.
I guess lightning gun was mostly used in short distances so the bug was not obvious.
It _does_ have warnings. 15 or so on the actual game's code.
Great video again! Please keep going! This is better than Netflix :)
I'm very surprised the programmer did a bad swap, I can't remember ever making a mistake like that (I probably have, just forgot), I understand it was probably just a late night mistake or something of the sort, very interesting. There's a popular interview question that asks the programmer to swap 2 variables without a temp one. My favorite answer is using XOR
x = 2
y = 3
x = x ^ y;
y = x ^ y;
x = x ^ y;
// x = 3, y = 2
this, however, is horrifying and shouldn't be used.
Also I'm not the most familiar with C, isn't ignoring a return value like that a warning? I just always assumed you would need to assign cast it to void? or even just assign it to a value and let it be optimized out by the compiler?
Hello, this is written in QuakeC, a language specifically designed for Quake's game logic, with a custom built compiler. It likely had very few validity checks like the one you suggest.
@@MattsRamblings out of curiosity: does QuakeC have macros in it? Because usually C programmers define simple macro for this operation.
@@proosee No, it's a very primitive scripting language that has all sorts of weird idiosyncracies.
I remember that even when compiling the game's code, QCC gives something like 15 or 17 warnings (it's been a very long time, so I forget the exact number), and it's very possible that that is one of them.
Stunning as always.
Was this meant to be a pun
This video is #2 on hacker news at time of writing. Congrats, and awesome concise video!
🎉🎉🎉
I mean, what are we to believe, that this is some sort of a magic lightning gun or something? Boy, I really hope somebody at id got fired for that blunder!
Now we have witnessed FPS magic in Quake Champions. So damage had dependence on framerate. This is true sorcery.
Whenever you notice something like that, a wizard did it.
Calm down. Someone at iD messed up the implementation of some code. If it was caught in 1996 it would have been patched, probably by the same person that wrote it, and that would have been the end of it.
@@jimmyhirr5773 you should look up what a joke is
@@StraightOuttaJarhois You're a wizard, Harry.
Imagine being a shalrath (vore) living your life normally when you suddenly feel an unfathomable pain then you die XD
I've been wondering if this exists in NetQuake. I think of it were it would be noticed more, but I feel like it should have been noticed a lot earlier in online competitions than it was in speedrunning.
It's in the QuakeC code (part of the game data) so it ought to apply to *any* engine unless it goes out of its way to mod it out.
Huh so rumors about the lightning guns creation for the remote viewers division had a kernal of truth to them neat.
I was wondering if the side beams can potentially triple the damage, and may explain why the gun has such high DPS (300), but looking at the quake c it seems like subsequent traces only deal damage if the previous didn't hit, and it just deals 30 damage per cycle. There also seems to be some PvP specific funky Z velocity push that only happens on the primary beam, but the bug should work in deathmatch too.
That makes me wonder: Is the center beam prioritized if it and another beam contact different targets? Or can you end up in a situation where you have the center beam dead centered on an enemy, but since you're at an angle where one of the side beams is hitting an enemy in a completely different part of the map the enemy you're actually _trying_ to attack goes unharmed?
The beams *can* all cause damage at the same time, but they have to be targetting different entitites. This means that you shouldn't end up in the situation where one beam hitting something will prevent the other beams from causing damage.
Cool collaboration!
Awesome explanation! I'm kinda sad that this video doesn't show off the tool you developed. It was mentioned around the 14-minute mark in QSE's counterpart video.
Thank you! I actually made that tool sometime after I'd finished the video, and at that point it was tricky to work it in. I'm glad QSE got to show it off though.
Does this 'bug' also work in QuakeWorld against other players?
I have never heard of it and I played QW for 10+ years on the European scene.
I'm not part of the QW scene but it does appear that the QW progs (or at least the version released to github) has this bug too github.com/id-Software/Quake/blob/master/qw-qc/weapons.qc#L507 . If it is I'd imagine it'd be patched out in server code, but I would love to know if anyone knows for sure.
@@MattsRamblings Interesting. Since I never heard of it being used, I am guessing it was patched early, maybe even in Kombat Teams around '98/'01.
I don't want to sound smart - we all do stupid mistakes (me especially), but I'm puzzled how this could happen: using temporary variable to swap two others is like an example shown to beginner coders (usually show along with XOR swap trick) and knowing that for function to change the value passed as an argument you need to provide a pointer to it is like C 101.
Well, what can I say: write your unit tests*, kids 😇
*) except for the games, without bugs we wouldn't have fun bugs like this or even bunny hopping 😅
You make great content!
Why is it 0 - f_y rather than just - f_y ?
Hey there, I'm not completely sure but this looks like a limitation of QuakeC (the C like language that the quake game logic is written in), where it lacks a unary negation operator. A quick grep through the game source doesn't turn up any unary negations, and its not supported by the byte code (the intermediate representation that the QuakeC gets compiled to), and nor can I find it in the parser source: github.com/id-Software/Quake-Tools/blob/master/qcc/pr_comp.c
QuakeC is a very odd and limited programming language. Very much built on the spot without much thought put into its design. It gets the job done for scripting game mechanics but it’s missing a lot of features that you’d take for granted in most proper languages.
Yeah, the original QCC compiler lacked a ton of simple things you have in other languages - you couldn't do increments like i++ for example, and AFAIK even for loops were out of the question. Luckily nowadays we have compilers like FTEQCC that bring up most of the C features back to QuakeC.
@@Astfgl I think there was plenty of thought put into its design. But some of those thoughts were "we need to have the compiler working and pretty much frozen months before release so we can actually complete and playtest the levels, so let's not add more features unless they're really important."
@@hobbified What I meant is that it was designed based on what was needed at any point in time, rather than being a well-thought out language designed ahead of time by someone with a solid understanding of language and compiler design. It has all the hallmarks of an in-house domain-specific language built in a rush and with very impromptu decision-making.
id Software revisited the idea of using a virtual machine to run game logic in Quake 3 and they did a much better job that time. Not in the least because they chose to use regular C and an established compiler (LCC) for their scripting language that time, but also because John Carmack actually took two weeks off to properly work out his ideas for the QVM toolchain before plugging it into the game engine.
So if you line it up right you can do 3x damage if all 3 lightning beams hit the same enemy?
Hello, the function only counts the damage once in that case.
Great video. I can't believe it took so long to notice this bug.
It's nice to see that even in a groundbreaking game like Quake, developers make the same mistakes I do in JS front-end development - we're not as different as I thought
How did I know you used vim
That normalize() mistake is so easy to make in GLSL as well, hate it. Would be so much clearer if it were normalized() instead
All hlsl and glsl intrinsics are functional i.e. they do not modify the arguments and instead return the computed value. Personally I like this style for all math functions, even in other languages.
@@nooan79 He was complaining about the naming. Not about the functional style
@@LeMustache sure but in hlsl and glsl the function is also called 'normalize'
@@wintermute1814 Yes. That's the point of his comment
@@LeMustacheYou can't name every mathematical function by the past tense verb!
Y=sqrted(x)-sined(2x)-smoothstepped(x,.1,.1)
It's implied in a mathematical function (and most programming functions) that it returns the result, it doesn't change the parameter! And in C (and I assume quake C, you'd need to write normalize(&v) if it was a function that modified it.
Has anyone made a "no LG bug" mod to let you play with the intended mechanics? I know it would be kind of... not huge, but I'm just curious.
Hello, modern gameplay mods (eg. alkaline, copper) have fixed this bug.
I insta-click your videos. Thank you, Matt.
According to Michael Abrash early in Quake's development, he discovered a bug in the Pentium chip's hardware, the infamous "f div" bug, which caused completely random snaps to totally different parts of the map for a split second.
are speedrunners allowed to design their own custom buggy CPUs to finish the game faster ? :)
Quake 1 code was open sourced?
The code was released more than 20 years ago I think
Yeah it was GPL'd in the late 90's - including engine code, QuakeC gamecode, QCC compiler and map compiler tools. It's what kept the community alive all these decades, and the reason why Quake 1 is the game in the series with most user content I'd say.
Yup. Doom, Quake, and Quake II each had their source released by Id 3-4 years after their respective games - and at about the same time as the games *two engine generations later* (which is why they weren't worried about giving the old tech away for free). Stuff moved fast back then, and the source releases were good PR with very little cost in terms of "giving away the secret sauce".
Not only was the entire engine open sourced in 1999, the Quake C game logic was open sourced by the time of release (!!!), meaning someone could have discovered this in 1996!
The bean counters didn’t like it, but John Carmack was adamant that they share their technology with the world and allow everyone to learn from their work. And oh boy did we learn. A lot of this tech has laid the foundations for how games are developed even to this day.
How long was this known about before someone dug into the code?? Wouldn't that be the first place you look? .-.
Quake Speedruns Explained digs into it a bit in their video but yes, it is interesting how it took so long to deconstruct ua-cam.com/video/zfY96tAqmdI/v-deo.html
I've always wondered what that code was intended to do. I think your theory makes the most sense since it can be chalked up to two simple programming mistakes.
Wow, what a bug.
If I follow you correctly though, shooting at enemies without moving the mouse at all should deal 3 times the damage to an enemy in front of you though right?
Hello, the function has some logic which stops the same entity being damaged by different beams, see github.com/id-Software/quake-rerelease-qc/blob/main/quakec/weapons.qc#L469 . It does appear though that you can do 3x the normal damage as long as the beams each hit different enemies.
Parkinson's LG
This seems like such a weird and somewhat hacky implementation to me. If I were to program this, I would grab the player’s right directional vector (pretty sure Quake already pre-calculated that somewhere) which is already normalized, scale it by 16 units and then use that to offset the beam’s start and end positions. Since the player rarely has any roll applied, there’s not much need to flatten the vector either. Someone must have programmed this in a hurry and then didn’t thoroughly test if it works.
The side vector isn't automatically pre-calculated. But QuakeC *does* have a function (makevectors()) that takes a pitch/yaw/roll angle and generates 3 separate front, side and up normalized vectors, which would work just fine here by inputting the player's viewing angles, and not even need any normalization.
I think they did this way because the player's angle wasn't passed down to the LightningDamage function, only the origin and end points of the beam (which are calculated previously via traceline in W_FireLightning). So when they were expanding the code, they probably decided it was easier to just make a quick and dirty calculation by hand based only on the origin/end coordinates passed to the function.
Yeah I guess so. It’s been a while since I did any QuakeC programming so I’m rather fuzzy on all the details. Calling makevectors() just for this one function was probably a bit too expensive anyway. You’d think it would make sense to calculate the player’s directional vectors once per frame after updating the position and angles and then cache them somewhere globally, since it’s such a ubiquitous thing needed almost everywhere in the game logic.
"then didn’t thoroughly test if it works."
It doesn't look like they tested it at all.
@@bmFbr I just had a closer look at the QuakeC code and it is as I remembered: the directional vectors calculated by makevectors() for the local client are stored in global variables that are available throughout all of the QuakeC code: v_forward, v_up and v_right. These are defined in defs.qc with the comment that they're global variables set by built-in functions. You can also see the lightning gun firing code make use of the v_forward vector to create the ray to trace for the lightning beam. So the lightning damage function absolutely could have made use of the v_right vector to create these two offset lightning beams.
@@SteveBennett1 Unless they happened to be lined up in exactly the right direction for the secondary traces to be roughly in the right spot :P
OMG, Broken!!! It's like this code was written by Chat-GPT or something