• Content count

  • Joined

  • Last visited

About themoonrat

  • Rank
    Advanced Member
  • Birthday 11/25/1982

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  • Location

Recent Profile Visitors

686 profile views
  1. There is no correct way; as you've noted, there are options available to different circumstances. One that throws errors if the texture is not found is my personal preference. Since I'm not using the loader in my game, I therefore use PIXI.Texture.fromFrame.
  2. You only get the confirmation message you're looking for once you've created a renderer
  3. I believe some of your pause maybe due to uploading textures to the GPU for the first time. You may want give the prepare plugin a go renderer.plugins.prepare.upload(textureOrContainer); Upload all of your textures after loading has ended, but before you've hidden the loading screen.
  4. According to the bottom of that, there is an event you can subscribe to called 'update' texture = Texture.fromImage( 'blah.svg' ); texture.on('update', () => { console.log('yay'} ); But is there any reason you can't use the built in loader to do this for you?
  5. For mobile, I'm happy with 2048x2048. Most devices do support 4096x4096 now, but I found that some devices would stutter sometimes, when the texture was being uploaded to the gpu, and older iphones showed weird artifacts But you want as few texture swaps as you can, which rules out 1024x1024. So 2048x2048 was the sweet spot for my needs
  6. True There are two paths you can take here 1. adding and removing sprites onto the container. Advantage, the renderer is only iterating through an array of children it actually needs to render, which will be quicker. Disadvantage, addChild and removeChild are manipulating arrays, which can be slow and janky. 2. create a pool of sprites you can use up front, and reuse them by changing changing visibility. Advantage, no touching arrays; a visible on/off switch is very simple and speedy. Disadvantage, you could be iterating through tons of sprites every frame that aren't ever going to be rendered, which is a waste of time As xerver says, you will have to profile your game to see which works out best in your circumstances. My instinct is 2, just to avoid dealing with constant array resizing, but i may be wrong!. Please let us know what performed better... I'd love to know the answer!
  7. I'd rather do the later where possible, but If you wanted to do the former, then on a click/touch event callback from the parent you get can interactionEvent. will give you a Point object with the global x and y co-ordinates of the click/touch. If the children are a sprite/graphic, you can use that to call their containsPoint function; if not, you'll have to create your own similar function.
  8. Is there a reason you couldn't just set yourSprite.visible = false; On the ones you don't want to render anymore? That would be preferable and stops rendering or calculating transforms on those sprites.
  9. @mattstyles I could read your explanations all day long, even when I already know the anwer on the subject matter. Keep up the good work!
  10. is the page that breaks down version changes in plain English Top one is changes for the next version that hasn't been released yet, then under that the actual released version changes. In the case of that Text change, the optional third parameter let's you share around a canvas between text objects rather then them all use their own. If you've lots of instances of the same piece of text in the same style in different places, then you could save a little memory via sharing the canvas.
  11. In your attempt to define player (after the let), you are referring to player (the last parameter) let player = Unit("./img/player.png",150, player); //error , player is undefined. I believe what you wanted to do was let player = Unit("./img/player.png", 150, 'player');
  12. Try PIXI.settings.SCALE_MODE = PIXI.SCALE_MODES.NEAREST Before you create the renderer
  13. There was No idea if it works with latest pixi. Unfortunately, otherwise you're going to _have_ to control texture size. You can't have a problem of too many textures in memory but then say you can't remove textures from memory... You're going to have to find a way or you have no mobile game! mattstyles raises a good point.... when in one game area, load textures for it, but when going to another area, delete the old one, and load the new one. Tricky, but possible. You could also, for lower devices, have a different set of assets that are of a lower resolution. So you have your x1 assets you're loading now; well, have 50% scaled down versions of them, load them into pixi as x0.5. should be pretty easy to do, and your gpu memory usage is now 25% of what it was. For my game, i have assets for x1, x0.75 and x0.5, and i load the size appropriate for the device. If you can't do either of those two... do some detection code to not let anyone below your required device spec play. "Sorry, your device is not modern enough to play this game"
  14. Have a follow of the thread here where we did get it working if it's still of interest:
  15. I'll do a PR for adding this into the documentation. Documentation is tough cover all explanations for peoples usage, and tough to get enthusiastic to look through, so any PR contributions are greatly appreciated from the community!