About the jerkiness on the movement...

...Or stuttering as it has been described on other topics. This is starting to get on my nerves, while it is certainty subtle, this jerkiness on moving objects, scrolling backgrounds and anything that has to have a smooth movement in general, the more I test and fiddle around with Construct, the more evident and annoying it gets. In this topic R0J0hound gives some intelligent input to the non educated like my self, I keep the garbage collection procedure as one candidate for the problem, the issue is how to eliminate this thing. I can not accept this as a handicap on C2 generated games. As a little issue that perhaps the average angry bird user wont notice. It's a real problem both aesthetically and gameplay wise in fast paced & tight controlled games.

I've finally made a 60 fps screen capture of a simple test capx. The problem is vastly exaggerated from the video capture, but it is indicative as to how this jerkiness looks like. There are some parts in the video that the movement is smooth and notice that the fps are 99% of the time at 60. In reality, on every layout cycle the jerkiness will happen 3 or 4 times. So, this means than every 5-7 seconds (on average) the user will experience an unwanted jerkiness that will disconnect him or her from the desired gameplay.

Here is the video file zipped:

[attachment=1:9elj9hqt][/attachment:9elj9hqt]

And here is the capx.

[attachment=0:9elj9hqt][/attachment:9elj9hqt]

—, if this HTML5 & browser related and can not be fixed, then it's a serious problem on the direction Scirra has taken with no native export. This isn't something that needs benchmarks to see, it's obvious to the naked eye and it should be addressed. My question is, can it be addressed? Is it something that Scirra can do to fix this?

when I run the capx (preview or exported) it doesn't look like the video..

EDIT: I guess you said the video exaggerates it, but I only get one moment of jerkiness (if at all) right on the initial load.

Not that I haven't experienced the jerkiness, I'm just not seeing it here.

I saw that problem in the past actually, and I think GC is the culprit, as I remember some updates lowering it a lot in some of my projects, I would say it is possible to fight it (I think it is:

Duration of a tick min(1/Vsync, (time took by the GC when it cleans up+max(time for rendering, time for logic))), so if we can have guidelines on how to reduce the amount of garbage, and if some updates helps with that, that could be done.)

Also, that would mean that an higher end computer will not see the problem as much due to the speed of rendering and logic, so if you do not sees it, that could be why, but this problem exists.

Also, one should keep in mind that html5 is a relative new way of game development, that still is in it's beginning with a lot of things to improve. I think in the future we will have less problems, as browser support, performance and stability will improve for sure. But until then, one should consider if C2 is the right tool for his project. If you want make fast, heavy action games with lot of things going on, maybe you should choose another tool, like Unity or Game Maker, that offers 'true' native export. I don't say, that Scirra should not try to improve and fix these issues, but everything has it's limits and maybe they just can't be fixed right now.

OP, do you have webGL enabled in the browser that you took that video from? That is the exact same stuttering I get when webgl is off for any reason, and FPS seems irrelevant when it happens.

Can you double check the webgl is active? This also would explain why others running it don't share the issue.

Also, one should keep in mind that html5 is a relative new way of game development, that still is in it's beginning with a lot of things to improve. I think in the future we will have less problems, as browser support, performance and stability will improve for sure. But until then, one should consider if C2 is the right tool for his project. If you want make fast, heavy action games with lot of things going on, maybe you should choose another tool, like Unity or Game Maker, that offers 'true' native export. I don't say, that Scirra should not try to improve and fix these issues, but everything has it's limits and maybe they just can't be fixed right now.

I can't accept the fact that HTML5 is a new gaming platform for this particular issue. Having a constant, smooth movement is a foundational premise and one should build the rest of the game upon that. I am criticizing the fact that in any simple capx with 10 sprites and 3 events the user's experience will be compromised by this kind of jerky behavior. I don't think that I should need unity to create something as elementary as the example I posted here and run it without hiccups.

skelooth , I use chrome to check my tests, I find chrome to be the fastest browser and more reliable in sound issues currently. Yes, the webgl is enabled (not disabled in the chrome://flags), I have an nvidia gtx 660 ti on my system and my graphic drivers are up-to-date. I repeat that the capture does not represent reality, the jerkiness in this video is very frequent and evident most of the time. I am posting it however because it captures and portrays the thing that I describe and name "jerkiness", just to make sure that we are all on the same page. In reality, every few seconds (between 5 and 10 or so) this "thing" happens, it lasts for a fraction of a second and it looks like the object that is in motion goes back and forward, occasionally with ghosting frames in-between, just as you can see in the video.

Perhaps my eyes are hyper sensitive to the motion, frankly, I am puzzled that this subject isn't brought up more often by other users. I don't think that they don't experience it, my guess is that they choose to ignore it as a minor issue. However, I don't accept it as something trivial, I believe that this is a major flaw for any final project. I am not trying to blame Scirra for it, I just have to know if there is something that can be done about it or not.

I agree 100% with — I've noticed this jerky movement, especially at the start of a layout, and it's a real quality spoiler. There are plenty of html5 games that don't suffer from stuttering and I would expect C2 should be able to produce the goods with respect to quality rendering, especially for simple layouts like the example posted above.

"I use chrome to check my tests, I find chrome to be the fastest browser and more reliable in sound issues currently. Yes, the webgl is enabled (not disabled in the chrome://flags)"

Maybe it's being reported incorrectly? Do webgl only effects display? My experience is that C2 is always smooth with webgl, even at low frame rates its consistent, but non webgl is always very jerky, and have tested this on 5 machines/devices. , win7, android, linux, linux in a vm, win8, using a variety of methods (manually disabling gpu, using different browser, etc) to cripple or enable the webgl.

This is literally all I have to go on.

It looks like either DT is inconsistent or there is some sort of pixel rounding issue in certain contexts. at least to my eyes. (I keep harping on pixel rounding problems because if things are being rounded wrong or being forced to render at solid positions, you could get a discrepency of as much as 2 pixels per tick, and that would have a net effect of looking a lot like the jerkiness we're seeing).

Again though, I've only seen it happen in non webgl mode.

And to note, I do not believe it's C2's doing. I'm pretty convinced this is a technical limitation to canvas.

On my old wheezing laptop, webgl off produced smoother scrolling than when it was on...

So I just did a rather unscientific webgl on/off test on the layout I'm working on - and webgl off is smoother by a country mile (Intel HD4600 and i7 with more RAM than I will ever need). That's not right, is it?

Edit to add that after 10-15 secs the webgl on scrolling becomes smooth, it's only a visible issue at the start of the layout.

Check your GPU benchmarks. I assume games run okay? Do you ever get artifacting? maybe you have a specific hardware problem? Because you're right, it should go in the opposite direction, especially with a 660 it should be able to crank out 100s of fps (i get solid 120fps on my 120hz monitor for simple c2 apps)

Edit:

Oversight on my part, do you have many webgl only effects enabled? Because that would explain the non intuitive frame rate change.

On my old wheezing laptop, webgl off produced smoother scrolling than when it was on...

So I just did a rather unscientific webgl on/off test on the layout I'm working on - and webgl off is smoother by a country mile (Intel HD4600 and i7 with more RAM than I will ever need). That's not right, is it?

Edit to add that after 10-15 secs the webgl on scrolling becomes smooth, it's only a visible issue at the start of the layout.

WebGL adds some overhead on the JS part, that would confirm the Garbage Collection then.

Good questions skelooth, and no - I have no webgl shader effects on my layout, platform behaviour, 4 parallaxing layers, 220 objects and 30 collision checks per tick. The interesting thing is that the engine seems to settle down after a short while, and that it seems to get 'upset' by changes to the layout content....

I just tried Ashley's performance test in Chrome... webgl off = 6000 objects at 30 fps, webgl on = 4000 objects at 30 fps. I have no idea why webgl would be less efficient than canvas... I got similar but slightly worse performance in Firefox.

here's the link to the blog with the perf tests

Aphrodite, GC is where my suspicions lie as well.

skelooth , I don't know how to check if it's reported incorrectly, I am able to run very complex scenes with tons of webgl effects in constant 60 fps and the jerkiness will be the same. If my card is somehow blacklisted and my tests run on brute force with a handicap that takes the form of stuttering, I would very much like to know how to check and fix it, although the same will hold true to any other user that will try to play the game and will be vulnerable and hopeless against the Browser's capricious blacklisting. Also, if this isn't the case, I wonder what good is disabling webgl in C2 is for, if it creates this kind of fundamental problem. I don't think that's the case.

On the other hand, contrary to the issue mentioned in this post , I don't encounter these crippling problems that are mentioned there when the frame rate goes below any reasonable value. I made a test that spawns sprites until any given fps threshold and up to 17.000 sprites or so I get 60 fps. If I continue to spawn sprites the game still feels ok until 20-25 fps (around 27.500 sprites), at that time it just doesn't feel responsive anymore. The jerkiness issue that I have exists in every intermediate frame rate value, but when the fps drop as low as 20 or so it's not anymore a noticeable or relative issue.

Also, in your last post if you are referring to Colludium , he has Intel HD graphics, I am the one that mentioned the 660 ti.

Colludium , are you sure that you can't detect the issue after 10-15 seconds? Remember that it comes and goes sporadically and it's evident if you keep following the square with your eyes (in my example). Otherwise, you need to have some kind of interactivity to notice it (like a platformer that moves and jumps around), or infinite scrolling backgrounds that move at constant rates.

And yes, I feel too that changes in scenery (like moving into an other area of the layout) affect this issue. I just don't even go that much ahead, I want to nail it and see if it exists even at the basic level.

[quote:2nud8k5r]Also, in your last post if you are referring to Colludium , he has Intel HD graphics, I am the one that mentioned the 660 ti.

I'm just too lazy to cross reference who's saying what, and offering my experiences in hopes that someone finds them helpful.

When you are benchmarking all of these sprites, do they move? (so you can look for jitters?) 27,000 sprites is an aweful lot. At that point the bottle neck might be CPU and not graphics since it needs to loop through all those sprite objects each tick. Bottle necked code by nature feels unresponsive, because it takes longer for input signals to get processed.