The code behind Quake's movement tricks explained (bunny-hopping, wall-running, and zig-zagging)

Explanation of how the player movement code in Quake gives rise to these three different player movement "bugs", with a quick look at TAS movement mechanics at the end.
Big thanks to the Quake Speedrunning Discord for helping me out with getting TASQuake running on my machine, and for clarifying terminology.
Here are the original C versions of the acceleration functions:
github.com/id-Software/Quake/...
Chapters
00:00 Introduction
01:13 Acceleration on ground
03:05 Zig-zagging
03:54 Circle jumps
04:17 Wall-running
04:46 Acceleration in the air
05:18 Strafe-jumping / power-bunnies
06:21 Tool-assisted techniques
07:23 Outro

[@MattsRamblings]

A couple of quick notes: - There's some overlap with my Quake 3 strafe jumping video, but the way strafe-jumping / bunny-hopping manifests itself in Quake is different, plus this video includes wall-running / zig-zagging. - The terms strafe-jumping and bunny-hopping are used somewhat interchangeably to mean speeding up in the air using the strafe keys. According to some definitions there is a difference between the two, but there's no real concensus and I generally use "strafe jumping".

[@kered13]

To elaborate, the different between Quake 1 movement and Quake 2 movement are in the air acceleration constant and the max speed constants. Quake 1 has high air acceleration and low max speed, Quake 3 has low air acceleration and high max speed.

[@RoboZombie777]

Im not sure if these were how the terms were used back then (I only ever started playing quake during the later years of QL to the QC era) but I always under stood "bunnyhopping" to mean Quake 1 style airstrafing with lots of air control while "strafe jumping" to mean Quake 3 style jumping with minimal air control. Both ultimately derive from the same physics bug but operate very differently in practice. Edit: It's also worth noting while Quake 3 Promod and Anarki in Quake Champions have both Q1 bhop and Q3 strafejumping active, their bhop implementation is a separate physics component "bolted on" to the normal usual Quake physics. I know that a lot of QW diehards don't like CPMA airstrafing for that reason.

[@sandorhahn9441]

The fact that this complicated mechanic was introduced even in the early quake games and still holds strong speaks volumes for i.d software. I'm still playing q3 daily and it's largely due to the flexibility of this mechanic.

[@enneff]

They didn’t plan for this to be the case. Reading the code it seems the intent was to cap player acceleration at zero after a certain absolute velocity. So arguably this is buggy movement code. However it’s certainly fun movement code, and that’s what matters the most. The real testament to id software is the fact people are still playing Quake to this day. (Btw, it’s “id” not “i.d.” - tim willits once aggressively corrected me on this lol)

[@sandorhahn9441]

@@enneff time willits must have heard that too many times in the past, hey? Sure the acceleration is capped in early quake'. Doesn't mean that the cap couldn't be adjusted in later releases. Which opened the door for Bethesta's QC. Each character has a different acceleration cap.

[@sandorhahn9441]

Nothing but a friendly debate by the way. I'm still playing QL, though it's cool watching the QPL games

[@Bozothcow]

More like volumes for John Carmack. He basically did all of this work as far as I understand.

[@mcilrain]

They tried "fixing" this bug in Quake 3 when they realized the insane skill gap it produced was causing the genre's mainstream popularity to die but the players rejected the change.

[@rosodudersd260]

Your original video on Quake 3 strafejumping was helpful for me understanding it 2 years ago, which is also when I started practicing bhop trick maps in QuakeWorld (after years of playing Quake: Live). There was only a bit of new info for me here (wallstrafe, tool-assisted frame perfect forward acceleration), but I greatly appreciate the clarity of your explanation here with the pseudocode and visual demonstrations. This will definitely be something I link people in the future, along with the Q3 strafejumping video. At one point I looked into the code myself to try to understand why the technique for Q1 bhopping (hold strafe only, turn mouse at a constant rate) differed from the technique for Q2+ strafejumping (hold forward + strafe, angle mouse to a slowly shifting sweet spot). I was perplexed, because what I found in the QW code was identical to what you showed in the Q3 strafejumping video. I was stumped until I realized that the difference is driven pretty much entirely by physics constants. I'll speak in Q3 terms, but in both cases the game tries to alter your movement in a desired direction by projecting your current velocity onto the desired direction and then subtracting the result from sv_maxairspeed. If the remainder is positive, it accelerates you in the desired direction by the remainder multiplied by the sv_airacceleratevalue and the frametime. In Q1, the max speed you can get in a strafing direction is rather small (sv_maxairspeed=30) but it is attained very quickly (sv_airaccelerate=106), hence you have to constantly turn towards a new direction to accelerate into it. In Q3, the max speed you can get in a strafing direction is rather large (because sv_maxairspeed=320) but it is acquired slowly (sv_airaccelerate=1), hence you have to find a sweet spot with your view while you gradually accelerate in that direction. Something interesting about about Q2 is that it actually retains the Q1 airaccelerate function but simply has it off by default in favor of the unified accelerate function used for ground and air alike. You can re-enable Q1 bhopping in Q2 multiplayer if you set sv_airaccelerate to 106, as it simply switches to the old airaccelerate function if the sv_airaccelerate value is above 0 (doesn't work in Q2 singleplayer sadly, as pm_airaccelerate is hardcoded to 0). Similarly, you can re-enable Q1 bhopping in Q3 by setting sv_maxairspeed from 320 to 30 and sv_airaccelerate from 1 to 106, as demonstrated in this video: kzbin.info/www/bejne/g5i6opR6ptB1epI Also, humorous note: in the Q3 movement code, you can find a "proper" implementation of air control that avoids the "strafe jump maxspeed bug", but is commented out because it "feels bad". This lines up with John Carmack's blog post where he says he tried to remove the strafejumping exploit, but reverted it because it "changed the normal running movement in an unfortunate way". Lucky break we got there! www.gamers.org/pub/archives/plans/[e-mail]/1999-04-24_1999-06-05 The Q1/2/3 movement codes if anyone wants to peruse them; look for the PM_Accelerate and PM_AirAccelerate functions: github.com/id-Software/Quake/blob/master/QW/client/pmove.c github.com/id-Software/Quake-2/blob/master/qcommon/pmove.c github.com/id-Software/Quake-III-Arena/blob/master/code/game/bg_pmove.c

[@jlewwis1995]

Lmao carmack sounds like freaking nintendo in that post, he's basically going like "we know you like this fun thing you can do in the game and it makes it more fun to play but it's a bug(tm) so I want to remove it" but it turns out he found out why he SHOULDNT remove it unlike nintendo :P

[@spaceowl5957]

Whoa that’s really interesting. I would love to see a video comparing the “proper” implementation with the actual one and why the proper implementation feels worse

[@GroinMischief]

3:55 Another convenient way to do the prestrafe is to do it with left/right only. This makes it much smoother to adjust the view angle when you transition to air movement, in fact you can keep turning at more the less the same rate as you did on the ground. This is convenient in Q1 especially, because the sweet spot for air and ground turning is nearly identical.

[@vamsigagjew1535]

I finally managed to implement this into my unity fps project, and while it's pretty scuffed im proud of it

[@attractivegd9531]

This video is of high quality in every sens. Quick question, what engine did you used to render Q1?

[@MattsRamblings]

For the third-person shots I have a set of Python scripts that parse demos / models / maps and composes them into a blender scene. For the first-person shots I use Quakespasm, with the speedometer ported over from JoeQuake.

[@ausilliam]

@@MattsRamblings im an avid blender user and i gotta say thats sick as hell

[@semih3665]

Really like the visuals you use to explain these things, makes the video soo much better! Thank you for your work!

[@q3dqopb]

Fantastic. I am a TAS player in Q3 defrag, and I know Q3 physics to a similar extent. I used to play some QW, and it was interesting to learn how strafe tricks are similar and different between these 2 games.

[@joshcantype]

Great video, I've recently been very interested in the air strafing mechanics of several games and finally seeing a mathematical explanation with great demonstrations has cured me of my curiosity.

[@theredstormer8078]

Thank you so much for this video. I have been looking for a good explanation of this for a long time and all I could find was a bunch of math that I had no way of really understanding. I knew how to air strafe (at least for TF2 physics) and I had the muscle memory down pretty well but I always wanted to know how it worked exactly and if I could mimic it myself in my own projects. Thanks.

[@OhhBabyATriple]

Really enjoying your content. One of the best channels on KZbin. Please keep uploading

[@tonyfroman4382]

Great video!! Well explained and with concrete examples and visuals to back it. Subscribed :)

[@ThefamousMrcroissant]

Absolutely LOVELY video! So well presented with the top down illustrations too, just wonderful work. Having dived into the source myself I already knew what was the origin of this VERY fortunate "bug", but I always had a rather difficult time explaining it to others. You do it so well here.

[@benapple9587]

your channel deserves so much more attention, i've been binging these for hours

[@zedespook]

This is so simple, yet so amazing. Thank you for the video!

[@SpicyCurrey]

Your videos are continually fantastic. Ive been making a similar video to this (showing graphs of viewangles/perfangles and speedgain) but your videos are so good there's no point:p

[@kocode13]

I love this video! Using this video i made my own quake style movment in my game! It helped me so much to make a satisfiying movment.

[@makegamerepeat2606]

Thank you so much. I was earching for such a detailed explanation. Your video allowed me to unterstand the topic fully.

[@2123b_b]

quality video, never seen this explained in such great detail

[@SensSword]

0:45 and I'm already having massive nostalgia. Didn't have a computer fast enough to execute that hop at the time and marveled at a kid who did and could.

[@Siledas]

Nice video. Really interesting and very well-made.

[@HardToBeAPoopGod]

i know exactly 0% about codes and scripts, and yet i 100% understood this! i've always been curious as to how wallrunning specifically works super well done ♥

[@CYXXYC]

New video just when i was going over this channel again? Very nice

[@philipme2073]

What a total masterpiece of a video on this topic.

[@bartoszpietrzak4978]

Wow, this is awesome material!

[@ghb323]

you’re like UndocumentedPannen on SM64 explanations.

[@ricurse]

Nice thorough video

[@fjdjzfhrsut8063]

When the video was this good and to the point I thought it was going to be one of those 10 year old vids but it's soo recent. Astonishing.

[@MxDOOM]

Great explanation!

[@TreeFrogOnATree]

thanks, got this movement style working in my project :D

[@nixedification]

Great vid! Earned a sub!

[@tehsimo]

I've been doing this for years but never really understood it, this is nuts

[@just__khang]

Very well done video

[@sinus4784]

love your videos can't wait for me

[@jamesisntmexican]

these vids are great!

[@SnareX]

The graphs just saved me from a headache. I'm using a similar strategy in my current project but I'm trying to eliminate b hopping

[@bxlxrteeworlds8782]

finally a vid!

[@madmadderson7318]

This is everything I ever wanted

[@spaceowl5957]

I knew the source/quake movement was special the first time I picked up COD. And it’s really interesting to learn more about. Thx for sharing! I zoned out for the second half because it was really hard to understand but I made an effort to understand the first half and I’m really confused as to why they architected it this way? As far as I understand, the physically accurate way of updating speed and direction based on an input vector (aka wishdir) would be to take the current velocity vector, and then add the wishdir vector, and maybe clip the magnitude of the change to the max acceleration, and the magnitude of the result to the max speed. And that’s it. You’ve updated the speed and the direction on a physically accurate way. But instead they do the speed change code separately from the direction change code and then do this weird dot product which I guess approximates what happens to mafnitude (aka speed) when you add two velocity vectors (the resulting magnitude is higher, the more the vectors point in the same direction. And the dot product is larger, the more the two vectors point in the same direction). But the dot product is just an approximation of what you would have to calculate if you were being physically accurate. And because it’s just an approximation, you have weird stuff like strafing increasing speed. Why do they do this?? Why not just add vectors normally? It can’t be a performance thing right? So it must have some advantages to game feel or design that I don’t understand. That would be great to explore maybe in some future video. “Why” they made it I’m such a strange way.

[@spaceowl5957]

I have one idea: When you use the weird dot product you get the following behavior: When you walk forward speed, and then suddenly walk straight to the left or right, the speed will slow down first, before picking speed back up. (Because the dot product for 90 degree angles is zero) Meanwhile if you just add vectors (the “physically accurate” way) you wouldn’t have the same slowdown when changing directions. This would be physically accurate to like a hockey puck on ice. But if you’re simulating human movement it might feel more realistic to have the extra slowdown during a direction change of the dot product method. Just because of you change directions 90 degrees as a person in real life you would probably slow down first, instead of just “adding on the perpendicular speed” just because of how legs and bodies work. But

[@ciCCapROSTi]

Yes. I had no idea how that TAS thing worked, I assumed it switches back and forth too fast to see, but that didn't sound right, rendering would show the flicker, there is no smoothing in Quake. But if it directly controls wishdir, then yeah, that explains it.

[@LaserBread]

What I find funny is that while zig-zagging was fixed in most Source engine games, you can do it in Team Fortress 2 to overcome the speed penalty from taking damage while invulnerable from Bonk! as a scout.

[@Terminatorm101]

If someone would have shown me such a video 20 years ago :) I really would love to watch and listen about Q2 trick jumps explained with the same level of depth

[@simonkhouryAU]

AMAZING!

[@plusplusplus9837]

very cool video! i wonder why current speed is calculated as a scalar projection instead of as the magnitude of velocity?

[@XuryGreer]

Thank you for these videos, they have been extremely helpful while I've been developing my own character controller. Could you do a video on how Valve limits these issues in Half-Life 2, Team Fortress 2, and Counter-Strike: Global Offensive?

[@OmegaRC59]

I know it's 2 years late, but the main limiters are different in each. Old Engine HL2 doesn't limit, but New Engine HL2 does it by counteracting your velocity with backwards velocity, which causes the backhopping bug. TF2 limits your speed by slowing you down instantly on ground contact. CSGO does it by limiting how often you can jump, though idk if it has any speed capping. Hope that's at least somewhat interesting 2 years later

[@XuryGreer]

@@OmegaRC59 Thanks for the reply, this is still relevant for me even after all this time. Do you know where I can read more about these implementations?

[@OmegaRC59]

@@XuryGreer hmm, the technical side of it I wouldn't know where to look other than the leaked source code for the various games (which iirc does not include CSGO, but L4D2's jump limiter implementation I think is similar but toned down, don't remember if L4D does this), but as for videos, for HL2 Pinsplash has made a video talking about bunnyhopping I think? For TF2 Shounic I know has made a video talking about one of the betas, in which bunnyhopping fully worked, and mentioned the differences between how it works now and then. For CSGO I don't know, I think 3kliksphillip talked about it with the whole FrankieOnPC bhop script cheating scandal years ago. I don't know off the top of my head for that, never played CSGO I just like watching Phillip lmfao

[@owenwexler7214]

Valve killed Half-Life 2: Deathmatch by doing this.

[@Ra11y]

YES MATT

[@soulhunger1]

Thank you so much for explaining how the TAS works, because I was super curious about that when I started watching it and saw the oddly straight jumps. Excellent video.

[@Stevenbustamento]

This was a fucking great video.

[@callumcuda7903]

Great video. I know you focus on quake but would you consider doing a video on surfing in CSS and other games. Basically, you use ramps to exchange vertical velocity for horizontal velocity and vice versa but beyond that, I and most other players don't really know how it works. I think a video explaining it would have wide appeal.

[@ItsRayful]

Its the same engine basically, the goldsrc engine is a modified version of the quake engine and it powered cs1.6, and css is just a (heavily) upgraded goldsrc engine. It works the same way it does in this video. Im pretty sure, if you set airacceleration high enough, you could surf in quake aswell. Edit : Yup, you certainly can : kzbin.info/www/bejne/fYSrq5J7nd-iicU

[@hambum3697]

Can you make a video on cs source bunnyhopping because its different from quake bunnyhopping and I'm trying to make make own character movement in UE4? Great videos btw they helped me a lot so far :)

[@kyoobqa]

It's basically the same thing since CS:S mechanics were derived from Half-Life: Source, which in turn got its movement from Half-Life, which was based on the Quake engine and had the exact same bug. CS:S bunnyhopping servers use a crazy value, like 1000, for sv_airaccelerate that makes the acceleration slopes way flatter.

[@solaris5303]

It's almost exactly the same as Quake's, plus some cvar changes and the introduction of the function "PreventBunnyJumping" in gamemovement.cpp (which caps the speed and makes bhopping mostly useless).

[@landscapesandmotion]

The Action Quake 2 Mod had entire maps based on the bunny hopping mechanic and skill. Was the glory days of 56K dialup internet gaming in the late 90s early 00s

[@mrvectorhc7348]

Soooo cool

[@skope2055]

awesome

[@owenwexler7214]

As someone who wants to make an arena shooter game with fast bunnyhopping one day, this is relevant to my interests.

[@rob_i208]

For awhile, and thanks to your previous videos, I've thought that a controller may technically be superior to mouse and keyboard. I didn't know about the current tool assisted speedrun until now. Thanks for pointing it out at the end!

[@TheRaker1000]

im a bit amazed at how much of this is applicable to portal 2 (2011)

[@VideoGamesCompleted]

Hello Mike, would you briefly explain why holding forward while in the air in Quake causes you to lose speed when attempting to bunny hop? It's one of the difficult transitions for me is going from Quake 2 or Quake 3 asd having to let go of forward while in the air because you want to keep holding forward in Q2/Q3. I always wondered what it is that causes the speed loss in Quake 1 when holding forward.

[@faisalwho]

Collision detection in quake is "continuous", which basically means no matter how fast you move, if you hit a wall, it will detect the hit. Collision detection in games like Mario 64 was "discrete", meaning the distance traveled would be broken downcintoca fixed number of steps and it would see if a hit occured in that step. So, if a character moved 10 steps in 1 frame, and your number of steps broken was 5, then the object would advance every 2 steps and a collision test would take place, 5 times that frame. But, what if the character moved 100 steps in one frame and the number of checks was still 5? Well, the object would be moved forward 20 steps before the next test would occur, and if the wall was 5 steps thick, it could be that the hit against that wall would go undetected. So why am I saying all this? In Mario 64, only the forward velocity was capped, but the developers didn't bother to cap backwards velocity. The player then could back up against a wall, start jumping backwards gaining enough speed to where the movement in that one frame would be large enough to skip that wall for collision detection. This is why in Mario 64 speed runs you see them going through the wall. However, this is not feasible in quake.

[@Gamepro5]

What units are frametime in? I tried implementing this in an engine whose units are in meters and not quake units, so I'm trying to figure out why my acceleration is almost instant. Proportionally scaling all the numbers doesn't fix it. Also, what does the friction function look like? is it vel = vel * 4 * frametime ?

[@stellar4677]

1:39 the length of the forward and side vectors can be adjusted with a ???? forward speed and a ???? side speed variables

[@MattsRamblings]

I mean the `cl_forwardspeed` and `cl_sidespeed` console vars

[@hsg1380]

After implementing this into my game I'm stuck with a bhop that requires always holding the w key. I think the cause might be with how the wishdir snaps. any ideas?

[@Fezezen]

How come in Quake 3 you need to hold the W key and only periodically change the view to gain speed, while in Quake 1 and Half Life you don't have to hold it and you have to change the view more rapidly?

[@ItsRayful]

I cant answer with authority, but to me that seems like the kind of thing where the developers tried to "fix" their earlier mistake, only to introduce another form. Kind of like it was with Half Life 2 and accelerated backwards bhopping

[@mrxtersof2393]

hey man can we replicate the movement of soldier of fortune 2 ?

[@ieatgarbage8771]

I KNEW fastwalk and wallstrafe were the same. They both have the same max speed and involve moving at an angle to your velocity. I didn’t realize they both were the same as airstrafe because I assumed they just intended you to be able to gain speed that way.

[@ridlr9299]

Hey Matt do you think you could explain exactly what [ground/air]_accelerate, [ground/air]_speed, and stopSpeed actually do (wishdir, [ground/air]_speed, and [ground/air]_accelerate being the parameters for the Accelerate function). I've managed to mostly replicate the feel of the Quake III movement just by guessing and checking, but it would be nice to better understand how changing those variables in one way or another affects the movement. Thanks!

[@GroinMischief]

Ground/air_speed sets the target speed, ground/air_accelerate sets how fast you reach the target speed. So with these two variables you can decide how fast you accelerate in a straight line. These are the essential variables and what their values look like between the two games: Quake 3: Ground_speed 320 Ground_accel 10 Air_speed 320 Air_accel 1 Friction 6 Physics tickrate 125 Quake 1: Ground_speed 320 Ground_accel 10 Air_speed 30 (ground speed multiplied by 0.09375) Air_accel 106.6666666666667 Friction 4 Physics tickrate 72 Note that your acceleration is affected by both speed and accel variables. If you have zero max speed, you have nothing to accelerate to. Physics tickrate also affects your acceleration. Higher the tickrate, the more speed you get when you turn. I'm not entirely sure what StopSpeed does, but it's probably got something to do with how fast you come to a full stop when moving to the opposite direction of velocity. I'm not sure if Q3 even uses this variable, it's much more noticeable in Q1.

[@nortropgrumann9594]

Chemical Fantastical

[@0x2480]

i'm just curious as to how the TAS script works, like does it generate a new vector and just rotate it repeatedly until it gets the best wishdir?

[@MattsRamblings]

You can actually solve it analytically. Here is the TASQuake code that finds the optimal angle for maximum acceleration (not written by me) github.com/lipsanen/TASQuake/blob/master/Source/tas/strafing.cpp#L167 . The different branches should correspond with the branches in the air accelerate function.

[@NeZversSounds]

For a long time, that clip function baffled me. But it's just a clamp function.

[@joelalain]

you know a game is epic when 25 some odd years later ppl are in-depth analysing everything about it, including code interpretation. John Carmack is the best

[@JonCombo]

Rocket Jumping? Slope Boosts? Trimps? General Pain Jumping? Water Gliding?

[@snowob]

what if add_spd wasn't capped?

[@use0fweapons]

when the graph appears at 3:10, what is the red line?

[@MattsRamblings]

The red line is the hypothetical acceleration you'd get if you had the given wishdir-velocity angle. So to accelerate as fast as possible you should keep the blue line at one of the peaks of the red line.

[@use0fweapons]

@@MattsRamblings perfect, thats what i thought but i wanted to be sure before i asked the follow up question. so does that go to say that on every jump, there is an ideal angle to point the mouse at for maximum speed gain? bonus question: any idea how much of this applies to Quake Champions? lol

[@use0fweapons]

this is always something thought i kind of *thought* was happening but i never knew how to dig in and get this info. if my earlier question is correct (about the mouse angle), then this would be SUPER valuable for teaching new players how to strafe jump.

[@GOUST3D]

Joe Rogan: Jamie write this down, WRITE THIS DOWN!

[@GoOnMaz]

Old call of dutys run off this Engine and you can strafe there too

[@SeedRamples]

Great video. I only have one complaint, and that is in the way you create your videos, not the actual material the video is discussing. You speak very close to your microphone, and you also speak very softly. This makes so when you turn the gain of your microphone up, the viewer can hear every little lip smack. I suggest that you speak a little further away from your microphone and speak louder so your lip smackings are softer. Once again, great videos and really interesting stuff! Just an audio issue 👍

[@ZdrytchX]

Thanks for making this and the q3 physics demo, I wnated to make a demo on showing quake 1 air physics (as replicated in valve's source games) uses the same maths at quake 2/3 air physics with different accelration and speed limit values. I kinda ended up forgetting on making one for it but you illustrated it very nicely. Also regariding TAS airstrafes, there's a few vids on this but the examples in your video weren't that well demonstrated. There's ones where they dont use joystick input but orientate the camera directly such as the one for half life getting 600 ups in 1 second: kzbin.info/www/bejne/e2OsooR_fKaiorM

[@SergeySkokov]

So, it's bug, right?

[@MattsRamblings]

Most definitely

[@soukuw9146]

Are you telling me my bhops are shit?

[@jlewwis1995]

6:55 so this "technically" means quake could be beaten faster with a controller? Damn you console plebs you win this time 😂

[@rob_i208]

Technically you would need to a Controller and a Mouse, but yeah.

[@ItsRayful]

Not with only a controller, the controller would need to be looking around to navigate the level or "inject" the frame perfect strafe inputs. Pretty sure it cant be both

[@marscaleb]

The way you say "Wishdir" throws me off.

[@maximkosheleff]

Strange decision to do useless python code instead of show ordinal C

[@keiyakins]

Not really. Pseudocode has a long history of being used to clearly present algorithms

[@eadweard.]

Very interesting to see the technical details of what ruined Quake for me. I could just about buy that we were super soldiers firing grenade launchers at each other in haunted castles. But everyone constantly jumping up and down as they did so was just a step too far.

[@rushoffman965]

>Pseudo python LMAO

[@theitatit]

python ruins the video bye.

[@pu55yEaterr]

why would you use python as the pseudo code tho

[@ItsRayful]

why is the bot still gaining speed at 7:33 while doing a strafe-jump motion if he already accelerated frame perfectly before that and not reaching that speed? Or rather, why is he still gaining more speed doing a continous strafe jump instead of frame perfect air strafing