• Content Count

  • Joined

  • Last visited

  • Days Won


Sawamara last won the day on August 4 2014

Sawamara had the most liked content!

About Sawamara

  • Rank

Recent Profile Visitors

614 profile views
  1. Yes, pixelArt: true is the one that actually solves this one.
  2. You are not reusing the "animations" in a group, but the sprites themselves. So of course there will be no more items to get() after your 30th usage.
  3. Phaser uses javascript. Therefore, you can simply send out XMLHttpRequests (for example) for data regarding your multiplayer session (so you can poll your server, for example, for any new moves your opponent made in a chess game.) Then, all you need to do is have the code handle the resulting JSONp response text. But this is just a quick and dirty example, I am sure you can use sockets and advanced mulitplayer techniques as well, just make sure to have a bridge between your api calls and your phaser game handling the data it is given.
  4. .x, .y properties of the object, maybe? : )
  5. Pixi works on stock android browser too, I can confirm that, 4.2.2 OS. However, filters do not seem to work. Edit: To clarify, pixi-based code can run on the stock browser, but I was unable to run the bunnytest as well. I do not know what exactly is the problem with that specific code.
  6. Setting button to null does not delete the button though, be careful with that. The only way to get "rid" of it is to allow it to be garbage collected AKA removing each and every reference made towards it. But that is more of a general JS discussion, not exactly Pixi. Disabling the sprite's interactivity, as far as I know, removes the handlers too.
  7. If I learned anything from the previous thread of mine ( ), it is the following: Say you use multiple files for the explosion and the ship. That means that you should be able to do the following: ship.image1 = new PIXI.BaseTexture(image1) //If the image1 is already an image, otherwise use BaseTexture.fromImage(src)ship.image2 = new PIXI.BaseTextrue(image2)Then, you declare the frames of animation from image 1, then from image 2: ship.frames1 = [];ship.frames1.push(new PIXI.Texture(ship.image1,new PIXI.Rectangle(....));ship.frames2 = [];ship.frames2.push(new PIXI.Texture(ship.image2,new PIXI.Rectangle(....));So when you initialize the ship, you will probably use the frame from your initial image, using something like this: ship.sprite = new PIXI.Sprite(ship.frames1[0]);And when you will need to use the explosion, you can just setTexture your way through it, like this: ship.sprite.setTexture(ship.frames2[0]) //..... or whichever number your explosion animation currently stands)Hope this helps. To clarify whether this approach works or not, I will try it out soon, and get back to you.
  8. Thank you! This indeed was what I was looking for! Had to look around because initially, I was confused how to setup the sprite itself (in the other thread where a question similar was taken, you suggested that the frame1 was going to be the default (or first) texture assigned to the Sprite, and indeed, that worked! So thank you. This means that you have one more strong pixi.js-convert from now on One tiny thing, though. Instead of this: this.btexture = new PIXI.BaseTexture("warrior-sprites_2x.png");I had to use this: this.btexture = PIXI.Texture.fromImage("warrior-sprites_2x.png").baseTexture;I have no idea how or why, but nothing showed up on the code if I opened with the first option. The second, however, worked.
  9. Hello there! I decided to migrate my whole work-in-progress to Pixi JS, well, mostly because it is amazing, and I have put off learning it for waaay to long. However, my problem is this: the way pixiJs seems to handle spritesheets, it is REALLY not feasible for me. Let me tell you why. I am building an RPG where dozens (or more likely: hundreds) of spritesheets will be stored. I really, really do not want to overcomplicate JSON calls and make big, big files. Currently, a spritesheet has N lines for N numbers of animations. The only thing that is "strict" is that each line has equal values of width and height. Some animations require more space, therefore they are having a larger "global" width value, but that is it. So currently, my code goes like this: switch ( case "randomName1": { monster.anim1 = { frames: 10, width: 40*size, height: 40*size, startY: 240*size, specialRules: [[]], } monster.anim2 = { frames: 14, width: 60*size, height: 50*size, startY: 320*size, specialRules: [[]],}} break;So after this initail setup, now I know how long each animation lasts (frames), and the drawing/update determines the x,y,w,h values that determine the EXACT rectangle position in the spritesheet that is to be used as the monster's current frame in the animation. I can write a converter that converts this type of code into TONS of frames (preferably: monster.anim1.frames), but I really should not make JSON files out of it when my code can make it on the loading of the battles. So my question is this: please, please, help me understand how exactly pixi.js handles these spritesheets. The things I gathered so far: - I can load a texture, display something, then change its frame by setFrame, BUT then the change is not visible. If I take it off (removeChild), THEN change rect, then addChild again, the change is indeed visible. So I could make a code that, at each frame change ("animation phase changes"), takes the sprite off from stage render, then makes this change, then puts it back. Question is, is this something that is good performance? I also have parts of the game where multiple objects use the same image. However, I have no idea that under this system, how that would work. Should I have to make new textures for each (20-25) objects that share the same imagesheet? (PNG files, rectangles of paintings, usual stuff) So can someone tell me precisely how to define this? Because then I go and see that I should look for "texture.fromFrames", but THAT does not specifiy and image data. The image is not there. There I see AssetLoader, that has a meta tag, that has an image specified, yaay. But can I circumvent the process within javascript, and have it not require JSON files? Thank you in advance. I am feeling down just by thinking about all this, whether I am missing something crucial.
  10. At a glance, this seems like the usual image problem, where you are indeed setting the image's source sooner than it could load, thus giving you problems. Usually, you first set the image. var picture = new Image(); Then you do an onload, specifying that your assets should be used only when loaded picture.onload = (code that deals with that, either flipping a switch or something else) Then you add the source. picture.src = "imagesrc.png"; Now, you gotta make sure to wait for the image to load before you make any references to this in your regular draws. If you omit to do that, the image will not pop up at all. Or does so only after reloads.
  11. Hello! In the past year, I have decided to do a HTML5-based game, and I kept going at it ever since. Full production is something that is still a bit far ahead, but I managed to squeeze out every single little detail of canvas-related performance that I could find. Here are my experiences, tips, and all that jazz. 1.On buffers Simply using a buffer canvas (an invinsible one) and then drawing that to the screen instead of using image-> canvas is really, at first glance, not faster. The applications of this is not meant to be as simple as that, however. You want parallax scrolling? You want fancy effects generated from a multi-layered spritesheet? You can predict that is going to be needed? Then you can save processing time by using buffer canvases. There are all sorts of clever tricks to this. Imagine if you need to compile a 4-layered parallax background scroll in about...240 frames (4 seconds). You can process the picture, add the layers to a hidden canvas, frame by frame, in small parts. No single frame will make this buffering draw more than, say....50*50, once per frame. And then once it is completed (pre-painted), you can just draw parts of the buffered image, showing the user the parallax scroll in all its glory, by rendering it only once per frame. If you omitted this process, you will need to draw the bacgkround as it is moving N times, where N is the number of layers. This is just one trick. You can build animations from multiple layers, buffer it, and only draw one square (frame) instead of requiring multiple layers of composition and different draws over and over. Conclusion: buffer-canvases are good, when used with preparation. Just using them natively (for the sake of using them) is not a performance benefit. 2. Canvas size matters, especially (but not only) in mobiles. Never use bigger sized canvases than you would truly need. There is a directly testable performance gap between canvas sizes. Sounds like a no-brainer initially, but it is not. Logic would dictate that if I redraw an x*y size area of an 1200*800 canvas, that would be similar if I did the same redraw of an 1000*600 canvas, but it is not. Use clever positioning, CSS, background images if you want to be as optimal about this as you want to be. 3. The most important canvas optimization #1: Be smart about redraws. There has been many tutorials describing this. You should not redraw everything all the time. Multiple canvases are good because you do not need to clear/redraw stuff when one object moves. In my rpg game, there are currently 5 layers used. Background, UI-BG (frames) layer, character layer,puzzle layer, text layer. When the character moves around, it does it in a different canvas than the background. - 1) Only redraw animation frames when you need them to. Non-moving object? No redraw. - 2) Only clear (clearRect) when you need to. Be very precise about the areas needed to be cleared. Doing 5*(40*100) clears is usually better than doing one 400*100 clear. - 3) This has yet to be carefully tested - more like anecdotal evidence, but you need to organize your drawing like.....canvas 1: Perform all clears, all draws. canvas 2: perform all clears, all draws. DO not do canvas1 clear, canvas 2 draw, canvas 1 draw canvas1 clear canvas 3 draw canvas 2 draw canvas 1 clear canvas 4 clear. It is a performance loss. My own "camera" framework gets draw/clear commands thrown at it, and it keeps separate clear/drawQueries, and at the end of an animFrame, it draws all queries and clears all queries. Goes from canvas to canvas. I was afraid it is going to be convulted, but in a HTC Desire 310, I can achieve 30-60fps on my game, even without further resolution adjustments. And it has constant animations, parallax scrolling, moving puzzle, five layers. I am almost satisfied with it. Before I started optimizing the game, it crawled in single digits. 4. The main culprit behind slowdowns is usually the garbage collector. Seriously. I have looked at so many HTML5 Canvas/webGL games in the past few months, looking for answers, and most of them have the quick sawtooth performance that is painful to watch. Let us assume your game runs at 60fps. Theoretically. Now, with regular GC, you can get a visible slowdown every seconds, even if it is just a hitch to lower 50's. (60->57->51->60->51->etc.). You need to have a VERY carefully written code to eliminate this. Basically, no anonymous functions, no var declarations hundreds of times per frame, no spamming of new objects per frames. I could write pages on this - and if there is a relevant topic for it, I might. -,but this is the main part of it. 5. Be aware of smaller performance traps. Text rendering is one like that. Changing alpha value of a canvas again is. Doing translations is once again. (Better buffer both of these on a hidden canvas in a loading stage, and keep the alpha intact!). Do not use console.log on mobile versions, they will just throw exceptions sometimes multiple times per frames. What you started with is true: aim for the lowest amount of redraws and clears every frame. Find tricks to average these out and manage them that way instead of having busy and calm periods. I am right now at the end of my canvas "patience". I still love this little tech, but I am at a point where I am looking at just porting all that to webGL. Canvas support will stay in the game just in case, but it is clearly not going to be flawless on low-end mobiles for a few more years. It is going to be "fine" in better-than-average mobiles, average or better tablets and excellent on iPads/iPhones, viable on most modern desktop PC's. But you have to be careful about the resource uses.