• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Videlais

  1. @slash If you are using the WebView mode for CocoonJS, you are actually just using the platform's default browser. For most Android devices, this is usually Chrome or some version of it. Something to try, then, is to load up the game in a browser on the device and see if the same problems happen. If they do, it might not be CocoonJS, but something to do with the browser itself and how it is positioning things. Something else to think about is that the layout on mobile devices is often different than that of Desktop browsers. It might be that your 320x480 canvas size is being scaled incorrectly. The Android device you are testing on might have a screen size larger than that and the coordinates might be off by some amount. The problem could also be Phaser itself. I don't remember what fixes made their way into 1.1.6, but I do know 2.0 should be the most up-to-date with patches and fixes for the known issues when working with CocoonJS.
  2. @CaueCR: Sure. I'd be interested in some code to get video working. Like I wrote, I haven't tried it yet myself. If you can post it using the code highlighter here or supply a link, I'll take a look. I haven't seen or heard of other people asking about video, but I'd be happy to add it to that list too.
  3. @Gamma: This post has a collection of the issues I've seen with CocoonJS. It should address the scaling, text, and audio problems. The differences between System WebView and 'Accelerated Canvas/WebGL' modes are often kinda deceiving. The System WebView creates an API layer and then calls the default browser on the platform. It's more or less just handing off the task of running the code to an instance of that browser on whatever platform it is running on at the time. The 'Accelerated Canvas/WebGL' is the mode where things like CocoonJS extensions and other additional functional are enabled for use. This is the generally recommended mode for Phaser to run in, but also introduces a number of problems, as you've found out the hard way. However, the good news is that Phaser 1.2 has fixes for many of the known problems. (And I've personally written two libraries to fix other ones.) Unless you really need a version before 1.2 (2.0), I recommend just waiting for the new Phaser version.
  4. @CaueCR: I've been working to submit patches for Phaser with CocoonJS for several weeks now. I've been updating this list as I've gotten documentation of issues and proof of different ways to solve things. Some functionality is still not working correctly. However, many issues have been patched in the development build of Phaser. I personally haven't tried working with videos and CocoonJS yet. From past experience with HTML5 video, though, I do know encoding formats can often be to blame for errors. Depending on the platform (Android, iOS, etc), different video and audio formats are needed. This is true across browsers too -- Chrome, Firefox, and Internet Explorer all support different video and audio formats. Phaser also doesn't have HTML5 video support at the moment, and neither does CocoonJS -- you cannot "createElement('video')" currently. So, that might be a major obstacle. However, although I haven't tried them personally, there may be ways to patch video support back in via another JavaScript library, should you be interested. (It's possible Broadway.js might work, but I haven't tried it.) Many of us are not hiding things from people. We simply don't know the answers ourselves.
  5. @programlocura: If you are using the cloud compiling service, it will always use the latest stable version of CocoonJS. If you are the Custom Launcher, as you seem to be, it is always updated to the newest version per cloud compile too. Are you getting any other errors with Phaser itself? Version 1.1.6 still has some issues, but version 1.2 has patches for most known problems with CocoonJS.
  6. Can you load the CocoonJS Custom Loader and then your own code, or otherwise get access to CocoonJS' console? It's possible an error is being thrown inside CocoonJS itself and we might be able to fix or catch it somehow in Phaser. (This might already be fixed in Phaser 1.2 too. There has been a major update to how visibility works in the latest development branch.)
  7. A friend of mine works at a company that uses PhoneGap and he really likes it. I've also heard of people using Cordova. (It's what PhoneGap uses itself.) If you are only aiming at iOS and you have access to XCode, Ejecta might work too.
  8. @rich: I saw your questions right after you posted them, but wanted to make sure I had run several more tests before answering. Here is what I've tested and documented with screenshots today: The CocoonJS Custom Launcher has TrueType font support. (Search for "TrueType Fonts" for the example on the demo page.) Create a "fonts" directory from the root of your project. Place any TTF files you want CocoonJS to use. When run, CocoonJS will automatically read and load all TTF files it finds. To use these in your project, use the filename before the extension. For example, if the TTF file was "arial.ttf", you need to reference it as "arial". However, what is not documented (yet), is that the Custom Launcher will retain these fonts in memory for as long as it is running. If you run another project with those fonts, CocoonJS will report a "Custom font failed to load" message, but still use them -- it doesn't reload them, in other words. Using multiple 'screencanvas' elements seems to confuse CocoonJS. When I tried changing Pixi.Text to use 'screencanvas' instead of 'canvas', it crashed the application after running for a few seconds. Directly writing text to the 'screencanvas' does seem to work. (Note: I have a "arial.ttf" file in a "fonts" directory with this code to guarantee the font exists.) (function(window, Phaser) { var game = new Phaser.Game(window.innerWidth, window.innerHeight, Phaser.CANVAS, '', {preload: preload, create: create, update: update}); function preload() {} function create() {} function update() { writeText("Updated text"); } function writeText(string) { var context = game.canvas.getContext('2d'); context.font = "45px arial"; context.textAlign = "left"; context.fillStyle = "#ffffff"; context.fillText(string,,; }})(window, Phaser);My current thinking is to either have a reference to the current canvas in Pixi.Text (which I'm currently working on), or write some code that acts like Pixi.Text, but is custom designed for CocoonJS usage. Maybe something like Pixi.CocoonJSText that is used only when CocoonJS is detected? I don't know. I think I might be able to pass a reference to the canvas via Phaser.Text somehow.
  9. @mariogarranz: Confirmed. I tried the Bitmap font example with Phaser 1.2 and got the exact result you described on my Ouya. While I was testing my own gamepad polling code with the Gamepad Debug example, I noticed another text problem too, where the text would seem to layer or even disappear if it was updated at all. The more rapid the change, the less likely it would be seen over time. I was hopeful, since learning CocoonJS supports loading TrueType fonts directly, that the problem would go away when using those, but it seems to be tied to some combination of Pixi and CocoonJS. At least in the code examples I've seen from Ludei, they seem to be writing directly, using fillText calls, to the 'screencanvas' element's drawing context. I'm curious if the solution is in either having Pixi.Text use 'screencanvas' elements (instead of 'canvas' ones), or if all Pixi.Text calls should operate on the 'screencanvas' used by world.stage. I'm not sure. More testing is needed.
  10. Introducing the Phaser CocoonJS-Ouya Gamepad plugin! It is still in 'beta,' but seems to work well in the testing I've done and, most importantly, takes into account the few problems I am aware of with CocoonJS + Ouya gamepads. The solution I came up with was to copy over the Phaser.Gamepad and Phaser.SinglePad code, rename the objects, and make changes in a few functions to match the research I've done. I also, as I'll see about adding to Phaser proper soon, wrote in a radial deadzone algorithm for detection of values normalized within axis deadzones. It gets rid of that input 'snapping' when an axis value suddenly isn't in the axis deadzone -- a smoother transition over that threshold. I also extended the number of possible gamepads from 4 to 11. At least according to the official Unity SDK code, the Ouya can support up to 11 gamepads at once.
  11. Update: As confirmed in the Ludei Support Center, "timeStamp is always 0, yes.It is true that the gamecontroller indices increase after disconnection." For the moment, it looks like fixed-rate polling is the best way to go for CocoonJS on the Ouya (and possibly on other Android devices). I'm still working on a plugin and should be done within the next couple of days. At that point, I'm also going to expand out the Text section above, as I have some more solutions for that, and include many more details about what to expect when using the gamepad API.
  12. Some progress: I now have working code that takes into consideration the unreliable 'index' and 'timestamp' properties when using CocoonJS on the Ouya for gamepads using fixed rate polling. It has allowed me to individually test every button and axis value across Ouya, Xbox 360, and PS3 gamepads. I consulted the newest edition (25 February 2014 as of this writing) of the W3C Gamepad specification and specifically the newer Remapping section and verified that CocoonJS-Ouya maps all gamepad types against the 'standard' button mapping layout, but with the following caveats: Select/Back (button[8]) and Start/Forward (button[9]) are mapped to "Quit application" and "Ouya button." Pressing button[8] will trigger a prompt to end the application while under CocoonJS and double-pressing button[9] triggers the Ouya system overlay. (Note: the Ouya gamepad does not have these buttons itself.)The d-pad (button[12], button[13], button[14], and button[15]) do not work on Xbox 360 compatible gamepads on the Ouya. (This is a known issue and is confirmed in the official Ouya Unity code too.)Single-pressing the Ouya button (button[16]) or its equivalent on other gamepads does not produce a value. However, because double-pressing button[16] is a system-level interrupt, it will always bring up the Ouya system overlay.Now for the bad news: As I mentioned in this post, I have recently documented a bug where the first ([0]) gamepad will often produce out-of-range values for its axes[0] and axes[1] while at rest. Moving them at all produces the correct values, but the at-rest values are frequently quite wrong. (This picture and associated tweet is also visual proof of the ever-increasing index value problem too. It should not be possible to get an index of 10 unless there were that many gamepads paired with the system as well -- and there weren't.) Future-proofing recommendations for Phaser: The most recent Working Draft of the Gamepad specification also includes the GamepadButton interface and its associated 'value' (double) and 'pressed' (boolean) properties. I haven't checked if Phaser 1.2 tests for these yet, but it probably should. In all likelihood, Phaser 1.2 and the newest version of Firefox (which has this interface) will ship within a week of each other in March 2014. (Aside: I have working code that uses the older "MozGamepadConnected" and "MozGamepadDisconnected" events. Phaser should probably support these two as well -- and have code in place to swap the different button layouts. As I know, for example, that the correct Xbox 360 axes are axes[0], axes[1] for left stick and axes[3], axes[4] for right stick in Firefox Aurora currently.)
  13. @judax: Thank you for posting and confirming these issues! While the above information covers most of the common issues, I've recently discovered some more problems when running CocoonJS on the Ouya and specifically using the Gamepad API. (I have not been able to confirm these on other hardware and platforms yet.) As I mentioned in this topic the other day (and is now a question in the Ludei Support Center too), the 'index' property values on gamepads do not seem to be re-used after disconnection events. They always increase by one with each gamepad connected to the system. The Custom Launcher also occasionally remembers index values between sessions, starting the next run project with the last index value used plus one. I have also had issues with the 'timestamp' values on gamepads not updating at all, no matter the gamepad used. As of today, I have documented a strange bug with the first indexed gamepad's axes[0] and axes[1] reading very large numbers while at rest as well. As can be seen here with an Ouya gamepad, here with a PS3 gamepad, and here with a Xbox 360 gamepad, whatever gamepad is connected in the first slot will have large numbers as values for its first two axes. If they are moved even the smallest amount, the values produced are in the correct range, -1 to 1, but when at rest, and only with the first gamepad each time, these numbers seem to be appearing. See the top post for latest information.
  14. You can ask, plicatibu, but I might not be able to answer questions or help much for awhile. It was just last week we got the patches in to get Phaser working with CocoonJS more or less cleanly. And I've been spending most of this week working on gamepad code for the Ouya myself. It's on my TODO list to document the IAP and ad code in CocoonJS, though, but I might not get there for a couple of weeks or more.
  15. @plicatibu: Have you looked at the IAP Purchases documentation? I was able to get their demo (ZIP file) running just now on my Ouya via the Custom Launcher, but couldn't do much without a keyboard.
  16. @rich: I've been learning that's the case, yeah. There are people interested in doing HTML5 development using Phaser for the Ouya, but I haven't found another person specifically working on these problems and willing to spend hours digging through Phaser's code to solve them @kenyee: Yeah. And most likely, yes. If there is someone who has an Android device and a compatible gamepad, we could probably get confirmation if CocoonJS acts the same way on other platforms. (From my research, this table,, seems to be pretty good for detailing which phones have plug-and-play support for PS3 controllers. However, maybe the device needs to be rooted too? I'm not sure.) Anyway, as progress toward a solution to these latest hurtles, I've done the following two things: Submitted a question on the Ludei Help Center to get confirmation if these are known issues, the index and timestamp problems, and if they have already been fixed in the upcoming version of CocoonJS. Started work toward a fixed rate (150 ms) polling plugin for Phaser that will try to autodetect what type of controller (Ouya, Xbox 360 compatible, or PS3 compatible), load new deadzone values, and configure correct button mappings.As progress is made, I'll update this thread to let other people know.
  17. Thanks, @rich. Since posting that, I've been thinking it might be easier in the short term to make a Phaser plugin that handles gamepad input specifically for use under CocoonJS on the Ouya. Something that avoided these two issues, indices and timestamp, but acted like the current Phaser gamepad API. It would also allow for a different set of button constants, threshold, and deadzone values too. All things, I know from previous experiences with the Ouya, that will be needed after the polling issue is worked out.
  18. As you might have seen a few days ago, I've been trying to work out what is needed to get Phaser working as best as possible on an Ouya using CocoonJS. It has been a very frustrating road and, while I have had some successes, I've also finally hit a point where I really want some other people's opinions on where to go next. First, though, some solutions. So, as it turns out, I was only partially right in the additional property to test for in my change to the "pollStatus" code for gamepad input. It actually needs to test for the property and call the function too. Here is the code for that. var rawGamepads = (navigator.webkitGetGamepads && navigator.webkitGetGamepads()) || navigator.webkitGamepads || (navigator.getGamepads && navigator.getGamepads());(This has the added benefit of working in Firefox Aurora too now, but more on that a little later in this post.) Through my testing, I was at first surprised and then highly annoyed to learn that the 'index' property of gamepads in CocoonJS is unreliable. While the specification states indices start at zero, it doesn't include how counting should happen between gamepads being connected, disconnected, or reconnected. The result of this is inconsistency is that, in CocoonJS anyway, you might get "0, 1, 2" for the first three controller indices, or you might get "0, 5, 8" sometimes. (It also doesn't help that the CocoonJS Custom Loader remembers the last index as long as it is running. I was up to an index of 25 at one point yesterday.) To combat this issue, and hopefully not break the existing Phaser code for other systems, I have the following patch for "ongamepadconnect." this._ongamepadconnected = function(event) { var newPad = event.gamepad; _this._rawPads.push(newPad); for (var i in _this._gamepads) { if (!_this._gamepads[i].connected) { _this._gamepads[i].connect(newPad); break; } } };Instead of trusting the index of the gamepad, it looks for the first open slot within the four gamepads (as of 1.1.5 in Phaser) and 'connects' it. If all are connected, "_gamepads" is not updated. And here is the patch for "ongamepaddisconnected" too. this._ongamepaddisconnected = function(event) { var removedPad = event.gamepad; var removedPadIndex = 0; for (var i in _this._rawPads) { if (_this._rawPads[i].index === removedPad.index) { _this._rawPads.splice(i,1); removedPadIndex = i; } } _this._gamepads[removedPadIndex].disconnect(); };This time, instead of removing according to the "removePad.index" (as was previously the case), it finds the index of the pad to remove from "_rawPads" and uses that. Because I wanted to test the above code on another system, I turned to running in Aurora (since I knew it supported the two events). This became a very Good News / Bad News situation. Good News: Aurora passes the same "(navigator.getGamepads && navigator.getGamepads())" test CocoonJS does. No changes there. And there is now a new 'connected' property per gamepad built in too. Bad News: Gamepads no longer have a 'timestamp' property and buttons are now "GamepadButton" objects. The former is a fairly easy fix. Test if the index of the button array is an object and then look for its 'value' (float) or 'pressed' (boolean) property. The later is more complicated, and a problem I've recently learned CocoonJS suffers from too. (After the Aurora testing, I used the same code on my Ouya in CocoonJS. It has a 'timestamp' per gamepad, it turns out, but it remained a '0' during all of my testing. Not helpful. At all.) All of this explanation and code now brings me to some questions: Should the Phaser code be re-written to match these two systems? And if so, what is the best way to go about it?It should be possible to use "" to record our own timestamps. And I think this could even happen as part of "pollStatus" function somehow. But I really want some second, third, and maybe even fourth opinions about how to go about it, or if it should even be done in the first place. After all, the Aurora and CocoonJS timestamp issues might work themselves out in their next versions. Or they may not. I don't know if it is worth waiting several weeks at a minimum to find out. Is there anyone out there willing to either work with me or independently collaborate on this Phaser + CocoonJS debugging?I'm making progress in fits and starts. And I know other people are waiting for the go-ahead to start using Phaser in CocoonJS without problems. I figure there has to be at least one other developer willing to just check over that "Yes, this works for me too" or "Nope, I don't see that here" on these various changes. While I was thrilled @rich was willing to adopt my earlier changes, it has made me more skittish the deeper I go and the more little bits of code I change to get Phaser working in CocoonJS as smoothy as possible.
  19. @jerome: Please do! That's been the one problem with all this, the lack of documentation and general knowledge about getting things working with CocoonJS. I'm still hunting down some occasional issues with gamepads on Ouya in Phaser, but plan to write a guide on all this at some point soon myself. I've been trying to decide if I should wait for 1.2 or cover adding in all these different patches as part of the guide.
  20. Last update of this information was 13 August 2014. Note: As of this writing, CocoonJS (2.0.*) comes in a total of three modes. [system] WebView creates an instance of the default browser for a platform, loads its own API, and then hands off the code execution. In most cases, it is the same as running the code in a mobile platform's default browser. WebView+ is often the same as WebView, but adds in Chromium-based libraries. For Canvas+ mode (previously accelerated, "Canvas 2D/WEBGL") it strips out things like XML and most DOM and CSS support to make running the canvas as fast as possible. Because of this, most common things like getElementById and createElement in JavaScript have reduced functionality. It is designed purely for Canvas-based projects. (For the 2.0 branch, see the changelog from 1.4.7.) Since there is limited DOM support, make sure to use an empty string for the parent element during the creation of a game object when using the accelerated/Canvas+ mode. (This is to make sure the created canvas element is appended to the document.body object, and not some other element the getElementById function cannot find.) var game = new Phaser.Game(window.innerWidth, window.innerHeight, Phaser.CANVAS, '', {preload: preload, create: create, update: update});Issues with Phaser <= 2.0.7 and CocoonJS <= 2.0.2 (Canvas+) Images Use of multiple images may introduce disappearing or flickering results. Text Single-line text printing works. However, using the newline character will not produce the correct results. Setting anchor.y values do not work correctly.Shadows do not work. XML CocoonJS does not have native support for XML. Its XHR does not return responseXML and it does not have a window.DOMParser object. Scaling Generally, you can use window.innerWidth and window.innerHeight to compute the size of the screen in CocoonJS. However, if you know there might be a device pixel ratio issue, the following code works for that. var width = window.innerWidth * window.devicePixelRatio;var height = window.innerHeight * window.devicePixelRatio;Depending on your needs, Phaser's built-in scaling manager will often be enough. However, the following code suggested by Starnut should be helpful for accounting for odd screen sizes as well. var w = window.innerWidth * window.devicePixelRatio,h = window.innerHeight * window.devicePixelRatio,width = (h > w) ? h : w,height = (h > w) ? w : h;// Hack to avoid iPad Retina and large Android devices. Tell it to scale up.if (window.innerWidth >= 1024 && window.devicePixelRatio >= 2){width = Math.round(width / 2);height = Math.round(height / 2);}// reduce screen size by one 3rd on devices like Nexus 5if (window.devicePixelRatio === 3){width = Math.round(width / 3) * 2;height = Math.round(height / 3) * 2;}var game = new Phaser.Game(width, height, Phaser.CANVAS, '');BitmapFonts Because of the lack of XML support, one solution for BitmapFonts is to convert the XML into JSON and use an alternative loader. This post covers the code needed and what to use to convert the XML into JSON. Audio Most often, audio problems are related to the device itself, not CocoonJS or Phaser. If you are running on an Android device, make sure you have OGG or WAV (16-bit ONLY) files. Apple devices support MP4, OGG, MP3, WAV (16-bit ONLY), or MPEG. (Remember too that MP3 decoding, depending on the device, can often be slow.) On some platforms, a user-activated event (like touch) is needed to enable sound. This specifically affects iOS devices, but is not uncommon on other platforms too. Using something like a "Tap to Continue" button or an initial menu works well to signal to the player to tap to enable both the game and sounds. Filters Filters don't work currently. (As reported here.) Buttons There is currently a problem where image-based buttons can sometimes disappear. It is under investigation. It is HIGHLY recommended to update to newer versions of Phaser ( >=2.0.7) and CocoonJS ( >=2.0.2). Issues between older versions of both libraries are no longer being actively tracked.