Excellent find, thanks. I hope it runs WebGL.

— People are swines on Play for giving 1 star for crashes without giving any feedback or reasons first or contacting your support email.

My advice would be to exclude weaker devices.

IntelRobert According to the version log, IAP and advertising APIs won't be added until V8 Canary in July. Is there any other way of getting these working earlier? Is there any way of manually adding them?

Thanks as ever for your great help on this forum.

I noticed, at least in my own tests (page 9), that CJS performs better where there are larger amounts of alpha transparency but otherwise Crosswalk performs better. Has anyone else noticed anything similar?

IntelRobert If a published app is signed with the same signature as a previous CJS build, will the user's webstorage be retained when updating from a CJS build to a Crosswalk build?

Supporting multiple densities does seem pretty standard. Google recommends it all over the Android developers site.

As Ninjadoodle says "The other bonus is that if you decide to update your apps in the future ( as resolutions get higher ) you can just upload higher resolution graphics with a (for example) — suffix and the engine will take care of the rest ( only use those graphics if the device is a very high definition TV or tablet )."

2 years ago we started developing at a 800,420 resolution for the Galaxy S, which seemed like a sensible mid-range device but is now becoming a dinosaur. In a few years time we'll need to overhaul all our apps and adjust all the pixel values if there isn't any screen density asset control. A nice simple system would really help future proof games, as retina screens and their Android equivalents get denser and denser.

It really limits what we can currently achieve too. We have the same problems with our English vocabulary apps. We require a lot of pictures, but are limited to about 100 vocabulary pictures at the moment (assets no more than 7MB) so we can't really sell our apps or use IAP and are limited to ads.

Our layouts are no bigger than our screen sizes. We make great efforts to only use the pictures that are needed for each level (the pictures are on an unused layout), which does help a bit, but all the pictures are decompressed into system RAM, at least on Android 2.x.

Strangely I get 100MB RAM use on Android 2.x (Galaxy S and mini) but only 25MB on my Sony Xperia S (4.1) - so either the Sony handles images better, Android 4.x does or CocoonJS works differently on 4.x. Perhaps the app usage info is not accurate on 4.x, but games do resume very quickly.

Can anyone confirm whether this layout by layout loading issue just with 2.x or applies to 4.x too? Our games are designed to run on 2.x so we haven't tried pushing 4.x to see how many vocabulary images we can use on 4.x. The 2.x market share is decreasing rapidly so I'm starting to worry less about supporting it.

I have compared CocoonJS Vs Crosswalk XDK in 3 games. None have physics, text objects or much collision checking.

Device: Sony Xperia S with GPU, Android 4.1.2,

1) Learn and Spell English Words

play.google.com/store/apps/details

Loading Time: 25 secs CJS, 13 secs XDK

Size: 16MB CJS, 27MB XDK

Idle Menu: 53FPS CJS, 39FPS XDK

Swiping levels menu (constant swiping with a lot of transparencies): 46FPS CJS, 36FPS XDK

Gameplay (lots of transparencies): 50FPS CJS, 39FPS XDK

2) Verb War

Loading Time: 25 secs CJS, 10 secs XDK

Size: 9MB CJS, 21MB XDK

Idle Menu: 55FPS CJS, *58FPS XDK

Swiping levels menu (constant swiping): 52FPS CJS, *55FPS XDK

Gameplay (Lots of moving sprite fonts): 50FPS CJS, 46FPS XDK

3) Match-Up Learn English Words

play.google.com/store/apps/details

Loading Time: 29 secs CJS, 14 secs XDK

Size: 17MB CJS, 28MB XDK

Idle Menu: 30FPS CJS, *58FPS XDK

Swiping levels menu (constant swiping with some transparancies): 30FPS CJS, 31FPS XDK

Gameplay (scaling when turning cards): 31FPS CJS, *45FPS XDK

As already mentioned the audio is very quiet using the XDK, the orientation doesn't lock and the Android bar shows, which I'm sure will be resolved.

Upscaling is good and crisp using both CJS and the XDK. All 3 games were designed at 800px but have been scaled up to to 1280 in my Xperia. This compares well to the standard (Appmobi style) Android export which is blurry.

Overall the frame rates are higher using CocoonJS in 2 of our 3 games. My frame rates are all averages from several minutes of testing and observing rather than a system measured average, but I'm confident that they are fairly accurate.

Interestingly the XDK only seems to win where there are no transparencies or sprite fonts (which include transparencies in our games), which leads me to believe CJS handles transparencies better than the XDK, but I'd like to test further.

The CPU usage is always much higher using CJS.

damjancd Wouldn't putting all the objects in a family and picking the family solve your problem?

Ashley I wouldn't have expected them to have been picked by a false condition on its own, but if the system condition is the one which returns true, shouldn't the red and yellow squares still be picked due to the parent event the OR block is a sub event of? Please can you confirm that they would still be picked by the parent event (in this case object creation)? Thanks

— It was in this thread:

scirra.com/forum/r144-or-block-is-broken_topic75820.html

You have to overwrite eveng.js

Generally the OR works ok, just not in certain circumstances.

Following patch: dl.dropboxusercontent.com/u/15217362/r144fix.zip

From thread: scirra.com/forum/r144-or-block-is-broken_topic75820.html

The OR block still isn't working properly. Perhaps it's just reverting back to 143?

Link to .capx file (required!):

dl.dropboxusercontent.com/u/41218343/OR%20Bug%20mixture%20of%20condition%20types.capx

Steps to reproduce:

1. Launch in preview from layout "Run"

2.

3.

Observed result:

See the red sprite:

Instance variable (condition not met)

OR   >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Event does not fire (Rotate 45)

Global (condition met)

The 2nd condition is not noticed. It only happens when there is a mixture of a sprite condition and a global condition and in that order. The other three sprites rotate as expected, which are various mixtures of global/instance variable conditions. The yellow and red sprite conditions are identical except for the order in the OR block.

Expected result:

All sprites should rotate 45 degrees

Browsers affected:

Chrome: yes

Operating system & service pack:

WIn 7 64bit

Construct 2 version:

R144

Guif0DA Do the relevant events use an OR block picking objects of the same type?

I've got a similar lag issue with an OR block used as a sub-event:

Family Variable = value 1

OR

Family Variable = value 2

I'm not sure if it only effects families.

This consumes 50% of my CPU. If I disable one of the conditions the problem goes away.

Ashley I think this is related to the bug fix in R143 ("OR blocks which were sub-events to ordinary blocks did not always pick instances correctly")