Construct as a unity editor extension.

Post » Thu Sep 14, 2017 7:53 pm

Ashley wrote: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 :roll: ) 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.
B
25
S
4
Posts: 53
Reputation: 1,289

Post » Thu Sep 14, 2017 9:02 pm

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.
Image ImageImage
B
169
S
50
G
170
Posts: 8,292
Reputation: 108,728

Post » Fri Sep 15, 2017 12:14 am

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...

ErekT wrote: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.
B
32
S
10
Posts: 370
Reputation: 3,156

Post » Fri Sep 15, 2017 4:06 am

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.
B
16
S
8
G
2
Posts: 44
Reputation: 2,388

Post » Fri Sep 15, 2017 5:34 am

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.
B
89
S
30
G
11
Posts: 269
Reputation: 12,268

Post » Fri Sep 15, 2017 6:44 am

Tinimations wrote: 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.

would like to know what you use here..I'm having crippling mobile performance, that comes out of nowhere and goes away completely after a few minutes.
B
97
S
32
G
16
Posts: 1,200
Reputation: 16,682

Post » Fri Sep 15, 2017 10:46 am

Honestly, I struggle to see anything wrong - I've had tests like this one which I've been using for ages. I just ran it on my HTC 10 and it consistently measures it hitting v-sync within 1ms. On my desktop it measures <= 0.1ms. In Firefox it's so accurate, the v-sync jank is locked on 0ms. So I can't see anything wrong.

I would guess it's somehow device or OS specific. But so long as everything looks fine on my end, what do you expect me to do? It looks like our engine is v-syncing just fine. As ever, a minimal reproduction with the right hardware and OS combination is the best way to investigate any issue. You can also report issues to browser vendors yourself directly, which I would encourage you to do so - if you report them to me all I would do is forward the report to them, but I won't if I can't reproduce it myself. You can easily cut me out of that process.

If you have general performance concerns, the C2 engine is very mature by now, having been used widely for ~6 years. The performance characteristics are generally excellent, there are no significant known bottlenecks or weaknesses, and it's robust and proven for a wide range of games. I have tested and profiled heavyweight games like The Next Penelope and reviewed our engine's performance, and everything was working fine. In the past, it's also been very, very common that people blame us or browsers for their own mistakes, like extreme fillrate abuse. I am very confident our engine is actually working great. That's not to say there aren't any bugs or issues, but by now finding any kind of serious deficiency in our engine is actually a rare and pretty surprising case. I think you should weigh up the likelihood of that accordingly when running in to issues.
Scirra Founder
B
395
S
233
G
88
Posts: 24,376
Reputation: 193,842

Post » Fri Sep 15, 2017 1:00 pm

Your test is reliably dropping frames here and there. You said yourself it drops a frame every 10 seconds or so.
I can have DOOM (with a Chrome, skype, c2 editor, discord, screen recorder all running in the bg) drop less frames than your test on the same machine.
Any fluctuation caused by OS processes causes more issues with the test than it does in DOOM.

I understand the major performance problems people are experiencing can be traced down to a number of OS/Browser issues, but even at it's best, a simple test cannot outperform a modern 3D shooter.

People having bad code is also a different issue entirely. Some of the commenters here might have a problem related to that. I understand that there's a mix of issues blamed on Construct, some are legit, some are not. Everyone should heed the repeated advice of sending over minimal reproducable cases that can isolate the causes and those can be forwarded to directions where they're helpful.

There's also been first hand experiences with larger games where writing messy code will result in less performance drop in Unity.

As for the next penelope, there was a post-mortem (which I have saved, which has been deleted on the internet) pinning abysmal performance on WiiU (advertised platform) on HTML5 and "gifted" helpers couldn't do much resulting in the attempt to rewrite the whole game in C++.

Could you please comment on each of these @Ashley
1) It is impossible to have a C3 app not drop frames on a minimal project on each of the advertised platforms.
2) Vsync cannot be disabled, thus you're stuck with lag associated with Vsync.
3) These issues are out of your hands because of HTML5.

Your confidence in your engine is well founded, I certainly believe you when you say "it's working great". It is an amazing editor and gives me the ability to work at a speed I've never experienced before. Your work is spotless and the editor is robust.

The way I see it, HTML5 is the best solution for Construct currently due to your small team, but it comes with an epic boatload of small issues.
Each device build is tangled on other vendor's problems like a hellish hair day.
You've said native comes with it's own baggage with graphics driver changes and such, but the vendors handling these changes are "gamers first" people. See for example Nvidia G-Sync, which allows the screen to draw instantly when the frame is served. Awesome stuff.

The solutions I see here are either to bug the hell out of the device and browser vendors and wait for everything to sort out (which has been going on, but I saw peak performance of HTML5 7 years ago when a super talented team made a competing engine to Construct and the only advance since has been improvement in audio playback. Some things have even gotten worse.)
OR
Get a bigger team and do native. It's a hurdle, but at least here it's possible to reach "perfect" performance.
Out of curiosity, how many labor years would it require to get a native exporter?
B
25
S
4
Posts: 53
Reputation: 1,289

Post » Fri Sep 15, 2017 2:42 pm

jobel wrote:
Tinimations wrote: 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.

would like to know what you use here..I'm having crippling mobile performance, that comes out of nowhere and goes away completely after a few minutes.


It was an in-house tool at a big software company my brother works at. I can only access it through him unfortunately.
B
32
S
10
Posts: 370
Reputation: 3,156

Post » Fri Sep 15, 2017 2:57 pm

We did make a native engine in Construct Classic, and it still occasionally dropped frames.

Everyone thinks that making a native engine will magically fix everything. It's not the case.
Scirra Founder
B
395
S
233
G
88
Posts: 24,376
Reputation: 193,842

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: Daviboy211996 and 4 guests