will construct3 be as strong as unity??

newt , I base my conclusions on what I see with my own eyes, even the most simple test scenes just doesn't feel as responsive as they should. I've made my own examples in the past and even now, with a beast of a machine that I run them on, I don't get smooth movement.

On this topic, there is an example made by somebody and a exe provided by Jayjay that makes a direct comparison, unfortunately, the exe doesn't have an fps indicator, but on my previous machine there was a clear difference between them.

OK, but your example ran smooth on my less than beastly machine in NW, Edge, and Chrome, but stuttered in FF.

This is starting to feel like an argument for a desktop exporter, but I wonder if we don't already have an alternative via W10 universal apps.

...............I say that hesitantly as my machine can't do webgl.

So my conclusion is its hardware, always hardware.

And I just don't know why because C2 is able to make any 2D games. It's powerful and we have good selling platforms that facilitates for all of us. Steam is a mother for indie devs and a huge "self-publishing-promoting-InsertMore" with almost any need to pay. I don't understand why. It should be treated as a more importantly thing because why would someone care about invest so much time and effort to complete a good and polished game for PC if, in the end, scirra doesn't fully support the integration with the biggest selling platform for PC?

I'd love to see NW.js being updated more often for C2. I don't see the point why 0.12.3 can't be downloaded from Scirra's site. Maybe someone can explain this to me?

Also an offically supported Steam plugin is a must have. I don't believe Scirra can rely any more on the current state of the Greenworks plugin. They have to make an offical built-in plugin, and in my opinion for C2 as well, not just for C3. Do you want to get C2 even more popular? Then make it easy for developers to support the major platforms without having them to install an old version of nw.js and plugins manually. Sure, it's not a big deal to do, but for a newcomer to learn all the necessary steps, it could be bothersome.

—, good points. My audio won't work in NW 10.5 and audio bugs in old versions of NW will not be fixed by scirra, so the abandoned state of the Steam plugin is rather disheartening. The latest version of NW should be either available here or it should be made clear that is been added once but now the rest is up to us because scirra are doing other things. These lack of follow up details might be symptoms of scirra being a team of one, but they don't assure me that anything different will happen in c3.

Pssst, hey mahdi71, everything uses c, but don't tell anyone, it's our little secret.

what?

Most everything runs on a subset of C, even C2, even your phone.

newt I think that's over-simplifying it though, because it's many layers of "a subset of C" when it comes to HTML5

JavaScript doesn't compile, so it is interpreted at runtime by the browser/JavaScript engine, which probably turns it into bytecode, which then is run by another interpreter at OS level (like .NET) which is running within the operating system made in C and compiled into assembly.

C++/C games skip a lot of those layers (and do have more dangers since you manually clean memory, but if you know what you're doing this is a performance increase over generic garbage collection). C# skips the first few layers that HTML5/JavaScript has, starting from the bytecode level.

Layers/encapsulation is a performance hit (no matter how tiny), this applies in software, network traffic, shipping, and more.

In a (possibly a bit over-) simplified way, this is how C2 and CC games layer:

True, I guess "native" isn't that accurate.

Java is like immigrate with green card, and Javascript has a work visa.

Haha newt I love that comparison

Most everything runs on a subset of C, even C2, even your phone.

ohhh no kidding !!! let me tell you a secret , every computer runs on 0 and 1 !!!!!

JavaScript doesn't compile, so it is interpreted at runtime by the browser/JavaScript engine

Most modern Javascript engines use just-in-time (JIT) compilation to machine code. They use a flow something like script -> bytecode -> profiling -> machine code generation. This means well-written Javascript gets "truly" compiled and can reach pretty impressive levels of performance.

> JavaScript doesn't compile, so it is interpreted at runtime by the browser/JavaScript engine

>

Most modern Javascript engines use just-in-time (JIT) compilation to machine code. They use a flow something like script -> bytecode -> profiling -> machine code generation. This means well-written Javascript gets "truly" compiled and can reach pretty impressive levels of performance.

I think that only occurs in the context of C2, on iOS8+ WKVWebview, right?

Nitro-JIT engine.

I notice it performs very close to Chrome on PC, ie, similar cpu usage for my test games, which is rather insane when you think about how powerful an Intel i5 or i7 is compared to what's on an iPad Mini 2.

I think that only occurs in the context of C2, on iOS8+ WKVWebview, right?

I'm pretty sure all modern web browsers do jit. Chrone, Firefox and Safari each are continually making js faster, and jit is always utilized in some way.

> I think that only occurs in the context of C2, on iOS8+ WKVWebview, right?

>

I'm pretty sure all modern web browsers do jit. Chrone, Firefox and Safari each are continually making js faster, and jit is always utilized in some way.

Okay, but Apple's implementation is so much faster. It's worlds apart to compare WKVWebview Safari vs Android Chrome for example.

— if it is the reason why safari is faster, as there can be a lot of things that can be slow from the browser side even before or after the compilation.

Also safari I think runs only on iphones, which are defined, with hardwares fully known by the browser vendor, which is also the OS vendor, far less compatibility issues have to be worked around, and since compatibility is always put before execution speed, there may or may not be things that are not as fast as they could on android browsers' side just to make sure it works correctly.