Wish I knew of a better title, but the issue is rather specific.

So the producer of the game I'm working on has given me new animations to put in the game. I knew there might be issues right off when the new animations are 45mb when the originals were 1.7mb. This is a html5 browser game by the way.

Now a bit of history. What I have the engine do is cut up the spritesheets at load time into frames of canvas. Basically caching the animations beforehand so there's not need for computation while the game is running. Then I release the references to the spritesheet to be cleared by using ref = undefined; so the memory holding the big unused spritesheet images can be reclaimed.

And back on the story. The new animations crash the web browser at resource loading time. I assume it's taking up too much memory, and too fast for the garbage collector to catch up. As the only change made to the game between it working and not working were the new larger animations, I take that to mean the new animations are the problem. You can't push a web browser too hard as it is and the game is approaching 180mb with these new animations.

I then proceed to tell the producer that these animations are too big and to either slim them down or go back to the old animations(which looked fine enough to me). He claims that he got them down to 2mb and that it was still crashing for him. That doesn't sit well to me since he won't give it to me to test. Anyways, his prediction is it's just the pixel count that's causing the problem not the size of the images, and the size of the images doesn't matter. This doesn't sit well with me either. I'm not an expert on images but I have an idea on how they work and I'm pretty sure that's not it.

His solution is to join them all together into one giant massive image and have an xml file explain where the animations start and end. I've seen this before, so that's not a problem. It's that the resource manager doesn't do this, and I'd have to spend days on making this feature when I'm pretty sure it's not going to make a difference. Because if it's just a pixel count problem(like he says it is) then having one massive image won't fix that. It's the same surface area for the animations, just all together.

If there's someone out there with more knowledge on how images work and has stuck it out through the my long story, here's where I get to my question. Am I right in this issue that the problem is the size in mb of the images? Or, is the producer right that it's the amount of pixels and one giant spritesheet with all animations will fix our problem? By the way, this isn't a full game. It's a tech demo, that's past its set release date already by a week. The full game we'll work on later. Now I don't really care who's right in the end, as long as I know what I have to do to fix this.

Thank you

  • \$\begingroup\$ What do you mean by the amount of pixels? \$\endgroup\$ – Luis Estrada Aug 13 '12 at 19:39
  • \$\begingroup\$ I'm not even sure... I think maybe he means the resolution of pixels in an image being what's taking up so much memory... He's from an art background haha \$\endgroup\$ – G1i1ch Aug 13 '12 at 20:44
  • \$\begingroup\$ I would suggest making some test images, to determine what the actual problem is. \$\endgroup\$ – Luis Estrada Aug 13 '12 at 21:29
  • 1
    \$\begingroup\$ -1 Extremely ranty. In addition, you don't give us enough information to solve your actual issue. You don't tell us about whether the new files are larger pixelwise, or just less compressed with the same surface area, it's only maybe implied. You also don't tell us whether the current animations are in a sprite sheet or not. Ultimately, you ask us: "if the amount of pixels are a problem, then if we do this thing that gives us the same amount of pixels, will it fix it?" (obviously no) whilst also telling us lowering the filesize alone won't fix it. There's no answer we can give you to that! \$\endgroup\$ – doppelgreener Aug 15 '12 at 7:47
  • 1
    \$\begingroup\$ Also the only edit I could come up with for this is the following: "I have a HTML5 game. Due to producer decisions, our 1.7mb worth of spritesheet-based animations have just gone up to 45mb. These new animations crash the web browser. A producer claims that compressing these images won't fix it. If we combine the images into a sprite sheet without shrinking the images, will that fix it?" That's... that's as much useful non-rant information as I can get out of this really. There's no useful information about image dimensions, count, etc, just the filesize. We can't respond based on this. \$\endgroup\$ – doppelgreener Aug 15 '12 at 7:49

Your info is a bit sketchy, I would like to know what resolution is that spritesheet? How many sprites does it contain? How is it compressed? How is the 2 MB version different?

Browsers tend to work in different ways internally, so I can't tell exactly what will happen, but I would assume that as you load an image into into a canvas it is going to be uncompressed, meaning that whatever compression was applied won't matter, it's the raw pixel count that is important. If all else fails you have to get the pixel count down.

During the process of cutting up the image you will hold two full copies of the data, thus doubling the problem.

As for not cutting up the sprite sheet, I'm worried what performance effect that will have.

If I were you I'd split the sprites into multiple smaller spritesheets and keep only two of them in memory at once (one downloading, one being cut). That should keep the overhead reasonable.

And 180 MB, that is a heavy hitter for a browser game, I assume that it is mostly images? Are you trying to keep it all in memory at once or do you have some loading/unloading strategy? You might want to experiment with some tiered caching strategy, I guess you can avoid the unpacked version of an image but still assure that it sits in browser cache by keeping it in a dummy <img> object that is not attached to the DOM.

  • \$\begingroup\$ I've since figured it out, it turns out what you say is true, canvas objects take up monstrous amounts of memory. How I fixed it is I stopped caching the animations and just drew straight from the spritesheet itself. And loading/unloading resources isn't an issue, I've had that built into my engine for a while. \$\endgroup\$ – G1i1ch Aug 20 '12 at 22:07

What about some asynchronous loading of that animations or lower quality of pictures? I don't think, that the giant massive image can resolve your problem.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.