Hi!
After failing to create a Flyspray bug tracker account (activation link is invalid), I'd like to know if some of you know something about it.
I've noticed a weird phenomenon some time ago and couldn't find anything about/against it.
This may even be an original engine behavior - I admit, I didn't test it in the DOS version - and may not be related to EDuke32, but maybe it can be fixed.
Here is the deal:
Ingame or in mapster, by pressing forward and backward on the keyboard consecutively, you'll see that the Duke slightly strafes to the left or right. This depends on the direction you are looking to, like it depends on an axis on the map or so. If you keep it pressed, no more strafing is added, but every time you press one of these buttons again.
The farther you move, the higher the impact on the direction. The more often you press a button, the higher the angle.
Try this:
Press forward or backward once as short as you can and watch the floor below. Shortly before the Duke stands still, you can see he strafes a bit. Repeat that and you see the Duke wanders around.
I hope this can be tracked down, as it makes precise movement impossible.
Regards
Page 1 of 1
movement bug: forward/backward adds a little strafing
#1 Posted 03 May 2017 - 12:40 PM
#2 Posted 03 May 2017 - 03:02 PM
A quick test shows this is a bug going back to at least Atomic Edition and not an EDuke32 bug.
It's probably a rounding error somewhere, honestly.
It's probably a rounding error somewhere, honestly.
#3 Posted 03 May 2017 - 03:10 PM
I can confirm that this is generally quite common in older games. One very noticeable example is Nitemare 3D when holding the walk button, I've also seen it in Doom engine games and other Build games. I can only guess that it has something do do with lower precision versus later engines, everything has to come back as an integer, and... well, basically;
Sounds about right to me. I am doubtful that games such as these were really made with precise movement in mind, they aren't platformers and were instead focused on action such that you generally wouldn't notice.
Duke 3D does have slightly odd movement and collision code in that the game sometimes fails to keep Duke within bounds properly, so it's probably safe to assume that the code behind everything isn't really very precise at times.
Quote
It's probably a rounding error somewhere, honestly.
Sounds about right to me. I am doubtful that games such as these were really made with precise movement in mind, they aren't platformers and were instead focused on action such that you generally wouldn't notice.
Duke 3D does have slightly odd movement and collision code in that the game sometimes fails to keep Duke within bounds properly, so it's probably safe to assume that the code behind everything isn't really very precise at times.
This post has been edited by High Treason: 03 May 2017 - 03:21 PM
#4 Posted 04 May 2017 - 01:53 AM
Here, try using this modified GAME.CON:
http://s000.tinyuplo...746428283365664
It's not 100% accurate to Duke's normal rate of deceleration, but it's damn close, and he no longer moves in the wrong direction at the end.
This will not be corrected without a mod like this, because it falls under the category of classic gameplay behavior. Similarly, there will not be any source level "fixes" for other quirky behavior in the original game, such as how Duke moves faster when strafe-running.
CON code in case anyone is curious:
http://s000.tinyuplo...746428283365664
It's not 100% accurate to Duke's normal rate of deceleration, but it's damn close, and he no longer moves in the wrong direction at the end.
This will not be corrected without a mod like this, because it falls under the category of classic gameplay behavior. Similarly, there will not be any source level "fixes" for other quirky behavior in the original game, such as how Duke moves faster when strafe-running.
CON code in case anyone is curious:
gamevar logxv 0 0 gamevar logyv 0 0 gamevar xvel 0 1 gamevar yvel 0 1 gamevar decay 0 1 gamevar moveang 0 1 move PGROWINGPOP // Used only as a variable actor APLAYER MAXPLAYERHEALTH PSTAND 0 0 ife input[].fvel 0 ife input[].svel 0 { ifg decay 1 { cos xvel moveang sin yvel moveang mul xvel decay mul yvel decay setp[].posxv xvel setp[].posyv yvel } else { setp[].posxv 0 setp[].posyv 0 } mul decay 5 div decay 6 } else { getp[].posxv logxv getp[].posyv logyv getangle moveang logxv logyv ifl logxv 0 mul logxv -1 ifl logyv 0 mul logyv -1 add logxv logyv sqrt logxv decay shiftr decay 4 }
#5 Posted 04 May 2017 - 01:38 PM
Thank you all for your comments, now I don't feel alone anymore.
Special thanks to you, Trooper Dan, for providing this workaround!
Special thanks to you, Trooper Dan, for providing this workaround!
#6 Posted 04 May 2017 - 03:39 PM
WKjun, on 04 May 2017 - 01:38 PM, said:
Thank you all for your comments, now I don't feel alone anymore.
Special thanks to you, Trooper Dan, for providing this workaround!
Special thanks to you, Trooper Dan, for providing this workaround!
It was fun, and in the process I learned how to do better ice physics, if I ever have to put that in a mod again.
#7 Posted 20 June 2017 - 06:54 AM
That's an old bug...
It's been a long time since I've noticed that...
It's been a long time since I've noticed that...
Share this topic:
Page 1 of 1