Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Linguica

The Doom Movement Bible

Recommended Posts

Is there anything that would lead to one-sided and two-sided linedefs being treated differently when it comes to wall running? I have a memory of an outdoor TeamTNT DM level where you could wallrun around the perimeter fence really easily. As I remember, the fence was a simple axis-aligned two-sided impassible linedef box.

Share this post


Link to post

Yes, for some reason 2S impassible linedefs are ignored by the PTR_SlideTraverse function, which checks to see if a linedef can be slid on. More specifically, the pseudocode is like:

if(line is 1-sided OR opening is too short OR ceiling is too low OR floor is too high)
    add to line slide list
else
    return
Note that it never actually just checks if a linedef is impassible. Sliding along 2S impassible lines ends up being functionally identical to thingrunning - the engine never knows what to do so it always resorts to the stairstep routine. (So if the 2S impassible linedef happens to be axis-aligned it will work "normally", even though it's kind of an accident.) That's why rubbing on the fence to the left of the start of Doom 2 Map01 feels so weird.

Share this post


Link to post
chryso said:

Is there anything that would lead to one-sided and two-sided linedefs being treated differently when it comes to wall running? I have a memory of an outdoor TeamTNT DM level where you could wallrun around the perimeter fence really easily. As I remember, the fence was a simple axis-aligned two-sided impassible linedef box.


Linguica beat me to it, but you can construct a square room in any map editor to create/duplicate the scenario. Place one 2 sided line and run against it. Now opposite of that line create a rectangular sector equal in length, and raise that sector 32 pixels high. You can compare the difference that way. I've used raised sectors as windows or other objects to get around it, and I'm sure I wasn't a pioneer. I think earth.wad from 1994 gave me the idea.

Share this post


Link to post

Oh the fun...

That brings back memories of 12-13 years ago when I ran into all those glitches and tried fixing them.

To be honest, I'd have problems playing with all those things still present these days.


That 2s omission in the sliding code was the first one I went after back then.

Share this post


Link to post

I always thought they must have done collisions with square box, cause with circle the player would be stuck in every 270 degree corner when sliding a wall. I wonder if in todays games the still have cube as a collision box. I would even trust it, cause its a lot simpler and saves a lot of pain in arse.
Only one bad thing about it . Does this mean that in orthogonal direction you will pass 32 pixels wide corridor and in diagonal 45 degree the corridor will have to be 32*sqrt(2)?

Share this post


Link to post
NinjaLiquidator said:

Does this mean that in orthogonal direction you will pass 32 pixels wide corridor and in diagonal 45 degree the corridor will have to be 32*sqrt(2)?

Yes. It also implies that every hitscan/projectile attack has a higher chance to hit a thing under a 45 degree angle than under an orthogonal angle, simply because the thing's "radius" is wider at 45 degrees.

Share this post


Link to post

Adding my vote of approval. Great job, Linguica! This must have taken you weeks to research, and it answers countless questions on this and other forums.

I guess in your research, you added some instrumentation to your personal Doom source port. For example, the display of the TAP. I'd be interested to know (without too much hassle), what statistics and instrumentation you added, and how you captured and studied that data. Cause I can imagine that this would require analysis of a lot of data, while being able to repeat very specific tests!

Again, your efforts are very appreciated. Wow!

Share this post


Link to post

Here's my vote to sticky this thread.

Share this post


Link to post

amazing info, thanks

make it sticky, link it to the wiki or so

Share this post


Link to post

What about the monster's ability to activate slow walkthrough lifts and them always being stuck when they're on an edge?

Share this post


Link to post

^ The slow walkover lift is one of several linedef types hardcoded so that monsters can activate them. And when a monster happens to be in a place where the height difference between its feet and the lowest point on the floor below the monster is greater than the max step height (24 units), and cannot get out of such a position by making a single step in any direction, the monster becomes stuck.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×