• Content Count

  • Joined

  • Last visited

  • Days Won


Videlais last won the day on August 31 2014

Videlais had the most liked content!

About Videlais

  • Rank
    Advanced Member

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2275 profile views
  1. It could any number of things, unfortunately. To start: Have you tried your game using WebView mode? How about WebView+? Do those work? If so, check the console. Is it reporting any errors at all? If so, where and with which functions? If you are using the Launcher app, try turning off WebGL from the settings. Does that help? Does it still not work? Finally, try disabling all functionality and reverting back to just the most basic creation of a Phaser.Game object. Does that work? How about when you add in states, images, or sprites? Do those work now? You might need to test things one by one to find it.
  2. For those interested, there is an older patch I wrote that does something like this too. Instead of pre-populating a cache, though, it draws the font to a temporary canvas, calculates its height, and then saves the value for every font requested.
  3. No, it won't be any faster. However, the file is needed to setup the window.cordova object and its associated events. As @chg wrote, Phaser looks for the window.cordova object to be defined (which comes from including "cordova.js" before Phaser) and, if so, then waits for the 'deviceready' event. You also might not be using any of the Camera or Vibration stuff, but any audio playing -- for which the Media plugin is needed -- comes after the 'deviceready' event is called too. You cannot access plugins until after the 'deviceready' event, and Phaser doesn't know to wait for it unless window.cordova is defined first. It's better to be safe and just include it. (@spencerTL already answered this, but I thought I would group this with the previous response.) Other than making sure "cordova.js" is loaded before Phaser, you shouldn't have to do anything. As I wrote above, Phaser will try to detect window.cordova and then act from there. However, as I note in the top post as well, Phaser doesn't automatically detect and act on the 'pause' and 'resume' events (yet). So, you will need to handle those somehow.
  4. To apply my own prognosticating to this: I think there is a move, even among the wrapper engines like CocoonJS and Ejecta, toward more WebView-based tools. As one example, Ludei's own CocoonJS Command-line Interface is just the Cordova tools with the injection of WebView+ (Chromium libs) on top. And PhoneGap, as is pretty commonly known, is just Apache Cordova with a different name and a remote compiling option. Based off this article, and some moves I've seen and have started to make myself, then, I definitely see WebView (be that UI or WK) as a large part of the future of mobile HTML5. Those apps compiled to use the native API, and not have to go through a translation layer, are always going to be faster. As long as the WebView code improves, and I see no reasons why it wouldn't, I see the same long term answer Scirra did: more WebView, less wrappers. However, as someone who has tried (albeit very slowly) to introduce patches for Cordova/PhoneGap to Phaser, I don't think anyone should suddenly jump ship from CocoonJS to Cordova. There are some major issues, like the use of the Media plugin, for example, that complicate even the seemingly simple task of playing audio. And Phaser definitely needs to catch more Cordova events (like "pause", "resume", and "backbutton" to start) before even simple apps will work as expected in production settings. That written, though, if CocoonJS was dropped from Phaser in the coming months, maybe even by the beginning of next year, I wouldn't mourn it too much. I was a big proponent of it early this year, I know. But, given the frustration of all the weird hacks we've had to use and constant shifting of what works with each version, I've stopped being an apologist for it. Maybe the next version will be better, maybe, but there is only so much "Oh, the next version, for sure!" I can take.
  5. That might be the fastest way, yeah. I've been hoping someone would come along and write a patch for mobile resizing, but that hasn't happened yet. So, in the mean time, what you outlined, scaling sprites and using innerWidth and innerHeight, is probably the easiest way.
  6. I wish it did. That would be very helpful. Sadly, though, CocoonJS works as sort of a reduced browser environment. Unlike PhoneGap (Cordova), it doesn't use the native platform's WebView framework, but renders things itself. It works more like an abstract to a graphics engine than as something common to nearly all other browser-like user agents. Since everything is not scaled together (although maybe using ScaleManger would help with that?), you might need to scale things yourself, too. I know this can be frustrating, accounting for position changes, but it is, unfortunately, a part of building apps for different mobile devices. Because they can have different dimensions and pixel ratios, you have to make decisions about what to support and where you employ different scaling. Only supporting certain device types or platforms may help with that, depending on what you want, but as of right now, there isn't an easy way to scale things perfectly in Phaser when using it with CocoonJS. And while we've made some progress on responsive scaling (see 2.1.1's RESIZE under ScaleManager), patches accounting for hybrid app frameworks still lag behind. So, yeah, you might need to position things relative to each other. And will probably need to scale sprites to match the increased canvas size too.
  7. Just to clarify, @BinaryMoon, are you writing that you are adding an extra image at the end of your create() function per scene? Something like the following: function create() { //Creating stuff game.add.image(0,0,'');}If so, and we can verify this is a working solution to the problem, we could probably roll it into a patch for Phaser at some point. (This was, in fact, the solution previous to 2.0, anyway. Looks like it might need to be added to this hack.)
  8. You should scale your game to the screen. See the section under "Scaling" here or the several threads covering scaling on the forums. Looking at Phaser's ScaleManager might help too, depending on your needs.
  9. Probably not. Detection of Cordova/PhoneGap is relatively new to Phaser, and I haven't really gotten around to detecting and using various plugins yet. Looking at the API for FastCanvas, though, changes to use it would have to happen at the Pixi level. (Phaser uses Pixi.js for all its rendering.) And given that, it seems unlikely that it would be integrated any time soon because of the API differences between FastCanvas and Canvas itself. However, if you, @BobDylan, or anyone else wanted to start work on this, looking Phaser.Canvas is the best place to start. Changing how Phaser creates a canvas and then checking what errors happen afterwards would give you a great starting place to seeing which functions need to be changed and where.
  10. @Binary Moon: Phaser (2.1) should now detect CocoonJS.App and the 'onSuspended' and 'onActivated' events.
  11. Something we might have to do is watch CocoonJS.App.onSuspended and CocoonJS.App.onActivated as part of that same checkVisibilitityChange() function within game.stage. However, before we can do that, someone probably needs to put a check within the Phaser.Device code for the global variable CocoonJS.App. (And there's a conversation to be had if the current check is enough, or if it should be combined or separated into two different checks: one for the CocoonJS environment and another for if CocoonJS.App exists.)
  12. Have you looked under "Scaling" on the issues thread? I've been trying to collect and post solutions others come up with for dealing with scaling in CocoonJS there. From that, my first suggestion would be to use window.innerWidth and window.innerHeight to make sure you are scaling up or within the full CocoonJS reported space. Many people have also reported that Phaser's scaling manager using EXACT_FIT works well for them too.
  13. It's definitely got problems. There's no getting around that. However, looking at Phaser's compatibility with other hybrid app frameworks like Cordova/PhoneGap and Crosswalk right now, it's pretty much on par with everything else. You take on some risk using any of them. And they all come with their own issues and quirks to be aware of.
  14. That's a great point. I should have wrote something about that too. While CocoonJS is free as of this writing, they could change their mind at some future date. That's a potential risk to be aware of with going with them. In fact, it's also, to a smaller degree anyway, a risk with going with PhoneGap too. Adobe (which now owns the brand) could decide to charge when using its remote compiling functionality at some future point as well. It's part of the reason, without completely going off track here, why I've moved over to Apache Cordova and have started to work on patches for that in the last couple of weeks. Because it is part of the Apache foundation, it will always be free. It might be slower than CocoonJS sometimes, but the code will always be open for anyone to read or contribute updates. (Full warning: As of the writing, Cordova patches for Phaser have been slow. It's going to take some time before full compatibility.)
  15. Believe me, I'm right there with you about bemoaning mobile browsers and Phaser compatibility. No matter how far we seem to come with patches for CocoonJS -- and more recently Apache Cordova -- we'll always tied to the platform's code and hardware. If it's terrible, our project's run terrible. Not a whole lot we can do about it. It's not much of a consolation right now, but we (Phaser) have come a very long way toward being able to run on these platforms at all this year. I can remember back in early February when there was very little mobile platform detection and CocoonJS was completely broken with Phaser. Now, more or less six months later, Phaser can detect all major hybrid app frameworks and has a number of optimizations for things like CocoonJS. As you wrote, sometimes it is a matter of waiting out the patches and software updates. That's good to read. I'm glad you were able to find a work-able solution, even if it doesn't sound all that great overall. If you end up using CocoonJS and happen to come across new solutions (or problems) please feel free to post in that Common Issues thread. Even if I have personally stepped away from CocoonJS some more recently, there are a number of developers who do post in that thread on a fairly regular basis who are actively using CocoonJS. (We are also in somewhat of a holding pattern until a new version of Phaser or CocoonJS comes out to start new testing too.)