I’ve done quite a bit of searching, but I can’t find how to set JMonkey or JBullet to run at faster than real speed. I.e. running at 2X speed, the tpf passed into everything would be double what it would normally be. I’d be using this to test out some quadcopter stabilization logic I’ve written in faster than normal time.
Sorry if it’s a simple question, but I couldn’t find the right search terms.
Thanks for the suggestion Normen, but I’m trying to test the effectiveness of different AI behaviors. These can be simulated without the need for player input, and instead of waiting for each to play out in real-time, I’d prefer to be able to run them as fast as I can without the physics getting jumpy. I realize I could increase gravity and scale my forces, but I was looking for a neater way to do it.
(Also, it could be a cool play with as a game mechanic…)
Still, debugging an application with physics is an headache. I managed hacking JME by setting the tpf manually, but I was not able to find the same hack for physics...
LOL if you do things like manually “hacking” and setting tpf then you don’t need to wonder why everything is strange, doing that is very wrong ^^ The solution to change the speed was given here if you care to read. I think you just need to get a better grasp at what you’re doing, its not exactly hard.
Yes, I can understand that. But sometimes, I need several minutes figuring out what’s happening, since I’m working on some tricky multi-agent AI algorithms. Even at slow speed, this is simply too long.
Setting tpf manually makes each step the same length, whatever the time I need to check it. The idea was given to me by the Video-recording appstate, which makes the framerate a steady 30 frames per second, whatever the real time needed.
Nope. If I did that, time would still run while I was debugging. I simply changed the tpf variable as the first action of the update method. It works only because all is done in a single method. This is why I was talking about ‘hack’. Not clean, but easy and efficient.
Of course, this is not scalable. If you have several application states, I think you cannot do that.
Is there a clean way to achieve this, “pausing” the simulation during debugging ? Without this, next tpf is several hundreds… And it becomes impossible to track the system evolution.