Ive been struggeling for the longest time now with how to correctly slow down time in my game.
Ive tried to keep it simple and get it to work correctly and precisely in a simple scenario 'a falling rock affected by gravity'
Ive been following an example wich states that this is how you do it:
Set SpeedY_ to: SpeedY_ + GravityStrength_ * TimeRatio_
Set Ypossition to: Ypossition + SpeedY_ * TrimeRatio_
However, doing the math on this produces inaccurate results.
Ive also tried few other methods and solutions, but i cant get it to work and i cant seem to wrap my head around it.
What i want to do is simple enough:
I want a falling Rock affected by gravity, to move the same distance accross 2 frames at 100% speed, as it does across 4 frames at 50% speed.
I know this is not an easy question.
Could someone pleace help me slow down time?
I have not tried this myself. But I am always leery of trying to make MMF2 do things with anything other than a complete integer and I avoid most decimals. One thing I would suggest as a possible solution is to create the game with its native state as the slow speed, and then multiply everything from there.
In other words, the regular pace for the game is at 50%, but unless the "slow down time" feature is activated, the game always works at double speed. the player won't know the difference, and when you want to switch the game to the slower speed it would work fine.
At least theoretically, this works in my head. Good luck to you.
Are you trying to manipulate the object's Y position directly? You can't move something by 0.5 pixels, so you can't treat coordinates as floats. Just use an alterable value for all your calculations and then, after the rest of your movement events, set the object's x and y to the appropriate values. Sorry if I misunderstood
If it's any consolation, I can't get the Maths to work either, and I wrote the article
All I know is it works... somehow, by some evil trickery... it works
If you plug the formulae into an object in MMF, it'll jump and fall consistently across different time ratios. So I suspect we're just not testing/understanding the arithmetic properly.
Yeah, basically I had a problem with getting gravity to work myself, and found the solution that worked for my example was the one I mentioned in the article, which is shown in the examples, namely to apply the ratio on gravity twice - once to account for the fact that gravity is applied more often at slower speeds, and a 2nd time to reduce the on-screen display speed.
The maths do kind of work if you walk through them in excel, but they're still inaccurate over time. In my tests, I start with an upward inertia of -5px per frame. On each frame we apply 1px * time for gravity to arrive at a revised inertia, then apply time again on the total inertia remaining. The figures are close enough if you compare different rates side by side, but even so they do drift apart over time. Thankfully, it doesn't really notice in a game.
The issue behind it is the use of compound percentages - suppose you charge someone 25% of £1000 each year (£250). Your boss decides he'd rather charge them twice a year to improve cash flow. But look at the math:
First six months: 12.5% on 1000 = 125.
Second six months: 12.5% on 1125 = 1265.63.
See that it doesn't add up to the 1250 that it would if you'd applied only one lot of 25% rather than two lots of 12.5%?
I think that's what's happening, in which case I'll need to use a variation on compound interest calculations to sort it. D'oh!
Well i am in the process of figuring out an accurate method for slowing down time, specifically a method that 'applies gravity correctly' because this is what is causing the inaccuracy in the first place.
Ill try to convey the basic idea behind this throug an example:
If the timeRatio is 0,25 ( 25% game speed ), gravity should only be 'applied' every 4 frames ( not every single frame, while objects still move every Frame )