[REQUEST] Developer to set FPS

Ashley - Thanks for doing this. I just tried it out with my game, and as you said it has some unusual behaviours. I have a event that reads:

Every tick - Apply Force Self.Physics.Mass*12*dt at angle 90

This creates a gravity in physics that I can turn around or completely turn off.

In any case, I'm finding that it appears to be twice as strong now. I believe it's the DT that's causing the change, which is unusual. Please see this capx for an example:

https://dl.dropboxusercontent.com/u/50465867/Errors/FrameRate.capx

The problem seems to stem from the frame rate independence. Toggling in and out of it causes more issues.

Thanks for doing this. I just tried it out with my game, and as you said it has some unusual behaviours. I have a event that reads:

Every tick - Apply Force Self.Physics.Mass*12*dt at angle 90

This creates a gravity in physics that I can turn around or completely turn off.

In any case, I'm finding that it appears to be twice as strong now. I believe it's the DT that's causing the change, which is unusual. Please see this capx for an example:

https://dl.dropboxusercontent.com/u/50465867/Errors/FrameRate.capx

I don't think force should use dt in that case, if the frame rate is 30, the dt will double, it is normal, since dt is the time between frames.

or maybe I misunderstood

AnD4D

Time

dt

Return delta-time according to the object's own timescale. See Delta-time and framerate independence for more information.

scirra.com/manual/133/common-expressions

scirra.com/tutorials/67/delta-time-and-framerate-independence

You shouldn't use dt when applying forces. The physics engine applies dt itself if it has been enabled.

Ashley - When I do not use dt with force in my game, the physical objects move slowly on mobile devices, even with framerate independence on. When I use DT, the physics moves as expected. This was a change I made only yesterday, and it improved my game somewhat.

Not sure what else I can do then. As I said, force doesn't appear to be working for me the way I want it to without DT.

It's only when I use the new frame rate half function that things break now.

What are my alternatives?

Instead of every tick, change it to every 0.001 seconds? If using DT gives me the effect I want, how should I not use it?

Thanks a lot Ashley to try to implement it :)

I hope it will work well.

I can't try it (as a lot of beta, i have a "kernell32" pb that makes me unable to open the soft), but i hope it will be implemented on the next stable realease.

Thanks !

OK, first impressions:

From testing on my Laptop (FW31ZJ on Chrome, wheezingly old but reliable), i9100 Samsung S2 & Toshiba Excite tab (both in Android Chrome and CocoonJS) and iPhone 4S (Safari). Tested using a couple of embryonic games I have.

Bottom line: I?m not convinced....

On laptop (Chrome):

Is there a bug (?). If I set reduced framerate in layout 1 then this did not translate to layout 2: the game then played at 60 fps. If I set the reduced framerate in Layout 2 then all worked as expected (on Chrome in Windows 7).

Reduced quality on laptop. This is not because of the reduced framerate; to my eye it appeared that the game framerate was varying slightly even though the fps showed a constant 30.

Mobile / tablet:

Within CocoonJS (not compiled to apk ? only in debug app). I add this for interest as I know this will not be a direct concern. With reduced framerate enabled, CocoonJS debug display shows double the framerate I would normally expect (approx 120 on the S2) while on an on-game fps display I had the fps was shown as 60 and not 30... Wierd.

On mobile (Android Chrome / Safari): Results of variable quality. To be honest, I didn?t notice any significant improvement in the quality of the displayed games when they were capped at 30 fps, as if ? similar to the case with the laptop browser ? the update rate was changing ever-so slightly during play even though the indicated fps figure was a constant 30 fps. This was similar behaviour I had observed when the fps was not capped, so this was not an improvement in my opinion.

So, I now take a big fat slice of humble pie. I think that Ashley was right on this one (I owe you at least one beer!). Unless there is another way to cap the fps at a solid rate with less jerky results, this isn?t the solution I was hoping it would be ? at least for my needs. As previously mentioned, the fix will probably be to be patient and wait until mobile browser / cpu technology catches up. Sigh.

Anyone else any thoughts?

AnD4D

That's right. You shouldn't be using dt. I understand the the desire too. but it's a bad idea. Box2D isn't built to work with dt. Box2D has a straight foward information that the results of Physics from Box2D are dependent on the binary being run on. So this means that results will be different from different CPU render levels.

Box2D suggestion is to just use different levels of settings for the devices. This is annoying. Instead there is a way better alternative. There is a high resolution fixed time step for Box2D. but it needs to be programmed in manually to the use of Box2D. The problem is that C2 fixed time step is rudemntary and not advanced enough to handle different platforms. You will need to modify physics timestep option. So every tick you will need t modify how many steps the Physics will use. This will smooth your physics.

Also I want to point out that I'm not convinced that the 30fps implementation in C2 right now is the right implementation. From what was written it sounds like option doesn't limit just FPS rendering to 30FPS, but also your entire game logic. How hard is it to just say. Draw On Time X and to set that time X. I get the feeling this is an entire game slow down :( BUT I could be wrong and we might just need more practice.

jayderyu

In my game I have a variable that has dt taken away from it every tick. This is the timer. I have a physics object that is constantly pulled in directions using force.

Without dt, at 60fps, it's fine. On my mobile device, on occasion it's so slow the timer manages to run out before the physics object manages to drop. If dt is already on physics objects, why does this happen?

If I add dt to the force, it seems fine on my mobile device. I'm so confused. I'll switch it back to without dt, but I'm not sure what's going on.

AnD4D

because dt is still based on a millisecond clock. C2 uses dt based on a 60fps millisecond clock. So when you use dt your trying to create a universal math and multiplied value. The reason and it's just suspect reason that the 30fps dt isn't the same due to the idea that yoru also only processing logic at 30fps rather than continuing to handle logic at 60fps.

Not that I would associate logic to FPS at all. I'm just using that as an anology.

So on

PC, box.ImpulseAngle(0, 100 * dt)

iPAd, box.ImpulseAngle(0, 100 * dt)

In theory tries to unify the the force based on the clock. So results should be similar.

How physics works is that Box2D uses a time step.

Each time step consists of 2 primary values.*

* Step

Step is the amount of px the objects moves per itteration. Large steps allow for farther movement. but this reduces accuracy for collision detection. This can lead bullets to shoot through objects.

*Itteration

The number of times the physics shuold take 1 step(above). The more itterations a Physics.Render will call step.

Now when a programmer makes the basic timestep. it tries to take into account the difference of time from last frame render and how many Itterations shuold be called. However this usually works best for FASTER computers and often the basic time step doesn't do very well on slower than the primary development computer.

This is the problem that's happening hear. Your slower computer can't keep up with out something to fix the speed value.

Now how does dt come into this.

Well keep in mind that the dt is a reference time between. 0.0 to 1.0. On a faster computer the dt is much smaller due to the fact that it does everything faster. Where as a slower computer dt is a larger number to compensate for the difference in time.

So when you set your mobile game to run at 29fps vsync it falls out of sync. And the reason I think this is happening is because yoru logic is now running at 29fps(speculation based on what I'm hearing. In theory with all the exrta time your logic should be able to more than keep up... unless your game logic is throttled.

So this is why I think the current C2 use of 30fps isn't to give developers more logic time for physics and game processing, but instead to slow down the game to run on older devices. So instead of giving you access to all the yummy CPU time. C2 drops everything.

That's all speculation of course. but it's one reason why your game is having troubles with the lower 30fps.. you don't have more CPU time you have less.

Colludium's results are pretty much what I saw: it did not work reliably, and it was still choppy even when half framerate mode was in effect and it was measuring 30 FPS. I'm not sure how it could be improved - the current algorithm is "if last frame was not skipped, and the last frame was less than 29ms ago, skip this frame". That ought to work with vsync-aligned ticks, but I guess browsers (and non-browser platforms like CocoonJS) treat their tick rates differently or give up vsync-aligning ticks in some cases. Perhaps this might be possible to do well in a native engine, but I think since there seems to be varied tick rate logic in each browser I doubt it is possible to make a high-quality framerate limiter that works across all browsers.

One solution might be to just alternate frames blindly (just skip every other frame regardless of timing). However on a 60 Hz monitor as soon as you drop to 29 FPS you might end up halving the framerate all the way down to 15 FPS again. I'll do some tests and see what really happens with that.

Ashley

Is it possible to force DT to be greater than/equal to 29ms instead of skipping? When you say skipping it sounds like it either still does the same calculations but skips rendering, or it ignores the processing for that tick.

Maybe make a "End of Tick" check, where if by the time it's done processing that tick, if 29ms has passed it goes through, but if not then it waits. This way you'll have some potential idling on the processing side, but it should never stutter on it's own if it can run at any framerate above 30fps smoothly as you're not halving a rate but just waiting until the rate is a certain amount. Well theoretically, but as far as I know you might be doing that already. :P

Other than that I do not know. IMO if you can't get it to work smoothly in a week you can always come back to it at a later time, as there are more important features to work on.

Ashley, thank you for continuing to look into this. I really think that this can be a tremendously important new feature, especially for action games.

Incidentally, how do other developers do it? What logic do they apply to only draw 30 times a second while processing logic at normal speed?