tunepunk, no, I didn't do an in-depth investigation. However, if pure draw calls were the limiting factor then each engine should have max'd out at the same value when rendering bunnies. Therefore, I think that there's an overhead that each engine carries when ascribing draw calls to the GPU, such that the final yes-render figure is a mix of a GPU and a CPU limitation. The test also didn't measure jank (because I couldn't be bothered to create an fps-waterfall graph for each one) - that would also be of value because it would represent a measure of the quality of the player's experience.

Ads and IAPs are beyond me for c2 (and Godot...!). I only learned how to program (I am still an amateur!) by making plugins for c2 - all of the concepts are translatable to other engines, and I only chose Godot over Unity because it's way easier to learn because the interface is simpler.

I can only recommend you do a forum search for cocoon.io advice - it's almost the same as phonegap (zip up your export and import it into cocoon) but it's been a good while since I experimented there. If your games don't require moving action scenes then phonegap will suffice for mobile for sure.

A cross platform alternative for NWjs can only be Electron (which I have never used and it looks complicated for a non-coder) - so you might be better off waiting for a stable NWjs branch (or use different versions for different platforms?).

Wrapped JavsScript will always suffer from lower performance -if- the wrapper tries to be a full browser instead of it being a performance optimised game engine. GPU bottleneck might be the cause in some cases, but in my experience a wrapped c2 game will always perform worse than one that was made in another game engine. There are no magic answers - all users of even the top game engines have to consider hardware limitations. It's just that c2 adds a layer of complexity (the browser) that is not optimised for games. Of course, here's the data - try out a simple bunnymark test:

c2 capx

godot engine bunnymark

get godot here

I tested on a desktop (i5 16Gb HD4000, NWjs for c2 export) and mobile (Nexus 5X, Phonegap for c2 export); when the FPS dropped to below 55 I considered the test complete. Results:

Godot desktop: 2200 bunnies

Godot android: 750 bunnies

c2 desktop: 1450 bunnies

c2 android: 420 bunnies

Irbis - I am sorry for your plight. I can only suggest you try cocoon.io and Electron as alternatives for mobile and desktop respectively. I've not tried Electron (I hear good things about it, though) but cocoon.io was impressive the last time I checked.

If the game runs at 60 FPS at 100% scale but at a much lower fps when at full screen then you've got a GPU filtrate problem or your GPU is black listed by Chrome. The game logic cannot be at fault. C2 offers a low quality upscale setting, which might help. You could also try running nwjs using integrated graphics....

Mmmm - at first it made no sense when I changed the primary event sheet for No 2, but I think there was a browser cache problem. It appears to be working correctly for me now...

That's an amazing bug-find! I can reproduce it - and I fear for the repercussions for the c2runtime.....

Check the active event sheet for each layout.... We've all been there!

I don't mean to be a negative Nancy all the time, but "wait for c3 runtime" on all the most voted features on the new requests platform doesn't make me feel great.

Yup - it's quite depressing. Either 'wait until c3 runtime', or 'future consideration' (ie wait until after c3 runtime....) for things like scene graph and advanced particles. Approx 90% of suggestions have not been reviewed, which gives the impression that the suggestions platform has already been abandoned.

Zacros - thanks for the bug fix (more adjusting was required than in your suggestion, so please download the plugin again)! I've updated the repository, including minor (non-breaking) changes to the edittime.js, to make it easier to read.

Glad you like it!

C2 inspired me to learn basic JavaScript programming, and for that I am very grateful. If c3 offered more than just renting c2 in a browser then it would have grabbed my interest, but the subscription model and its lack of progress over c2 has caused me to look at other engines. I don't believe c3 will be usable by serious devs for at least another 2 years - runtime re-write anyone?

If scirra used c2/c3 and their features to make top-notch games then many of the issues reported in these forums would have been fixed years ago. Armed with the disappointment that c3 appears to be in a cycle of indefinite amendment, I spent the last few weeks trying out Corona SDK, Unity and Godot Engine - all to compare to c2 html5 exports with other 'native' offerings.

Here's what I found:

C2 exports really don't perform well on low-end tech - and this is not always caused by the gpu. Something to do with using a full browser to do some simple maths and move a few objects, I guess. If scirra made games using their game editors then there would be universal acceptance that browser-wrapped JaveScript gives poor performance on low-end devices. A simple moving object and parallax background from a c2 export (wrapped in either phonegap or accelerated cocoon.io) ran at 15 fps on my Lenovo tablet. The same assets and a similar test from Unity, Godot and Corona all performed at 60 fps (Corona perf was truly amazing with physics as well...). The very same assets...

I think that the c2 editor is excellent, but the c3 editor feels slightly slower and offers less workspace to the user (bigger fonts and icons, like reading a news website in mobile-mode on a laptop). Not to my taste, but not truly terrible either. I have no idea how usable it will be or how it will perform when a complex project is loaded... Of the other engines I tried, Unity felt most visually comfortable to work in, but the API is truly complicated - Godot was the friendliest overall...

All game engines have bugs and require work-arounds for design limitations. However, with the recent announcement that the c3 runtime is to be re-written, I think it's safe to say that it will be a couple of years before this is finished and stable. It reminds me of the last few years of c2 development, where the excitement was found in adding new stuff rather than completely adding new stuff and then supporting it...

My main concern, however, was the poor performance of browser-wrapped exported games on low-end tech. For that reason above all I have decided to move on to use the Godot Engine - an excellent editor, used by the devs to make games, and with a less complicated API than Unity (based on Python, looks a bit like Lua). Who wants a full browser engine to run a 2d side-scroller?

c3 = not for me. I will occasionally tinker with c2 (where it's far easier to make plugins than it is for c3). Perhaps one day I will finish making a system to export layers into a Corona SDK project...

NotionGames, I tip my hat to you and your artwork - it's amazing!! I share your reservations - IMO, c2 is being relegated as a hobby engine..... and c3 is an editor that is aimed only at game editor devs. It's clear that the scirra 'customers' are not the priority in this relationship.

For the record, I think that the c2 editor is second to none and that the event system is outstanding. But to export only to Google Chrome and its derivatives... That's a fail and why I will never make a game in c2/c3 again; even though, for prototyping and level editing, c2 is amazing....