In the article about the physics of EdgeBug and JumpBug we got acquainted with a technique called bounce. This name is not commonly used, and in addition to it, we will now introduce another one. You can find many examples of shortcuts, when a player falls from a great height, bounces on an inclined surface and then hits another surface, gaining vertical speed. Moreover, this surface is usually not a slide, but movement on it is very similar to sliding. Such an example can be found on kzno_extremeblock, when the player hits the start button, then moves on doubleducks to an inclined surface and there this kind of sliding occurs, which we will call Glide. Let's try to understand the physics of this phenomenon.

We already know that in PM_WalkMove a trace is performed in the direction of the velocity, and if this trace does not touch anything, then the end of the trace becomes the new position of the player origin. When moving from a horizontal surface to an inclined one, the trace will intersect this inclined surface at some point, and then, just like it was in PM_AirMove, using the PM_FlyMove call, we need to move the position to the intersection, and then project the velocity vector onto the inclined plane and move the remaining path along the plane. However, the work of PM_WalkMove does not end there:


The coordinates and velocities obtained during the PM_FlyMove operation are saved in the down and downvel variables, then the following alternative path is calculated: trace the step height stepsize (18 units) up, move to the end of the trace, call PM_FlyMove, another trace back by stepsize down, move to the end of the new trace. As you might guess, this movement option is designed to allow you to climb steps without jumping. And the choice between the two options is made as follows:


If the trace down by stepsize intersected the slide, then we choose the first option. Otherwise, we choose the option that produced the largest horizontal movement. Moreover, in the second option, the vertical speed is taken from the first option. It sounds somehow not obvious, so let's consider a simple example. Let's say we move at a speed of 400 units/s towards a plane inclined by 45°. Two possible movement options will look like this:


Although there are no steps here, the second option wins in terms of distance. In this case, the horizontal speed will remain the same, and the vertical speed will be taken from the calculation of the first option (the projection of the speed onto the plane will give 400 * cos(45°) units/s, and its vertical component 400 * cos(45°) * cos(45°) = 400 / 2 = 200 units/s). Then PM_CategorizePosition will detect that the vertical speed is greater than 180 units/s, and will set the flag of being in the air. On the next frame, instead of PM_WalkMove, we will be taken over by PM_AirMove, which will get a speed of 400 horizontally and 192 vertically (gravity, represented by PM_FixupGravityVelocity and PM_AddCorrectGravity, managed to take away 8 units/s from us). Inside it the call of PM_FlyMove will project the velocity vector, so we will get (400 + 192) / 2 = 296 units/s horizontally and the same number vertically. From this point on, the logic of the movement really does look like what is happening on the slide: the vertical speed loses 8 units/s, the total speed is projected onto the plane and becomes smaller in magnitude. The difference here is that as soon as the vertical speed is less than 180 units/s, PM_CategorizePosition will stop claiming that we are in the air, and the speed control will again go to PM_WalkMove, which, together with PM_Friction, will reduce the speed much faster.

For this example, it is easy to estimate what the minimum initial horizontal speed should be that will allow you to go into glide. Based on the condition in PM_CategorizePosition of 180 units/s vertically, we get 360 units/s horizontally. For flatter planes, the required speed is even higher. From this it becomes clear that the usual prestrafe run-up will not be enough to go into glide. However, here comes the following idea: what if we try to do a glide by jumping while moving up an inclined plane? As we found out in the article about bhop physics, the vertical speed after the jump is sqrt(2 * 800 * 45) - 4 = 264.328 units/s, which is greater than 180, so all we have to do is gain horizontal speed greater than 264.328. But doing this with a prestrafe run-up is not so difficult, and after projecting the speed onto the plane, the vertical component turns out to be greater than at the moment of the jump, which means the jump itself will be higher. This jumping technique, which increases height by going into a glide, was once called Nannou Jump in honor of the jumper Nannou, who used it to demonstrate an extremely difficult shortcut on the map ae_strafers_heaven:


Here he accelerates with W to a speed of 277 units/s and jumps onto a wall 64 units high. According to calculations, to increase the jump height by 1 unit, it is enough to gain approximately 271 units/s horizontally. However, the difficulty here arises firstly from the fact that not all of the gained prestrafe has the desired direction, secondly, the starting point of the jump is below the foot of the wall, and thirdly, after the jump, you still need to have time to fly to the wall before the vertical speed changes its sign.

The jump height can be increased even more if there is a possibility of gaining speed beforehand. For example, the last jump on all1_hb_Johnny assumes that the speed will be gained during the fall (the block height here, according to the inscription, is 65 units):


It should be noted that the last jump of the map can be done in an alternative way by using weidjump, whichever is more convenient for you.