Is recommended to create new object as sprites with 5 animations instead of 20 animations?

No. It's more efficient to fill a single spritesheet instead of splitting your animations between more objects.

This blog post may clear your doubts.

https://www.scirra.com/blog/87/under-the-hood-spritesheets-in-construct-2

I think there is a lot of confusion about what is really CocoonJs .

CocoonJS (Canvas+) is not a browser, it's a wrapper that mimics a browser intercepting draw calls and "converting" them to OpenGL ES calls so you can't expect the same behaviors that you can see using a real browser.

"WebGL is faster than Canvas2d" is a true statement only when there's a real browser involved but since WebGL is not supported by iOs what we see on our iphones screen is an "emulation".

Ashley said once that WebGL engine is a little slower due to technical reasons on javascript execution side and a lot faster at drawing things on screen. So, in the end, you have an huge performance improvement. But this happens only on real browsers.

We don't know how CocoonJS works behind the scene but we know that the iOS SDK agreement requires apps to use Apple's own JavaScript engine which is a lot slower than modern JS engines.

My speculation is that since maybe CocoonJS accelerates in the same manner both Canvas2d and WebGL calls, the gap you see in favour of Canvas2d is related to the slow and old JS engine that apple imposes on their developers.

sergyperov

I can assure you that the majority of the android devices out there support this.

I'm also testing a lot my game before the release on every phone and tablet I can get my hands on and had similar issues only with low-end cheap chinese tablet. Tested also on HTC newest devices (One and One mini) with no problems at all.

You have a Galaxy Note 2 powered by a Mali-400 GPU.

Try to export with CocoonJS 1.4.7 instead of 2.0.0 and avoid crosswalk until they add the gpu-blacklist removal option.

I'm saying this because I noticed a severe drop on performance on some device of my test base with the release of CocoonJS 2.0.

I never associated this issue with the chromium GPU blacklist but today I noticed that every device that struggle with crosswalk now have a bad performance also with CocoonJS 2.0. And all those devices have GPU blacklisted by the chromium team (Mali 400-Adreno 200)

Maybe Ludei team has adopted the same blacklist after the introduction of their chromium based webview+ also for their old canvas+ product. I'm just speculating since CJS is closed source and communicating with Ludei is somewhat hard.

Ludei now runs two parallel projects under the name CocoonJS.

One is the old CocoonJS renamed Canvas+, the other is an accelerated webview for cordova projects called Webview+.

Webview+ is a full DOM-Browser embedded inside your app based on chromium project, just like Crosswalk, so even if you manage to export a C2 game to run on Webview+ (I don't know how much efforts this task can request since I didn't bother trying it) you'll get very similar results to those you'll get exporting your game in a breeze with the C2 Crosswalk exporter.

PhoneGap was started by another team that used Cordova and made easy packaging. but PhoneGap is not Cordova. Then I believe Intel bought PhoneGap.

I have to correct you.

Adobe bought phonegap and Intel bought Appmobi.

ALI3D69

I found this: https://code.google.com/p/chromium/issues/detail?id=288731

[quote:2qb0tax0]I've now got a Galaxy Tab 3 and spent some time investigating this issue. Indeed the problem is that the EXT_robustness implementation on the Mali-400 does not support reset notification. However, Chrome doesn't use virtual GL contexts on these GPUs, so in theory the effects of WebGL shaders could be confined to the respective WebGL GL context.

I did some further testing (https://codereview.chromium.org/24037006/) and turns out it's still possible for long running shaders in the WebGL contexts to block GL execution in other contexts -- not limited ones in Chrome. Based on this I don't think we want to enable WebGL on Mali-400 based devices.

It seems to me that the problem with devices powered by the Mali-400 series GPU (basically a lot of samsung devices, the major player in the android market) is limited to the use of webgl shaders.

If i'm not wrong this turns to be a good news because, when crosswalk will support the gpu-ignore-blacklist flag, a developer can simply avoid shaders to get an hardware accelerated version of his game without fearing crashes or other unintended behaviors.

yongsheng correct me if I'm wrong, as a php developer I'm not into GL contexts at all <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz">

Right click on package.appmanifest and select "View Code"

Find the line

<Identity Name="XXXXX-XXXX-XXXX-XXXX-XXXXXXXX" Version="1.0" />

And make it look like this:

<Identity Name="XXXXX-XXXX-XXXX-XXXX-XXXXXXXX" Version="1.0.0.0" Publisher="CN=XY" />

(Where XY is your name as publisher, for example knifegrindergames)

If you want to test on a real device remember to click on the arrow next to the play button and select "Windows Phone 8.1" as startup project (Windows 8.1 is the default option).

Said that, my first experience with WP 8.1 was quite disappointing with a lot of inconsistencies, audio drops and crashes, but since i make an heavy use of event sheet includes (r166 have a bug that reverts the usual order of fired events), VS 2013 is still a RC (not even RTM), WP8.1 is still a beta and I'm running it on a 512Mb device (a crappy Lumia 520)... well... I can't blame anyone or anything for that. I'll test soon on a proper device (a Lumia 920) building my project with C2 r167 and I'm confident that a lot of issues will go away.

Curiously Canvas2d mode seems a lot faster than WebGL.

Have you tried to see if also AccelertionWithGravity return no values?

I'm saying this because I faced a similar problem on a totally different device (Windows Phone) where Alpha, Beta and Gamma values returned 0 due to the lack of inclinometer (or gyroscope, don't remember) on lower spec devices like lumia 520.

intelXDK can too

The old intel xdk and crosswalk are two different things.

A product like crosswalk for iOs that runs your html5 app in a real browser with an accelerated canvas. a fast JS engine and full DOM support don't exist and will never exist until Apple review its very restricted policy about third party browsers.

Faster, silky smooth, no more audio bugs and now totally useless.

This new version introduced in my app a noticeable lag in the acclerometer readings that simply butchers my game.

Other than that on my galaxy s4 the loading time of a compiled app is now simply unaccetable.

I think little games without accelerometer based controls will benefit a lot from this update.

In my particular case it's 2012 again, I have a game that is simply undeployable. But in 2012 I was not worried at all because I was confident that while making a slow burner project the technology would be ready when finished.

Now that the game is almost ready and with a public demo in preparation I'm really starting to get pissed off in regards of ludei, cocoonjs and the whole html5 ecosystem.

Don't get me wrong, I know that Cjs 2.0 is still in beta and this issue will be probably fixed in the future, but why the hell they didn't release before a stable CJS 1.4.8 with all those audio bugs fixed instead of packing them in a beta of a major release? Why?

They have hands down the better technology out there and they're ruining their reputation with one of the most demented release cycle management in the entire software history.

I think I'll switch to crosswalk even if it's still in beta and struggles more than CJS on lower specs devices.

A little update on my ultra-slow burner project: Clyde, a "retro platformer with modern controls" for iOs, Android and (hopefully) Windows Phone 8.1.

I have these permissions on my builds.

android.permission.WRITE_EXTERNAL_STORAGE

android.permission.INTERNET

android.permission.ACCESS_NETWORK_STATE

android.permission.READ_PHONE_STATE

android.permission.VIBRATE

android.permission.RECEIVE_BOOT_COMPLETED

All of them are quite standard for a game. I don't see anything "scary" for a potential customer like camera access and geolocalization.