jayderyu - if nothing on the screen changes, C2 actually stops rendering because there's no reason to, it just leaves there previous frame there. You can also deactivate the entire event sheet with a variable, or have events that only run upon interaction such as triggers. Both should help.

Just try deactivating stuff or making stuff invisible, repreview, and watch what it does to the framerate.

I'm talking about optimizing the events in C2. Finding things like deactivating collisions for offscreen objects, cycling through instances for intensive events instead of trying to process them all at once, etc.

Yep, Game Dev Tycoon.

Jayjay - at least from what I experienced with loot pursuit, I have to disagree. To be honest, loot pursuit isn't even really a large game - it's just large in comparison to most construct projects, and CC was barely managing it. I had to close and reopen my project after opening/closing the image editor 10 times because of a memory leak to keep the IDE from crashing, I have an event I can't edit or move or it instantly crashes the editor, it took 10 minutes to open one specific event sheet, every edit on that event sheet would pause CC for 7 seconds before I could make another, pressing undo would lock up CC for half an hour, deleting an object did the same (I once deleted multiple objects at the same time and had to leave my computer processing it for hours), and the runtime sometimes crashes - imagine trying to find an event that crashes on an event sheet that pauses after each edit for 7 seconds when it takes 3-5 minuted to preview. It was sometimes literally faster to throw away the day's work and start over.

As I mentioned before, that's my experience, and the bugs that different people encounter vary. I just want to warn people thinking about trying to make a big game with CC that someone already tried it and it did not work well.

A game made with node webkit, which C2 uses for exe export, has been greenlit for steam. So yes, C2 games can get on steam.

Yeah Construct 2 is maybe better, it maybe enters to what todays players are waiting for (browser games, etc.), but it stills browser games.

If both can create something that looks exactly the same to the user as an exe, what's the difference? The fact that it's running JavaScript instead of c++ doesn't dictate what size, depth or quality of the games you can make with it. The fact that people make small, shallow low budget games for browsers is not because the technology behind it can't handle a larger game. It's because people generally aren't looking for an involved gaming experience while browsing the web and depend on ad revenue/sponsorships which generally aren't big money, and the market has built itself around that. With C2 we can export as exe, so we can circumvent that issue entirely.

We can't really create big projects, with big libraries, musics, sounds, saved data, etc., yeah we can create a simple funny game, but in my opinion C2 isn't done for big projects yet, it's on the path to become, but not now, just my opinion.

Based on personal experience, that's incorrect. C2 is far more stable, has a much better workflow, exports to more platforms, is actively developed, etc etc. Also, having tried it, you really don't want to make a big project with CC. Seriously. It's basically a minefield - some people have few problems with it, for others it's very troublesome. It's not worth risking months or years or work to discover that CC can't actually handle the project. Starting loot pursuit over in C2 was a very painful decision after having worked on it in CC for years.

A new version of cocoon js is coming out soon. Try again on that.

Also, there many be ways to optimize your rendering/code.

I haven't read all the article you've linked, but it just sounds like it's not talking about what C2 and cocoonJS really do.

You're not having a browser executing your JS code when exporting through cocoonJS, you're having some native application.

It's a native application, but it's still interpreting JavaScript as far as I understand it. In a test I did a while ago, I seem to recall cocoonjs being less than half the speed at running code than safari on iOS, so being a native app isn't helping it there (I haven't tried the new 1.4 version though, maybe it's improved).

And even if it is "slower" as other apps, the recent cocoonJS 1.4 deals a solid 60 fps on most android devices (awaiting for Apple's approval on iOS) and that's what mostly matters as far as games go. (Also taking into account the recent addition/modification of 2DBox physics specifically for mobile through cocoonJS which should allow for proper physics handling which, so far, could be a bit of a bottleneck in mobile CPU performances).

But what results in 60 fps is highly variable. I can get 60 fps out of cocoonjs 1.3, but 1.4 with webgl is faster at rendering, so developers can do more per frame. A blank white screen is easy to process, but tons of collisions, instances and code running at once might get 60 fps in safari but not in cocoonjs. If JavaScript was replaced by something faster, it would be a significant boost to what people could do.

Node-webkit exports as binary to desktop and so has about the same performances as chrome on desktop, so no issue/relevance there either.

It's still relevant from a technical perspective, because node webkit is also still running JavaScript to run the C2 games. Even if v8 compiles them, as the article states, they can only do so much. However, it's true that the article is mainly talking about mobile, and desktops are fast enough that the concerns aren't really an issue, even on my amd Athlon 4400+ which scores like a tenth or less of the speed of a lot of modern processors.

My biggest frustration is that no one seems to be willing to collaborate on a proper modern language that solves all of the problems that JavaScript has. Nacl/pnacl sound brilliant, but no one else seems to have any interest in it. Dart also solves a bunch of problems, no one else seems to be backing that either. Everyone keeps talking about web technologies being the future but they keep using a language that is stuck in the past that simply has a lot of inherent performance problems, as it simply wasn't designed to be a high performance language. What we end up with is the equivalent of people trying to put rockets on a clunker to make it go faster rather than properly design an F1. Even if you can make it somewhat fast in the straightaways, the sucker can't turn.

Regardless, even on mobile, even in cocoonjs which is not as fast at running code as safari, it's obviously still fast enough to make a game with.

I'm not really meaning to complain about the performance issue either - it's fast enough for most of what I want to do on mobile, and desktop isn't an issue almost at all - I'm more frustrated by various groups' inability to work together to improve things properly.

Anyway, thanks for the article, Alcemon. It was an interesting read.

Edit: ninja'd

I guess it depends on the definition of native. Games in cocoonjs on the surface run same as an app coded in other languages, but it's interpreting JavaScript behind the scenes which isn't as fast as something like c++ or whatever is used for iOS apps. Cocoonjs is sort of like a specialized browser made for games and has specialized features for games that browsers don't have, and is made to appear like it's not really a browser at all. It is also currently the best option, though some have tried game closure and like it, even if it's harder to use.

Even though it seems native, it's not. Two things are holding back performance currently in cocoonjs v 1.3 on iOS - 1, the new version isn't out yet, which has webgl which should be faster than its current rendering method. 2, cocoonjs's JavaScript execution speed isn't as fast as safari's - I seem to recall one of my tests running at something like half the speed safari was. I don't know yet if the soon to be released 1.4 improves on this or not.

The custom movement behavior has a push out action.