• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Videlais

  1. Yeah, but there are still some problems, unfortunately. When I was testing it yesterday, the first version I tried worked, so I reported that back to them. However, when I tried a new version after that, it didn't work anymore. (Changing the Android versions helps to install the Launcher, but the Ouya intent settings aren't there anymore sometimes -- it doesn't register as a valid 'app' on Ouya.) As soon as this is cleared up, I'm going to post a guide on getting HTML5 projects running under CocoonJS on the Ouya. I started writing it last week and have all the screenshots -- the steps themselves haven't changed since February -- but am waiting till I know it will reliably run and show up correctly.
  2. Ezelia is absolutely right that, in most cases, the issues are with some variation of the code and the system, not Phaser itself. However, many of those errors read as if CocoonJS itself is not loading correctly. I also highly recommend you use their Compile Launcher for testing first, before using their cloud compiler. It's available on the iTunes store and GooglePlay store. This will allow you to test things yourself instead of waiting on the 20+ minute e-mail with your changes each time. (You can also, under the 'Android' section for a project, pick different SDK versions to target too. If you want a Compiler Launcher for an earlier Android version, that is the best way.) I've also been tracking issues between CocoonJS and Phaser for months now. Be sure to look at this list. It gets updated as I receive or read about issues or solutions. (You can also report things in that thread too.)
  3. This thread is usually the one most people start with when trying to scale projects and games using Phaser. There is also the documentation on using ScaleManager itself too. And an example on scaling a sprite. There is no easy answer to this. Depending on your needs and willingness to try different services, putting HTML5 games on different app stores can be very complicated. Some services to explore are PhoneGap, Cordova, and CocoonJS. However, each come with their own problems and issues.
  4. Have you looked at ScaleManager? It is accessed through the game's scale object. This thread also covers different ways people are using it. game.stage.scaleMode = Phaser.StageScaleMode.SHOW_ALL;game.stage.scale.setShowAll();game.stage.scale.refresh();There is also an alternative, although not recommended, way of using CSS to force the browser to use its full, available dimensions. canvas { position: absolute; top: 0px; left: 0px; width: 100%; height: 100%;}
  5. Videlais

    Sprite layering

    bringToTop would work, so would checking the original draw ordering. If certain things need to be 'behind' of other objects, create (game.add) them first. The drawing order, unless changed by bringToTop, works from the order they were created. Often, it can be enough to make the player-controlled object to be the last game.add in order and 'on top' of the other drawn items.
  6. Hi, gbachik. Generally, you can use the following: var game = new Phaser.Game(window.innerWidth, window.innerHeight, Phaser.CANVAS, '', {preload: preload, create: create, update: update});CocoonJS reports the size of the screen through its window.innerWidth/Height. I also highly recommend reading through this list of common issues between Phaser and CocoonJS. It covers all of the reported problems we are currently aware of.
  7. Okay. Thank you for the detailed response. I'll add it to the known issue thread.
  8. That's my current working theory, actually. It has to do with the last item, be it a group, sprite, or something else, that is not getting drawn. The empty, default image is adding an extra object to the rendering group that is not being drawn, but is adding to the total number of objects. What is even stranger is that the total number is correct, though. And by-passing Phaser's normal creation functions works too. I had a recent test that created pure Pixi.js objects and injected them into Phaser. They were drawn but mostly covered up.
  9. Yes. In most cases, it is more efficient to take the memory cost up front when possible. Have you looked at Group.enableBody? Or Group.physicsBodyType? You should be able to use one of those when creating a new group to enable physics bodies before adding the group to a larger group. What you might want to do to handle only some subset is forEachAlive or forEachDead and, for the third parameter, send in the exact number to work on, exiting the loop when it is reached. That's usually the suggested way, yes. The one you showed. Like in this example. If you really want to work on a lower level, you can still call lineTo from the game's drawing context. You will need to call moveTo, lineTo, and stroke manually each time to do it, though.
  10. What version of CocoonJS are you using? 1.4.7 or 2.0? And which mode, Accelerated Canvas or System WebView for 1.4.7, or Canvas+, WebView+, or System WebView with 2.0? And what version of Phaser are you using? The 1.X or the 2.0.X branch? This problem might be related to another image issue we know of and I want to make sure it is not something new.
  11. For the browser, is that the desktop browser, or the one on the device? For example, does it work in both Chrome on the desktop and Chrome on the Android phone/device too? Also, what mode are you using for CocoonJS 2.0? Canvas+, WebView+ or System WebView?
  12. While it is a bit in the future for Phaser according to the roadmap, I did notice this same problem using node-webkit with Phaser recently. With a large number of sprites (like a huge tilemap, for example), the garbage collection became so severe the game was unplayable.
  13. Well, if you want to keep the sprite.body.x/y += 32 code, you could use something like this example. Then, combine the checkOverlap with TilemapLayer.getTiles and Tile.intersects or checking its Tile.index. (If your colliding tiles are a separate layer, intersects would work, otherwise testing for its index would be a better fit.) Within the update loop, check for input. For that direction, move a fully transparent sprite 32 pixels in that direction. Run the checkOverlap test. If it passes (returns false), move the actual sprite in that direction 32 pixels. If it fails (returns true), reset the fully transparent sprite to the same position as the real sprite and don't move. I'm not sure how useful this analogy will be, but I think about in terms of navigating a two-dimensional matrix. From wherever you are, if you want to move in a new direction, you need to test the new x and y position of that direction. For 'up', that is y - 1. For 'left', that's x - 1. (Or, in this case, 32 pixels instead of just one unit.) If you don't plan on using the physics system for velocity or other calculations, you could just use overlap-checking functions. One set of checks for the group of player sprites and another for the players against the tilemap.
  14. Yeah, CocoonJS 2.0 is targeting Android 4.4 (API level 19) exclusively. Any system version less than that won't be able to install the newer launcher or any compiled projects using CocoonJS 2.0. (I've already filed a bug report about this with them.) You should still be able to build with CocoonJS 1.4.7 from the Ludei project page, though. While their launcher in the GooglePlay store is the newer, 2.0 version, you can still create one using their 1.4.7 version by creating a developer account, creating a project, and requesting a 1.4.7 compiled project or launcher. However, you will need to side-load this older version yourself.
  15. Just a heads-up: I just filed a bug report with Ludei over the sdkTarget and maxSdkTarget for CocoonJS 2.0 Android projects. They are currently exclusively targeting API level 19 and all devices (including the Ouya) not running Android 4.4 are incompatible with both the launcher and all currently compiled projects because of it. Until they either fix this or update their iOS client through the iTunes store, I'm not going to be able to test anything with CocoonJS 2.0 for awhile. However, I will continue to track reported issues. I just won't be able to confirm them from my end.
  16. A couple of things you should be aware of for CocoonJS and Ouya: As of this writing, the difficulty of selling a CocoonJS-wrapped HTML5 project on the Ouya is very high. I got very close a couple of weeks ago and then learned that in-app purchases (IAP) don't work with the Ouya marketplace and CocoonJS. Until the 'choice' is in place, IAP is the only way to sell apps on the Ouya right now. CocoonJS doesn't, as far as I've been told, plan to support the X.509 certificate decoding needed for Ouya's IAP API. In other words, we all have to either wait for the Ouya marketplace change in the 'coming weeks' or, if there is significant interest, work on a JavaScript solution. (I'm all for working on a JS solution, by the way, and have a headstart on some code even, but am in a wait-and-see mode with CocoonJS 2.0.) Bonus: You didn't write you were going to use Phaser, but there are lots of problems with Phaser and CocoonJS 1.4.7 right now. We are all waiting to test things with CocoonJS 2.0 and see if anything has changed. Yes, they will. I've done significant testing using this way. When used with something to wrap them like PhoneGap or CocoonJS, that is. The way Cordova works -- that's the underlining technology behind PhoneGap and even CocoonJS -- is that it acts like a local server and a browser combined. Things like XHR are routed to the native system as file requests and it then renders the pages. CocoonJS (1.4.7) especially uses the native platform's API to render things for its WebView mode. So, that's Safari for iOS and Chrome for Android. As mentioned above, you just ZIP up your files, send them to Ludei, and they e-mail you a link, usually, 15 - 20 minutes later with the compiled files for whatever system you picked. However, for testing, you actually want to use their Compile Launcher. It's available on the iTunes store and GooglePlay store. This will allow you to test things yourself (which I highly recommend) instead of waiting on the 20+ minute e-mail with your changes each time.
  17. I was answering your original question about moving only 32 pixels at a time. That is how you do that, by moving an exact, fixed amount each time. You are right that collisions won't work with this method. The problem is that the various physics systems in Phaser work off of velocity. They need to know the amount of movement (velocity or similar calculation) in order to separate the objects upon detecting collision. Moving the sprite's bodies directly does not involve velocity and will not trigger collisions usually. r00's solution reads as if it might work, though. Before each move, testing to see if the sprite.width/height + 32 would trigger an overlap with specific tiles in the tilemap and, if not, calling the animation/tween and making the move. Instead of 'Arcade' physics, you might have success using one of the other two systems as well. P2 uses a different, unit-based movement system, for example. If you didn't use gravity, you could have your players move around the world in something approximating 32 pixels. Maybe even something like the tilemap demo? It would be changing your code for a different physics system, but it might be closer to your total solution than my own first suggestion.
  18. @rodrigogrow: Sorry about that. I haven't updated the code recently to fix problems like that. Unfortunately, I'm now waiting to see what CocoonJS 2.0 offers and if my library is even needed. Until I get a chance to update it with 2.0 information, this thread is the most accurate as of this writing. (It suggests, as I do until my library is fixed, that you use either RetroFonts or the alternative JSON loader another post details.)
  19. This is probably not going to work. CocoonJS acts like a browser. While it would probably understand most of the JavaScript involved, it does not have the same internal API as Node.js does. Things like require() don't exist natively in it and it wouldn't know to load the necessary node modules to get everything working correctly. However, that doesn't mean you couldn't change things or even use something like Browserify to build all the browser dependencies for you. You would just have to aim at making things work as if you were going to use Chrome or Firefox instead of server-side development.
  20. I think you are right. I got about that far in my own more recent testing and updated the wording on the top post to read "rendering" instead of loading. We aren't sure. Well, I should clarify that *I'm* not sure, myself. I have had several e-mail conversations with different people (including Rich himself) over the last couple of weeks and we couldn't seem to easily narrow down the problem. With CocoonJS 2.0 coming out today, though, I'm going to start a new round of testing and see if the same problems exist as soon as I get the chance.
  21. @ChuckLeone: I was going to write up the instructions today for getting CocoonJS 1.4.7 working on the Ouya as a blog post, but I just got the e-mail that version 2.0 is out. If you really want to use 1.4.7 (which has many problems with Phaser and especially with gamepads themselves), send me a direct message and I would be happy to reply back with the instructions. Otherwise, if you don't mind waiting a few days, I'm going to need to test CocoonJS 2.0 now, see what it offers, and if the old problems still exist.
  22. Videlais

    Device detection

    Adding on to what @Starboar wrote, have you tried something like the following? var width = window.innerWidth * window.devicePixelRatio;var height = window.innerHeight * window.devicePixelRatio;It would detect the full available width and height, as Starboar wrote, and take into account the devicePixelRatio too. Of course, this also introduces the problem of scaling your assets according to the game world. This thread covers some different techniques other people have been using for that. But, basically, it is playing around with game.stage.scale options and finding one that matches your project's needs.
  23. Yeah, that will happen. It's exactly as you wrote: it will be called twice if you also make your own call to player.update() too. A couple thoughts: How about just changing the name of the update function on player? Maybe something like "updatePhysics?" That way, your player object would update its internal Phaser.Sprite bits automatically, you could run the collision checks, and then do the movement/key checks after by calling something like "updatePhysics" from player at the end of game's own update().Without using player.update(), you could encapsulate some of the movement as separate functions within player and just do the key checking from game. Call things like moveLeft() or moveRight(). It isn't a full encapsulation answer, but it would allow you to do additional things for types of movement if you wanted.
  24. Nope. But its computed size can often not be a power-of-two, sometimes. This can be a hidden problem for WebGL projects. For the NPOT issue, all images themselves must have their dimensions be powers-of-two as well. Anything loaded must be in those pixel sizes I listed. Maybe? Check all the obvious things like sound volume (browsers often have lower sound levels) and the audio files loaded. Is this just a different computer, or a different browser too? Some browsers can't load certain audio formats for licensing reasons. Check the console to see if there were any problems for that. Also check the most obvious thing too: does that computer even play sounds? Is it connected to speakers somehow?
  25. What I think might be happening is the values are being saved across sessions. Exactly. That's what can be so frustrating about testing with localStorage. It retains the values across sessions and even after the browser is closed too. Something to try, like I ended up doing myself, is using store.clear() once every test to make sure nothing is being saved between one test to another. That can often save you from having old values saved when you don't want them to be.