3dfxdev / EDGE

EDGE Source Code
http://edge2.sf.net
74 stars 10 forks source link

player movement 'inertia' seems funny in 3dge #24

Closed ryan-sg closed 7 years ago

ryan-sg commented 8 years ago

So, I have noticed this for a very, very long time. It is probably the only thing that annoys me a bit about the edge engine and thus 3dge that follows.

When moving around at high speed, if you hit a wall, to move away from it it almost feels like you are fighting the marine from trying to continue to run into the wall. It seems like the game keeps player movement inertia going even after hitting a wall, something that the original game seems to stop from happening once you hit something.

A good test is any map with an exit behind a door in a straight line -- if you run full tilt at the door, as you hit the door, release the forward key and hit the open button, the marine blazes through the door once it opens at the same rate of speed as if you were still holding forward key. Works best on those 'quick' doors.

I hope I've explained this well enough, the effect causes you to kinda 'stick' to things when you hit them at high speed making counter-retreat harder. I am not sure the functions in use here, but if there is something that dictates movement of the player from ..inertia or gravity if you will, should it maybe reset to 0 once the player hits an immovable object/wall so that movement in another direction doesn't have to wait for the 'slow down' of running into said immovable object/wall?

Corbachu commented 8 years ago

Yeah, i saw PrBooms implementation, so I will modify and integrate it in the engine soon :)

ChillyWillyGuru commented 8 years ago

EDGE keeps track of an object's momentum in 3D. There are cases where it clears the momentum, but clearly it's not in this case. That was the cause of the jump bug we fixed - the movement code didn't clear the z momentum on one case, leaving the player with some momentum when they next jumped that had to be countered.

ryan-sg commented 8 years ago

thanks for the insights @ChillyWillyGuru! Another possibly easier test case for this is just strafing side to side at the beginning of doom2 map01. If you counter your strafe direction before you hit a wall on either side, the direction change is quick and responsive. As soon as you hit a wall before countering the strafe, definitely feel the 'stickiness'...as it were.

Corbachu commented 7 years ago

The momentum bug has now been fixed; Chilly cleared it if there is no sliding that can be done, as of commit 18bb710. Try it out and verify -- if it looks good, I will close this.

ryan-sg commented 7 years ago

hey hey! I just checkout out master and gave it a whirl. Unfortunately, it still seems pretty sticky to me, if i run head-on into a wall and try and back away the moment i hit, there is still a bit of a delay. I thought it was weird that bobbing was stopping when i hit any walls, but then i noticed the commit about it being intentional, so i'll get used to it ;-)

edit: trying to run around the outside of the 2-pillar room you start in on map01 doom2 seemed to be a good comparison between prboom-plus and 3dge for me, in 3dge, most of the time i end up getting stuck in the hallway cuz the marine slips in there the moment he leaves the wall in the hallway gap. in prboom-plus i am able to fly around the walls and miss the hallway with relative ease. I can also crash into corners in prboom-plus and escape again pretty easy, where in 3dge i tend to get stuck and need to wait for things to 'settle' before moving again. this stuck state happens pretty quickly, so we're talking less than 1sec here, but noticable enough during regular gameplay that I usually end up many times in places i don't want to be ;-)

Corbachu commented 7 years ago

So are you talking about the time it takes for Doomguy to stop moving once you let go of the key?

ryan-sg commented 7 years ago

Nope, that actually works fine as long as I let go of +forward /before/ I hit a wall. Just did a quick comparison between prboom-plus and 3dge and it seems pretty much spot on.

Only when I hit a wall direct. Maybe I try to explain another way, before I try and find some sort of recording software to make videos :-D

These two executions:

prboom-plus -nomonsters -warp 1 3dge -nomonsters -warp 1

Run straight up the stairs and bump the wall. As soon as you hit the wall, hit +backwards.

In Prboom-plus, the backwards movement starts immediately, in 3dge, I am stuck to the wall for some small amount of time <1sec. Same when hitting a wall in reverse then trying to go forward.

Alternatively, just stand at a wall and run into it. Then hit your +backwards key. Prboom-plus no matter how long i hold +forward into a wall, as soon as I hit +backwards I start moving backwards. In 3dge, if I stand idle at a wall, then hit +backwards, I immediately move backwards. If I hold +forward while standing at the wall, then go to +backwards, there is that same delay.

Apply that logic to any time you actually hit a wall, and thats where I get the real sticky feeling if I bump into corners when moving around fast, as that happens no matter what angle I hit.

I am starting to worry that this behavior might be specific to me :x

ryan-sg commented 7 years ago

It almost seems like, after doing the tests /without/ hitting a wall, that 3dge uses the exact same calculation of slowdown when running into a wall (while standing up against it) as it would if you were running freely then immediately hit +backwards.

Corbachu commented 7 years ago

I have implemented a fix:

In P_XYMovement:

            if (blockline && blockline->special)
            {
                P_ShootSpecialLine(blockline,
                    PointOnLineSide(mo->x, mo->y, blockline), mo->source);

                // CA 8.7.17: 
                //reflect momentum away from wall (try to fix sticky walls physics?)
                // Seems to work in making things less "sticky".
                mo->mom.x = mo->x * 2 - mo->mom.x;
                mo->mom.y = mo->y * 2 - mo->mom.y;

                if (!P_TryMove(mo, ptryx, ptryy))
                {
                    // // CA 9.21.17:  Can't move, clear momentum
                    xmove = ymove = 0;
                    mo->mom.x = mo->mom.y = 0;
                }
            }

Verified to finally fix the inertia clearing bug! =)

usernameak commented 7 years ago

More than year!

Corbachu commented 7 years ago

I know, but with time comes knowledge ;-)