Search In
• More options...
Find results that contain...
Find results in...

# DooM Speed Bug.

## Recommended Posts

If you have a transparent wall like midbars3 and you run along it, pressing in against it, you will get a speed equal to turbo 255!.

AFAIK it's with all (not olny 'transparent') walls which are running north/south (?).

Any wall running north/south with no doors etc in it i think

It's called wallrunning, and it only happens in select places (most commonly with perfectly south-north walls) due to trig errors in the doom engine. The error is such:

You send a command to the engine to move a few units. Of these units, we can turn them into a parallel (to the wall) component and a perpendicular component. The parallel component is the speed along the wall, and the perpendicular is the speed into the wall.

Normally, when you crash into a wall, you slide along it. This is how the engine calculates this slide: first, it moves you to where you'd end up if you were unobstructed. Then is finds you were obstructed, and moves you back. Then is calculates the parallel component with respect to the wall you crashed against, and moves you that far. If that hits another wall, it moves you back, and does the parallel-speed calculation again, this time with your new speed and wall.

The wallrunning bug occurs due to sign errors in the trigonometry lookup table. Say you have a velocity X, composed of parallel_X and perpendicular_X. Lets say you're running into a wall and the angle between your desired direction and the walls direction is Q.

perpendicular_X = X*sin(Q).
parallel_X = X*cos(Q).

However, because of a few errors in the trig lookup table, cos(Q) returns a number of the wrong sign! That means if you add the vectors X, -perpendicular_X, and -parallel_X, instead of ending up where you started (which is the assumption in the code), you end up warped down the wall. How much down the wall? Well, if you draw the triangle that this forms, you find that you're warped according to the cosine law of triangles:

Your difference D_X from your original position (along the line of the wall) D_X^2 = X^2+ X^2 -2X*Xcos(A) where A is the angle between the two movement vectors.

D_X^2 = X^2+ X^2 -2X*Xcos(A)
D_X = sqrt(2X^2 * (1 - cos(A))
D_X = X sqrt(2-2cos(A)) +

What is A? A is simply (pi-2q) radians ... because the sum of the angles in a triangle is pi, and you have 2 angles which are q... Now, recall from trigonometry that cos(pi-x) = sin(x).

Now not only does this warp you down the wall, but it also moves you ALONG the wall with your parallel velocity, as it would normally.

M_X (total movement) = D_X + parallel_X
= X sqrt(2-2sin(2q)) + Xcos(q)

Obviously to get the maximum 'speed' you want to maximize D_X (to warp farther). The way to do this is to minimize q. At one point i found that the maximum theoretical speed was ~400% normal. Notice though that this does not monkey with your momentum -- since instead of moving you faster it just warps you along the wall. Therefore as soon as you get off the wall, you are moving with a regular rate.

There you have it - the wallrunning bug. I believe (but have not verified) that the wall pass-through in map17 (and perhaps even the squeeze-throughs in map19 & others) also are due to this bug - except they get warped along the perpendicular axis.

Given that you're pushed along the wall parallel_X twice due to the bug, and then moved parallel_X after, that's 3 times parallel_X. Seeing as the maximum straferunning speed is 128% normal maximum speed that gives a figure of 384% times normal maximum speed for wallrunning.

For perfect straferunning, maximum speed is 141% ... so wallrunning pefrect straferunning ideals out at 423%

Of course these are ideals and should be impossible to reach (as q = 0 so you're not moving into the wall at all so the effect is not triggered!)

I should have known. I mean, Duhh, I have a 98 in Technical Math and I couldn't figure it out. Guess next time, I should look at the source code, eh? ;)

And on a side note, completely unrelated to this, anyone else notice that they get an error while trying to start a csdoom server with FF_I? =)

tarin said:

AFAIK it's with all (not olny 'transparent') walls which are running north/south (?).

Tarin, yes it is.