Amazing to see this game running on portable PC's: https://twitter.com/acampy/status/910681476110438407

Looking forward to when it's running on Switch and PS Vita too in 2018! <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

Also, we just released a new Teaser Trailer today too!

why do we get janks even if our games are frame rate independent ???

is it because the code can only ever use the previous dt in the current loop? so a single spike dt throws everything off. i.e. you need a more constant framerate for framerate independence to work smoothly ?

I think it mostly comes down to JavaScript being awful ( https://medium.com/javascript-non-grata/javascript-is-a-dysfunctional-programming-language-a1f4866e186f ), especially when it's not created via compiling C++ into JS with something like asm.js, but mostly also because it has poor memory management/"garbage collection" that will build up unused memory (eg: destroyed objects and variables) until it purges it and usually cause some lag. Many developers have been trying to improve this, as it's an issue larger than just Scirra: http://tinyurl.com/y8wfs8kx

If I remember correctly, I think Scirra/Ashley actually has some great methods of reusing data to help combat the garbage collection.

Would a call for another wrapper fair any better than a native export?

Make their own using Node?

>

> > You're only comparing the Chromium engine - have you tried Edge and Firefox? They have different v-sync engines. Edge was particularly good IIRC.

> >

> Chromium is the only option we have if we export to pc.

>

Would a call for another wrapper fair any better than a native export?

Make their own using Node?

Good idea, a dedicated wrapper would probably make a difference even if they never go into making a fully native engine. It might even mean they can make ports of Node exporting to consoles themselves.

I think if they are willing to dig down deep enough into it, there are some performance gains to be had for sure.

eg: Having something designed specifically for use by Construct might even mean they can do some native speed-hacks perhaps? (eg: intercept JavaScript math functions and return the result in some C++ code instead maybe? also for the built-in C2 plugins maybe they can offload that into some C++ code too?) even more useful would be if they had better control over the garbage collection/memory management, but I don't know if Node would enable that.

Events for general game logic should be fast enough even if they are in JavaScript, but things that happen every single frame are going to be a source of jank, especially with the memory management/garbage collection being so bad in HTML5.

Also, here's my results for testing in Firefox and Edge with — 's project and C2 r246 running fullscreen on 1080p monitor with GTX 1070 and i7 6700k:

Firefox: "JANKY" starts at 300/frame, gets awful at 400/frame, with dt reporting anywhere from 25 to 35

Edge: "JANKY" both starts and gets bad at 600/frame, dt hitting 25 to 30. Gets as awful as Firefox at 700/frame

I tried exporting CC to fullscreen and was able to reach 1300/frame before it started saying "JANKY" a lot, and even then it was still pretty smooth/didn't cover the whole screen in Janky

Holy crud, where have i been?? when was this released? IS it complete and bug free or an alpha?

It was "released" a couple months ago now, but it's still technically in beta I think.

Only an editor change so far, the export still runs on the Construct 2 runtimes/exportrs, but now the editor does work in the browser itself which is very neat on a technical level (only other HTML5 tool I've ever seen do that is SuperPowers).

Posted this in the other thread as well, but since it's also relevant here:

Can confirm jank in — 's post on my GTX 1070 + i7 6700K:

CC: at 950/frame, 28fps (running in background/not in focus), no jank

C2 / NWJS: at 600/frame, 33fps (running in foreground/in focus), jank

I made a test for others to see if they get the same results as I do.

The skull spawns explosions each frame, you control the amount with +50 or -50.

When dt goes over 25ms, it spawns "JANKY"

CC exe: https://www.dropbox.com/s/4ckkxbez7iou0 ... C.zip?dl=0

CC project: https://www.dropbox.com/s/ysfbukb3jnrpw ... l.cap?dl=0

C2 NW.JS export: https://www.dropbox.com/s/uv9tw0guvq0vs ... w.zip?dl=0

C2 project: https://www.dropbox.com/s/fos16fpcahcm4 ... .capx?dl=0

Results for me:

CC: at 600 /frame, no jank. Can stay jank free for minutes.

C2: at 200 /frame, jank every second on Chrome and NW export.

C2: at 50 /frame, Random jank every 5 seconds or so on Chrome and NW export.

Can confirm on my GTX 1070 + i7 6700K:

CC: at 950/frame, 28fps (running in background/not in focus), no jank

C2: at 600/frame, 33fps (running in foreground/in focus), jank

Ashley Bunnymark was not optimized for each platform. It was a rough comparison at best and there were many people seeing higher results for native anyway.

It is a good comparison of sprite rendering which you have done well with due to WebGL. It would have been nice if WebGL was supported on WiiU for sure.

> Your article is the case against Construct Classic.

>

No, it's a case against making native engines for Construct 2 and sticking to HTML5. It addresses your points.

I honestly don't see how it answers my points. An (although beautiful) low-collision count top-down racing game and a few tech demos dont hold up to actual CPU-heavy games/platformers on Steam whose developers are telling you HTML5 is not matching up to expectations set by similar tools (eg: Classic and Fusion and GameMaker)

The ones that are already porting to other engines (including us) are finding we can fit more visual FX and complex code into the game yet have smoother performance and support for lower end hardware and even mobile and consoles.

Plus it also doesn't answer: Is C2 really that much more optimized than CC? Because if it is then it stands to reason that CC can't be used as a "native" benchmarking tool.

I am really tired of all these arguments. I already wrote our whole case: the case against native engines

In general the whole argument that "due to <some random issue> you should drop everything and build native engines!" is ridiculous. Why not just fix the issue? Native engines come with their own whole pile of issues, many of which are worse than the issue being raised, so this is just completely off the cards. If we actually did that, I think it could easily be such a big disaster as to risk ruining the company. I guess people are still going to tell us we should do it though.

BTW someone started another thread about v-sync accuracy worrying that it was locked to 16ms and thinking something was wrong - but actually it was v-syncing so accurately the number didn't change. Hardly sounds like a problem

Your article is the case against Construct Classic. My earlier post already explains why this is not a fair comparison:

[quote:1ga04zqv]

1. Construct 2 and 3 are way more optimized than CC (or so you say in your blog posts). The only way it would be a fair comparison is if these optimizations were back-ported. If there is negligible gains to be had then all the "such better performance!" blog posts are lies/exaggerations no?

2. Your skills as a coder are better now and you have more experience from CC & C2 runtimes

3. I still notice CC games are smoother than C2, even on my GTX 1070

Also notice at the bottom of my last post that I suggest Scirra get involved in the native wrappers. I accept that HTML5 for the games is not changing. Unity could technically be seen as a native wrapper too, but a better demarcation point would be a project converter.

Cryptwalker Xbox One likely has better performance thanks to Edge and WebGL, but what Scirra called console export on the Wii U was not good enough to actually release an action game on.

That said, console export was the largest draw of funding for our latest successful Kickstarter and if we werent using Unity there would be a lot less interest as most of it was PS4, Switch, and Vita. Saying games do best on PC is simply not looking accurate to me comparing C2's best sellers to games like Super Meat Boy and Shovel Knight.

There are some kinds of games that will sell great on PC, but there is also more competition due to lower requirements to enter the market, and even if you have many Steam users showing up on SteamSpy a lot of those could be people who purchase resold keys from bundles and giveaways that make you effectively no profit.

Overall though, console support matters, especially to indies working commercially.

Unless Scirra start getting hands-on with making at least native wrappers for consoles, mobile, and desktop themselves (I'm happy enough with ports of open source wrappers even) and take accountability for them, I can't recommend serious projects to be made in this until the day every single device, mobile/console/desktop, is running a real Chrome browser equivalent and has specs matching a PS4 or higher.

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.

I love when Construct Classic is being brought into this as if it compares to Unity or GameMaker.

1. Construct 2 and 3 are way more optimized than CC (or so you say in your blog posts). The only way it would be a fair comparison is if these optimizations were back-ported. If there is negligible gains to be had then all the "such better performance!" blog posts are lies/exaggerations no?

2. Your skills a coder are better now and you have more experience from CC & C2 runtimes

3. I still notice CC games are smoother than C2, even on my GTX 1070

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