About the jerkiness on the movement...

Discussion and feedback on Construct 2

Post » Mon Oct 27, 2014 12:24 am

Sorry for the double post. Editing is not very reasonable on my phone right now.

But I forgot to mention for start up jerkiness people should have a loading screen/pause a layout momentarily on start up/ layout change.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Mon Oct 27, 2014 10:42 am

Actually, lerping the positions graphically would not help that much, as the lerping would jitter as well, and would be an insane amount of work just to work around bugs that will be fixed eventually (#reallife, you cannot rely on hack tricks, bugs must be fixed, as doing hacks tricks is the worst you could do actually for anyone involved).

Same for the loader, it will make the player wait an empirical amount of time, when this jitter will be fixed, it will be there, making people wait for no reason (well, I guess the jit compilation would benefit from that even later so it is not that problematic if done well.)
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Mon Oct 27, 2014 6:39 pm

Aphrodite wrote:Actually, lerping the positions graphically would not help that much, as the lerping would jitter as well, and would be an insane amount of work just to work around bugs that will be fixed eventually (#reallife, you cannot rely on hack tricks, bugs must be fixed, as doing hacks tricks is the worst you could do actually for anyone involved).

Same for the loader, it will make the player wait an empirical amount of time, when this jitter will be fixed, it will be there, making people wait for no reason (well, I guess the jit compilation would benefit from that even later so it is not that problematic if done well.)


How would keeping not help? Wouldn't it smooth the movement so to speak?

As for loading, I was under the impression many people see the most littering at a layout change or project start. A load/pause would allow all resources to fully load hopefully reducing jitter.

But I agree completely. Movement and animations should looks smooth without having to find ways to "fix" it.
But I wonder what might be broken. I know personally I don't have any perceivable jitter. I also have a rather powerful computer CPU and gpu wise....which doesn't help with trying to find performance or visual stuttering haha.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Mon Oct 27, 2014 11:52 pm

Tylermon wrote:How would keeping not help? Wouldn't it smooth the movement so to speak?


I think that the problem is that during run-time you don't know when a frame is going to be dropped by the browser - so your lerp-ed positions won't always be drawn every tick anyway. And once a frame update is missed then it's too late... Also, lerp-ing everything will just add to the cpu/gpu workload, which is unlikely to help the problem. The only way to have a smooth experience across a broad range of browsers seems to be to have a small and not-zoomed canvas size and to have not much graphical changes taking place (kind of the opposite of what I want to do...).
A big fan of JavaScript.
B
74
S
20
G
69
Posts: 2,215
Reputation: 43,852

Post » Tue Oct 28, 2014 12:35 am

@Colludium there is no way to avoid this issue. its everywhere. some people are more sensitive to it than others. but its clearly a lot better with IE, it has only the "normal"lags whith whith i can also live. ive tryed it on several high end pc`s, linux, android, laptops and so on... its aleways there. you just cant see it so good with small layouts haha :D

regards
B
19
S
7
G
1
Posts: 222
Reputation: 2,546

Post » Tue Oct 28, 2014 1:22 am

Yeah - IE is smoother than Chrome by a long way. Pity its interface is so, well, Microsoft...!!
A big fan of JavaScript.
B
74
S
20
G
69
Posts: 2,215
Reputation: 43,852

Post » Tue Oct 28, 2014 3:18 am

Wow, this might explain the micro-pauses I'm getting with my game on CocoonJS! Perhaps there is hope after all, since Ashley's theory seems pretty spot on.

If anyone is interested, I made a thread on Ludei's website, requesting them to also look into their compiler to see if they can fix the frame dropping. If you're also a "Cocooner" then please upvote the thread to show your interest in the issue.

And also, I made a simulation of what my simple bouncing square application looks like on my phone through CocoonJS. I have always assumed the stutter was simply garbage collection, but now I'm thinking it's a combination of that and synchronous compilation. Whatever it is, I hope it can be fixed soon!
Image
B
10
S
3
G
2
Posts: 196
Reputation: 2,053

Post » Tue Oct 28, 2014 4:41 am

Poking around, it looks like construct 2 uses
requestAnimationFrame
and
setTimeout

Like Dalal said, this causes problems. Browsers can do only one thing at a time, and with javascript this eventually leads to this stuttering.
The solution? As far as I can tell is to use CSS for animations.

found this example online.

http://www.html5rocks.com/en/tutorials/ ... e-raf.html (The way it looks like Construct 2 animates using requestAnimationFrame)

http://www.html5rocks.com/en/tutorials/ ... imple.html (The same animation using css)

Edit:
Also reading about GSAP
http://greensock.com/gsap
Looks fairly promising.

As for if this necessarily will help with smooth animations I cant say. I feel a square box is rather different than an animated character/object changing frames.
Part of the issue also falls to device vertical sync and fps. I took the example from page 1, changed speed to always match fps. And obviously there was 0 jittering.
The problem is it moved slower than I like.
There could be an internal issue within construct and how it draws frames, because it does not match the refresh rate. (Everything takes place logically as if 60fps I believe?)

Digging around, it looked like this is due to that setTimeout code I was talking about. It looks like it is set to 16ms (60fps) which obviously is bad. Static frame rate/refresh/logic has these issues. A dynamic system would always look smooth. Able to adjust with fps drops and rises.
I could be wrong about how construct is animating things. But It would probably be better if it animated based on dt rather than using the timeout.

The people with high refresh devices don't see nearly as much jitter because they refresh so fast it compensates for any fps variance.






Ahhhhh screw it. Everything I know and keep reading about game/film/web animation and why it looks "jerky/jittery" all comes back to interpolation. If you interpolate between delta time and desired speed things should look smooth(er). I think the issue comes from while speed might be interpolated etc, the animation frames themselves are not. The draw calls themselves should interpolate what we see, I don't think it does.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Tue Oct 28, 2014 2:10 pm

Tylermon wrote:Part of the issue also falls to device vertical sync and fps. I took the example from page 1, changed speed to always match fps. And obviously there was 0 jittering.
The problem is it moved slower than I like.


Can you please post the changed example? I am curious to see if it will perform with 0 jittering on my machine also.

As for the CSS vs RequestAnimationFrame, call me crazy but the CSS performs worse on my system! That's on Chrome, Firefox and IE 11 doesn't animate the thing at all!
composer - multimedia artist
www.eli0s.com/en/
B
69
S
26
G
5
Posts: 1,146
Reputation: 9,829

Post » Tue Oct 28, 2014 2:20 pm

eli0s wrote:As for the CSS vs RequestAnimationFrame, call me crazy but the CSS performs worse on my system! That's on Chrome, Firefox and IE 11 doesn't animate the thing at all!


On my system actually RequestAnimationFrame looks almost like stop-motion animation, while CSS is nice and smooth. Tested in Chrome only.
ImageImageImageImage
B
157
S
66
G
41
Posts: 2,599
Reputation: 34,835

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: bobcgausa and 12 guests