Common Phaser + CocoonJS issues

[Michel (Starnut)]

As phaser is only 2D what is the point of putting phaser in webgl and then turning it off in Cocoonjs ? Does it still gives improvement performance compared to canvas context ? (Sry for maybe stupid question)

 

That's actually the point: Nobody was trying to run their game under WebGL. People were running their games in Phaser.CANVAS mode, but under CocoonJS, it seems, WebGL wouldn't shut off entirely and, thus, messed up rendering.

[presidenten]

That's actually the point: Nobody was trying to run their game under WebGL. People were running their games in Phaser.CANVAS mode, but under CocoonJS, it seems, WebGL wouldn't shut off entirely and, thus, messed up rendering.

Hold on, doesnt Phaser.WEBGL mode give some drawing optimizaitons? I thought the whole point of going with CocoonJS was to get hold of those optimizations to get speedier canvas...? Have I been dreaming or are you guys talking about something else?

[Luis Felipe]

Thanks for passing on info on these newer developments!

 

@presidenten, true but CocoonJS claim to have up to 10x canvas acceleration ( http://support.ludei.com/hc/en-us/articles/202321098-Canvas-Promo ) so it could compensate for the WEBGL vs CANVAS performance loss, at least I think so.

[Videlais]

Hold on, doesnt Phaser.WEBGL mode give some drawing optimizaitons? I thought the whole point of going with CocoonJS was to get hold of those optimizations to get speedier canvas...? Have I been dreaming or are you guys talking about something else?

 

It does. WebGL has tons of optimizations I would love for Phaser to be able to use with CocoonJS. Unfortunately, as Starnut wrote, people aren't using it. There have been problems for months now with WebGL in Phaser under CocoonJS and the general consensus is to avoid it when possible.

 

My hope with the latest turning-off-WebGL hack is that it gives us some time to fix everything between now and Phaser 2.1 in the next several weeks. This latest little hack solves a number of other, more annoying issues at the moment and I remain at least somewhat hopeful it that it leads to figuring out why we are seeing Canvas and WebGL modes being mixed in Phaser right now when used with CocoonJS.

 

Believe me, I love WebGL. It's way better than pure Canvas for drawing things. However, at least right now anyway, I'd much rather have images working normally again in the short term as we try to patch up WebGL support in the longer term.

[presidenten]

Not sure if this is of any help, but if found this:

 

http://support.ludei.com/hc/en-us/articles/201810268-ScreenCanvas

 

 

How to enable ScreenCanvas

// Set the screencanvas property of a canvas to true before calling to getContext():var canvas = document.createElement("canvas");canvas.screencanvas = true;canvas.width = window.innerWidth * window.devicePixelRatio;canvas.height = window.innerHeight * window.devicePixelRatio:var ctx = canvas.getContext("experimental-webgl");

So maybe we need to add that last line in phaser to use it properly?

[bp74]

Hi guys,

I did some tests regarding this issue and i want to share what i found out - maybe it helps a little bit to fix this problem.
I do not work with Phaser or Pixi.JS but i see exactly the same issue with my own library. So here we go ...

I have tried three different ways to load the webgl texture:
1) load the texture from a image element
2) load the texture from a canvas element
3) load the texture from the ImageData taken from the canvas element.

None of those three methods worked, all methods have the same problem that the texture is not rendered. I changed the fragment shader in webgl to draw solid color pixels and it worked fine. This way i can see rectangles on the right position with the solid color of the shader (which just draws the color instead of the pixels from the texture).

So it seems that the texture is transparent everywhere. Next i checked the ImageData taken from the canvas element and indeed every pixel is transparent. Therefore the issue is not that the webgl texture does not work, it's simply the source where we load the texture gives transparent pixels (r:0, g:0, b:0, a:0). This is pretty strange because the very same canvas element (which seemingly contains transparent pixels) renders perfectly fine when it is directly drawn to the screen-canvas.

Hopefully this helps,
Bernhard

[rich]

I've been doing a lot of Cocoon testing and fixing today. This is Cocoon 2.0.0 on iOS7

 

So far I've done:

 

* Wrapped all touch, keyboard, mouse and fullscreen events that CocoonJS doesn't support in conditional checks to avoid Warnings.
* The SoundManager no longer requires a touch to unlock it, defaults to unlocked.
* Resolved issue where Cocoon won't render a scene in Canvas mode if there is only one Sprite/Image on it.

 

I've been playing with combinations of pure canvas, screen canvas, webgl enabled/disabled (in cocoon and in phaser) and am finding the following:

 

1) WebGL mode + ANY operation that does a canvas GPU upload, like game.debug or using a BitmapData or Tilemap is REALLY slow. Like 3fps slow.

 

2) WebGL mode (with no gpu upload) appears to be no faster at all than Canvas + screencanvas enabled. In bunnymark I'm seeing exactly the same quantities + fps rates across the two. Swapping to a webgl renderer made no difference at all.

 

3) The Path Render Quality made no difference in bunnymark (may do with larger textures?). The speeds between Default, Highest and Lowest were the same.

 

4) Filters don't work at all (either in plain Pixi or Phaser) even after sorting out the filter creation errors.

 

5) Sprite Batching makes no speed difference in webgl vs. just blasting sprites around. In Pixi I managed 1500 sprites at 30fps in webgl and that was regardless of screencanvas set on or off. In Phaser a sprite batch of 1500 sprites in webgl was around 15fps. So not great.really.

 

6) TileSprites don't work in Canvas mode because it appears context.createPattern isn't supported. I managed to get a solid block of colour working as a tilesprite, but not one with an image based fill. In WebGL mode it works fine.

 

7) Thankfully I had no issues with input handling or arcade physics. Something good at least then.

 

My conclusion is that it's a weird mixture of things Cocoon just doesn't support, mixed with what are blatantly Cocoon level bugs, combined with Phaser/Pixi trying to do things natively that Cocoon doesn't like / doesn't have support for anyway. While I did find several Phaser specific issues (and fixed them where I could) it still feels like I'm working inside some highly 'flakey' environment :-/

 

I'll carry on playing, but at least I know from this that there is absolutely no way Phaser can ever be 100% Cocoon compatible, not with the current limitations.

[Videlais]

* Wrapped all touch, keyboard, mouse and fullscreen events that CocoonJS doesn't support in conditional checks to avoid Warnings.

* The SoundManager no longer requires a touch to unlock it, defaults to unlocked.

* Resolved issue where Cocoon won't render a scene in Canvas mode if there is only one Sprite/Image on it.

 

Thank you, Rich, for looking into these things. I'm glad to read at least these three issues should no longer happen.

 

 

4) Filters don't work at all (either in plain Pixi or Phaser) even after sorting out the filter creation errors.

 

...

 

6) TileSprites don't work in Canvas mode because it appears context.createPattern isn't supported. I managed to get a solid block of colour working as a tilesprite, but not one with an image based fill. In WebGL mode it works fine.

 

I think I tried Filters before too and didn't get them to work. It reminds me to add them to the top post list.

 

It's good to know there is a root cause, lack of context.createPattern support, that's messing up tile sprites support. I know I have seen lots of people struggling with that for months now. I'll just make a note in the top post to explain that they don't work with CocoonJS and why.

 

 

My conclusion is that it's a weird mixture of things Cocoon just doesn't support, mixed with what are blatantly Cocoon level bugs, combined with Phaser/Pixi trying to do things natively that Cocoon doesn't like / doesn't have support for anyway. While I did find several Phaser specific issues (and fixed them where I could) it still feels like I'm working inside some highly 'flakey' environment :-/

 

I'll carry on playing, but at least I know from this that there is absolutely no way Phaser can ever be 100% Cocoon compatible, not with the current limitations.

 

I definitely feel the same way. Best case, I think, is just a more refined list of what the issues and problems are, not necessarily solving them.

[hyperandroid]

I've been doing a lot of Cocoon testing and fixing today. This is Cocoon 2.0.0 on iOS7

 

So far I've done:

 

* Wrapped all touch, keyboard, mouse and fullscreen events that CocoonJS doesn't support in conditional checks to avoid Warnings.

* The SoundManager no longer requires a touch to unlock it, defaults to unlocked.

* Resolved issue where Cocoon won't render a scene in Canvas mode if there is only one Sprite/Image on it.

 

I've been playing with combinations of pure canvas, screen canvas, webgl enabled/disabled (in cocoon and in phaser) and am finding the following:

 

 

1) WebGL mode + ANY operation that does a canvas GPU upload, like game.debug or using a BitmapData or Tilemap is REALLY slow. Like 3fps slow.

 

 

This is a mobile GPU limitation. Any canvas usage as texture, means creating a buffer, pixelgrabbing the image (which could mean extracting pixels from a GL texture back to memory), and then uploading pixels to texture. This operation is never suitable to be done in realtime. Not even in desktop in my MBA. For small textures for example with fillText, a new texture must be created and uploaded, but cocoonjs has a cache mechanism that tries to minimize the impact of such operations by reusing previously generated textures.

 

 

2) WebGL mode (with no gpu upload) appears to be no faster at all than Canvas + screencanvas enabled. In bunnymark I'm seeing exactly the same quantities + fps rates across the two. Swapping to a webgl renderer made no difference at all.

 

 

This has a clear explanation. Cocoonjs canvas renderer is already completely hardware accelerated, taking full advantage of batching. This is done natively, so for any drawImage call in a canvas, a native side operation is involved. For Pixy, and any other decent WebGL renderer, the very same operation is being performed: batch as much as possible, but in this case, pixy is doing the same operations in javascript. Ok, bound to native buffers by using buffer arrays, etc. The consequence is that there can be very little difference in CocoonJS between drawImage and using all the Pixy mechanism for sprite batching in webgl.

So your results are pretty consistent with what I am saying, CocoonJS canvas renderer could beat or may be on-pair with any webgl sprite batching implementation like pixy's one.

On the other hand, if you want vertex tinting, 3d content, more blending mode, etc. no canvas implemenation will be of any help.

 

About screencanvas (setting style="screencanvas" in the html) needs some explanation too. Why the screencanvas makes things faster is because behing the scenes, Android draws all the content to an offscreen framebuffer. Using screencanvas forces the system to use the screen instead of an off-screen element. This speeds things up *a lot*, in the order of 10+ fps simply because there's no extra copying from the off-screen to the screen. In a mobile environment, GPUs are bandwidth limited, so this can save very valuable GPU data transfer. If you want to use filtering, this is the same scenario. Filters require offscreen treatment and then copy back to the screen, which sinks performance. The tradeoff between 60fps and visuals is served.

 

3) The Path Render Quality made no difference in bunnymark (may do with larger textures?). The speeds between Default, Highest and Lowest were the same.

 

 

There's a missunderstanding here. The path render quality if for vector tracing operations. For example, how many substeps a bezier will be divided into before tessellating the paths. It makes no impact on performance when drawing images/quads, so the results are consistent.

If will make a high impact though when stroking/filling arbitrary paths by calling fill/stroke.

 

On the other hand, there are specific extensions for leveraging the gaming ecosystem when running CocoonJS. These are the texture reducer, available in the configuration and which can be enabled programmatically. This is handy when your game loads tons of images and runs out of memory. The other scarcest resource in mobile is memory. This will make an impact in your visuals because will be using half/quarter/etc. the size images instead of your original ones, but will make as well an impact in performance boost because, as in the screencanvas point, less bandwidth will be transferred on the GPU.

The texture reducer can be set programmatically, to for example apply only to some images named with a pattern, or to images which are bigger than a threshold (for example 128x128 pixels).

The other extension is dispose. You can call anytime dispose on an image object to reclaim immediately the memory it has allocated. Garbage collectors in mobile are extremely lazy, and when loading new stages, it is a good idea to call dispose on every image you want to get rid of, instead waiting until the GC does its job. There's always a conflict between when the GC does its job and your needs.

There's an experimental option for automatic texture packing of the images which saves a lot of memory too, but at the cost of not being able to delete images at will.

 

4) Filters don't work at all (either in plain Pixi or Phaser) even after sorting out the filter creation errors.

 

 

We will have a look at this. In our WebGL renderer filters work out-of-the-box. Will get back on this as soon as we execute pixy and have some results.

 

5) Sprite Batching makes no speed difference in webgl vs. just blasting sprites around. In Pixi I managed 1500 sprites at 30fps in webgl and that was regardless of screencanvas set on or off. In Phaser a sprite batch of 1500 sprites in webgl was around 15fps. So not great.really.

 

 

Could you share this code so that we could give it a try ? Our stress tests are with 5K sprites and we get a decent framerate.

 

6) TileSprites don't work in Canvas mode because it appears context.createPattern isn't supported. I managed to get a solid block of colour working as a tilesprite, but not one with an image based fill. In WebGL mode it works fine.

 

 

As a rule of thumb, when something works in webgl and not canvas, it is a bug on the cocoonjs renderer. createPattern for a CanvasRenderingContext2D object is a common operation that should work great. We'll make the necessary testing on this too.

 

7) Thankfully I had no issues with input handling or arcade physics. Something good at least then.

 

My conclusion is that it's a weird mixture of things Cocoon just doesn't support, mixed with what are blatantly Cocoon level bugs, combined with Phaser/Pixi trying to do things natively that Cocoon doesn't like / doesn't have support for anyway. While I did find several Phaser specific issues (and fixed them where I could) it still feels like I'm working inside some highly 'flakey' environment :-/

 

I'll carry on playing, but at least I know from this that there is absolutely no way Phaser can ever be 100% Cocoon compatible, not with the current limitations.

 

 

CocoonJs has already shipped several Phaser based games, and we plan to still be able to. Phaser evolves very fast and we expect CocoonJS technology to be up-to-the-expectation. We work hard to bring a good solution for both iOS and Android platforms. Here's Ludei's commitment  to make the best support possible for Phaser games running in CocoonJS.

 

We'll write a post with our findings and possible workarounds. If any of you guys could supply us with the code examples that don't work, that'd be great and could save a lot of valuable time. CocoonJS is not a browser based environment, and that's the reason why fullscreen events are not supported. it always run in full screen mode, at the highest resolution unless otherwise stated. Weird things like not rendering scenes with only one sprite are something we'll have a look immediately.

 

Thanks for all the patience. 

 

Best,

 

- Ibon

[hyperandroid]

 

4) Filters don't work at all (either in plain Pixi or Phaser) even after sorting out the filter creation errors.

 

 

 

Update.

Latest CocoonJS launcher for android in the market (2.0.0) runs well with pixy filters: "example 15 - Filters".

Still have to try it with Phaser filters though.

[rich]

Thanks for taking the time to reply Ibon, as you can see from the length of this thread (and how many months it has been going on) a lot of people are very confused why some things work, some don't and what is the best settings and course of action to take when using Cocoon.

 

Based on your replies above I would assume the following:

 

1) Using WebGL mode is mostly pointless, as Canvas+ is just as fast anyway and Phaser does nothing in 3D.

2) The screencanvas setting only makes a difference on Android? (I saw no difference on iOS, but didn't test on Android)

3) Using WebGL mode will harm any game using tilemaps, debug info or gpu texture calls (BitmapData, RetroFont, etc).

4) Sprite Batches don't make any difference in our test code, but you believe they should. So that definitely needs looking at (same for Tiling Sprites)

 

You're absolutely right that some people have shipped Phaser/Cocoon games already, which is why it always confused me how so many others were having problems. But having spent several days using it I can at least see why now: it's because there are parts of Phaser / Pixi that simply don't work, and other parts that work just fine! So if someone made a game avoiding the "problem" areas I can see that it would have been quite painless for them.

 

I would definitely like to see how to improve the sprite quantities. 1500 sprites at 15 fps was terrible this was on an iPad Mini running iOS7. I didn't test Android. Also does Cocoon running in Debug mode make it any slower than non-Debug?

[hyperandroid]

Thanks for taking the time to reply Ibon, as you can see from the length of this thread (and how many months it has been going on) a lot of people are very confused why some things work, some don't and what is the best settings and course of action to take when using Cocoon.

 

Based on your replies above I would assume the following:

 

 

Hey Richard and all the Phaser community,

 

we know we can do better and getting a more active position with you guys could leverage CocoonJS as deployment platform. Lesson learnt on our side.

 

About your comments:

 

1) Using WebGL mode is mostly pointless, as Canvas+ is just as fast anyway and Phaser does nothing in 3D.

 

This is right as an statement. CocoonJS canvas renderer is already quite fast. But if you plan to go with filters, tint, etc. you still have to go with WebGL.

**start added content**

After re-reading the thread, i think i did not made clear one point. The canvas renderer is already hardware accelerated, and for a moderate number of on-screen entities, it will be as fast as the webgl one. It is important to note that the webgl renderer under heavy load will always be faster than the canvas one. In a pure marketing demo like the bunny mark, webgl will always be faster than canvas.

**end added content**

 

 

 

2) The screencanvas setting only makes a difference on Android? (I saw no difference on iOS, but didn't test on Android)

 

Yes. On iOS, there could be a non perceivable performance gain. For android, and much more for older devices (S3, S2, etc.) .

 

 

 

3) Using WebGL mode will harm any game using tilemaps, debug info or gpu texture calls (BitmapData, RetroFont, etc).

 

Mostly for operations that requiere image pixels level manipulation. This operations should be avoided per frame.

Are RetroFonts something that you only build once, or need a per frame modification ? This is the kind of thing where a filter or custom fill mode for Pixy could make a difference.  Gradients are right now something especially slow in CocoonJS, but we have recently built shaders for mimic-ing the two gradient types on Canvas. If you guys need a WebGL shader for this purpose, we could supply with them. Our WebGL renderer has (almost) full canvas API support and gradients are among the supported features.

But getting back to the question, avoid getImageData in loops. Honestly, there's little we can do about speeding this up.

 

 

 

4) Sprite Batches don't make any difference in our test code, but you believe they should. So that definitely needs looking at (same for Tiling Sprites)

 

Absolutely. I'd love having your test case around and do some profiling on it. 

 

 

You're absolutely right that some people have shipped Phaser/Cocoon games already, which is why it always confused me how so many others were having problems. But having spent several days using it I can at least see why now: it's because there are parts of Phaser / Pixi that simply don't work, and other parts that work just fine! So if someone made a game avoiding the "problem" areas I can see that it would have been quite painless for them.

I would definitely like to see how to improve the sprite quantities. 1500 sprites at 15 fps was terrible   this was on an iPad Mini running iOS7. I didn't test Android. Also does Cocoon running in Debug mode make it any slower than non-Debug?

 

 

Agreed. 1500 @15fps is quite a low mark. 

When setting debug enabled in the launcher App, the performance penalty should be non noticeable. But when setting Remote debug, this will definitely hurt performance in favor of a full remote debug of the javascript code.

I think we could focus on this issue first, performance is 50% of the game experience, so please if you could, give us access to the sample so that we can assess the same  code base.

 

Thanks for all the feedback.

 

- Ibon

[rich]

re: tests, I was using Pixi Example 18 (Batch). All I did was change the quantity from 10,000 to 1500 and force a CanvasRenderer or a WebGL one, toggling between the two (I saw no difference between the two, so left it as a canvas renderer).

 

If you could look at this one first then we could look at Phaser second, as it's always easier to figure it out from a Pixi level first.

 

The other issue was Tiling Sprites in Canvas mode. Again I used a Pixi example (9 - Tiling Texture) but forced it to use a canvas renderer, as WebGL worked fine.

 

As I mentioned above ALL of my tests were on iOS, none on Android. It might have worked on Android, I don't know

[hyperandroid]

re: tests, I was using Pixi Example 18 (Batch). All I did was change the quantity from 10,000 to 1500 and force a CanvasRenderer or a WebGL one, toggling between the two (I saw no difference between the two, so left it as a canvas renderer).

 

If you could look at this one first then we could look at Phaser second, as it's always easier to figure it out from a Pixi level first.

 

The other issue was Tiling Sprites in Canvas mode. Again I used a Pixi example (9 - Tiling Texture) but forced it to use a canvas renderer, as WebGL worked fine.

 

As I mentioned above ALL of my tests were on iOS, none on Android. It might have worked on Android, I don't know

 

Hi Richard,

 

just tested both demos on Android Nexus 7 and iPad Mini (non retina).

Nexus7 with Batch example gives steady 60FPS with 5K sprites, and steady 35FPS with 10K sprites. Both with WebGL.

The tiling texture works as expected at steady 60fps in webgl.

 

For the ipad Mini, the tiling texture works flawless @60Fps with webgl renderer.

But the batch demo fails miserably. 10K sprites run at 3FPS, and 3K at 14FPS. There's clearly something wrong with this. We'll have a look at this asap.

 

All the testing has been done with the latest CocoonJS launcher available in the markets. I don't know whether you tested with the 2.0.0 version. If not, could you download and try the tiling texture ? should work as expected.

 

Thanks.

 

- ibon

[rich]

Did the Tiling Texture work on the iPad in Canvas mode? It always worked in WebGL for me.

 

Glad to see you got poor performance on iOS batching (i.e. it wasn't just local to me) AND that it should run at Android speeds - that will be a massive boost

[hyperandroid]

Did the Tiling Texture work on the iPad in Canvas mode? It always worked in WebGL for me.

 

Glad to see you got poor performance on iOS batching (i.e. it wasn't just local to me) AND that it should run at Android speeds - that will be a massive boost

 

Yes, it works in both Canvas and WebGL.

Well, I am glad too that you did get the right results. But honestly I'm a bit pissed off by the results

 

With 10K sprites, that should be more consistent with a canvas result, where the calls between native and JS will end up sinking performance. 1.5K should be ok in both thought.

 

So overall, the demos work on both iOS/Android, but batching performance on iOS is bad.

The performance issues also happen in our renderer so it is not pixi/Phaser specific.

 

Where there any other non-working demos for you ?

 

We know there are some issues with pixy when using fillText and is due how Pixi calculates font heights and baseline. It uses two dom elements to measure the difference and that in cocoonjs fails. On the other hand CocoonJS offers native text baseline position which is a nice workaround. I think the way to go should be pull-requesting pixi ?

 

Thanks.

 

- ibon

[rich]

I'll upload an example of a Tiling Sprite demo that doesn't work on iOS + Canvas for you.

 

Also how did you get the Pixi filters working? I can't see any of them working here (again, iOS). Got something online I can test for you?

[Videlais]

We know there are some issues with pixy when using fillText and is due how Pixi calculates font heights and baseline. It uses two dom elements to measure the difference and that in cocoonjs fails. On the other hand CocoonJS offers native text baseline position which is a nice workaround. I think the way to go should be pull-requesting pixi ?

 

Hi, Ibon. I can weigh in some on the fillText issue. It's specifically here within the Text object of Pixi.js. A few months ago, I wrote a pull request that attempted to add in a function for this that would calculate font height based on counting the pixels within a canvas. It's much slower, of course, but it doesn't rely on CSS support existing and can be more accurate for non-standard fonts.

 

Having text baseline support, unfortunately, doesn't do much for the problem. The current Pixi (and thus Phaser) calculation uses offsetHeight. In my own testing, this was always set to the canvas size instead of the pixel distance between the two DOM elements based on the font height.

 

It might be possible to find a fix that doesn't use CSS too much, but it would need to find a way through using whatever is currently supported in CocoonJS for measuring distances between DOM elements. (Or just, you know, using the slower way instead for now.)

[momonz]

I've been doing a lot of Cocoon testing and fixing today. This is Cocoon 2.0.0 on iOS7

 

So far I've done:

 

* Wrapped all touch, keyboard, mouse and fullscreen events that CocoonJS doesn't support in conditional checks to avoid Warnings.

* The SoundManager no longer requires a touch to unlock it, defaults to unlocked.

* Resolved issue where Cocoon won't render a scene in Canvas mode if there is only one Sprite/Image on it.

 

 

Quesiton, how did you wrapped the touch, mouse and fullscreen events? Did you create a new javascript file or re-use an existing javascript files.

 

Also, "The SoundManager no longer requires a touch to unlock it, defaults to unlocked." do you mean wrapping the above defaults sound to unlocked?

[Videlais]

Quesiton, how did you wrapped the touch, mouse and fullscreen events? Did you create a new javascript file or re-use an existing javascript files.

 

The commit shows which files were changed and where.

 

Also, "The SoundManager no longer requires a touch to unlock it, defaults to unlocked." do you mean wrapping the above defaults sound to unlocked?

 

Yes. Hopefully a touch should no longer be required. It was fixed in this commit. (The above and this commit have nothing to do with each other other than CocoonJS support.)

[Michel (Starnut)]

Just read through all of the recent posts (been away for a while) and feel very happy to finally hear a Ludei voice on this topic and see that some things have already improved. Thanks guys!

 

Really looking forward to future Phaser/Pixi integration into CocoonJS!

[altergo]

I have the problem with the buttons even in CANVAS mode.

 

Here is my game

 

 var game = new Phaser.Game(width,height, Phaser.CANVAS, 'game');

 

 

And the buttons

 

   for (var i = 0; i < 6; i++) {

 

            if(i%2==0) {

                this.button =  this.add.button((25+90*i), (600), 'buttons', this.actionOnClick, this, 0);

             //   this.button.anchor.setTo(-0.8, 0);

            } else {

                this.button =  this.add.button((25+90*(i-1)), (785), 'buttons', this.actionOnClick, this,  0);

            }

 

            this.ans_text =  this.add.bitmapText(60, -55, 'kuku', this.ans_style, 65);

           // bmpText = this.add.bitmapText

            this.button.addChild(this.ans_text);

 

 

            this.all_buttons.add(this.button);

 

 

        }

 

 

And the Listener

 

 // what happens when i click the button

    actionOnClick: function (button) {

    var log;

    if(button.value==this.char_bubble.char_trans) {

        // right

        blocksound.play();

 

        button.frame=1;

}

 

Nothing happens.

 

I tried to switch of OpenGL on Cocoonjs launcher

 

I use Cocoonjs 2.0.1  and phaser 2.0.4

 

Any suggestions?

[delueg]

Hello folks,

 

First awesome community!

 

I want to share my experience with the "Images not displaying right under cocoonjs".

 

Prolog:

 

One test-device of our little company is an Huawai where we always had the most problems. (Black-Screen after Restart etc. etc.)

 

So yesterday i saw this post http://likeadev.com/show/6-tips-to-make-your-phaser-game-work-with-cocoonjs.html where he mention that CANVAS Mode should be taken to avoid things like that.

 

So i switched to Canvas Mode. But then i had the Black-Screen-Issue always after App-Start.

 

What i never recognized before was that i  was still with 

 

1. Phaser v1.1.5

 

and that this Issue is known under this Version and has been fixed later.

 

So i updated to Version v2.0.5. 

 

After some refactoring it was quite nice - excepted that the pause handling was not the same.

 

No Problem i thought because i am on it at the moment anyway. I created my own pause handling - perfect.

 

After compiling with the Cloud Service from Ludei Version (2.0.1.) i had this Issue that not all images where rendered correctly.

 

( I always used Phaser.AUTO in the beginning )

 

So after some testing i can say:

 

1. With Phaser Version v1.1.5 i had no image rendering Issues at all ( only SVG didn´t work properly )

2. the trick with 

var fake = this.game.add.sprite(0,0,'');

was working as excepted but not all the images where fixed.

In my project i could fix it by just using a second empty Image so my code

var fake = this.game.add.sprite(0,0,'');var fake2 = this.game.add.sprite(0,0,'');

what is important is that it is at the end of the create function, otherwise no effect at all.

 

my code to recognice why 2 images :

 

i am not sure about that but i think it has to do something that the images are placed in a seperate context ( inside a second function ).

//last image in main context where not rendered and produced strange behavior when clicking on the space where it should be : means -> appears after tabbing on the empty space : -> but not the howto_screenthis.howto = this.game.add.sprite(window.app.half_w - window.app.w / 40, window.app.h - window.app.scale_ratio.highscore_btn.h * 2.2, "howto");this.howto.scale.setTo(window.app.scale_ratio.self,window.app.scale_ratio.self);var that = this;this.howto.inputEnabled = true;this.howto.input.pointerOver.id = 4;this.howto.events.onInputDown.add(function(){//was not rendered at all in the beginning only after setting a second fake imagethat.howto_screen = that.game.add.sprite(window.app.scale_bg_factor.x, window.app.scale_bg_factor.y, "howto_screen");that.howto_screen.scale.setTo(window.app.scale_bg_factor.s,window.app.scale_bg_factor.s);that.howto_screen.inputEnabled = true;that.howto_screen.input.pointerOver.id = 5;that.howto_screen.events.onInputDown.add(function(){that.howto_screen.kill();});});

 

 

so after i placed one fake image the last image in main context were displayed but the "howto_screen" wasn´t.

So after i set 2 fake images everything looked like it should.

 

Also Phaser.AUTO was no Problem. Couldn´t test on Huawai until now but NEXUS 4 is running good again.

 

Also didn´t delete the line of Phaser.Device like mentioned in this thread.

 

Maybe i have to do it when it comes to the Huawai  EDIT: i had to do this because on Ipad it was not working properly like mentioned above.

 

Hope i could help someone.

 

Giving love to the HTML5 Game Dev Community

[Latimed]

Hey guys,

 

For those who are facing the famous sound problem in iOS with CocoonJS when you have to make a tap before loading the sounds.

 

I found a very simple solution to such annoying problem, I was trying to solve it since last week and I finally found how to fix it and it's really easy.

 

All what you have to do is to put this instruction before you load the sounds (I put it in the Boot State):

game.sound.touchLocked = false;

 

 

The sound now will work without a need to make a tap in the screen on iOS.

 

Hope this will help you guys

[delueg]

Hello,

 

i have a problem on IOS iPad with CocoonJS and Phaser.

 

What i do is: 

 

In the create function i add an listener to the game like so.

this.game.input.onTap.add(function(e){			if(window.app.runtime_vars.player_dead != true && that.pause == false){				if( e.x < window.app.half_w  ){					that.jump(0);				}								if( e.x >= window.app.half_w ){					that.jump(1);				}			}		});

so after my player dies i have an self constucted restart to avoid some problems on low end devices like blackscreen and avoid loading times etc.

 

i can´t really show code here because that would be too much.. what i do is just remove and readd sprites and resetting variables and so....

 

But what happens on IOS iPad is that the onTap Event doesn´t work like before:

 

1. It is not as sensible like before

2. tapping the left and the right side at the "same" time ( for sure not the exactly same time im millisec - just human fingers  ) doesn´t work anymore,

means before my restart i can tap the left side on the screen and the right side.. and the player is doing both actions. After my restart this is not working anymore.. the action which is triggered slightly before the other will prevent the second.

 

3.EDIT: It is only happening after opening and closing a webview

 

Does anyone has an idea why this is happening? 

 

Thanks Jack