As can be observed in various levels, X-Moto's physics don't always work the same - in "Keep-Calm", for example, you don't press any button in the beginning, yet your chance to survive the first obstacle is only about 50%. This is quite annoying, even more so if the rest of the level is hard enough on it's own
[I managed to complete all levels but Cow 2 and Keep-Calm, but this issue demotivates me so much there that I don't really want to try them anymore]
Well, anyway: I just wanted to ask if this behaviour is the result of simple imprecision or randomness by design, and if there is anything that can be done about it. And if other people are bothered by that as much as I am :)
Yikes... Just did a quick search in the ODE sources for rand() and found out that randomness apparently is part a speed-optimization they are using...
Actually I thought it was deterministic.
I'll see if I can disable it, but I'm afraid that tinkering too much with ODE will cause unstability.
Hah, I knew it had to be something like this =/ Maybe it would be best to approach the ODE-developers - after all, they know their code better than anybody else. I can't imagine X-Moto is the only appliance of ODE that would benefit from full precision.
I already know what they would say: "Hey, just don't use the QuickStep algorithm!".
ODE supplies a range of different algorithms to use... the default (slow and accurate) one seem to lack any rand() calls. The problem is that all the hundreds of physical parameters of xmoto are calibrated to work with the current algorithm... when I change to the accurate algorithm, it doesn't work so well.
Ugh. I see :(
I just made the change to my local copy and tested it. The game physics feel about the same; except for Keep-Calm which directly needed the random behaviour everything seems to be neither harder nor easier. So, from my POV changing Keep-Calm would be enough - no tweaking of constants needed :)
The only concern left would be system requirements... quadratically rising complexity sounds problematic :/
"quadratically rising complexity" shouldn't be a problem as there's always a fixed number of physical bodies in the game (at least as it works now). The computational complexity is always the same.
The problem is that when using the non-QuickStep function, ODE spams the console periodically with various warning messages... at least on windows. That can't be optimal :)
Well, as you said in some other post you wanted to enable more dynamic objects that would be influenced by physics I thought it could get a problem later - especially as I can't really tell how effective the precise algorithm is, you don't notice any speed difference on a 3 GHz CPU ;)
I didn't notice the messages before because I started X-Moto via KDE menu. Hm. I guess you mean those (though they're not warnings, but errors):
ODE Message 3: LCP internal error, s <= 0 (s=-2.0410e+04)
They look suspicious indeed :/
A little bit of googling shows that many people fight with the LCP problem and that no one seems to have a really good solution. It's an internal error of ODE. The only hint that cropped up here and there was "it's caused by too tight constraints.... e.g. lowering the 'stiffness' of joints should make it have less LCP errors".
Well, anyway: It sounds as if the errors could safely be ignored. Maybe you should just try to suppress the output to the terminal?
Hmm... I'm afraid it's not that simple... I've experienced that those LCP errors can cause the game to explode - with bike parts flying all over the screen... quite spectacular, really, but not that playable :)
It's when you really stretch the bike and apply unusual forces to it.
Of course it could be just a matter of tinkering with the xmoto physics parameters. If you look at PhysSettings.h there's some alternative settings... those where the result of me playing around with it a while a back. They doesn't work as-is, and unfortunately getting to work will probably also require changing a lot of the other physics code.
The wheels' constraints are the problem - there is nothing pre-made in the ODE library that can be used for simulating it (it's not normal to have wheels moving in all directions, usually you limit their movement to the axis of the suspension). Because of this I hacked together something that did not use the internal constraint system of ODE, but instead updated the forces manually. And that's very difficult to keep stable (hence the high framerate requirement). The optimal solution is to make a custom constraint and integrate it into ODE, but that task seems rather overwhelming at the moment.
The problem is that I've already spent too much time on it, and I think there's more pressing matters. :)
Whoops, exploding bikes sound spectacular indeed :)
Anyway, I guess you're right to implement other things first. Just keep it on the TODO so it's not completely forgotten... Maybe someday you wake up with a great idea how to solve this problem more easily ;)
And one last post:
There _is_ a feelable gameplay difference I somehow didn't notice before: If a wheel gets stuck in a right angle of the terrain, it doesn't shake out by itself. This means it gets harder to climb small stairs like at the bottom of Muzakka.
I guess there's a simple solution for that, though.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.