xerver

Members
  • Content count

    1,441
  • Joined

  • Last visited

  • Days Won

    12

xerver last won the day on September 16 2016

xerver had the most liked content!

3 Followers

About xerver

  • Rank
    Pixi.js Moderator

Contact Methods

  • Website URL
    http://github.com/englercj
  • Twitter
    rolnaaba

Profile Information

  • Gender
    Male
  • Location
    USA

Recent Profile Visitors

1,526 profile views
  1. 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.
  2. Can you explain what you mean by this?
  3. 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;
  4. Honestly, not sure. Firefox is quirky sometimes.
  5. 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.
  6. 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.
  7. Just one is fine.
  8. 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.
  9. 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.
  10. 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.
  11. I recommend you run it through a profiler and having it tell you exactly what the problem is
  12. Can you post a running example of the issue please?
  13. Have you tried profiling and seeing why it is slow?
  14. Pixi's json format is the TexturePacker Hash output format. The meta contains metadata about the sprite sheet that doesn't necessarily describe the sheet itself. Smartupdate is used by TexturePacker but is not used by pixi. You can look at the source of the spritesheetParser loader middleware to know exactly what pixi does and does not use.
  15. Have you checked the profiler to see what takes so long? I did, and got this: Ok, so Texture.upload is taking a really long time. Next I then looked at your texture that was being uploaded to the GPU and it is HUGE, 3300x2920. That is 38.5MB of pixel data that needs to go to the GPU. It takes some time. You can mitigate the loading time by uploading the textured before they are used, using renderer.plugins.prepare to upload your texture at a loading screen. Low-end devices just can't move that much pixel data immediately, it takes time to upload.