full screen scrolling "jank" - wish to lock FPS

Ok..I really wish Construct 2 had a way for me to lock the FPS to something like 30.

My problem right now is I have a game where the entire screen is scrolling pretty fast. On PC is is 100% smooth. However, on mobile it "janks". In other words, randomly, the mobile device will decide it needs to do something else, causing the game to miss a few frames. When it catches back up, the scrolling "jerks" to catch up of course (its based on delta time). This "variance" in FPS looks bad and causes the game to lose "flow".

It's not the game that's the problem and in fact it's not really WebGL or HTML5 that is the problem. I also used to see this problem with OpenGL / C++ game I made a while back.

The problem is on a mobile device it's hard to get a 100% consistent 60fps SOLID, and any change in framerate will cause "jank" (even if the movements of things are tied to delta time, they still won't appear to update in time visually).

If I could somehow lock the game's FPS , or Tick, to 30 times a second, I think this would solve the problem, because any variance would be "covered" over by the lock - it could handle the variance by just subtracting or adding when it needed to, if you know what i mean.

I did experiment a bit with putting my own event in that watched delta time and basically "divided" it down and used that for movement. It seemed to work, but I don't recall if it was very effective or not.

Has anyone else seen this "jank" that I'm talking about? It's not due to the game I made nor due to how many objects there are. Because I can make a test game that is only one background image scrolling over and over, and you'll see the jank. Its more to do with the CPU of the device taking time to do other things while the game is running.

A lower FPS lock would give a frame "buffer" of time that could make up for any slight variances. trying to play at 60FPS does not, and will be extremely senstive to any change in frame rate, visually. (Objects still move correctly, but you will see a "jerk" in the motion because the frames are either being drawn twice, or it skips frames for a a couple frames)

-niko

As an example,

This code should lock to 30FPS.

Anyone else every play with this type of thing?

http://imgur.com/SeVqUyK

Reliably hitting 30 FPS on a 60 Hz display requires special scheduling support from the browser, which isn't supported yet, so you can't reliably do this right now. Here's an issue to star for Chrome to add support: http://crbug.com/522983

Hi Ashley, thanks for the response. Yep you're right, not much can be done about it right now. I'll just go with coding it all regular Thanks for the info

Hi all

So for now I fixed this problem by just using a constant every frame and ignoring dt altogether. Yes this means if the framerate slows down the game will too. That's fine IMO. (that's how all old school 2d games worked)

IMO many people use the whole multiply by delta time wrong. It is parroted over and over on the internet that you need to use it, but it causes more problems then it solves.

For one, you won't have determinism at all (you need a fixed time step for that - something that construct 2 can't really do at all...well, you can do it if you want to sacrifice some frames)

Secondly, ANY small change in framerate will cause "jerks" in motion because even though you *think* that multiplying by delta time will make your object maintain a constant speed, that's now how it works in the real world. Human eyes are very sensitive to small changes in motion like that (not to mention floating point errors), and that is the jerkiness I was seeing.

The best thing to do if you do want to use Delta time is to smooth it, don't use it directly! If you use it directly, and something causes a bunch of frames to drop, suddenly your objects will jump to a new position and the player has lost control (like I said, it's better to just slow down a bit rather than "jerk"). So if you want to stick with delta time then smooth it with the say, last 10 frames of dt, and use a running average as your dt, and not the instantaneous dt.

I still argue that just coding the game to be framerate dependent is best for 2d games. Especially on the iPhone where you know it's going to be 60fps cap. And most android phones these days are too. You could code the PC version to be delta time , but mobile should just use frame dependent to look better (or better yet, it should have two threads, one is the "physics" constant time, the other is the renderer itself with interpolation)

But seriously just multiplying everything by dt is only gonna cause problems in many, many cases

two good articles (besides the traidtional "fix your timestep" article)

http://www.learn-cocos2d.com/2013/10/game-engine-multiply-delta-time-or-not/

http://bitsquid.blogspot.com/2010/10/time-step-smoothing.html

nikolatesla20 .. Dude I want to really thank you for this. This was driving me crazy. I had only a simple demo going but I had jank. I was thinking can html/js be this bad???? I swapped animations , cut down backgrounds, cut sounds, used sprite sheets nothing worked. Of course I had a "smoothed" touch control and cam using the recommended lerp with dt. I was about to scrap Construct 2 for something else. just replaced x*dt with an equivalent constant and all jank gone and now smooth game demo..... I think it is insane that they recommend use dt for smooth anything. any frame drop will cause a jank. I tested on loads of high end latest phones all debug displays 60fps but if you analyse dt you will see it a very small change every few seconds on most mobiles. it was this that was casing the jank. thanks again.

Using dt may cause jank when fps drops but this is intended... if you don't use dt and you have very tight controls then weird things happen - like jumping being a different distance to what is intended. You should use dt only on things that are critical for exactness.

~Sol

I don't think so. in fact the opposite is true. whatever type of game you are making If you want pixel perfect exactness then you do not want to use dt for anything you want to let speed slow as framerate slows. if you have any part of you movement system tied to dt then even if you are running average 60 fps any momentary fluctuation in dt which appears to be very common, will cause your object to momentarily freeze or skip.

I don't think so. in fact the opposite is true. whatever type of game you are making If you want pixel perfect exactness then you do not want to use dt for anything you want to let speed slow as framerate slows. if you have any part of you movement system tied to dt then even if you are running average 60 fps any momentary fluctuation in dt which appears to be very common, will cause your object to momentarily freeze or skip.

Sorry I should have said, critical for exactness over time.

It's true that if you want pixel perfect exactness for collisions etc, not using dt can be better... however if you need to ensure your character moves X pixels over X time (for say, infinite runner games, or maybe using it for a real-time timer) then dt is essential.

dt is basically the equivalent of "skip X frames if less than 60fps" to make sure timed exactness is met.

~Sol