rcoaxil

Members
  • Content Count

    22
  • Joined

  • Last visited

  • Days Won

    1

rcoaxil last won the day on February 1 2016

rcoaxil had the most liked content!

About rcoaxil

  • Rank
    Member

Contact Methods

  • Twitter
    rcoaxil

Recent Profile Visitors

798 profile views
  1. When your collidables move too fast, you only have two options: increase collision check rate, or make sweep collision test. First option may only take adjusting physics engine update rate, provided it has support for such feature. Second option also requires physics engine to have such feature and is also only takes checking a flag. As far as I'm aware, none of three default physics engines support second option, but increasing update rate is an option for P2 engine.
  2. Field "game.add" refers to GameObjectFactory, and its function "audio" looks as following: Phaser.GameObjectFactory.prototype = { //***// audio: function (key, volume, loop, connect) { return this.game.sound.add(key, volume, loop, connect); }, //***// } So there's precisely zero difference since both do exactly the same thing. From really pedantic standpoint, "game.sound.add" is marginally faster performing since you don't have to reference the GameObjectFactory first nor call its wrapper function - not that it's relevant, with the kind of frequency you'd call this function. You can use whichever you find better fitting with the rest of your code.
  3. Well first you need to render the color wheel. A simple sprite will do, but you can also do it via shader, with no actual graphics used anywhere. You need to register click on the general area of color wheel, it's precise location. First you check the distance to color wheel center through common euclidean distance equation, that would be saturation value. You immediately divide it by color wheel radius, to normalize it. If it's greater than 1, then click was outside of color wheel. But you may want to cap it to 1 so that stray clicks count anyway. Second, you measure angle between color wheel center and click location. You do it via Math.atan2 ( wheelx - mousex, wheely - mousey ) but there might also be a Phaser binding for this - whatever you're more comfortable with. This would be the hue value. You also normalize it to range between 0 and 1. Color wheel itself can only represent hue and either saturation or value, it's limited to only 2 components, and one of them is hue. Color wheels that use saturation and value are "color rectangles". Which is to say, you will need an additional bar for choosing the missing component. You just measure position of the cursor along the bar and normalize it to fit between 0 and 1. But if that degree of color selection freedom is not necessary, you can simply use value of "1" as a substitution. Finally, you use any of the multitude available solutions of conversion from HSV to RGB, such as this. Hue goes to "h", saturation to "s" and value to "v", obviously. On the output, you get an object that contains your RGB color. function HSVtoRGB(h, s, v) { var r, g, b, i, f, p, q, t; if (arguments.length === 1) { s = h.s, v = h.v, h = h.h; } i = Math.floor(h * 6); f = h * 6 - i; p = v * (1 - s); q = v * (1 - f * s); t = v * (1 - (1 - f) * s); switch (i % 6) { case 0: r = v, g = t, b = p; break; case 1: r = q, g = v, b = p; break; case 2: r = p, g = v, b = t; break; case 3: r = p, g = q, b = v; break; case 4: r = t, g = p, b = v; break; case 5: r = v, g = p, b = q; break; } return { r: Math.round(r * 255), g: Math.round(g * 255), b: Math.round(b * 255) }; }
  4. Well you can still just put a quick check in the code for proper initialization and retry if it failed the first time. I don't own any Mac hardware so I can't investigate myself.
  5. What you're doing wrong is, basically, not using an HTTP server to serve you content. Yes you need that even for local machine. Luckily for you, there's a really simple method that requires precisely zero fiddling. 1) Install node.js 2) open up node.js console, switch to directory in which you wish to install server (you can simply use Node's own directory) 3) install http-server via npm (type "npm install http-server") 4) start http-server, type your game directory as an argument (e.g. "http-server c:/phaser/vm-wip/"), keep the console window open 5) open up your game in your browser by your local address on port 8080 (e.g. "localhost:8080/") 7) next time you want to start the server, you first need to switch to the directory in which it's installed and start it from there Voila. Now you develop your game in the same (more or less) environment as it would be on a real server. If something doesn't work with this setup, there's very good chance it won't work on real server either. As a side note, cross origin content is a huge security hole. You should always consider possibility of attack through it.
  6. Phaser loader doesn't knows anything about size of the files you're loading, so it uses file count as progress indication. If you wanted to display progress based on amount of data loaded, you'd have somehow know in advance total size of files you're loading. It is usually applicable to use "onprogress" event of a loaded element, which returns you exactly how much data was loaded and how much there is to load total, but 1) it wouldn't return any data until the loading have actually started, which may take a while, and 2) you'd have to hack into Phaser.Loader class. Though if you precisely knew all file sizes in advance and could just pass them to Loader class, then hacking it to display progress based on bytes rather than file count would be entirely feasible operation and would actually work well. Even if that wasn't the case, you could still just put byte progress bars for individual files, and put file count next to them. Oddly enough, Loader actually has "onprogress" event handler punched into it, but it's a blank function. You'd have to change it to something like this: xhr.onprogress = function ( bytes ) { this.onProgress.dispatch ( file, bytes ); } But of course there's very many of specific loader functions, and you'd need to do this with every single one of them. And in the class header you'd need to create appropriate event: this.onProgress = new Phaser.Signal ( ); Then on loading progress you'll receive a Phaser.Signal with first argument to callback function being file structure (you only need its "key" field really) and the DOM event. callback = function ( file, bytes ) { if ( bytes.lengthComputable ) { loadingbars [ file.key ].fraction = bytes.loaded / bytes.total; } } Note that length may not be computable, e.g. if total file size is not known and it's just loading the stream until it finally ends, without expecting end of file at any particular point.
  7. Pretty sure you can't, Phaser works within canvas element and renders all the stuff right into it, or in other words, none of the stuff it renders are an actual DOM elements - there's only canvas. But, with some clever CSS, you can implement scalable divs outside of the game canvas. Some of the latest additions include "calc( )" which works exactly as you'd expect, and "vw" and "vh", which stand for "viewport width" and "viewport height" respectively.
  8. Quick googling netted me a whole bunch of similar issues, but on a whole lower level. http://stackoverflow.com/questions/8611063/glktextureloader-fails-when-loading-a-certain-texture-the-first-time-but-succee Seems to be a common issue on Mac, seems to be a bug only occurring in a handful of very specific situations, and of course it's worked around by performing completely unrelated operations. Try putting the following line before you load a texture, see if it works. game.renderer.gl.getError ( )
  9. Well you can check if the object returned has proper dimensions.
  10. You see, I'm asking because rather than looking for help accomplishing specific goal, you're looking for help accomplishing one very specific step on your way to the goal. But it might so happen that the whole path you chose is sub-optimal and thus the whole topic is moot. If you describe the goal you want to achieve, people might suggest better ways of getting there. I would keep an array of sprites that can be duplicated, sorted by depth in descending order, so I could iterate over them all and the first one to pass hit test is the one I'm looking for. Of course that would be redundant if you can do that with any sprite from a specific group. If there's really many of them, I'd also used spatial partitioning of some sort because too long lists create too big processing burden. Also keep in mind that sprite hit area is rectangle. So you may need to individually assign proper hit testing polygons to them.
  11. If you want, I can give you sources from my library for handling multitouch input. It supports designating specific input zones with their own separate events, and some basic gestures (singe & double sweep, pinch and twist). I don't have any practical reason to keep it to myself so I might as well just give it away. It was written for GameMaker but I assume it's easily portable to Javascript and Phaser. Since I'm developing a game that will go well with mobile platforms, I may need to port it to Phaser anyway. I developed it just for my small hobby project of minimalistic paint tool for mobile devices, which I abandoned.
  12. In the other thread the issue was narrowed down to Tilemap plugin tanking performance in post-render. Seems like it needs to grind though all of your tiles to determine which ones should be rendered, and it does it in not so stellar fashion. Try using a spritebatch directly in place of the tilemap. In most other engines, just rendering your entire map in a sprite batch without bothering with any culling winds up just as fast (often much faster) than using sophisticated algorithms.
  13. The top one is obviously the one with smallest Z coordinate. Exactly what are you trying to accomplish, though? Just duplicate a sprite with a small offset by clicking on it? What you're doing may not be the best approach altogether.
  14. Most likely a bug in Cordova's underlying framework. Try to trace exactly what causes the slowdown. Run a profiler to see which functions' running time skyrockets after switching. I never worked with those, but I have a hunch this has to do with framework pumping huge amount of events trying to catch up for the time it wasn't running.
  15. There is no magic, but you really have to very carefully examine your code for possible problems. As far as I see it, it plasters 100% alpha all over the surface. I'm gonna need a more complete source of your shader. I had similar issue when I tried using "vColor" - unless you use shader directly, it's not defined and results in glitches. I've noticed that shaders only work 100% "properly" if you attach them directly to renderable objects using their "shader" property.