When loading images from a sprite sheet in PIXI.JS is the order or amount of sprite sheets important?

0
votes

I'm using Texture Packer to create sprite sheets for all of my game image resources. I end up using a multipack of 5 sheets with a max of 2048x2048. I have a good amount of sprites being loaded into various containers, sprites, tilingsprites, etc. Should I be creating these sprite sheets more intelligently based off of what container they are going to be loaded on?

I feel like i'm doing something fundamentally wrong because my performance doesn't seem to be the greatest. I stripped my game down to only load 6 sprites to try to get to the root cause of the problem. I even split up my sprite sheets to individual containers. So container 'A' uses images from sprite sheet 'A' while container 'B' uses images from sprite sheet 'B'.

Even with these very minimal graphics being loaded my CPU usage skyrockets and my computer fan goes wild. It just seems like the computer is working extremely hard to only show 6 sprites. I don't notice that when I try the demos/examples from the pixijs website.

I'm really not sure what I'm doing wrong. Are my images too large? I have a few that are about 1440x900 pixels. The images all get compressed so the size isn't too large but do large dimension sprites slow things down? I'd show some code but my code base is quite large. I've tried this out on canvas and webgl. Webgl performce better but I get the same cpu spikes for both.

1
canvashtml5-canvaspixi.jstexturepacker
Yes and no? take your pick as the problem could be anything, images to big,CPU too slow,GPU slow, low resources, bad code, bad browser, or any one or more of many more. You will have to supply some code if you want to find out why your code is struggling. Personal I suspect bad event handling and or instantiation , or leaving open paths when rendering to the canvas, they can usually get the device's fans going. – Blindman67

1 Answers

1
votes

On webGL, displaying the graphics is GPUs responsibility. So if the CPU is choking, when using webGL, I would be fairly sure myself, that the issue is in your code and not in the sprite size. Basically webGL just has limitations to how big textures it can display: https://www.khronos.org/registry/webgl/sdk/tests/conformance/limits/gl-max-texture-dimensions.html , https://webglstats.com/webgl/parameter/MAX_TEXTURE_SIZE

So in webGL, optimally CPU should upload the sprites to GPU only once, after that CPU changes the position of sprites and sends the new positions to GPU, with each animation cycle and GPU redraws the sprites. But you mentioned that your codebase is big, so I would doubt that as the core issue personally.

You should find out which part of your code causes the spikes. You can use e.g. chrome devtools profiling for that and continue from there forward.