When did you compile this APK? We updated that javascript file 3 days ago. Try this apk https://db.tt/x76en6Wz or create a new one in the cloud.

Yes, I must've compiled it just before the update. Now, it works, thanks.

Next I go into the Intel XDK, build 1995, and do these steps:

1. Go to Projects tab, and click on "Start a New Project".

2. Choose the "Import your HTML5 code base" option, and browse to my Construct 2 export directory in the "Import From" field. Click Continue.

3. In the "Project Name" popup field, enter "HelloWorld". Click Create.

4. In the "Project Importer Results" window, I leave everything alone - the "Source Directory" is blank (I've also tried ./), and both "Use Cordova Plugins" and "Game Project" are set to no. Click Continue.

5. I get a message that says "Congratulations! Your project has been created successfully".

6. I click on the "Emulate" tab, and I get a mockup of a phone, with a black screen that has a little bit of a white border at the top. If I produce an APK and load it on my phone, I get the same black screen - the emulator is faithfully showing the same thing the phone does.

Emulator never works for me. I don't know why and never tried to find out why. Only sound works, I just don't use it.

Here's .apk I exported with no problem, try if it works works you.

I don't see anywhere in your steps mentioned setting up build settings, so I suppose you didn't set any.

7. In the Intel XDK, in the upper left corner, click on PROJECTS

8. In the Hybrid Mobile Build Settings, on the right side uncheck icons Android, iOS, Windows 8 - you'll be left only with Android-Crosswalk

9. Click on the + sign below and expand the menu

10. Check those properties

fullscreen - yes

orientation - portrait

signed - yes (just for testing)

Crosswalk version 12

Can you send us the zips you are using so we can reproduce and debug the problems?

Here are my files

.capx

.apk

.zip

results - fullscreen only on one device

Ashley

Would "preview without sound/music" mode help? Sometimes I need to check just collisions or animations.

What about "preview low res" mode? In Adobe After Effects, down sampling can be choosed for the preview.

[quote:or2joyv9]At the quarter resolution setting, the program only renders every fourth pixel, and then scales up the result to fit in the Composition panel. This allows it to build the preview much faster and can be helpful for reviewing complex animations. This lowered resolution is for preview purposes only; it does not affect the final output quality when you output your file.

Don't know if it's possible or how difficult it'd be to add, but that "no sound mode" looks pretty easy.

ludei

TiAm

No luck with the fix, it's still on the 1/4 of the screen.

1st test

game window size 1280x720 - 16:9

Test devices

• Samsung Galaxy Tab 3 SM-T110 - 1024 x 600 - Aspect Ratio 128:75 - 170 ppi - passed
• GIGABYTE GSmart Guru G1 - 1920 x 1080 - Aspect Ratio 16:9 - 441 ppi - failed
• Samsung i9300 Galaxy S III - 1280 x 720 - Aspect Ratio 16:9 - 306 ppi - failed
• Samsung Galaxy Tab Pro 8.4 SM-T320 - 2560 x 1600 - Aspect Ratio 16:10 - 359 ppi - failed

I did next 2 tests just to see if an app resolution would have any affect on the results.

2nd test - game window size 3840x2160 = 16:9 - Samsung i9300 Galaxy S III - 16:9 - failed

3nd test - game window size 800x500 = 16:10 - Samsung Galaxy Tab Pro 8.4 - 16:10 - failed

Tried to recompile a WebGL export of my project in cocoon.io

Game runs great...in the bottom 1/4 of my screen.

Can you try the Cocoon test apk from this post?

Window size - 1280, 720

webGL - ON

my device has resolution 1024, 600 and it looks normal.

this is from my testing with crosswalk, so not sure if it is applicable with cocoon, but I had a game that was cpu hungry on crosswalk, 40% up to 70%. I did some stress test and I found one big red flag that made me stop all plans for the game at the moment. It devoured my battery life like crazy! I mean insanely battery hungry! No other games I played even came close. A comparison, I played real racing 3 for 20 minutes, and my game for 5 minutes. Checking the battery usage, my game used roughly 10x more power. Not sure if this is the case with cocoon, but just wanted to let you know so you could look out for it next time you do a stress test.

As someone mentioned couple posts back, Crosswalk (and Cocoon) is an extra level on top of the game to make it run and it takes more power by doing that extra work which native games don't need to care about. That's something we can't avoid and it means we have to be even more careful about resources when using C2.

From those few tests I did lately, Cocoon takes about 50% more CPU power than Crosswalk (it looks, it doesn't scale that much when adding more sprites, so that's good). It's great it can keep 60 FPS, I just hope it doesn't mean 50% more power consumption.

Is new cocoon supporting webgl? They got some issues with it last time I checked.

I think it's fixed. In the test version the webGL is set to ON.

I did a mistake when testing and corrected the original post with accurate numbers. It makes no difference in the result, just changed FPS numbers.

did you use old Cocoon? or new ".io" one?

The new one.

Here's the test version 2.

source .capx

Crosswalk export .apk

Cocoon export .apk

32 sprites with sine behavior and again tested on Samsung Galaxy Tab 3 7.0 SM-T110

Crosswalk 12

14-18% CPU

41-49 FPS (average 44)

Cocoon

32-42% CPU

60 FPS stable

FPS makes it clearly visible what export you should use for exporting C2 games. Again, this is how things are at the moment and they may change in the future. I'll do some more tests to see where the Cocoon will break.

update

For testing, I was using cw12 shell with gpu blacklist. This turned the device into canvas 2d mode and the results for Crosswalk were much worse (22 FPS). After exporting the testing version with Intel XDK it uses webGL correctly and FPS went up.

Still it doesn't change anything about which export performs better at the moment.

Crosswalk is lagging no matter if 1 or 32 sprites are used. I'll try to add more sprites to see if it makes a change in FPS.

Here's the same test .capx exported with Cocoon, so we're not talking theory.

Download the apk

Samsung Galaxy Tab 3 7.0 SM-T110

webGL

Vivante GC1000

32-39% CPU

60 FPS stable

FPS is great, no problem. Now there's just one thing which bugs me, din't notice that before. That CPU usage went from 10% on Crosswalk to almost 40% with Cocoon

Hopefully it won't be a problem. I'll try to do some stress test.

I don't know what people complaining about crosswalk.

I think, they're complaining about 1 sprite game lagging on a device with a 4% market share (GPU MODEL = Vivante GC1000: 4.0%), which is like 40 000 000 devices.

You're right, Crosswalk will be good. It's too late to start developing any native export. There are always limitations while developing. Right now, it's the performance of the Crosswalk export. Fortunatelly, there's another option in Cocoon, which at the moment gives best results. It may be again a different story in 6-12 months.

Fireche

I know only Crosswalk. I'll call you ArcadEd, he's one of the CJS experts around.

i expect my games to run on adreno and mali gpus, others are not even being used anymore. powervxr is lost case, and tab3 uses also some crappy gpu. not a problem for me, today mostly 90% devices use mali/adreno.

Maybe, if you target top countries, like USA, Canada, Australia, UK, Germany..., I don't believe you can get anywhere near 90% globaly.

That test is stripped down to a minimum, 30 events, 3 sprites, 3 tiled backgrounds and low res 400x500px and from 9 devices - 3 unplayable, 6 good, but 2 of them didn't max fps, even at this low requirements.

The only usable statistics I could find is this

Mali and Adreno gpu's make 75% - if your game is more than 3 sprites & 3 backgrounds, you might want to remove their low end versions.

Adreno = versions 200 to 225 which supports up to OpenGL ES 2.0 - that's 7%

and Mali - sub 400 - 1%, and you we're down to 67%.

One third of all players can't play the game properly, maybe even more, because Mali-400 supports up to ES 2.0 and from the test results, we can see it could start loosing fps when adding more objects.

I think, to be sure it's best to support ES 3.0 and up, if you really want to go with Crosswalk.

Distribution of the OpenGL ES 3.0+ in the last 6 months - 2015

• Jan - 30%
• Feb - 31%
• Mar - 32.5%
• Apr - 34%
• May - 36%
• Jun - 37%

It could get to 50% by the end of 2015. What type of game you're making?