Sorry your browser is not supported!

Could I interject into this argument to request all the feuding participants to post their *ideal* code for their *ideal* solution. I realise code has been posted above but I detect from the development of the argument that some of that code might usefully be reconsidered.

If code is posted, that way the rest of us can at least see precisely each protagonist's solution and give it a test, and then wade in with views.

This is the first code I posted in this thread, with some minor modifications.



To add smoothing by averaging the factors over a short amount of time. Change your function to this.



You can change the value of smooth to whatever you like to add more or less smoothing. You'll have to test it to see what gives you the best visual effect for your particular application.


Q: Why do you divide the number of milliseconds per loop by 1000.0?
A: When setting up a game you need to know what scale you will be operating in fairly early in the design so that models can be made the appropriate size, and speeds and distances can be set.

For example, if your model is supposed to move 10 DBPro units per second, then "MOVE OBJECT Obj, Speed * factor#" should give you that speed multiplied by the proper decimal representation of the number of seconds that have passed since the last move.

So if 14 milliseconds have passed since the last move, 14 / 1000.0 = 0.014 seconds and if Speed = 10 then in that time the object should move 10 * 0.014 = 0.14 DBPro units.

Multiplying that out we get,
1000 / 14 = 71.43 Frames per second
0.14 * 71.43 = 10.0002 DBPro units per second


Hopefully that clarifies things.

I don't think anyone has any dispute with the first code box above. It's standard among many other TBM examples I've found on the net for other game engines.

The smoothing was not my idea, but when I found it I tried it, and it smoothed out a problem I was having with jerky movement. Use it, play with it, change the smoothing value, and see if it helps. If not, pull the averaging code out and go with the original code.

Kistech, might want to check what variable `h` is for.

Also, is there a reason to do everything in floats? Why not divide once right at the end for factor# and save all the float additions etc. Or am I missing something. (Never having run your example)

When I implement timer based movement, I tend to implement it from the start. The code becomes part of the main loop, like this:



Like KISTech, I also prefer to divide by 1000. That way "speed" becomes that much easier to grasp since it's in pixels/second or units/second. Very useful if you're programming a game where you use - let's say - 10 units for 1 meter.

Cheers!
Sven B

@KISTech

Thanks for posting your code. I do have a couple of observations. It seems to me, and maybe I am missing something, that you have at least three or four local variables in your function when I think you intend them to be globals. These include "flast", "h" and "t". Is "t" supposed to be "h" - I'm guessing this is a typo? Otherwise t isn't used at all and the function doesn't work.

Also, precisely what, if anything, is your function returning? Presumably nothing? I also assume that factor# is also supposed to be a global?

And shouldn't the "factors(smooth) = Diff# / 1000.0" line be in the for next loop? As presently written, only the array entry at factors(30) will update.

At the moment I'm reading your code as conceptual. I understand what you are trying to do. But your code doesn't actually work as presently written for the reasons set out above.

[face -> palm]
My bad. It's been corrected.



If you look at the upper code those are globals, and h was supposed to be t.

The second code piece variables are meant to be in addition to what is shown in the first one.



No. The for next loop is moving all of the array elements UP one slot overwriting the first, and then the current value goes into the last slot (in this case 30).

The function doesn't "return" anything, but sets factor#, which is a global.

With the addition of the variables from the first code box, and the corrected typos, this should work fine now.

[face -> palm]

My bad. I only looked at the second code box, not the first. *embarrassed cough* Apologies!