Experiments with Engine Step Size.

So, I've been fooling around with a simple formula that adjusts the game to adjust to step size.



The top code adjusts the step size (ten is default) and the bottom adjusts the based off the step size. This can be used to filter out movement so it works properly no matter the step size. For example, if you want consistent X-speed:



This works with most things step size tends to affect (x,y speeds, gravity) And thus, by theory, allows the game to remain consistent in timing for most of the issues step-size can cause.

Here's where it gets interesting. As higher step sizes (game runs slower) actually allows for more performance! I've done various tests below with always active, collision based actors. with a behavior attached to each.

Flash testing:

10 - default: 35-40 of these before heavy FPS drops on my PC on flash



20 - About 75-80-ish before heavy FPS drops. The game runs with 1 frame input delay, which doesn't function that badly. (Note, moving the camera other than pointing it to an actor causes it to stutter at anything after 10, which I would avoid)



30 - Input delay is noticeable, timing on variable functions feels iffy, almost 90 of these actors until heavy frame drops.



40 - Collision issues, and stiff feeling of control. Almost 110 actors before heavy frame drops. Game seems to skip frames?



Decided anything after 50 would not feel worth to document.

Windows:

It's been well known that windows runs miles better than Flash, so lets put that to the test, shall we? (Note, all the same odd effects like input delay also count here)

10 (default) - about 180 before dropping to 30 FPS on my rig



20 - 250 before I started getting some nasty lag.



30 -  about 290-ish before the lag got bad.



40 - 330 actors before heavy lag.



So what about a step size of 5? Which is the game running twice as fast, and thus demands more resources. Logically, it would make things move at half speed. But for impacts on FPS? Let's test.

Flash - 20 actors before serious lag.



Windows - 100 is when the FPS dropped badly



(Also, anyone with a 60 + FPS monitor want to test if it will run at beyond 60 FPS with this method? Would be interesting)

Lag and functions.

For those who don't know, change in attribute functions can react oddly in some ways when the FPS drops. Depending on how you use them, the following can happen on low FPS:

* If used for X and Y speed momentum, it'll cause you to slide about like ice heavily.

* Things will take longer to react (for example, if you used a function as a way to determine if a button has been held)

Logically, some automatic adjustment behavior will need to be set up based off the FPS in order to fix this.

In conclusion. If you wanted to squeeze out some extra performance subtly, you could make the game run at a step size of 20 and adjust the timing and movement as so.  This both doesn't look that awful, and doesn't hinder gameplay as much as others.

The physics model is going to degrade as the step size increases. If you're relying on accurate physics then I can't say modifying the step size is a good idea.

If you run the engine at a lower tick rate than the drawing refresh rate, then you'll get multiple frames for the same engine iteration. For 60FPS this means you shouldn't set the step size greater than 16.

Worse though is the case where the engine step size is longer than the frame time, and step size is not a multiple of frame time. Consider setting the engine to 50 ticks per second, and drawing at 60 frames per second. Some frames will draw the same engine iteration twice, where as some will only draw it once. That might be why you're getting a stutter.

If you have a performance issue there's probably another solution that gives you better gains with less risk for new problems.

Interesting. I assumed that it ran slower, which is why the performance was overall better.

Either way, I just did this more so as a test to see how the engine would function at different step rates. I am interested at what happens to the refresh rate when ran at 5, though.

I'd expect diminishing returns on performance. Fewer engine updates will certainly mean less CPU usage, but the engine update loop isn't the only factor in CPU use. If you run more updates per second then you should get improved accuracy in the physics simulation, but you wouldn't really see the difference unless you were modeling something that's unstable at default values (like a tall stack of boxes).