Jump to content

Videlais

Members
  • Content Count

    170
  • Joined

  • Last visited

  • Days Won

    1

Videlais last won the day on August 31 2014

Videlais had the most liked content!

About Videlais

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    http://videlais.com
  • Twitter
    videlais

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2432 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
  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.co
  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. Tho
  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 bu
  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
  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 l
  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 br
×
×
  • Create New...