But it does day it has a master control for animation speed.
So if you want to call it four times, you could call it with an anima speed of (1.0 / 4.0), ie: 0.25.
But that assumes you know how many times you're going to call it per loop before you actually start calling it.
Then again...
Maybe you cal call it with an anim speed of 0 as many times as you like, and only call it with an anim speed of 1 at the end. After all, you DO NOT want your objects moving while you are in the middle of updating your physics, which calling it with a number other than 0 would do, IF you were using render tweening.
Also, calling it with 1 all the time is okay as well, because the first time you call it everything would go to it's "final resting position" and from there could not move.
Hm... But if you moved things with physics and called it again, they would move. But you want them to move when you move them with physics because you want to check that the collision occured as expected.
Hm. This makes me think that doing physics with render tweening isn't going to work very nicely. If my physics says to move the box to position X, and the next time I update my physics it's not yet at position X like I expect it to be, that's not good. Probably.
I think the solution here is to ignore Blitz's render tweening system which is woefully inadequate and broken, and just go with variable framerate updates, which are much easier to code, or write your own render tweening system. Though that will require you to write a lot of code for animating entities and brushes and things between a set of values. Convieniently I recently released a couple systems which would be perfect for that though. :-) And they're free so you can't complain about that. :-)
So if you want to call it four times, you could call it with an anima speed of (1.0 / 4.0), ie: 0.25.
But that assumes you know how many times you're going to call it per loop before you actually start calling it.
Then again...
Maybe you cal call it with an anim speed of 0 as many times as you like, and only call it with an anim speed of 1 at the end. After all, you DO NOT want your objects moving while you are in the middle of updating your physics, which calling it with a number other than 0 would do, IF you were using render tweening.
Also, calling it with 1 all the time is okay as well, because the first time you call it everything would go to it's "final resting position" and from there could not move.
Hm... But if you moved things with physics and called it again, they would move. But you want them to move when you move them with physics because you want to check that the collision occured as expected.
Hm. This makes me think that doing physics with render tweening isn't going to work very nicely. If my physics says to move the box to position X, and the next time I update my physics it's not yet at position X like I expect it to be, that's not good. Probably.
I think the solution here is to ignore Blitz's render tweening system which is woefully inadequate and broken, and just go with variable framerate updates, which are much easier to code, or write your own render tweening system. Though that will require you to write a lot of code for animating entities and brushes and things between a set of values. Convieniently I recently released a couple systems which would be perfect for that though. :-) And they're free so you can't complain about that. :-)