Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Timer based movement ?

Author
Message
Serge Adjo
19
Years of Service
User Offline
Joined: 3rd Aug 2006
Location:
Posted: 15th May 2010 21:00 Edited at: 15th May 2010 21:31
when the program run slowly the player move slowly, but if the program run fast the player move fast... there's no canstant speed for the player... So please how can I achieve easily 'timer based movement' for my current project in a few lines of code using I suppose the command TIMER()... and without any plugin (I've already tried some plugins) ??

EDIT: I've also tried the functions provided in an older newsletter but didn't worked ...
I've also looked at this: http://forum.thegamecreators.com/?m=forum_view&t=149887&b=7 but when I use the KISTech's function I don't get constant results...

Nizze
18
Years of Service
User Offline
Joined: 12th Jan 2008
Location: Right here - where else?
Posted: 15th May 2010 21:31
Try:

Speed# = 1.0 * (60.0 / screen fps())

Where 60.0 would be replaced with the framerate you've set your program to run at and 1.0 would be replaced with the speed you want your character to move with when the program runs at the set framerate. Hope that helps.

long Array[2147483657][2147483657][2147483657][2147483657];
What could possibly go wrong??
Indicium
18
Years of Service
User Offline
Joined: 26th May 2008
Location:
Posted: 16th May 2010 01:29
Quote: "Speed# = 1.0 * (60.0 / screen fps())"


If you're going to do that, at least do this:


Rawwrr. Sig Fail.
Newcastle is awesome
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 16th May 2010 04:50 Edited at: 16th May 2010 04:53
I have actually modified that code since then to make it smoother.



The reason is, if your computer is going much faster than the desired movement rate, then factor# will be 0.0 which means nothing moves. By averaging it over the last 30 frames, you get nice smooth movement.

By the way, I think it's a little further down in that other thread, but there was significant discussion about how your movement code should be based on TIME, and NOT on the desired framerate.

baxslash
Valued Member
Bronze Codemaster
19
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 17th May 2010 10:29
This works fairly well but I've yet to find a really good solution!


...then when you move a character (for example) just do it like this:


(Posted this on the wrong thread the other night...)

=PRoF=
23
Years of Service
User Offline
Joined: 17th Mar 2003
Location: Milton Keynes, UK
Posted: 17th May 2010 15:52 Edited at: 17th May 2010 15:53
I was using Spooky's TBM code from the code snippets board for a long long time.

Then I thought I'd try it myself (altho slightly simpler...)

Here's my code..



It seems to work ok, you decide how fast you want your object to move/turn per second, and then multiply that value by system(0).move to work out how far it goes that loop.

If anyone wants to n00bslap me for getting this wrong, I don't mind This is another of my late night drunken ponderings, and I sometimes make huge glaring errors.

>edit<
You need IanM's matrix plug in for the hiTimer() command, altho it will work if you just change it to the normal DBP timer()

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 17th May 2010 18:27
All the examples above are doing pretty much the same thing.

- Find the difference in milliseconds between LOOPS (NOT FRAMES)
- Divide the difference by 1000*
- Move the object it's speed value multiplied by the time factor

* If you include your desired framerate in your calculation, and you decide to change the framerate, you would think changing your calculation to include the new desired framerate would result in the object moving the same speed, but it doesn't. Give this a try.

- Run your program with the calculation including the desired framerate of 60, and set SYNC RATE to 60.
- Now change your desired framerate and your sync rate to 30.

The movement is different because it's not based solely on time.

Now try this,

- Run your program with sync rate set to 60, but leave the desired framerate out of the Time Based Movement calculation.
- Now change your sync rate to 30.

You'll see that the object moves at the same speed no matter what the framerate is, because now you are basing your calculation only on the TIME it took between loops.

It took a lot of convincing before I saw this. So I'm hoping this helps someone else "see the light" as well.

=PRoF=
23
Years of Service
User Offline
Joined: 17th Mar 2003
Location: Milton Keynes, UK
Posted: 17th May 2010 19:02
@KisTECH
Is mine wrong then? there is no desired framerate calculation in it? :/ I'm confused

I'm sure I've tested it and its more accurate than Spooky's (as it doesn't average it all out, which causes a stop/start effect when running on my lappy)

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 17th May 2010 19:06
Yours is fine. It does the correct calculation.

Yes, averaging helps smooth things out considerably.

=PRoF=
23
Years of Service
User Offline
Joined: 17th Mar 2003
Location: Milton Keynes, UK
Posted: 17th May 2010 19:13
@KisTECH
*phew*, lol.

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 18th May 2010 18:00 Edited at: 20th May 2010 01:41
I guess you were that dunk eh?

[edit]
err, uh.. I mean WEREN'T that DRUNK.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 20th May 2010 00:18 Edited at: 20th May 2010 01:10
I notice you guys stole my implementation above. Here's a simpler version.(baxslash)
This is the simplest accurate explanation anyone is going to give you.



Add the Global definitions to the beginning of the program.
Add the Functions to the end.
Add FrameTimer() after every sync. Only call it once per sync. (Each Screen Update)

Multiply any movement distance by FrameX# before it is applied. Also works for other things that screw up when framerate changes.

If player moves a distance of 1 at 60 fps, then he should move 2 at 30 fps and 0.5 at 120 fps, etc. The multiplier corrects this movement distance.

Edit: Also using "Sync Rate" is horrible. Having the screen update automatically regardless of whats happening in your loop is bad. You should sync manually so you are certain the screen is actually ready to be drawn, like GUI updates, FX, animation. I can see no reason for changing the reference framerate from 60. You can easily work with a clean reference value, regardless of actual framerate. Yeah the code can screw up if you up and decide to change the reference. But there's just no reason to change it. Why would you ever let it sync on it's own like that? You'll be loading an object and the animation isn't set and it will have some weird animation frame flash on screen. Or flash on screen with no texture. This is bad! Never do this! How are you supposed to implement Bloom or HDR shaders? No post processing effects? How do you implement reflective surfaces?. These require syncing only specific cameras at a time. "Sync Rate" is worthless.

That is all.

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 20th May 2010 01:56
For the most part, I agree.

However there is still no reason to include the Ideal framerate in your time based movement calculation.

Leave sync rate set to 0 and your Ideal framerate at 60 and run your app, then change your Ideal framerate to 30 and run your app again. Your objects will move at a different speed. The idea is to move the object at the same speed over the same amount of time, regardless of the framerate.

Sync rate IS useless, I agree. That's why I run a control loop, and run my Game loop and Display loops separately.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 20th May 2010 02:04 Edited at: 20th May 2010 02:25
"...Ideal framerate at 60 and run your app, then change your Ideal framerate to 30 and run your app again."

Why? why change it? Yeah movement will be doubled in speed. But there's no reason to change it. None at all. It serves no purpose. None. You are making a completely arbitrary point.

It's not even a situation where the player might adjust a setting. It's completely pointless.
You don't need to worry about the Ideal framerate changing because there is no reason to change it. Ever.

The ACTUAL framerate changes. So that is compared with the IDEAL framerate so a default speed of 10 for the player can be increased/decreased to maintain the same actual speed on screen.

"The idea is to move the object at the same speed over the same amount of time, regardless of the framerate."
The example I gave above, and the reference to my work above (baxslash) does exactly this. I don't think you understand that "ideal framerate" is just a reference so you can say player moves at speed 100 at 60fps and correct the speed if fps goes higher or lower.

Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 20th May 2010 02:25
Thought I'd post this again, cause it's a pretty decent article on game loops: deWitters - The Game Loop

A dream is a fantasy, if you achieve that fantasy it was never a dream to begin with.
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 20th May 2010 02:57 Edited at: 20th May 2010 03:00
I do understand. You are actually at the same place I was before I realized that the Ideal framerate in the equation is the pointless part, and if you do decide to change the desired framerate it will screw you up.

Yes, you might make an app that the ideal framerate stays the same, and that's fine. I've seen games in the past where you could change the framerate. (granted it's been a while) I've also written an app that dynamically adjusts the ideal framerate based on several factors. (I can tell you more about that if you want)

In all of these cases, the Ideal framerate doesn't belong in the equation.

Let's do the math, this will be a good exercise for me.

Assumptions:
- Ideal Framerate : 60
- Object Move Speed : 10

Experiment:
- Current Framerate : 60

Diff# = 16.67
Ideal# = 16.67
FrameX# = 1.0
---------------
Object Moves 10


- Current Framerate : 30

Diff# = 33.33
Ideal# = 16.67
FrameX# = 2.0
---------------
Object Moves 20

Your object just moved twice as fast in 1 second, because your framerate changed.


Now let's try it without the Ideal framerate included.

- Current Framerate : 60

Diff# = 16.67
FrameX# = Diff# / 1000.0 = 0.01667
-------------------
Object Moves 10 * 0.01667 = 0.1667


- Current Framerate : 30

Diff# = 33.33
FrameX# = Diff# / 1000.0 = 0.03333
-------------------
Object Moves 10 * 0.03333 = 0.3333

Yes, the values are small, but here's the thing, they are supposed to be. Multiply the result by the current framerate and you'll get 10. Whether the framerate is 30 or 60 or 90 or 2000, the object will move 10 per second, which is the speed we specified.

0.1667 * 60 = 10
0.3333 * 30 = 10

(I took the liberty of rounding here and there..)

Quote: "Thought I'd post this again, cause it's a pretty decent article on game loops: deWitters - The Game Loop"


Yes, it's a very good article. That's what led me to make my dynamic framerate system I'm using in Worlds Apart Online.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 20th May 2010 03:21
Assumptions:
- Ideal Framerate : 60
- Object Move Speed : 10

Experiment:
- Current Framerate : 60

Diff# = 16.67
Ideal# = 16.67
FrameX# = 1.0
---------------
Object Moves 10


- Current Framerate : 30

Diff# = 33.33
Ideal# = 16.67
FrameX# = 2.0
---------------
Object Moves 20

Your object just moved twice as fast in 1 second, because your framerate changed.

WRONG!

You forgot that at 60fps, the movement updates twice as often as it does at 30fps.

Assuming the object is moving forward the entire time for simplicity, at 30fps each jump is 20, at 60fps each jump is 10, but there are twice as many.

Distance = Distance.

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 20th May 2010 04:15 Edited at: 20th May 2010 04:24
Sometimes it requires seeing it to believe it. (and to see where I've made mistakes sometimes..)

I've started this program with the Ideal framerate included in the equation. The best I could do to simulate a drop in framerate was to introduce a delay. Change the amount of delay with the 1, 2, or 3 keys. ` resets the delay to 0.

The interesting thing is, you are partially right, as long as you don't change your Ideal# value. If you should decide to make your app run at 40 FPS instead of 60, you'll have to adjust all of your movement speeds to compensate.

Try changing the Ideal# value to 1000.0 / 30.0 and the Sync rate to 30 and you'll get different movement values.

Set Ideal# to 1000.0, and change whatever you want. The movement value wont change.



By leaving the Ideal# out of the equation, you can change the Sync rate or the delay to anything you want and the object will ALWAYS move the speed specified.

So, I have to admit that it still works with the Ideal framerate included, but it's still not necessary, and causes you to make lots of changes if you want a different framerate.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 20th May 2010 09:28 Edited at: 20th May 2010 09:38
You are completely wrong.

The "Ideal Framerate" is a constant that never changes. It is compared to the FPS of the program on each frame, so movement can be slowed or sped up.

There is no purpose for changing this value after you have selected it. It doesn't change in the operation of your program. There are no drawbacks for the value changing because it does not change.

Your argument is irrelevant, because the problem doesn't exist.

Again, do not use Sync Rate. Never use it.

baxslash
Valued Member
Bronze Codemaster
19
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 20th May 2010 12:40 Edited at: 20th May 2010 18:29
Quote: "I notice you guys stole my implementation above."

Excuse me @Mage but I stole the code I posted from the code base and NOT from you...

By the way, the word "steal" is defined in the Oxford English Dictionary as:
a. take (another person's property) illegally. b. take (property etc.) without right or permission, esp. in secret with the intention of not returning it... I could go on but that might be seen as fecesious. My point is I stole nothing and thought that the version I posted was a well known and well used solution.

Personally I don't care if someone posts something similar to my own solution as there is almost always something to learn from their implimentation.

Sorry for retorting so late in the day but I've been very busy, and sorry for being off topic but I don't like people pointing the finger when nothing has been done...

Benjamin
23
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 20th May 2010 16:02 Edited at: 20th May 2010 16:05
I hope this is relevant, I'd just like to point out that it's always best to use sync rate 0 and enable v-sync when you can. Much easier on the system and doesn't use more power than it needs to.

Anyway, the simplest way to explain TBM is that you simply move an object according to the milliseconds passed since the last frame. Some people use units/sec for specifying the speed of movement, and divide this value by 1000 before multiplying by the elapsed time.

Oh and one more important thing that people seem to miss. Only store the result of timer in *ONE* place, since otherwise a millisecond or more may elapse between captures and you'll lose time. Store the result in a temporary variable and use that in your equations.
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 20th May 2010 18:14 Edited at: 20th May 2010 18:27
@baxslash,
Quote: "Excuse me @KISTech but I stole the code I posted from the code base and NOT from you..."


Actually it was Mage that made that statement.

@Benjamin,
Quote: "Only store the result of timer in *ONE* place, since otherwise a millisecond or more may elapse between captures and you'll lose time. Store the result in a temporary variable and use that in your equations."


If I read this right, you suggest reading the timer into your one variable at the top of the loop? Wouldn't that cause excess milliseconds to pass while you are processing your loop before it triggers an event the next time through?

@Mage,

Quote: "The "Ideal Framerate" is a constant that never changes. It is compared to the FPS of the program on each frame, so movement can be slowed or sped up.

There is no purpose for changing this value after you have selected it. It doesn't change in the operation of your program. There are no drawbacks for the value changing because it does not change."


Exactly my point. It doesn't change. So it doesn't need to be there. It has no purpose. However if you did want a different ideal framerate, then guess what? You have to change all your speeds.

Did you run the program I posted? Did you examine the data? It proves that I'm simply stating fact, it's not about being right or wrong.

and statements like,

WRONG! and You are completely wrong. aren't warranted. Let's keep this a civilized discussion and not turn it into a shouting match shall we?

[edit]
@All,
I used sync rate in the example to control the framerate more easily. That's all. In all of my actual apps I don't use sync rate or vsync.

baxslash
Valued Member
Bronze Codemaster
19
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 20th May 2010 18:25
Oops, I noticed that just after I posted it... thought I'd already edited it sorry @KISTech!

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 20th May 2010 18:27
No worries. Happens to the best of us.

Benjamin
23
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 20th May 2010 18:31 Edited at: 20th May 2010 18:32
Quote: "If I read this right, you suggest reading the timer into your one variable at the top of the loop? Wouldn't that cause excess milliseconds to pass while you are processing your loop before it triggers an event the next time through?"


Store it wherever you want - I assume the operations where you store the difference and the last time will be close to each other anyway. If any time is 'missed' that iteration, it'll be used in the next iteration.

Of course, what I'm saying only really applies to when you want to store the value for the difference and a reference to the last time. For anything else it doesn't matter.
baxslash
Valued Member
Bronze Codemaster
19
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 20th May 2010 18:35
It really p****s me off when someone on these boards accuses someone else of 'stealing' their code or their idea like I went into his house and hacked into his PC or something!!

If you don't want people to use it DON'T POST IT!!

It's not like I claimed it was my own work or something, besides which I don't think it was yours either.

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 20th May 2010 18:38 Edited at: 20th May 2010 18:44
@Benjamin,

Ok, I have a lot of times in my program where I grab the timer value for various purposes, both nefarious and honorable. I think I understanding what you were getting at.

@baxslash,

I actually got the code from a post that DarkCoder made. Don't know when it was actually posted. It's been a long while since I found it and modified it for my own purposes.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 25th May 2010 03:26
Quote: "It really p****s me off when someone on these boards accuses someone else of 'stealing' their code or their idea like I went into his house and hacked into his PC or something!!

If you don't want people to use it DON'T POST IT!!"


Quote: "Excuse me @Mage but I stole the code I posted from the code base and NOT from you..."


You misunderstand. I was speaking completely in jest. I have no problem with you or anyone using my code. That's why I posted it. I posted it on this forum, and I placed it in the codebase.

It's entirely possible it was re-posted several times by others. There's nothing wrong with that. It just caught my eye. I recognize my work. I don't think you did anything wrong.

Feel free to use as you see fit.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 25th May 2010 03:43 Edited at: 25th May 2010 03:45
Quote: "
Quote: "The "Ideal Framerate" is a constant that never changes. It is compared to the FPS of the program on each frame, so movement can be slowed or sped up.

There is no purpose for changing this value after you have selected it. It doesn't change in the operation of your program. There are no drawbacks for the value changing because it does not change."

@KISTech
Quote:Exactly my point. It doesn't change. So it doesn't need to be there. It has no purpose. However if you did want a different ideal framerate, then guess what? You have to change all your speeds.

Did you run the program I posted? Did you examine the data? It proves that I'm simply stating fact, it's not about being right or wrong."


You make an arbitrary statement that there would be a problem if it was changed and then provide no reason why you would need to change it.

The scenario you are suggesting doesn't happen. Yes if you changed my code, speeds would be uniformly different. But there is no reason to change the code. Speeds are referenced at 60fps. There's no reason to change the reference. At any fps.

This makes your entire argument pointless.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 25th May 2010 04:10
Quote: "WRONG! and You are completely wrong. aren't warranted. Let's keep this a civilized discussion and not turn it into a shouting match shall we?"


Sorry dude, just losing patience. You keep presenting a problem that has no reason to be created, and doesn't exist in a real world situation.

There's no reason to go into my functions and make changes. None. So any problems in doing so are irrelevant.

baxslash
Valued Member
Bronze Codemaster
19
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 25th May 2010 10:40
Quote: "You misunderstand. I was speaking completely in jest"

OK, no problem. It just didn't sound like a joke, maybe it would help if you used something to show you aren't being serious like or or the well known "lol" (for example)?

Maybe I over-reacted a little.

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 25th May 2010 18:46
Quote: "You keep presenting a problem that has no reason to be created, and doesn't exist in a real world situation."


In your code perhaps, but different people are just that. Different.

If you like everything you ever code to be 60FPS, that's great. Some people don't, and if they use your code as it was written, their speeds will be off. That's the only point I'm really trying to make. There's no reason for the "reference" to be there at all.

However, at this point I'll say that we should just agree to disagree on this point and move on.

Cheers.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 3rd Jun 2010 04:37 Edited at: 3rd Jun 2010 10:25
Quote: "If you like everything you ever code to be 60FPS, that's great. Some people don't, and if they use your code as it was written, their speeds will be off. That's the only point I'm really trying to make."


No. My point is speeds wont be off. Speed will be consistent. The code does what it's supposed to do. You could set it to 30, 25, 10, 1000. As long as you pick one and stick with it speeds will be consistent.

And that's all above the whole overwhelming point that there's no reason to even go into my function and be changing things. You have provided no reason why this is necessary in the first place. A program running with an erratic frame rate bouncing all over the place is going to have accurate and consistent speeds with the code I wrote.

The code works exactly as it should.

Perhaps a test is in order.
The following code is a rewrite of your previous code listed above. Your timing function has been rigged to be active when holding the Control Button. The problem is I had to edit your function to use the built-in timer. Instead of the plugin timer you were using. The function isn't working to well perhaps you can correct this. You should be able to do this without changing anything but tm_Update().


Also one more thing, the rotating cube can cause an optical illusion and appear to change speeds visually. Keep an eye on the rotation period indicator as it will time the entire rotation.

[b]Update: I corrected the issue with KisTech's Timing Function. It's now a properly implemented comparison.

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 3rd Jun 2010 06:59
Quote: "No. My point is speeds wont be off. Speed will be consistent. The code does what it's supposed to do. You could set it to 30, 25, 10, 1000. As long as you pick one and stick with it speeds will be consistent."


Which precisely proves my point.

Look, here's the thing.

In your code

Ideal# = 1000 / 60
FrameX# = Diff# / Ideal#

In my code

factor# = Diff# / 1000

Why are you dividing by 60 ???
What purpose does it serve ???

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 3rd Jun 2010 09:16 Edited at: 3rd Jun 2010 10:25
I have your answer. First, I updated that Code i posted in my last message. Run it. Hold Control Button for a few seconds to toggle between both of our timing methods.

First things first:

Quote: "Why are you dividing by 60 ???
What purpose does it serve ???"

factors(30) = Diff# / 100.0
You are dividing by 100, what purpose does that serve?

Secondly and this is very important.
Forget the fact that you are Averaging the last 30 frames for a second. If you ignore this then my code always spits out a value equal to 6 times the value yours does. Check it. It's true.


My code actually does the same thing yours does when you don't average values. The value is merely 6 times larger. This means any issue over accuracy is irrelevant. Both methods are equal.
Proof: Check it. It's True.

Mind = blown.

This brings me to my third big point.
I had a good look at your code. Why are you averaging your timing?!? This is extremely bad!

Proof:

Take a look at the code I posted in my previous message. I updated it. It shows what your code does with your averaging when the fps is always changing. You have a major issue here.

I have a constantly changing delay driven by a SIN() function that your averaging can't handle. Take the averaging out. This is a huge problem. If fps suddenly jumps from 20 to 40, your program still thinks fps is somewhere in between for about 30 frames.
Check the code in the previous message. I Updated it. It's complete proof of this.

Otherwise, this settles it. Your method (without the averaging) is the same as mine. QED.

baxslash
Valued Member
Bronze Codemaster
19
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 3rd Jun 2010 18:08
I hate to say it but that's a pretty compelling argument...

It certainly does seem that you are both getting the same results but using them in different ways.

I also wondered about the possible problems associated with averaging framerate, like if you had a large DarkPhysics explosion affecting many objects it would still be allowing for a 'normal' framerate of say 60fps when only achieving about 30...



KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 3rd Jun 2010 18:51
Averaging the timing smooths the movement. It could just as easily be across 10 loops, or 100, although I wouldn't recommend the latter. I chose 30 after testing several settings, because it gave the smoothest motion without causing other issues. Nice drawings though.

This all started because there was mention that the Timer Based Movement is (or should be) tied to the desired framerate in some way. On that point I strenuously disagree, and for the reasons I've already stated several times.

I'll say this one more time so there is no confusion. YES, THE MOVEMENT IS CONSISTENT NO MATTER WHAT YOU ARE DIVIDING Diff# BY. I GET THAT.

My question is, WHY ARE YOU DIVIDING IT BY 60? Because that implies that you are tying it to the desired framerate in some way.

Quote: "factors(30) = Diff# / 100.0"


Sorry, that should have been 1000.0. Why?

The reason is simple, and is the basis for this entire argument.

You are (or should be) basing your Time Based Movement on the number of MILLISECONDS that pass between each loop.

Let's say that you are setting your scale at 1 DBPro Unit = 1 Meter and you want your character moving at 1 meter per second.

At 60 FPS : 16.667 ms have passed

Ideal# = 1000 / 60 (= 16.667)
FrameX# = Diff# / Ideal# (= 1)
move object Obj, Speed * FrameX#
--------------------------------
Object moves 1 unit in 16.667ms (or 1 * 60 frames = 60 units) (Gee, that's not what we wanted.)

factor# = Diff# / 1000.0 (= 0.016667)
move object Obj, Speed * factor#
--------------------------------
Object moves 0.016667 in 16.667ms (or 0.16667 * 60 frames = 1 unit)

So as you can clearly see, you are dividing by 60 because of the notion that the movement should be tied to the desired framerate, but there's only one thing the movement should be based on. TIME.

Are we done with this now?

baxslash
Valued Member
Bronze Codemaster
19
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 3rd Jun 2010 19:23
I think I see where you are both coming from now... correct me if I'm wrong...

KISTech:
You are saying that there is no need to base TBM on an 'ideal' framerate.

Mage:
You are saying your code is fine as there is no need to worry about a changing 'ideal' framerate.

Actually you are both right, Mage you must agree that it is not necessary to base your movement on an ideal framerate. It is just the way you are doing it...

KISTech you must agree that there is no need to alter the ideal framerate and on that basis Mage's code gives the same results as your own...

I'm sure if you actually look at what your two arguments are based upon you are not disagreeing, just doing things in a different way to each other!

Now kiss and make up...

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 3rd Jun 2010 19:52


Fair enough.

It's just that,
Quote: "Mage's code gives the same results as your own."


Isn't quite right. However, if that's the way he wants to do it, he's entitled. If it works for him who am I to try and change it.

I'm only pointing out that if you are going to make your virtual world a reasonable facsimile to the real world, then meters per second should be meters per second, not meters per second per frame.

That's all this was ever really about.

baxslash
Valued Member
Bronze Codemaster
19
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 3rd Jun 2010 23:10 Edited at: 3rd Jun 2010 23:12
Quote: "I'm only pointing out that if you are going to make your virtual world a reasonable facsimile to the real world, then meters per second should be meters per second, not meters per second per frame."

As far as I can tell the ideal frame rate is just another way of working out the number of meters he wants to move per second.
EDIT: I got that muddled, what I meant to say was it's how he works out the amount of time that has past

There's an argument against your smoothing technique when it comes to realism though, but I don't want to spark another 'disagreement'...

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 3rd Jun 2010 23:34
The averaging wasn't my idea, it was DarkCoder's, or maybe we came up with it about the same time, I don't remember.

The end result is that my game runs more smoothly because of it, so It's not something I'm going to debate either.

Quote: "it's how he works out the amount of time that has past"


Other than it's really not how much time has passed. That's been my point all along.

1 frame at 60 FPS = 16.667 milliseconds, which when represented as a proper fraction of a single second, is 0.016667 seconds. That's how much time has passed.

I never meant for this to become an argument. I just wasn't being this clear at the beginning, and got off track a time or two. My apologies for that.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 4th Jun 2010 03:51
Quote: "At 60 FPS : 16.667 ms have passed

Ideal# = 1000 / 60 (= 16.667)
FrameX# = Diff# / Ideal# (= 1)
move object Obj, Speed * FrameX#
--------------------------------
Object moves 1 unit in 16.667ms (or 1 * 60 frames = 60 units) (Gee, that's not what we wanted.)

factor# = Diff# / 1000.0 (= 0.016667)
move object Obj, Speed * factor#
--------------------------------
Object moves 0.016667 in 16.667ms (or 0.16667 * 60 frames = 1 unit)"


This is a false argument because all I need to do is move object Obj, 0.016666666 * FrameX# to do the same thing.

Now that you have switched to "Diff# / 1000.0" this actually has some merit since it's now what you've been saying it is. Unit's per second. This fact isn't really all that important because Unit's are not meters. So in one game people may be 10 units tall, and an others may be 2 units. So you end up back to square one, experimenting with speeds on the go until everything looks right. You are robbed any actual benefit in arranging Factor# this way, despite the elegance.

Quote: "you are dividing by 60 because of the notion that the movement should be tied to the desired framerate, but there's only one thing the movement should be based on. TIME."


So you are saying dividing by 60 is unnecessary. Certainly. But it doesn't matter. It doesn't matter because 1 unit doesn't equal 1 meter or 1 foot, and ends up different for everyone. So the fact my values are scaled by 60, doesn't mean anything.

I like the notion of saying units per second. I think this is a good idea because I like the elegance. It's a little simpler.
Quote: "If you should decide to make your app run at 40 FPS instead of 60, you'll have to adjust all of your movement speeds to compensate."
Quote: "YES, THE MOVEMENT IS CONSISTENT NO MATTER WHAT YOU ARE DIVIDING Diff# BY. I GET THAT."

My entire point was that the code works.

"Smoothing Timing Values"
Quote: "There's an argument against your smoothing technique when it comes to realism though, but I don't want to spark another 'disagreement'... "

Quote: "Averaging the timing smooths the movement. It could just as easily be across 10 loops, or 100, although I wouldn't recommend the latter. I chose 30 after testing several settings, because it gave the smoothest motion without causing other issues. Nice drawings though."

Thanks. Wouldn't recommend the latter? Other Issues?
The issue here is that the code is no longer frame rate independent. Changes in Framerate make the program slow and speed up.
Proof: This demo has a constantly changing FPS. It compares both our methods.


Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 4th Jun 2010 04:00 Edited at: 4th Jun 2010 04:10
Quote: "
I never meant for this to become an argument. I just wasn't being this clear at the beginning, and got off track a time or two. My apologies for that."


No problem. So we discovered we are doing exact the same thing. Just your multiplier gives a prettier number when treating 1 unit as a meter. It's a pretty sound idea. It makes numbers simpler.


As far as smoothing is concerned. The case against is pretty solid.

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 4th Jun 2010 05:08
Quote: "As far as smoothing is concerned. The case against is pretty solid."


On paper perhaps, but the proof is in the silky smooth graphics.

http://www.worldsapartonline.net

Come sign up and check it out.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 4th Jun 2010 07:53 Edited at: 4th Jun 2010 08:38
No, you don't believe that.
Did you run that code I posted above? (2 messages above)

The fps is always changing and your smoothing completely screws up because the average value is always wrong. When you average your values like that the only hope you have is that fps is fairly constant or changes rarely.
More Proof:


1. Why would you need to smooth your values when the timing is supposedly fairly accurate?

2. Why did you say it would be a bad idea to smooth more than 30 frames? Why not 100, or 1000 frames?

3. You saw the "Averaging Diagram" I posted. Is it inaccurate?

This should be interesting.

baxslash
Valued Member
Bronze Codemaster
19
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 4th Jun 2010 10:43
Mage, why not try his game as he suggested? See for yourself.

Looks pretty smooth to me. I guess it depends on the PC but if you're running the game on a slow machine the affect Mage is determined to prove might be more noticeable. If the game is only running at 30fps then the smoothing occurs over a whole second whereas on a faster machine it micht be only over a quarter of a second (hardly noticeable and probably very smooth). Maybe you need to have a Timer Based Smoothing for your Timer Based Movement KISTech?

[psuedo code]
smoothing = fps()/4
[/psuedo code]

That said your averaging diagram is an unlikely scenario Mage, unless you're running other processes in the background which jump about in terms of CPU useage...

I think everybody is right... except me... so just forget I spoke...

Sven B
21
Years of Service
User Offline
Joined: 5th Jan 2005
Location: Belgium
Posted: 4th Jun 2010 11:32 Edited at: 4th Jun 2010 11:33
Actually I don't see where the smoothing comes from either. I can't see it doing anything else than make the game slow down at the moments the FPS drops (eg. loading in and positioning a new batch of enemies, spread over a few loops), as the average frame rate > actual frame rate. And it will speed the game up when the FPS rises (eg. the loading has finished), as the average frame rate < actual frame rate. Meaning you will make the timer based movement also dependent on the derivative of the FPS.

Cheers!
Sven B

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 4th Jun 2010 18:50
Without the smoothing, movement was jerky when the framerate changed, such as when loading several objects or textures from disk. That's not to say there aren't still pauses when that happens, as loading from disk is very slow. You'll miss frames no matter what. However instead of it catching up all at once in a single frame/loop, it catches up over a very short amount of time, making it appear smoother. World of Warcraft doesn't use smoothing, and it's very evident by the constant jerky movement. Most people think this is caused by network lag, and they're partially right, but if there's a known reason for it, why not smooth it's impact and make things look better.

Why not use 100 loops for smoothing?

Mainly for the reasons you gave not to use smoothing at all. 100 loops is to much smoothing, and it starts to become noticeable.

---------------------------------------------------------------

The other aspect of my program that you aren't aware of is the way I'm handling the main loop.

SYNC ON : SYNC RATE 0
and VSYNC is OFF

The main loop consists of some counters, and two other loops.

The Game Loop : Moves objects, checks collisions, accepts input, handles networking. Since it handles the movement of objects, it also executes the Timer Based Movement routine. (this is important to note)

The Display Loop : Sets up the screen elements such as sprites, text, pasted images, etc., and calls SYNC at the end.

I set an ideal Display Loop rate of 60, and an ideal Game Loop rate of Display Loop rate * 2.

Using the timer and a little math, the Game Loop is executed 120 times a second, and the Display Loop 60 times a second.

Now, I haven't found a machine yet that can run my app that fast, so when the framerate dips below certain thresholds, the desired Game Loop rate is adjusted to give a little more time for the Display Loop to execute. If the framerate comes back up above the threshold the Game Loop rate is allowed to adjust up. In the end a balance is found for that particular machine's abilities.

So in actuality, the smoothing routine is somewhat isolated from the framerate and typically runs faster than half a second.

Sven B.
This part was worth mentioning because in reality it's not tied to the framerate, but to the game loop rate.

By separating the game loop and the display loop I've been able to squeeze a lot more power out of the app, because the game loop is no longer confined to the "sync rate" whether that's controlled by the SYNC RATE command, or by turning on VSYNC. Those two methods leave your app hanging around doing nothing while it waits for the right time to fire off again.

Using the same concept on the server end, and setting the Display Loop to run only 5 times per second, and letting the Game Loop run as fast as it can, the Game Loop runs at over 20,000 loops per second. This gives the server a LOT of time to handle all the player networking packets and do all the processing it needs to do.

Sven B
21
Years of Service
User Offline
Joined: 5th Jan 2005
Location: Belgium
Posted: 4th Jun 2010 20:31
I get the whole balance thing.
A game gets 'jerky' when the display loop rate falls below ~25FPS. The brain doesn't interpret these images as moving anymore. But timer based movement doesn't have to do anything with that. It doesn't solve jerkiness, it solves the problem that speed changes when the FPS fluctuates.

But whatever suits you best right? I'm sure it works well for your game or you wouldn't use it.

Cheers!
Sven B

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 4th Jun 2010 21:11
That's a good point. Basically we're sort of like the film industry. We use lot's of smoke and mirrors trickery to make the player see what we want them to see. Even if it means fudging the numbers a little bit here and there.

Login to post a reply

Server time is: 2026-07-22 12:41:46
Your offset time is: 2026-07-22 12:41:46