• Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Videlais

  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. but if i don't need anything of the cordova api stuff..  no camera, vibration and so on..  what can cordova.js do for me.. is phaser in someway optimized for cordova - will it run faster?


    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.


    What changes do I have to do in order to wait for the deviceReady?


    (@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.

  3. Unrelated to the ogg issue, but I have to admit I found Ashley's latest post on the Scirra site fascinating. He's basically saying there is no need for Cocoon on iOS8 any more, and that actually PhoneGap will outperform it as soon as they move to WKWebView. As a result they deprecated the Cocoon exporter. Given the weird amount of hacks you're all having to use for Cocoon and the lack of assistance from Ludei I'm thinking that might not be a bad practise to follow.


    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.

  4. Videlais: So should I write some variable and then multiply every sprite and position? And then use innerWidth and innerHeight to scale game?


    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.

  5. I thought this code scale everything just like when you used Appgyver Steroids or Phonegap.


    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.


    I don't know what that code should do. Some game elements are on fixed position. Should I give every sprite not absolute, but relative position? Does every sprite expand, too?


    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.

  6. To fix the button issue I created a weird hack that involves adding a tiny transparent image after everything else in the scene. Not sure why this works, but it stops everything from hiding randomly. 


    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.)

  7. 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.

  8. 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.)

  9. 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.

  10. The message I'm getting from this thread is: "Don't use CocoonJS."


    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.

  11. I believe CocoonJS is indeed free right now, but they have plans to add pricing later on. Unfortunately they are not upfront about it and the links they posted about it are no longer working.


    Again, my bad, CocoonJs is not expensive (for now).


    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.)

  12. I'm still not saying that Phaser would be the problem here - I understand what you're saying about Samsung, and I found interesting and very depressing comments about Android's WebView in general . . . I'm extremely surprised and disappointed that Google could have let this happen. Whatever the reason is, Phaser and these common devices together produce unacceptably poor performance.

    However, the bright side is that the CocoonJS demos packaged with the launcher run extremely smoothly on the same device, I couldn't distinguish it from native even if I tried. This means that somehow, despite all the limitations, it indeed IS possible to create a smooth experience with HTML5 and these poor performing devices.


    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.


    Indeed even the CocoonJS launcher's showcase demos are chopping on these Samsung devices (good example: "Sprites 2" with adding animated fish), but ONLY for the first 10-20 seconds, and especially the first few. Since my Phaser example tween was only 20 seconds long and begun immediately, it was affected by this and I didn't see the problem ending. When I chained a bunch of new tweens totalling to a minute or so, there was no problem after the beginning anymore. Once my game is complete with menus etc, I doubt this will be a problem at all.

    Faith in technology and HTML5 development restored. :)


    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.)

  13. I'm surprised I can't find threads about Phaser development for Android and it's horrible performance. Generally the result of my googling is that making HTML5 games for Android is way worse than making Internet Explorer 6 hacks for websites was before. It looks like Phaser and probably most other frameworks are more or less unusable with it, so this is a huge issue.


    "Unusable" is a pretty strong word for Phaser on Android right now. It's definitely usable, but it's usability is often dictated by a number of other factors that are usually outside the Phaser community's control.


    The chief among those is the Samsung GPU code -- see here -- on its devices. It's just not good and can often cause problems, as @Str1ngS points out too.


    Another is compatibility with CocoonJS, which has had a number of ups and downs over the last several months. (Some problems should be fixed in 2.1, assuming the next version of CocoonJS doesn't change too many things.)


    I'm early in development of a game, and after my tests I've noticed it's lagging on Android even with the simplest possible tween for one sprite across the screen (code attached). This applies both to the native Android browser and using CocoonJS with Canvas+, my test device is Galaxy Tab 3. CocoonJS claims the fps to be over 60, but in reality there's the occasional chop in movement every few seconds. On Android's Chrome browser it's ok, but obviously that's not enough. If I use the moveToXY function instead of tweens, it's closer to acceptable, but still far from perfect.

    Any of the tips provided in the long and pinned CocoonJS thread don't seem to apply to this case, since I suppose it's more about Android than anything else. I'm very interested in hearing people's thoughts about this, have you made not-laggy games for Android with Phaser, and if, how on earth did you succeed?


    I'm sorry you weren't able to get any help out of the CocoonJS thread. I do generally test on a number of devices, including both iOS, Android, and even Ouya on occasion.


    As for the lagging, the somewhat obvious questions come to mind: how much is too much for you? Are you seeing drops as low as 10-20 FPS? Or is it dropping into the 50s FPS sometimes? If it is lagging a great deal, you might look at optimizing your code. Certain functionality like extra render and debugging calls can really slow down mobile device. Sometimes, getting rid of just a single extra draw call can improve performance a great deal.


    Finally, getting constant 60 FPS all the time just might not be do-able for your project. Depending on how much you are drawing, you could be taxing the device too much. Many devices cannot handle strenuous loads on their GPUs and will deliver lower performance.


    Obviously, I'm writing about more than just that code you listed, but those are pretty common problems you might want to look out for in the future as you proceed as well.

  14. There are a handful of different options.


    CocoonJS -- which is not "extremely expensive" -- is one used by a good number of Phaser developers. However, as detailed here, it does come with some issues.


    PhoneGap is another one, although it too has some problems at the moment. (See Cordova*)


    Crosswalk is a project from Intel that reports to work well with Android and Tizen.


    Apache Cordova is the open source engine behind both PhoneGap and CocoonJS's command-line tools. However, Phaser only has the minimum detection for it as of this writing and playing sounds requires some extra work. (See this thread for what to look out for when using it.)

  15. I'll echo what @kidos wrote: there is no best answer. The thread you found is a great start. So too is the solution kidos links to as well. And I'll even add in the section under Scaling in the thread "Common Phaser + CocoonJS Issues" as something to think about.


    Trying to target ALL touch devices is probably not a good idea. It means trying to account for all manner of strange screen sizes and resolutions. It can also mean a great deal of testing on alternative devices and platforms.


    It might be worth it to just target a single platform (Windows, iOS, Android, BlackBerry, Kindle) and a range of versions instead to optimize the experience for those users.

  16. My problem is how to embed phonegap audio code inside phaser play state which have animations, audio for each animation. It like how to get 2 different codes work together, an example like that.


    I don't know of any tutorial or example for that, unfortunately.


    I've started looking at ways it might be possible to write a patch to add in Cordova.Media support into Phaser's existing Loader and Audio objects, but haven't made too much progress yet. Because Cordova.Media doesn't conform to the W3C specification, I've been researching ways to either add some conditional loading or just write a plugin for Phaser that overwrites the audio object as Media.

  17. Last update of this information was 22 August 2014.


    In the hope of collecting together the great wisdom of the Phaser community, I am creating this thread dedicated collecting the issues -- not unlike the CocoonJS thread of similar naming -- between Phaser and Apache Cordova.


    [For the most part, these solutions work with PhoneGap too. However, at the moment anyway, I'm more interested in addressing the underlying system of both: Cordova.]


    How does Cordova work?


    When run on a device, Cordova creates a WebView, adds in API hooks, and loads the project via the FILE protocol. Put basically, it is like running your HTML5 project in a separate instance of the device's browser. However, unlike the device's browser, Cordova has the ability to be extended and granted access to additional functionality like the device's camera, geolocation data, or even barcode scanning through its plugins.


    Do I need cordova.js?




    While it is true that you can run projects without this file, it sets up useful Cordova functionality and populates the window.cordova object with system details. Without it, Phaser will not be able to detect it is running under Apache Cordova.


    Using --

    <head>...<script src="cordova.js"></script>...</head>

    -- will often be enough to load the script during run-time. (The file itself is added to the project during compilation or as part of established IDE functionality.)


    What's this 'deviceready' event? [This is now part of Phaser 2.1]


    Cordova was created to run on different devices with different requirements. One way to generalize all the required runtime tasks was to send a signal when everything Cordova-related was ready. That's what the 'deviceready' event is. Once it is sent, everything that was supposed to be loaded or created by Cordova (such as plugins) should now be ready.


    For Phaser projects that will use any Cordova plugins, it is highly recommended to wait for this event to trigger before enabling any code.


    For example, creating a function to load your game would look something like the following --

    document.addEventListener('deviceready', loadGameFunction);

    -- where loadGameFunction is a function to load your game or enable certain functionality for Phaser to use.



    Common Issues



    Scaled Viewport Size


    For devices not running iOS, the following line can be added to the <HEAD> of the HTML file to create a viewport and scale up to the size of the device's screen.

    <meta name="viewport" content="user-scalable=no, initial-scale=1, maximum-scale=1, minimum-scale=1, width=device-width, height=device-height, target-densitydpi=device-dpi" />

    For iOS devices, drop the "width=device-width, height=device-height".




    To enable media playback, you will need to add the Cordova.Media plugin.


    Once loaded, audio objects will need to be created manually using the Media object.

    var media = new Media(src, mediaSuccess, [mediaError], [mediaStatus]);

    [Hopefully, a patch or plugin to detect and use this functionality automatically will make its way into Phaser in the near future.]




    Using console.log will send messages to CordovaLog.

    • Android
      If using an IDE, it will often filter ADB logcat for the specifically named project activity. However, if using the command-line interface or if not filtered directly, using programs like grep or find can help narrowing down Cordova messages. Examples of this would be something like "adb logcat | grep CordovaLog" to filter for log messages from Cordova, including those sent using console.log.


    The 'Back' button


    On those devices that have a 'back' button or similar functionality, it is currently possible to exit a Phaser project run in Cordova by pressing or triggering it twice quickly.


    To prevent this action, you need to catch the event with code like the following:

    document.addEventListener("backbutton", yourCallbackFunction, false);

    See the Cordova documentation for greater details.


    'Pause' and 'Resume' events


    Whenever a Cordova instance is pushed to the background on a device, the 'pause' event is triggered. When it again is at the fore, the 'resume' event is triggered.


    Unless these events are caught by an event listener, the default action for Cordova is to completely reload the page upon the 'resume' event, potentially erasing the states and values of all active variables.


    To prevent this action, you need to catch both events and handle them somehow.

    document.addEventListener("pause", yourCallbackFunction, false);
    document.addEventListener("resume", yourCallbackFunction, false);

    See the Cordova documentation on 'pause' and 'resume'

  18. As with the thread @JP91 links to, you will need the Media plugin for Cordova/PhoneGap to play audio files.


    Instructions for installing and using it can be found on its GitHub page. (In the last couple of days, I've also started to patch Phaser for greater Cordova/PhoneGap support too. Greater compatibility is coming.)


    As for CocoonJS (and ultimately the Media plugin as well), you need to check file formats. Certain devices will only play certain types. In most cases, WAV is universally playable; OGG for Android and MP4 for iOS. (We keep track of the CocoonsJS-specific issues in this thread to help people out with that library.)

  19. Has anyone else had this issue? While loading our game in the more powerful WebGL through CocconJS we get 4 errors that I can't seem to explain.


    Well, the first question I have is to ask how you are loading your game. Are you using the URL or ZIP approach? Have you tried both? (I've had problems with the URL method in the past, so I always use ZIP now.)


    Keep in mind it still runs in slower canvas mode but we wont be able to get ads/leaderboards/acheivements I believe.


    Neither Phaser.CANVAS nor Phaser.WEBGL have any effect on CocoonJS functionality. The only thing that does is using Canvas+ or WebView+ modes (with CocoonJS files loaded) or not.


    If you are running Phaser.WEBGL in CocoonJS, I'm curious about how that is working for you. Most people have had problems with it in the past and I usually tell people to avoid it when possible.

  20. The cloud-compiled launcher has WebGL enabled and it cannot be disabled. But you can explicitly instruct Phaser to use canvas by . . . . but maybe that causes the problem I described previously.


    Yeah, it's been that way since February when I started working with CocoonJS. The only easy way to disable WebGL completely is through the launcher itself.


    Using Phaser.CANVAS doesn't really solve the problem, unfortunately. It prevents the far worse errors when explicitly using Phaser.WEBGL, but WebGL is still triggered by this line. (It's why the 2.1 version now turns off 'screencanvas', but also seems to introduce new problems.)


    Something both me and some others have tried, though, is taking that line out completely or disabling the check for WebGL in Phaser and then re-building the library. It will force Canvas and should work fairly well, but isn't really a workable solution for Phaser. (There was a good conversation about this back in May-June.)


    Somewhere I've read that you must convert your sound files to 16-bit waves in order to work properly with CocoonJS (it's not a Phaser issue). The file you showed us is 24 bit, so I'm almost certain that's the problem.


    Could you find that source for me? I confirmed 24-bit WAV files produce noise under the 2.0.2 iOS launcher, but won't be able to test on Android until much later today. Having a source to point at would be hopeful when updating the top post again, though.