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 / Sync rate for notebooks, help please...

Author
Message
The Slayer
Forum Vice President
16
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 5th Sep 2010 18:11
Hi all, I'm asking this here to get more responses.

I'm kinda stuck with this sync rate problem that I'm having. I thought I've got it sorted out, but appearantly not.
It seems that I never get a smooth movement (without hickups) if I don't use 'SET DISPLAY MODE 1024,600,32,1.
I'm having a hard time understanding how to get a smooth movement using 'SYNC RATE'. I'm using a timer based function, but even with it, the ball (it's for my break out clone) has those hickups when moving.
So, how does timer based movement work, and what does that have to do with the sync rate?
I mean, if you set the sync rate to 30, doesn't that also mean that every calculation, movement, code is run less per frame than when you set it to 60?
So, if that's the case, then you can't make something run faster if you cap the sync rate, right?
And, if someone has a notebook, how high is the top sync rate that it can run?

Thanks for the feedback!

Cheers

Slayer rules!!! Yeaaah, man!
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 5th Sep 2010 18:46
Timer Based Movement is based on the Timer value, which doesn't stop running no matter what your program is doing.

The result of a TBM calculation gives a "factor" to multiply your movement speed by to give accurate movement between frames.

If you post your TBM code, and the code you are using to move the ball I can probably help.

The Slayer
Forum Vice President
16
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 5th Sep 2010 19:41 Edited at: 5th Sep 2010 20:20
Hi KISTech, thanks for helping me out!
Well, here's the code (snippets) that I use:

At the top of my program:


In the main loop:


Also in the main loop to move the ball:


This is for updating every loop:


And this is the TBM function.


I tried your TBM function too, but I didn't get it to work.

When I use 'SET DISPLAY MODE 1024,600,32, 1 it runs smoothly, but without it, you can see the ball more than once, like it is sorta 'jumping' from one frame to another.

Oh BTW, did you get my latest email?

Cheers

Slayer rules!!! Yeaaah, man!
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 5th Sep 2010 20:37 Edited at: 5th Sep 2010 20:38


Then don't divide FrameX# by anything or you'll just make it smaller, which you don't want.

If you want to smooth the movement from the result, then add the result to an array and take an average of the last 30 results.



If the ball moves to fast or to slow, then adjust your speed, but not FrameX# to compensate.

Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 6th Sep 2010 09:15
Quote: "So, if that's the case, then you can't make something run faster if you cap the sync rate, right?"


To me it's always better to set the SYNC RATE at zero... especially if you want to use TIMER() based movement anyway. When it's at zero the program SYNCs as fast as the computer running it can handle.

=PRoF=
23
Years of Service
User Offline
Joined: 17th Mar 2003
Location: Milton Keynes, UK
Posted: 6th Sep 2010 11:48 Edited at: 6th Sep 2010 11:49
I have had issues in the past with Sync Rate 0, sometimes my computer is TOO fast, and the maths suffers from floating point innacuracies because the numbers are too small. (Not a problem the Netbooks are likely to suffer from, lol)

Altho I usually include an option for the player to set the sync rate in the advanced options menu.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 6th Sep 2010 11:58 Edited at: 6th Sep 2010 12:04
Quote: "If you want to smooth the movement from the result, then add the result to an array and take an average of the last 30 results."


Hey KISTech I told you before you shouldn't do that. If the frame rate suddenly jumps, your program still thinks the fps is higher/lower then it really is because the average takes a while to adjust. Throws your timing off and makes the speed inconsistent. Add Sleep Rnd(1000) into your main loop sometime.

Quote: "I have had issues in the past with Sync Rate 0, sometimes my computer is TOO fast, and the maths suffers from floating point innacuracies because the numbers are too small. (Not a problem the Netbooks are likely to suffer from, lol)"


=Prof= very important detail there, but it's also important to cap the frame rate because anything over meh...60ish is usually not seen anyway and makes the computer break. Plus why have the computer maxed needlessly maybe there's other programs running.

The Slayer
Forum Vice President
16
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 6th Sep 2010 12:08 Edited at: 6th Sep 2010 12:18
Quote: "anything over meh...60ish is usually not seen anyway and makes the computer break. Plus why have the computer maxed needlessly maybe there's other programs running."

So, what you're saying is not to set the sync rate at max, right? So, if I would set the sync rate to 40 or 45 (yeah, I know it's an odd number, but I think 30 is too low to get smooth animation), and leave the rest for other applications that might run in the background, that would be for the better?


Quote: "
Then don't divide FrameX# by anything or you'll just make it smaller, which you don't want.

If the ball moves to fast or to slow, then adjust your speed, but not FrameX# to compensate.
"

So, I don't move my objects only with FrameX#, but with an extra variable multiplied by FrameX, like this?


Oh, and one more thing that seems strange to me. If I print the value FrameX# to the screen, that value increases over time. So, doesn't that mean that the speed of my objects increase too over time?

Cheers

Slayer rules!!! Yeaaah, man!
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 6th Sep 2010 12:26
Quote: "o, what you're saying is not to set the sync rate at max, right?"

No just set it to 60 or 70 or around there. When you are up to 80+ it becomes ridiculous because the screen can't even produce an image that fast.

SET DISPLAY MODE Width, Height, Depth, VSyncOn
VSyncOn: Set VSyncOn to a value of one will force the screen to use VSYNC and syncronise to the monitors refresh rate.

Yeah this is your problem.
You set vsync and what happens is your program draws the screen and then just waits. It waits until the monitor is ready before drawing a new frame. This is causing your screen to "hicup". You don't need this.


Side Note


The top code you started with. I wrote that. The bottom was written by KISTech. They do the same thing. The values are different by a factor like exactly 60 each time or something. He knows this, but we had an argument over which was superior. So finding that out mid way ended up looking pretty dumb all round. So you should know this if taking advice from either of us.


The Timer Methods discussed are equivalent. They work. Your problem is you are enabling vsync.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 6th Sep 2010 12:33 Edited at: 6th Sep 2010 12:38

Is the same thing as...

Well. ok i rounded the decimal.
But it's the same thing as...


What KISTech told you about this line of code is completely right because it makes your code easier to read and manage. It's not related to your main problem though.

The Slayer
Forum Vice President
16
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 6th Sep 2010 14:21
@Mage

Well, I've finally (fingers crossed ) solved this problem. And, I didn't use yours or KISTech's code for it, but ShaunRW's Timer plugin.
For some reason, the timer function I used before didn't work all that good for me. Maybe I've set it up wrong, or something.
Not saying that there's something wrong with the code, but I don't have the time now to sort it out (want to get my game ready for the Intel compo). I'll play with it later, though.
I've tested my game at 30, 45, 60 FPS, and it ran the same speed all the time, so YAAAY!
So, that demo I promised, will arrive anytime now.

Quote: "SET DISPLAY MODE Width, Height, Depth, VSyncOn"
Quote: "Yeah this is your problem."

Well, I don't think it was my problem. Because I also tested it with Vsync on, and the gameplay and screen animation was perfect.
Setting Vsync off and setting the sync rate, still produces a less perfect refresh speed and animation. I can see the ball more than once. It's not much, but you can notice the difference.

Anyways, thanks all for your help!

Cheers

Slayer rules!!! Yeaaah, man!
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 6th Sep 2010 19:15
Quote: "Hey KISTech I told you before you shouldn't do that. If the frame rate suddenly jumps, your program still thinks the fps is higher/lower then it really is because the average takes a while to adjust."


If there is a sudden change, yes there is an inconsistent movement for 30 frames. However, the benefits of the smoothing outweigh the side effects that only takes a fraction of a second to resolve themselves.

Benjamin
23
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 6th Sep 2010 19:19
It's usually suitable to just update movement according to the time difference between the current and the previous frame.

Sync rate 0 + VSync + Timer-based movement = Good.
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 6th Sep 2010 21:35
Quote: "Well, I don't think it was my problem. Because I also tested it with Vsync on, and the gameplay and screen animation was perfect."


Hilarious. Now its also possible that the screen is thrashing if the fps is too high and vsync is off. "Half of one frame and half of the other is visible sometimes".

Is it possible you could post a working code showing your problem?

Quote: "yes there is an inconsistent movement for 30 frames. However, the benefits of the smoothing outweigh the side effects"

What are the benefits? I thought the whole point was to produce consistent movement.

The Slayer
Forum Vice President
16
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 7th Sep 2010 01:12
Quote: "Hilarious."

Hugh?

Quote: "Now its also possible that the screen is thrashing if the fps is too high and vsync is off."

Every time I set Vsync on, it runs smooth as silk (at the same rate that my monitor is refreshing). So, if my monitor is set at 60, 75 or at 85, the game ran smoothly, with Vsync on. It's only when I don't use Vsync, that I got those hick ups in the game.
Maybe it's related to my graphics card (or the settings)? It's a ATI Radeon HD 3870. Or, maybe the monitor (Compaq V75)?

Quote: "Is it possible you could post a working code showing your problem?"

Not at the moment, no. I'll see if I can put something up tomorrow or another day of the week.

Slayer rules!!! Yeaaah, man!
Mobiius
Valued Member
23
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 7th Sep 2010 09:19
By setting your game to run with vsync on, people with different refresh rates will experience the game at different speeds, which could lead to people cheating.

My signature is NOT a moderator plaything! Stop changing it!
The Slayer
Forum Vice President
16
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 7th Sep 2010 12:40
Quote: "with vsync on, people with different refresh rates will experience the game at different speeds, which could lead to people cheating."

Yep, I know that. That's why I've added timer based movement. Now, it runs at the same speed all the time, no matter what framerate, and no matter if Vsync is on or off. So, there will be no cheating.
But, what I'm trying to say is, that when I'm not setting Vsync on, you still see a less fluid movement. With Vsync on, you don't see any 'jumpy' movement.

Thanks

Slayer rules!!! Yeaaah, man!
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 7th Sep 2010 13:36
Quote: "But, what I'm trying to say is, that when I'm not setting Vsync on, you still see a less fluid movement. With Vsync on, you don't see any 'jumpy' movement."


Not quite sure I follow you. For a long time I'd been getting visible screen tears in some of my programs when I turned the camera. Then I tried using vsync on and the tears instantly disappeared. It's quite different from the jerky or unpredictable movement you can get if you don't use TBM - and you can get that with or without vsync on especially when the processor is struggling to keep up with the machine's refresh rate.
The Slayer
Forum Vice President
16
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 7th Sep 2010 14:09
@GG

Well, I'm starting to think that the problem maybe caused by the command that I'm using to move the ball (move object 'up' 'down' 'right' 'left', object). Maybe it's a bug? Maybe it isn't refreshing fast enough or something?
I use 'POSITION OBJECT object number,X,Y,Z' for other objects in the scene, and it looks like I don't have that jerky movement (or at least, it is less noticable).
Even with TBM, I get that 'jumpy' movement. It's like having more than one ball moving at the same speed, but not at the same position as the original ball.

Slayer rules!!! Yeaaah, man!
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 7th Sep 2010 17:27
Quote: "Well, I'm starting to think that the problem maybe caused by the command that I'm using to move the ball (move object 'up' 'down' 'right' 'left', object). Maybe it's a bug?"


Interesting. I vaguely recall a similar problem with the move camera commands. Can you post a simple demo?
The Slayer
Forum Vice President
16
Years of Service
User Offline
Joined: 9th Nov 2009
Playing: (Hide and) Seek and Destroy on my guitar!
Posted: 7th Sep 2010 18:10
Quote: "Can you post a simple demo?"

Not at the moment, no. I'm kinda busy getting the demo ready for my game BRIXOID that I'm submitting for the Intel compo. I'm currently recording the riffs for the metalsong I'm adding in the game.
But, once that's done, I'll post something here.

Slayer rules!!! Yeaaah, man!
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 7th Sep 2010 18:48
Quote: "What are the benefits? I thought the whole point was to produce consistent movement."


The idea is to produce consistent movement, but when there is a delay in the main loop you are going to get a "jump" in the movement because it's trying to catch up the moves it missed. (which is what I suspect The Slayer's problem is right now) The smoothing makes that jump less noticeable. While the actual position is off slightly from where it should be, it catches up in a fraction of a second. (depending on how much smoothing you use)

I'm looking at the game in much the same way that movie makers look at their work. It's a window into a world that is fake, where anything can happen, and it's all done with smoke and mirrors, light and magic.

We know that we cannot have perfect consistent movement when the framerate fluctuates, so we make it appear as if it never fluctuated, and continue on.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 8th Sep 2010 02:08 Edited at: 8th Sep 2010 02:14
Here's Proof Averaging Doesn't Work.

Proof of concept demo:


Infographic Explaining The Situation


QED


Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 8th Sep 2010 02:32
I think we've been here before.
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 8th Sep 2010 02:50 Edited at: 8th Sep 2010 03:27


Try this instead. You still had the resulting factor in both functions multiplied by 60, which throws everything off as I've mentioned before.

You also had the sync rate set to 120, which really doesn't matter all that much, but it's not likely going to be a chosen framerate for a released game.

So, now that things are set to normal, you can hold the delay as long as you like, and if you watch very carefully you can see that when the delay occurs, your block jumps a bit now and then, and mine is a little smoother.

We're talking about half a second of smoothing if you are running at 60 FPS. It's NOT a big deal.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 8th Sep 2010 03:52


Here you are telling him to change this code, saying I'm wrong. You called me out. So yeah I'm going to tell you that you're wrong when you're leading him astray.

Quote: "While the actual position is off slightly from where it should be, it catches up in a fraction of a second. (depending on how much smoothing you use)"


Quote: "If there is a sudden change, yes there is an inconsistent movement for 30 frames. However, the benefits of the smoothing outweigh the side effect"


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."


When you say things like this... then you talk about decoupling loops. Which didn't actually happen. Someone builds a demo showing the code isn't fps independent. Does all the math. Illustrates the whole issue. And you're still out telling people stuff that isn't true. It is a proven fact.

Now I wouldn't care too much, but you're telling people my code is wrong. I'm right. My code is right. And I proved it. I even proved your code without the smoothing is right. I even like your method since it's better written.

Quote: "The result of a TBM calculation gives a "factor" to multiply your movement speed by to give accurate movement between frames."


Then you say something like this. I'm I'm like wow he gets it.

The fact is the whole point is to make movement independent of the frame rate. If it doesn't do that all the time then there's no point. The method doesn't work.

If there's a problem with the math then please point it out.

Now I'm not trying to be a jerk, I've got nothing against you otherwise, i'm just trying to help. Now it would have been a bit better had some of our brilliant minds in the forum lent a hand to flesh this out.

If i'm wrong I'd like to know. Because i'd want to fix the problem.

I've given you the honest truth here to the best of my ability. You haven't given any indication ever that you've looked at any of these numbers.

Thanks.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 8th Sep 2010 04:08 Edited at: 8th Sep 2010 04:13
Quote: "Try this instead. You still had the resulting factor in both functions multiplied by 60, which throws everything off as I've mentioned before."


Finally some true interaction.
A very good demonstration. Here's what you did except I left the timers in place. And I sped up the squares to better show the motion.



Just hold down the ctrl button on this version for a couple seconds and release. The sudden change in FPS will be visible.

Quote: "
We're talking about half a second of smoothing if you are running at 60 FPS. It's NOT a big deal.
"

60fps isn't a problem it's when a car explodes or a player spawns or bullets start flying and every couple of frames FPS is dancing between 10-60fps.

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 8th Sep 2010 04:23 Edited at: 8th Sep 2010 05:51
I didn't call you out, I just simply told him the code he was using is wrong. I have no idea where he got it.

Since you've laid claim to it though, I'll say this. There are several tutorials and examples on the net for TBM, and none of them multiply the result by anything. They simply take the difference between frames in milliseconds and divide it by 1000, then multiply their movement distance by the result.

I've proven mathematically that it is the correct way to do it. So please don't suggest that I'm leading anyone astray.

Looking back through this thread I don't see where I've mentioned decoupling, but the tutorial here does talk about that.

What I don't remember seeing is you proving mathematically that your way is correct.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 8th Sep 2010 05:14 Edited at: 8th Sep 2010 05:18
Your non-frame averaging code absolutely is correct.

Quote: "
Since you've laid claim to it though, I'll say this. There are several tutorials and examples on the net for TBM, and none of them multiply the result by anything. They simply take the difference between frames in milliseconds and divide it by 1000, then multiply their movement distance by the result."


Yep and that's why I said...
Quote: "I even proved your code without the smoothing is right. I even like your method since it's better written.
"


In fact me multiplying or dividing anything has no bearing on the accuracy of the code. It just means the values Factor# mutiplies aren't 60 times bigger.
I could just as easily say Speed = 60 * Factor# instead of Speed = 1 * Factor# where Factor# is 60 times bigger. I'm not talking about this. I'm talking about averaging.

Quote: "I've proven mathematically that my way is correct. So don't suggest that I'm leading anyone astray."

In what way did you prove averaging out 30 frames corrections is correct from a mathematical standpoint?

I suggested you are leading people astray because you said.
Quote: ""If there is a sudden change, yes there is an inconsistent movement for 30 frames. However, the benefits of the smoothing outweigh the side effect""


And because I showed you before these things. And the guys talking about a need for consistent speed and you are handing him a method that by your own admission fails when the frame rate changes. (but only by a little bit apparently).

That graph up there is pretty straight forward. If there is a problem with the math showing averaging is completely flat out wrong then point it out once and for all.


Quote: "I've proven mathematically that my way is correct. So don't suggest that I'm leading anyone astray."

And when you say this I think you are trying to turn this into an issue about your actual timing code instead of the "Frame Averaging" method I've been talking about. You never proved this works. There's a dozen statements you've made admitting it gets the values wrong and then you'll end up saying the "benefits" outweigh the problems. So if the frame rate bombs out for a sec you want the game to slow down briefly so something doesn't jump across the screen too far (where it should be based on time) to hide the fact that the frame rate was low briefly. That's your benefit. The cost is the object is now in the wrong place forever.

v = d / t but you are using v(avg) = d(avg)/t.

So if you have some math then lets see it.
Again I want to help. If I'm wrong I want to know.
I'll have a lot of fixing to do if i'm wrong I want to know.
Show me.

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 8th Sep 2010 06:17
This discussion twists and turns in all different directions, and gets confusing when you say one thing, then code another. (I think I did it once or twice myself..)

Most of the quotes in your post above are about different issues than your responses indicate, so I think we're getting a little confused here.

At this point, as long as you are happy with this function.



Then I'm happy.

Whether or not you like, agree with, or want to use the smoothing is up to you.

The smoothing was intended as a fix to the jerkiness that is experienced during sudden changes in framerate. It's a visual enhancement, rather than a component of accuracy.

So let's leave it at that.

We both like the function the way it is, and anyone can use smoothing if they want to, with the understanding that it does change the speed of the object slightly over a short period of time to help prevent jerky movement.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 8th Sep 2010 06:37
Yeah exactly what I was trying to say.
Completely happy with that code.
Thanks for taking some time to look into the issue, and helping me improve the Timing Code.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 9th Sep 2010 15:52
I've been following this discussion with interest - but confess to being somewhat baffled and feel compelled to join in.

To me the obvious thing to do is NOT to use smoothing for the reasons that Mage has given. On the other hand smoothing seems to have some benefit. This has to be something to do with the brain works rather than the computer or mathematical correctness.

Here's a demo that I've written to compare the two methods (please let me know if I've made an error - no point comparing the wrong things). The demo runs at about 40 fps on my machine:



The default for the program is no smoothing, just press and hold 2 to see smoothing.

My impression is that the movement does indeed seem smoother with smoothing () - but the speed the sphere moves across the screen seems more consistent without smoothing (this is what I expect for the reasons Mage has given on numerous occasions if I've understood him correctly). So it seems that the issue has nothing to do with mathematical correctness (which I think favours no smoothing) and is more to do with the way our brains perceive movement.

Any more thoughts on this anyone?
baxslash
Valued Member
Bronze Codemaster
19
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 9th Sep 2010 17:03
I agree with GG here. I used KISTech's smoothing on one game I made and it worked great, on another it caused some strange lagging. When I tracked it down it turned out one of my functions that was called occasionally was really slowing the game down and causing that weird 'slow down then speed up' movement.

I guess if you have a fairly consistant framerate the smoothing can create a 'smoother' finish but if your code has some heavy functions which are used irregularly it might be better to not use it.

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 9th Sep 2010 18:01
That's pretty much it. I don't think it does work in all situations, it's just a solution that solved a problem I was having. YMMV as some would say..

In fact, I'm not even sure I came up with it. I thought I saw it in one of Dark Coder's posts before all this started, but I can't find it now.

If it doesn't work with 30 steps, you might get better smoothing from 60 or 90 or more. Granted that introduces more error mathematically, but if it gives the desired visual effect, then it's doing what it was meant to.

=PRoF=
23
Years of Service
User Offline
Joined: 17th Mar 2003
Location: Milton Keynes, UK
Posted: 9th Sep 2010 18:01
To date I would have to say that in my experience of using Averaging/smoothing with Timer Based Movement; I find that NOT using it is the prefered method for smoothness (especially on less powerful machines).

However, I've not yet tried KISTechs method of "decoupling the display", which would possibly remove the problems caused by using averaging/smoothing.

I am definately going to try this method though, after I have finished my Intel Comp entry.

Login to post a reply

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