Efficiency of a .02 Timer trigger

[Infinitegde]

Mmmkay. I'm making a physics system (so far, successful), but one problem is the fact that I was using a .03 second timer, which was very choppy so to speak, so I switched over to a .02 second timer, which is medium choppy, and I was wondering if I should switch down to a .01 in hopes that it will not be choppy at all. The problem is, is that, the timer regulates every unit on the map (which sometimes can go over 100), so I'm pretty sure this will lag, but I can't test it out atm, so I was wondering, just from experience, can .01 timers get laggy?

 

[TriggerHappy]

.01 timers get laggy

Very. Make sure you remove ALL leaks and don't use anything that deals with strings.

 

[Romek]

Timers can get laggy depending on what you're doing when it expires.
0.03 shouldn't be choppy though... And 0.02 isn't choppy either.
Maybe it's lag from what you're doing when they expire?

 

[Infinitegde]

LOL, yes I can imagine my screen full of random strings, and my comp starts to fry lol. Mmmmkay, so then how about a .02 vs .03 ?

No, not "choppy" as in the game freezes, but choppy as in the physics implemented make the units movements seem choppy. Like they are vibrating in place lol. (It's an ice physics system.)

 

[TriggerHappy]

0.03 is the safest and is what i usually use , the same goes for .02 as 0.01.

Very. Make sure you remove ALL leaks and don't use anything that deals with strings.

 

[Infinitegde]

Mkay, I'll leave it at .03 and try and clean it up.

 

[Romek]

What's wrong with using things that deal with strings?
As long as you're not creating a few unique strings every 0.01 seconds, then there really is no problem.
It's not like your computer will fry from displaying strings. Seems like you're getting the wrong idea here

 

[Infinitegde]

lol, its not that it will fry my computer literally, I put in debug msgs before and it was really irksome to play the game lol.

 

[DioD]

~30 fps is good, more then 40 waste of system resources.

 

[Builder Bob]

most physics systems work well on anything from 0.04-0.02 timers.

I find it strange that you experience very choppy unit movement with a 0.03 timer. There could be something in your calculations that makes it choppy. Like wrong rounding or something else.

 

[DioD]

you need to monitor FPS via tool or /fps command.

"choppy" actually can be FPS drop.

 

[Infinitegde]

hmm, no its not choppy as in laggy. The system is a ice physics system (atm) and right now Ive been working on sliding (already got collisions down =P ), and the prob is, the power is generated from the units movement, so if hes making a sharp turn, example, he goes X+ direction and accumulates a large Vel, if he suddenly turns and goes in X- direction, the unit movement and velocity collide so it looks like hes vibrating in place, thus making it seem choppy.

 

[chobibo]

maybe the problem is on x+ and x- values?

 

[Infinitegde]

na. The problem is that, during the .03 seconds the unit is not affected by change, he moves a certain distance, then when the timer activates he is moved a certain distance back, so it looks like he is vibrating as he moves, or warping very small distances.

 

[Builder Bob]

Ah, I know about that problem. I also made my ice physics like that in my map Gore Rider. I had to use a periodic 0.025 sec timer to make it look smooth for units up to 500 move speed.

It's an extensive system, as yours probably is too. With two axes (x/y) I can have up to about 10 units sliding without any fps drop, and with 3 axes (x/y/z) I start losing fps at anything over 8 units.


To figure out what timer period you need to use, I suggest you do this simple test:

Run a periodic timer that sets a unit's position to (x=0,y=0)
Give the unit move speed 522 (max)
Start the map and try to move the unit.
If it looks like it's not moving at all, you have the right timer period.

 

[Infinitegde]

Mmm but I also have 3 axes, and, although I dunno how to check the fps, I haven't noticed any difference when having multiple units sliding at the same time. (multiple as in 15-16)