Videlais

Members
  • Content Count

    170
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Videlais

  1. Not necessarily. You can add something like a 'triggerBox' property that is a Phaser.Rectangle and use that instead. var spriteA = this.game.add.sprite(0,0, cacheKey);spriteA.triggerBox = new Phaser.Rectangle(x, y, width, height);var spriteB = this.game.add.sprite(0,0, cacheKey);And then, to check, something like the following: if(spriteA.triggerBox.intersects(spriteB.getBounds())) { // spriteB overlaps spriteA.triggerBox's rectangle}
  2. nunziox, can you post some code or provide a link to the project? It is very hard to help you try to fix this without knowing what exactly is going on in the code.
  3. Hi, mraak. Yes, audio should work with all browsers. Testing using the URL Rocco posted should help troubleshoot. So should testing using the Phaser example of 'Play Music' too.
  4. Hi, titmael. Have you look at the Phaser examples? Specifically, have you looked at the 'Overlap Without Physics' example? You can create a new Phaser.Rectangle object and use its functions to check for overlap and if a certain set of coordinates are within that rectangle. Worst case, you can do the math yourself, checking if some coordinates are within a calculated circle too.
  5. Oh, believe me, I know how you feel about the disappointment. I started around late January on this integration too and had come pretty far -- writing a Ouya gamepad plugin, XML parser for CocoonJS, and solving many of those other original problems myself -- before the images broke in the 2.0 upgrade of both Phaser and CocoonJS several weeks ago. (If anyone is curious, I also wrote patches to add in basic text support for both Pixi.js and Phaser.js. The pull requests date two months ago.) The larger problem with most of this is that there just isn't that much interest in solving things as they come up. Many of us are reporting issues with either Phaser or Ludei, but as I know from having done the hard work myself, it often takes a great deal of time to track done the specific line and then come up with a check or hack to get around it. In every case I've personally solved with the integration between Phaser and CocoonJS, it has always been a matter of walking through the tens of thousands of lines of code manually, checking the calculations or output of different functions, and then reverse engineering where something is going wrong. But, anyway, on to the most recent audio issue... I did some audio testing today myself with Phaser and CocoonJS. (Test is here. And ZIP test file is here.) Using OGG with fallback to MP4 and MP3, I was able to play the audio successfully in Android in CocoonJS 1.4.7 and 2.0 using Accelerated Canvas/Canvas+ modes. In iOS 7.1.1, it worked as expected in Accelerated Canvas and in System WebView with CocoonJS 2.0. As Starnut pointed out, you do have to tap to start the audio, though. (And I updated the top post to reflect this on 10 May.) So, I'm of the opinion that there doesn't seem to be any current audio issues between Phaser and CocoonJS. Well, other than needing certain file formats per platform.
  6. Hey, everyone. Sorry I've been so slow to answer lately. As you might imagine from the timestamps on my early posts for this stuff, I've been fighting against -- and, yes, sometimes with -- CocoonJS for several months now. I decided pretty recently to just take a break from all things CocoonJS for a little awhile. First, though, thank you, @Starnut, for doing that work. As you wrote, and I confirmed on Ludei's site, CocoonJS does not support M4A at the moment. Under the "Audio" section for 1.4.7, they list “audio/wav”, “audio/x-wav”, and “audio/ogg” for Android. For iOS, they say “audio/mpeg”, “audio/mp4”, “audio/mp3”, “audio/x-wav”, and “audio/ogg”. (I double-checked what I initially wrote back in February and it is still correct. For Android, that's WAV and OGG. For iOS, that's MP4, OGG, MP3, and MPEG.) I was also happy to read that turning off WebGL fixed things in the Launcher. That's good to know. But, of course, as I expected with that too, you can't yet turn off the option for cloud compiled projects. (If we don't get a response back for over a week for that question, @Starnut, I'll send it along to some contacts I have at Ludei and ask them about it. That's no guarantee that they will add the option any time soon, but I could probably get an official answer that way.) (To give some perspective on the image issue between Phaser 2.0.X and CocoonJS 2.0: both parties have been aware of it since a few days after it started many weeks ago. From my own communication with Rich and my contact at Ludei, neither was sure what was causing it. So, it would be nice if it could be temporarily resolved by simply disabling WebGL. But, on the other hand, I'd much prefer to figure out the root cause and fix that at some point.)
  7. As somewhat of a non-answer, I'll write that it depends entirely on what you trying to simulate or model. It might make more sense to have a body (group) composed of parts (sprites) if they are similar in nature. However, it could also make sense to have a single unit, the body (sprite), and some extra parts (like a sword or gun) be part of the unit but their own sprites too for separate animation or collision purposes. JavaScript allows you to bind new properties at nearly any time. You are allowed to give sprites groups. And Groups can both contain and have sprites too. For example, in the following code I copied from a project of mine, I give all Soldiers a 'bulletGroup' that contains all of their bullets. In my model, it makes sense that Soliders have their own bullets function Soldier(game, x, y, cacheKey) { Phaser.Sprite.call(this, game, x, y, cacheKey); this.game.physics.enable(this); this.bulletGroup = this.game.add.group(); this.bulletGroup.enableBody = true; this.bulletGroup.physicsBodyType = Phaser.Physics.ARCADE; this.bulletGroup.createMultiple(13, 'enemyBullet'); this.bulletGroup.setAll('checkWorldBounds', true); this.bulletGroup.setAll('outOfBoundsKill', true); ... }Soldier.prototype = Object.create(Phaser.Sprite.prototype);Soldier.prototype.constructor = Soldier;However, I can also see the case for creating a 'spawner' object that had certain properties that was an object that extended Phaser.Group. Maybe it spawns but contains some other objects. function Spawner(game, squad) { Phaser.Group.call(this, game);};Spawner.prototype = Object.create(Phaser.Group.prototype);Spawner.prototype.constructor = Spawner;Spawner.prototype.update = function() { // Call the super.update() first Phaser.Group.prototype.update.call(this); // Do you own stuff};One of the advantages Phaser.Group has is its setAll, callAll, and forEach (family) of functions. Groups are designed to iterate over the items within them.
  8. Looking at the code on GitHub, it should just be a matter of calling -- $yo phaser-official:prefab "prefabName" -- with the name of the Phaser.Sprite subclass you want to use. Alternatively, you can define your class in a file and then call require() on it. (Using Node.js + grunt to create it.) Everything runs within the function scope it is created within in JavaScript too. If a class was instantiated within the window.onload function, and existed before the calls to game.state.add, all of the states could reference it. So, if you wanted global classes (singletons), either its class definition or an instance of it needs to exist before any code that references it is called. For example, something like the following: window.onload = function () { var game = new Phaser.Game(800, 480, Phaser.AUTO, 'phaser-sandwich-test'); var TCustomer = require('./states/TCustomer'); var TSaveManager = require('./states/TSaveManager'); var TWindow = require('./states/TWindow'); // Game States game.state.add('boot', require('./states/boot')); game.state.add('globals', require('./states/globals')); game.state.add('menu', require('./states/menu')); game.state.add('play', require('./states/play')); game.state.add('preload', require('./states/preload')); game.state.start('boot');};
  9. I've fought against this problem for a long time now. I tried, as I saw you did in the past too, valueerror, to use Tweens to move sprites using its 'body.velocity' for movement. A solution that works... until it doesn't. (For other people, you can, in fact, tween body.velocity. However, the problem becomes in resetting the velocity or reversing it. Moving objects have inertia and there isn't a clean solution to resetting the velocity of a moving object and setting a new one -- even with a tween -- without messing up collisions during that interim time.) What I eventually settled on doing was creating subclasses of Phaser.Sprite whose sole purpose were to act as elevators (up and down) or conveyors (side to side). Here is my example code: VerticalHorizontalHowever, there is still a problem with this approach. Occasionally, the sprites will 'stick' before moving again. It's 99% of what I want and have messed around with it a few times to figure out that last little problem, but am not sure exactly what is causing it in the first place. Oh, and those two examples are using the Arcade physics system. It shouldn't be too hard to port them to P2, though.
  10. So, this may be obvious, but have you run a console.log on tileGroup within the anonymous function called by forEach? What does that show? Is it actually the group it should be? Without more code to reference, my guess is that the function scope is getting mixed up somehow. If 'this.tiles' is a Phaser.Group, that should run correctly. Well, 'tileGroup' should not be undefined, anyway. I can't really verify the others parts.
  11. With the risk of diving into a lesson on JavaScript objects and the prototype chain, I've found a lot of the frustration people coming to JavaScript from other OOP languages have is that JavaScript isn't a typed language. That's the root of most of the issues between, say, coming to JS from Java, for example. Because JavaScript isn't a typed language, you can bind properties to nearly any object at any time. There are very few restrictions on that. JavaScript also borrows from some Functional Language aspects in how it handles execution scope too. A lot of its "weirdness" comes from how it binds the function scope of its this. Depending on the calling context, a function's this can be different things and still work correctly. As for the prototype property of objects, it might be helpful to know that, like in Java, all JavaScript objects inherit from Object too. However, the way inheritance works in JavaScript is that all objects created from another, preexisting object inherit all of its prototype properties too. Any object created through a constructor has all the prototype properties (including its functions) of its superclass. For example, unless the prototype.constructor property is overwritten on an object, it is an instance of Object in JavaScript (similar to how everything is based Java's Object class in that language). (It might be confusing to read now, but I've recently put together a crash course on my blog that covers JavaScript objects, classical inheritance in the language, and how to create hybrid classes.)
  12. Yeah, I totally agree with george. If you are going to be using classes (or anything with an inheritance structure), it is best to learn how the prototype property of objects works and when to use it. That can save you a great deal of code writing for larger projects. Trying to write object literals of everything would just be a waste of time in many cases. As for game states specifically, I agree with both sleekdigital and george. Since new instances of an object have all previously prototype properties defined for that object, it can make sense to define how, for example, a menu works once and then have subclasses only change simple settings. That could save you some time and lines of code, definitely. (However, like george, I rarely use this approach myself.) On the other hand, the disadvantage for associating all game objects to a specific state is that you can't easily use them outside of that scope without making a new reference. And switching between states is destructive too. Keep in mind that moving between a 'menu' and 'game' state means that all objects bound to the 'menu' state's 'this' scope will be wiped out. So, if we are talking about combining different patterns, I personally use a module pattern on a global level, creating a function closure and passing in the 'Phaser' object. Then, for my own sprites, I make subclasses of Phaser.Sprite and use a prototype pattern for the states themselves. That way, I can have a singleton instance of a player object existing outside of any one state and then move (update its coordinates) between states. (This is more useful when I map states to different levels. Each state's change is a level load.) However, as george wrote, which pattern to use is often dictated by how comfortable you are with JavaScript's prototype property. And generally what problem you are trying to solve too. All the different patterns are to solve different problems. Some can be used as solutions to the same issues, but not always. Or not without some knowledge of how they work in the first place and why they happen to solve a certain problem.
  13. Hi, mapsmaps. I've finally updated my guide to match NetBeans 8.0 and Phaser 2.0.4. Everything should now be working correctly. If you are still having problems, let me know and I'll try to help.
  14. Videlais

    Game states

    It reads as if you are actually asking about programming syntax styles rather than game states themselves, so I am going to try to answer that. As for using an underscore as a prefix for variable names, it comes from the need to visually differentiate between 'private' and 'public' functions in JavaScript (and other ECMAScript languages). Since JavaScript is a prototypical language, its inheritance structure is different from other traditional object-oriented languages like C++ and Java. Just about everything is 'public' in JavaScript in the sense that it can nearly always be accessed directly from an object by knowing its property name. In order to mark the differences between them, then, some programmers use an underscore before a variable name for functionality that is supposed to be 'private'. The underscores between words usually occur because variables can't have spaces in them. And one way to create the illusion of a space is to use an underscore. For example, if I had a variable named "Menu_Screen_Two", I could use underscores to help name the variable and make it look as if it had spaces in its name. The two other prominent syntax styles are Pascal Style, capitalizing each concatenated word in a property or function name, and Camel Case, having the first word be lowercase and each subsequent word start with an uppercase letter. The former, Camel Case, is used by the DOM standard in naming JavaScript functionality (like getElementById, for example) and many programmers use it for their own naming conventions as well. Remember too that JavaScript itself is not a typed language and makes no demands on how programmers name things other than the two rules of variable names not starting with a number and not containing spaces. Variables can be called "GameState", "gameState", or "Game_State". To the language itself, there is no difference. It will accept all of them. The other issue you are asking about concerns file names. Like programming syntax styles, this too is governed not by the language itself, but by naming conventions. Since JavaScript is built on past languages and those who write it often come to it from other backgrounds, many people name their files after the objects they contain. A game's menu, for example, may be in a file called "gameMenu.js" or something similar. This is for convenience, not because JavaScript demands it be that way. (Unlike, say, Java or ActionScript where it is a requirement that the filename match the object contained within it.) When a browser parses a HTML file and finds SCRIPT tags, it loads them one after the other into a global scope. For as long as that page is not closed or reloaded, all JavaScript within that page can generally access everything loaded after it within that page. All variables created during the first SCRIPT tag, unless deleted or created in another scope, can be referenced from later SCRIPT tags within the same page. For convenience, many JavaScript programmers use a system of naming files for what are in them and then load them in a dependency list. (If Object A needs Object B to exist before it can run, Object B needs to be loaded before Object A.) A common way of dividing up a project into different files is to have Phaser loaded first and then something like a "game.js" file next. For projects less than a few hundred lines of code, it is often easier to work on it all in one file and have that be something like a "game.js" file. However, it is a best practice to have files named after their contents and to load multiple files, even if that means more bandwidth taken up for testing. (For publishing/production code, it is best to use a closure compiler for JavaScript projects. However, that's definitely an advanced topic to learn about.) (To answer your question about game states, they need to have certain properties. This means that they can be objects or functions in JavaScript. All that is required is that for the properties of 'preload', 'create', 'update', and 'render' they themselves need to be functions. Those properties need to be able to be 'called' from Phaser's internal functionality and therefore must be functions.)
  15. If you have already checked the common issues thread, you probably already know that there is an image rendering problem. That is what your (1) reads as -- it's probably the image issue. If you are getting black rectangles, it is most likely that the images are either not loading or not rendering correctly. If you are using WebGL with Phaser in CocoonJS, there are a number of known issues with images not appearing correctly that still have not been fixed. If you are running in Canvas mode, it might be the same. Check under the MemoryLog in CocoonJS to see if, in WebGl mode, the images are not being loaded correctly.
  16. The only change I made for testing was to the following line: //Gameinstanzvar game = new Phaser.Game(width, height, Phaser.AUTO, '');Instead of Phaser.AUTO (which defaults to Phaser.WEBGL), I changed it to Phaser.CANVAS. It's not you. And it's not the Samsung phone either. The problem is between Phaser and CocoonJS. You can try a smaller image. That might help. However, after testing your files, I think this is the rendering issue that is affecting everyone right now. There is no solution and we are all waiting for it to be fixed.
  17. This is now a confirmed issue. I tested creating a single button in CocoonJS 1.4.7 and 2.0 on both iOS and Android. (Only 2.0 on iOS, though. I can't downgrade or co-install 1.4.7 without XCode.) In 1.4.7, using Phaser.CANVAS and Phaser.WEBGL, the button worked. I was able to tap on it and an event occurred. However, I was only able to get this same functionality in CocoonJS 2.0 with Phaser.CANVAS. When using Phaser.WEBGL on both iOS and Android, the event did not fire. (For those interested, the two test cases can be found here: http://videlaisstudios.info/testing/phaser/buttons/)
  18. Which mode are you using with CocoonJS 2.0? Canvas+ (Accelerated Canvas/WebGL), WebView+, or System WebView? When you were using it with CocoonJS 1.4.7, which mode were you using then? Accelerated or System WebView? For the events, do you have them enabled? And if so, are other taps/clicking registering? Or is it just for a specific button? If you can, could you post a link to the code or provide more context too? I'd like to rule out some simple problems before I add it to the list of known issues.
  19. I tested your files today. For me, it worked when forcing WebGL (on iOS using the CocoonJS 2.0 launcher app), but didn't work under Canvas mode. (Using Phaser.WEBGL and Phaser.CANVAS afterwards.) I confirmed that this code won't work correctly in either mode using System WebView. This is probably the rendering issue, then. There is nothing more I can do other than to recommend waiting until it is fixed or a new solution is found. (Sorry.) Edit: I meant to attach this earlier, but I noticed this error on two different devices too. It looks like your logo is too big for Android devices -- exceeds the 2048 limit for WebGL textures.
  20. Hi, Youle. It looks like you are trying to create an element you can't under the Canvas+/Accelerated mode of CocoonJS. If you look under the 'document' section of the CocoonJS 1.4.7 (and 2.0) feature list, you can see that createElement is limited to only a handful of things like image and canvas elements. (The same with getElementById too.) My advice is to either already have that element created before runtime as part of the HTML or, if you can, avoid using any DOM operations completely with the Canvas+/Accelerated mode in CocoonJS. (Remember too that you should use an empty string for the parent element of Phaser projects with CocoonJS so that it creates a canvas element and appends it to the document.body directly. An example is shown in the top post.)
  21. Hi, mapmaps. Let me save you an e-mail. I'm the author and I plan to update it this week. I'm also going to write a new version for NetBeans 8.0 and Phaser 2.0.3.
  22. Hi, Agnostic. Have you looked at the top post of this thread? I keep it updated with issues that are reported between CocoonJS and Phaser. For example, your code will probably not run correctly in CocoonJS. For its Canvas+/Accelerated mode, it doesn't have XML support. Unless you convert the XML to JSON and change some more things (as noted here), you won't be able to run it as-is. If the hack of using a "fake" image is not working for images or sprites (not bitmapFonts!), we can't currently do anything to help you. This is a known issue with no solution. (Sorry.)
  23. blackgames: You may be falling victim to the image rendering problem. (It's the very first one listed here.) Try adding the following line game.add.sprite(0,0,'')For example, probably here: var Boot = {... create: function() { game.add.sprite(0,0,''); game.state.start('load');...}That may or may not work. If it does, everything else *should* work as well. If it doesn't, you will probably have to wait till we fix the image rendering problem. (Sorry.) In the meantime, try using the System WebView option. When the Canvas+/Accelerated mode doesn't, it should.
  24. A quick update: If you run into the problem zanardi did, of having an Android device that does not match the official CocoonJS Launcher SDK version, you can change the Custom Launcher's target SDK version under the 'Android' settings from a Ludei project page. At the very bottom are two drop-down menus. Just pick what you want the minimum and maximum SDK versions to be from there. Remember that you will need to side-load the new launcher yourself after that too. (Personal plug: I wrote a guide for getting CocoonJS running on the Ouya. And another guide for CocoonJS and Google Glass too. If you want to get Phaser running on either device with CocoonJS, these guides should help you get started.)
  25. You (and several others) asked me for a guide to getting CocoonJS running on the Ouya. Here it is.