[Apologies if there's actually a way to do this already that I've missed! Please do let me know if that's the case!]

I've been running into a little bit of frustration, particularly with the Pin behavior. Basically, in terms of order of execution, it seems like behaviours always take place at the end of the (main) event sheet. This seems perfectly reasonable, but it causes problems in cases like the one I have now. Basically, I have objects that are pinned to other objects, which works perfectly fine. The problem is, if I want to have an object set position to, or point towards, a pinned object, there will always be a 1-tick delay. In some cases, it's very noticeable.

As far as I know, there's currently no way to get around this without scrapping the Pin behaviour entirely in that case, which isn't feasible for me as it's a pretty big part of my terrain motion system.

I don't really know what would work well in terms of a solution. Ideally, we'd be able to override the execution of any behaviour (or, at least, ones prevalent with this issue like Pin) to a specific place in the event sheet. No idea how feasible that is technically, however!

Anyone else run into this issue?

Nobody really ever knows what they are doing, they just do their best to get along.

0. Already have released a number of smaller, simpler games which have given you the knowledge and feedback necessary you need to avoid simple mistakes that will cripple development of a larger game.

szymek that Timeline feature looks interesting. Anyone who knows more than me know if that would be useful in diagnosing the current janking problems?

Intel HD graphics is the most common graphics card, so it really needs to be supported, even if NVIDIA wasn't being stupid and falling back when there's a much better GPU.

I've definitely been experiencing these stutters and latency since well before Chrome 38. Aurel Aphrodite can you confirm?

Just saw this post in another topic.

At this point in time there are 3 main reasons games don't get to run buttery smooth (as far as I'm aware):

1) GPU blacklisting: although this is becoming less serious over time as old devices die out, it's still not too hard to find old Windows systems or old Android phones where the GPU is buggy and prone to crashing, so the browser falls back to software rendering.

2) Synchronous Javascript compilation. While most JS engines compile code concurrently, apparently they still have some key points which still run synchronously, so block the game while it does whatever it needs to do. I think this only affects mobile, since most desktops are simply fast enough to do that work in <16ms and not drop a frame. Javascript engine improvements should resolve this, we have open bugs with browser vendors for this type of issue.

3) V-sync quality. This is a passing issue in Chrome (the Chromium team is aware of it and are working to fix it) and Firefox (which to me looks already fixed in Nightly), and is made worse by the fact the latest node-webkit is based on Chromium 38 which has the bug. This will be fixed in due course as subsequent Chromium and node-webkit updates come through.

This issue definitely doesn't fit in any one of these categories. I don't think this is related to the v-sync issue at all, since these issues definitely happened in Chrome 38 and before that as well.

No, it's nothing to do with the logic side of things, because it's purely based on window size.

— I find that the problems with streaming/recording are just an extension of the problems at large, e.g. fillrate limitations. Basically, when recording, the game is more likely to dip below 60fps, even on a very good machine. Even my high-end gaming laptop can barely run the game at 60fps and record at the same time (and that's *after* going through the shenanigans with the NVIDIA Control Panel to get the game to even use the GPU!)

These stutters/input lag have always happened afaik. I think it's a separate issue from the janking that's happening in later Chrome versions. Honestly, I don't even notice the janking amidst these other issues!

My question is: where do we go from here? I can't in good conscience release a game in this state. It's clear that minimal repros don't show the problems as effectively as 'real games'.

Maybe what we need to do is take some time to figure out exactly what it is in full games that makes the performance so bad. WebGL shaders was my #1 suspect, but disabling all the shaders in the game actually didn't have too much of an effect.

In 3 years using Construct 2, it seems like it's been constant battling with browser and wrapper developers. HTML5 is great, but we're entirely at the mercy of faceless megacorporations, usually with games not even being a priority for them. This makes professional development hugely frustrating. I can't commit to a release window because I have no idea when these bugs will be fixed. I can't commit to release on certain platforms (linux) due to some sort of driver issues.

The game is supposed to release in a few months but I'm afraid that eventually I'm going to have to delay it. Ignoring the fact that performance sucks for a lot of players, looking bad on youtube/livestreams is the worst thing a game can do, marketing-wise.

Yes, all these issues definitely have one major thing in common: window size (or, more accurately, GPU fillrate).

Yeah, Firefox is totally fine.

What Aurel said is basically the situation as I'm seeing it too. 60fps+, everything works great. But, as soon as we start to dip below that, things start going haywire. Things like livestreams, recording etc (especially with no GPU support) can cause lots of games to dip fps, and C2 games suffer horribly. Look up any YT video of Airscape and it's just terrible. I can barely even bear to watch recordings of Airscape anymore!

Optimization: Don't waste your time