Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Movement changes
- - Date 2019-05-01 14:58
Parent - - By Marky [de] Date 2019-03-09 09:26 Edited 2019-03-10 10:14
After digging through the movement code, I think that some of the "weirdness" in object movement (most of the times it behaves OK, but sometimes it is really strange) comes from the fact that objects move horizontally first. So, if an object has xdir 100 and ydir 100, it will try to move 10 pixels to the right first, stopping if there are any collisions, and only then it goes down. Looking at this I am surprised that diagonal movement (jumping, thrown objects) work well in our game :D, but of course the velocities from jumping and throwing are usually so low that the effect may not be as noticeable.
After the pull request I *might* want to try a branch that has a different motion strategy, with the following conditions:
* it is really just experimental, so I will not be surprised if we decide to not change that
* it may change the behavior of objects significantly, maybe breaking existing "veteran tricks" or even existing scenarios that rely on the current behavior
* it needs a good testing scenario that contains some typical movement patterns from the game, as well as the special cases here. This can and should be done before creating the branch, though :)

What are your opinions?

Edit: Moving horizontally first may have something to do with the gravity movement, just a note for myself.
Parent - By Zapper [de] Date 2019-03-09 13:17
Yes, please! I definitely think it's a good idea to revisit the movement code.
That's one of the main points that are basically always criticized in reviews (getting stuck on edges, awkward walking/scaling transitions, ...). So I definitely think it's worth a try :)
Parent - - By Luchs Date 2019-03-09 19:13

>it needs a good testing scenario


Another important factor here is the performance. Doing "better" movement probably means doing more work. Unfortunately, we currently don't have any benchmarks, so this is really just a  potential issue to keep in mind. However, people are already complaining sometimes that the game is running too slow and then we have no idea why.
Parent - By Marky Date 2019-03-14 20:07
Added a benchmark scenario. It runs various tests, until the game either hits 5 FPS or until one test run is going on for 2 minutes. Feel free to expand it :)
Parent - - By Caesar [jp] Date 2019-03-10 13:24
Wasn't the reason for that movement behaviour that sideways movement is directed upwards if it hits a wall, or so? It's been quite a while since I dug through that code, but I thought it somehow made sense…
Parent - By Marky [de] Date 2019-03-10 18:51
I am not sure if that is the reason for that movement behaviour. The redirection follows from the implementation, though. However, it should be possible to keep this behaviour with a different strategy.
Parent - - By Marky Date 2019-03-16 11:39
Did a significant change, in the benchmarks the code runs at roughly the same FPS (+/- 1, which I think is just the average noise I assume). Differences:
- in Tests.ocf/Movement.ocs the motion with very high velocity ends up in the corner, as does the motion with low velocity. Downside: The Clonk starts tumbling, because it still hits the landscape (although realistically should not)
- in Tests.ocf/Movement.ocs the rock does not fly around as much

You can try it out yourself with the code here: https://github.com/gitMarky/openclonk/tree/movement

High velocities are handled poorly in the engine, though: When you move a Clonk with SetSpeed(1000, -1000) while flying, the ydir will decrease to 0 due to friction from hitting a ceiling very slowly, and the Clonk just sticks there for a few seconds. My expectation is that the Clonk would stop and fall down immediately, however I have no *good* solution for that. The only solution I have is set the velocity to 0, but that would stop things on every little contact with the landscape.
Parent - - By Luchs [de] Date 2019-03-16 14:44

>You can try it out yourself with the code here


You could also push the branch to the main repository, then we'd get snapshots for it!
Parent - - By Marky Date 2019-03-16 15:16
Hmm, but how can I delete the branch again then?
Parent - By Luchs [de] Date 2019-03-16 15:56
git push origin :movement
Parent - By Caesar [gb] Date 2019-03-16 15:57
git push origin :some_branch should do the trick.
Parent - - By Marky Date 2019-03-30 15:43
Did that, the branch movement_changes is my latest version of the movement code. It makes some stuff more unified, but it is not optimal. Benchmarks run at about the same speed as before, there are no significant performance changes on my notebook. I'll be glad for a review and testing, of course.
Parent - - By Marky Date 2019-05-01 14:58
So, did anyone test it? For me it looks okay, and I'd like to continue working on that one, but I do not want to base further work on it if it gets rejected. It is one of the bolder changes, but not really new.
Parent - - By Clonkonaut Date 2019-05-01 15:48
I did some testing now, just playing around with regular objects in the game (catapult, cannon). Couldn't spot any wrong behaviour but was also unable to see any improvements. Are there specific things that work better after your changes?
Reply
Parent - - By Marky Date 2019-05-01 16:03
There is a test in Tests.ocf\Movements.ocs: If you launch an object with say xdir = 1000, ydir = 1000 down a tunnel (that has the same angle) and the path is free, then the object will move down that tunnel. On the master branch the object will first try to move 100 pixels to the right, then hit a wall, and tumble right away. It is an edge case really, but it should make projectiles that rely on our ingame physics behave better. Collisions with the walls may behave differently, though, meaning: less sliding all over the place.
Parent - - By Clonkonaut Date 2019-05-01 16:23
Yeah, I started the test, it did 3 out of 4 (and then failed) but there isn't much to see. We don't really encounter the situation you described but if it works better now then I don't see a problem with merging your changes.
Reply
Parent - - By Zapper [de] Date 2019-05-01 16:58

>We don't really encounter the situation you described but if it works better now then I don't see a problem with merging your changes.


I encountered that every time I made fast moving proectiles in Clonk (first time for CR Caedes in 2005) - and I always just wrote my own physics by hand. Maybe it makes a change for musket shots (if they even use the normal movement logic)
Parent - - By Clonkonaut Date 2019-05-01 17:19
Yeah, I'm sure some whacky 3rd party mods will benefit from the change.
Reply
Parent - By Caesar [jp] Date 2019-05-02 06:33
Hm. I do wonder about the CR Hazard laser grenade…
Parent - By Marky Date 2019-05-01 19:34
Yes, if you compare the behaviour with the master branch, then you'll notice the difference: On master the high velocity launched clonk will tumble, but the rock will pass and jump over that wall and land on the other side. On the changed branch, the rock does not jump over that wall, therefore the test fails. Personally I do not mind that, but it could mean that some scenarios that rely on particularly this behaviour may break.
Parent - - By Clonkonaut Date 2019-05-01 17:42
Okay, I do have one complaint. Duplicating objects in the editor crashes with your changes. :(
Reply
Parent - - By Marky Date 2019-05-01 18:22
Good to hear! That means I can find the problem and fix it :)
Parent - By Isilkor Date 2019-05-01 20:04
Reply
Parent - By Marky [de] Date 2019-03-24 10:44
Still trying out various things with the movement code - I'll sum up the insights here. Some of them are pretty obvious, but it may help understand things:
* The movement distinguishes between attached movement (walking, climbing) and free movement (anything else that just sits in the landscape (lorry, chopped tree, rocks).
* During free movement the velocity of the object is redirected between components, and the logic is as follows: Move horizontally first, if you get contact redirect the horizontal velocity upwards. Move vertically with the adjusted velocity. If you hit the landscape again redirect the velocity sideways, etc. This is important, so that objects can be pushed over small bumps in the landscape, but it also causes really strange things, such as fast rocks flying upwards, etc.
Up Topic Development / Developer's Corner / Movement changes

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill