Jump to content

Inconsistency in huge sprite performance


Nedyalkov
 Share

Recommended Posts

Preface

 

We're a small development team of four that is working on an educational project for the children with special educational needs such as those with autism, hyperactivity or delayed mental development. The project consists of two main parts.

 

Administrative part which covers management and functionality of student profiles, educational center profiles, teacher profiles, parent profiles, game administration in which teachers can replace characters, scale them and change different options based on the game, thus creating new game versions of the same idea.

 

And second, the actual games which are developed in Phaser. The games themselves are designed by a team of seven psychologists and teachers that we are working with, they are those who decide how the game will look like, approve designs and brainstorm ideas based on their knowledge about working with children with special educational needs.

From this come several restrictions or requirements:

- The game must be filling the viewing area of the browser when maximized;

- The game must be scalable so it can fit different screen sizes;

- Mobile or tablet support is not considered nor required, but it it comes for free it's a plus;

- Animations are complex and must be smooth;

 

Due to the last requirement, for the animations to be smooth, the sprites are usually large and consist of many frames. Our designer have repeated some of the frames that can be removed, but this is not the issue at the moment. Here are some of the sprites we are working with in our first experiment:

 

- Moving caterpillar

- Magician appearing

- Magician pointing

 

NOTE: I know the sprites can be improved additionally, actually those are parsed through TinyPNG unlike the original ones and some repeating frames can be removed.

 

The Problem

 

And here's a basic example to illustrate our problem, I just placed some of the sprites on the screen. The fps drop happens even if I don't attempt to animate all of them, so I doubt this is a real performance issue:

 

- A few sprite objects, animations are running smoothly as they should be;

- Adding additional sprite object in the middle, it ruins everything - (3000x2700 size, High-end CPU is hogging at 40-60%, fps drops at 3-5)

 

I've noticed that if I artificially change the size of the signs object, the stutter disappears. Here I make the sprite huge with simple resize:

 

- Resized middle object to 5100 x 4590, no stutter.

 

IMPORTANT: Be sure to close the stuttering example if you open several tabs because it affects everything.

 

We have absolutely no idea why this happens, from what I see it's some problem with the sprite layout and sizing, I've read somewhere that it's good practice to keep the dimensions on the power of 2 but those aren't. We are considering switching to Atlas but need to figure out if this is going to be a problem and why is it a problem to begin with.

 

We've asked for advice some colleagues in another company that are dealing with games as well and they've given us some very good advice regarding the repeatable frames and suggesting that the sprite size can be reduced dramatically. Additionally they've stated that the sprites are huge and this is causing the performance issue, however I do not agree because the above examples clearly illustrates that even if I increase the image size artificially three times it can still be smooth.

Link to comment
Share on other sites

A Chrome profile on your stuttering example shows it's spending >50% of the time in drawImage calls. My best guess is you are at some point exceeding the hardware maximum texture size, and the canvas may be falling back in to software mode or performing a very slow workaround to hardware limitations.

 

Still, your approach is a poor way to design memory-efficient games - take a look at this blog post we wrote for C2 users: https://www.scirra.com/blog/112/remember-not-to-waste-your-memory

Link to comment
Share on other sites

A Chrome profile on your stuttering example shows it's spending >50% of the time in drawImage calls. My best guess is you are at some point exceeding the hardware maximum texture size, and the canvas may be falling back in to software mode or performing a very slow workaround to hardware limitations.

 

Still, your approach is a poor way to design memory-efficient games - take a look at this blog post we wrote for C2 users: https://www.scirra.com/blog/112/remember-not-to-waste-your-memory

 

Thank you for the input Ashley, however, it doesn't really make sense, because the second example is working with fewer and smaller images and it's stuttering. While the third example is working artificially with a 3 times bigger in terms of size, both file and resolution, middle sprite and it's running smoothly. This is our first attempt at doing anything, so I will look into considerations for better memory management, however this isn't the issue you mentioned.

 

I can load many sprites of different types and it will run smooth, and then when I load this exact sprite with this exact size/layout things go really bad. The designer actually made a new one and when we replaced it our problems disappeared, that's how we learnt something's wrong with the sizing in the first place. Could be a glitch or something I'm unaware of in the framework sprite implementation, because I tried several other sizes close to this one and it was still stuttering, then I resized to ~5000ish pixels just to try and see what happens and the stutter disappeared. 

Edit: Your link returns an error at this point, I found a cached copy and the suggestions are very good but too general and do not apply in all cases. They do not apply to our case either, I mentioned mobile is of no interest and the desktop machines that it will work on have plenty of hardware for 3 huge textures. Plus, as mentioned before, our last example proves that memory consumption is not the cause of stutter. We can't really avoid the huge sprites, we can improve them by not more than 20% yet everything else has to remain the way it is. I only want to understand why the fps drops 90% in the above-mentioned case, once we run into severe memory issues we'll focus on that more.

Link to comment
Share on other sites

  • 1 year later...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...