• Content count

  • Joined

  • Last visited

  • Days Won


xerver last won the day on September 16 2016

xerver had the most liked content!


About xerver

  • Rank
    Pixi.js Moderator

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  • Location

Recent Profile Visitors

1,674 profile views
  1. The blog is down while we are thinking about how we want to manage it and where. Currently there isn't one. Best place for news currently is to follow us (@doormat23, @rolnaaba, @bigtimebuddy) on twitter. I'll let you know when we get the blog up.
  2. The texture you are reading from the loader's resource is a PIXI.Texture instance. When you do new PIXI.Texture and pass in the other texture, it is just creating a new texture instance that uses the same base texture of the first one you passed in. The end result of your code above is two texture instances with the same baseTexture. Not super useful unless you want the same image but different frame values (like in a spritesheet).
  3. You can extract them from the resources object and put them into any structure you want. The resources object is simply an object with string keys and resources as values.
  4. It does change the version of pixi.js, check your console. The demo code isn't versioned, pixi is.
  5. The loader can load all kinds of stuff, including images. Just pass the image URLs to the loader .add() method. It won't create all the frames for you if it doesn't load the json, but if you load it once you can do it yourself after that.
  6. Can you explain what you mean by this?
  7. You have to set that before loading the texture, since each texture can configure this separately. When you set that setting, you are setting the default value each texture should use. If you have a particular image that should scale nearest, but don't want them all to, you can set it just on that one base texture: texture.baseTexture.scaleMode = PIXI.SCALE_MODES.NEAREST;
  8. Honestly, not sure. Firefox is quirky sometimes.
  9. I feel like you are missing what I am saying. The issue you are encountering is not a JS issue, not a pixi issue, not even a WebGL issue. It is a GPU issue. You cannot fit texture this large on the hardware itself. You will have to use a different method of animating. When you use pixi above, it is using WebGL. You won't get different results doing it on your own. The textures still have to upload to the GPU and they still will take just as long. Look into skeletal animations, tweening, and timeline animations.
  10. No, it is the VRAM of the GPU. The RAM (main memory) of the unit is irrelevant. The GPU has its own VRAM and that is where the texture is stored. The delay is uploading your texture from main RAM to the GPU VRAM (video RAM). When uploading to the GPU, you can't render anything else (like an animation) because the GPU is busy receiving your new texture. This is why you normally do this on a loading screen. Do your animations without a spritesheet. Instead of having a box moving side to side and having each frame in a sheet, just have one image (the box) and move the position around over a timeline.
  11. Just one is fine.
  12. That tells you that 100% of measured devices have a GL version that supports 4096x4096. But say for example, it has 16MB of memory and can support the texture size you want. That means you can only have 1 uploaded at a time. When you want to use the second one, you have to replace the texture you have on the GPU with a new one, requiring a new upload. The reality is that with atlases this large you just can't preupload them all to the GPU. You need to either reduce the size of your textures or not use texture atlases for the animation you want to do. The second you start using texture atlases this large (and multiple of them to boot) you need to look into other ways to do animation because sheets like this aren't what you want. Unless you are OK with the required upload time. There is no code that will make the upload time go away, only make you spend that time at different points (like a loading screen). But you can't upload 2 4096x4096 textures at one time, not on old mobile devices.
  13. Means you created a more than 16 WebGL contexts and the browser is killing old ones for your new one. Means you loaded an image not natively supported by your browser so it has to do pixel conversion on the CPU. Usually means you copy from outside the viewport into a render texture, so to fill the buffer the browser will create a zero-filled buffer. As to what you should do to fix it, impossible to know without your code.
  14. Always check the profiler, it will tell you why things freeze: Some large texture is being uploaded, and causing that freeze. Probably a different texture than you preloaded. If you have a ton of huge textures to do these animations, then you probably want to do them in a different way than a spritesheet. Many mobile gpus can't even handle the texture sizes you are using.
  15. I recommend you run it through a profiler and having it tell you exactly what the problem is