Construct as a unity editor extension.

Prominent - I don't understand what you're upset about - previously, you could be standing by a wall, and "Is by wall" was false if you happened to also have a ceiling above your head. We fixed it so it's true again, as some other users noticed and insisted ought to be the case (and I agree). There is a backwards-compatibility risk which I carefully considered and was worried about, but I think you have to admit it makes more sense this way. Do you disagree? Should "Is by wall" still be false if you are by a wall, but happen to have a ceiling above you?

Does it return true if you are touching a ceiling and no wall to right or left? Because the way you word it in the update is that it would do this. If it does, then that seems bad to me.

"Platform behavior: 'Is by wall' is now true if the player has an obstacle directly above them"

-That wording fails to make clear if you are next to a wall while under an obstacle. It just says if you are under.

Does it return true if you are touching a ceiling and no wall to right or left?

No. Obviously that would defeat the purpose of the condition.

> Does it return true if you are touching a ceiling and no wall to right or left?

>

No. Obviously that would defeat the purpose of the condition.

Alright, well I wasn't the only one confused by the wording- I guess it is my fault for not realizing that the 'is by wall' condition has a left/right option.

Last I checked, most browsers could v-sync reliably to within 0.1ms. I'd be interested in any .capx examples I can try out. It's also important to say which browser and OS you're testing on.

https://www.dropbox.com/s/tyfj5687kmvf8 ... .capx?dl=0

Windows 10

Chrome Version 61.0.3163.79 (Official Build) (64-bit)

HW: desktop i5-6400, Geforce GTX960

It randomly shows frames of 2/60 if minimum framerate is 30 and sometimes 3/60 if you lower the min fps to 10.

Why does it drop to 30fps from a slightest irregularity? I'd rather show the next frame after 17ms instead of 32ms.

This shows noticeable jank while scrolling fast and when there's a sprite trying to flicker at 60hz.

https://www.dropbox.com/s/tyfj5687kmvf8 ... .capx?dl=0

Windows 10

Chrome Version 61.0.3163.79 (Official Build) (64-bit)

HW: desktop i5-6400, Geforce GTX960

It randomly shows frames of 2/60 if minimum framerate is 30 and sometimes 3/60 if you lower the min fps to 10.

Why does it drop to 30fps from a slightest irregularity? I'd rather show the next frame after 17ms instead of 32ms.

This shows noticeable jank while scrolling fast and when there's a sprite trying to flicker at 60hz.

Running Windows 10

Construct 3 preview window fullscreen

Chrome version 61.0.3163.79 (Official Build) (64-bit)

HW: desktop i7-6700k, Geforce GTX 1070, 1920x1080p dual monitors

Can confirm that the sprite flickered once or twice, even while standing still, sometimes it's staying white, other times it stays black, but generally it was 1/60th of a second.

However, I'd like to see a NodeJS export, as it was noticeably smoother in Chrome than any of my experiences of Jank in NJS/Node-Webkit

Chrome devs have been wrestling with vsync for some time.

https://bugs.chromium.org/p/chromium/issues/detail?id=467617#c85

this is just one of many threads regarding vsync, it looks like a very complex issue, especially if user is using two monitors with different refresh rates.

last post there is 29 august

and it looks like they are very very close to identifying why there are jank issues in some situations....

i do recall when I first started using construct last year there was some serious jank issues

however I haven't noticed any serious jank for some time. (maybe a little on start up, or if doing something heavy outside chrome) but nothing like it was

> Last I checked, most browsers could v-sync reliably to within 0.1ms. I'd be interested in any .capx examples I can try out. It's also important to say which browser and OS you're testing on.

>

https://www.dropbox.com/s/tyfj5687kmvf8 ... .capx?dl=0

On my Windows 10 PC it shows consistently one color. It drops a drame about once every ten seconds. That's about the same as our old native engine in Construct Classic managed. So we have reached parity with native.

(Why would a native engine drop frames? The OS has dozens of threads to schedule, and sometimes it might just schedule some work somewhere else and miss a 16ms frame deadline. Often if you go fullscreen the OS boosts the process priority and this happens less.)

Flashes like a machine gun on my semi older machine, which you can assume is at least half the market on desktop.

Another reason you should be designing for low end rather than high end.

Really?? My 6 year old laptop no flashing whatsoever. Maybe 1st second turned from white to black, than stayed black the entire time ( I moved it around and jumped a few times over maybe a minute )

It's about 8, so less semi, more old.

On my Windows 10 PC it shows consistently one color. It drops a drame about once every ten seconds. That's about the same as our old native engine in Construct Classic managed. So we have reached parity with native.

(Why would a native engine drop frames? The OS has dozens of threads to schedule, and sometimes it might just schedule some work somewhere else and miss a 16ms frame deadline. Often if you go fullscreen the OS boosts the process priority and this happens less.)

That's a crazy logical leap.

Same as what your native engine did 7 years ago on hardware from that time vs. what your brand new engine on state of the art computers does today does not mean you have parity with native. Here we have newt saying his 8 year old computer can't run a nearly empty project with acceptable performance, on which the same test made with construct classic should work flawlessly.

I can have DOOM (yes the new one ) idle at rock solid 16ms and max 20ms if you start playing (windowed or not), but a nearly empty construct project will keep consistently missing vsync which causes it to have a sudden 32ms frame here and there.

Can you have adaptive vsync? Can you draw a frame at 17ms?

Does Chrome and by association NWJS get low process priority? If so, can this be overcome?

The jank might not be the fault of Construct, but it relies on technology that cannot in it's current form reach parity with a native engine.

Please correct me if I have misunderstood something.

Well I think the logic in the capx is a little flawed. Besides the 0.025 dt expectations, the switching between animations rather than frames is questionable as that's not an expected process. Likewise comparing animations does not give reliable results in the wild as part of vsync is the ability to skip frames.

To me just setting the frame using a counter (frame=count%2) would give more reliable readings.

I should point out that that will still give me the flashing, but not for long, and in waves, and that's at full screen.

I get hardly any changes at 25% that size and below.

https://www.dropbox.com/s/k5fo9clf25pmv ... .capx?dl=0

I should also point out that that the other capx did give me constant flashing at fullscreen, and hardly any at reduced sizes.

If it all came down to parity it would be both a huge relief and dissapointment at the same time. I currently greatly struggle with random, sudden framerate drops on mobile, which can easily be throw into the 40s, never properly managing to recover. I've done a ton of tests to verify I don't create objects that never gets destroyed, or do anything out of the ordinary to cause performance drops. With advanced profiling tools provided by a third party, the APK of my game on avarage only used about 60 % CPU and 50 % GPU. It's able to hold a stable 55-60 FPS if nothing interrupts on my S7.

While the heaviness of my game might contribute to this, many of these framerate drops feels unexplainable. It doesn't feel like I'm doing anything wrong. If it was parity, it could be explained like that the occational low priority makes the game just heavy enough to chug. (@ashley Testing enough times I saw the same type of framerate drops with high-DPI display off, my game might not be too bloated/GPU bound after all).

I've also seen pretty insane framerate drops when previewing in chrome on a 970 gtx 32gb ram monster PC, so parity definately sounds like a plausable explanation.

Just such a shame there's no way to work around it. This reminds me of the garbage collection issues I had for the longest time while developing Klang. Always something...

I've ported most of my game to Gamemaker so I feel I can speak with some confidence about this. From my observations, Construct builds seem to run about as fast, if not faster than, Gamemaker builds on desktop. C2 definitely outperforms GMS on one of my old laptops, where I get 55-60 fps for the former, and 45-50 fps for the latter. But jank remains an issue. My C2 builds may outperform my GMS builds on slow computers but GMS never does the tug-and-jerk screen update thing. Never ever. It runs smooth or it doesn't. Consistently.

In my opinion, this is a pretty big deal and I urge Scirra to really look into it, not just hand-wave it away whenever the subject comes up. I won't go back to Construct for several reasons so it doesn't affect me either way, but it's a shame for an otherwise great product to be held back by these sorts of things.

This too summarizes pretty well how I feel. I'm very close myself to abandoning Construct because of this. After 3+ years of learning and excercising optimization tricks, I still can't feel confident that my game will run hard locked at a given framerate. This is soul crushing when making action packed music games that can't miss a beat.

Well, there will always be something.

So far I've only noticed a problem in one game. Every time it starts up on Galaxy s6 and there is a physics collision game will pause for maybe a 1/10 of a second ( first 3-4 collisions ) After that plays smoothly.

Same game, different phone or on PC no problem, plays smoothly all the way through. So obvious conclusion would be that there is a problem with Galaxy s6.

This is HTML 5 exported game played in mobile browser with or without going into full screen, not APK. Makes no sense at all why this would happen.

To be fair, in my projects (though nothing thoroughly completed) I haven't actually hit any troubling slowdowns or jankiness that appears to affect so many here. Probably due to the fact that my projects are usually NES style pixel based with the resolution set at 320x180px. This is with heavy use of onscreen physics objects, C2/C3 impressively manages to stay at a constant 60fps even with all sorts of spawning physic bits all over the place. Granted, i did get it drop down to 36fps while running on my 2014 i-5 Macbook Pro on a virtual machine - because C3 didn't existed yet. Running in native MacOS it still holds steady 60fps.

Now when testing this out on mobiles devices....well thats a whole other issue.