Animated sprites and memory

#1 Definitely have the whole sheet loaded. Each animated sprite does not allocate the whole sheet memory. The sheet is only allocated once.

#2 Thanks Johnny, I was hoping that was the case :)

If there any advantage to using MSourceRect with animated sprites or is that not possible?

Cheers

#3 You haven't read the documentation clearly ;) Its all too obvious when someone doesn't!

It is a massive advantage.

#4 I'm interested to know how technically it is a massive advantage?

I would have thought ...

Old method:

- Sprite sheet in memory with 40 sprites.

- Sprite object referencing two frames fo an animation

- Only two frames passed to renderer

New method:

- Sprite sheet in memory

- MSoruceRect defining two frames from the sheet

- Only two frames get passed to the renderer

Clearly there is something else I'm missing and would be interested in knowing or reading how it improves performance.

Cheers

#5 No, there was just a little misunderstanding :)

The methodology is in fact the same. The performance advantage being mentioned above is mentioned in terms of packing frames into a single texture. What that means is you can have enemy 1-4 all in the same texture, saving on having 4 separate textures one per enemy.

I think we are all agreeing on the same thing , but in a different way. Less textures = better.

#6 Thanks Sven, I was worried that I would be having to convert my animated sprites in one sheet from frame based to msourcerect . All the help on here is much appreciated :)

Cheers

#7 I'm currently working on packing everything into a sprite sheet. I'm wondering what would be the optimum size for a sprite sheet? Currently I have one sheet containing all of my sprites (some static, some animated) packed into 64x64 cells. The sprite sheet is now 1024x448 and will grow as I add more sprites. Would it be acceptable to load a 1024x1024 sheet into memory? I think that would probably be enough to contain all of the sprites and animations for my whole game.

I'm mot using MSourceRect, and I just use one large sprite sheet that gets split into 64x64 frames. Do you think this will work ok?

Previous to this, I was using several smaller sprite sheets, but I did't see any framerate improvements when I packed everything into one sheet, which was disappointing, and a bit confusing.

I'm not using PVR compression yet though, so maybe that will make a big difference?

just wondering if my approach is correct?

Thanks,
Mark

#8 Hi Mark, from memory 1024 x 1204 is as large as you can go dues to constraints on older devices. Couple of things to watch with the sprite sheets are that you untick filterpad and make sure you tick optimised - from looking at the code it is the optimised flag which streamlines some of the code around loading/unloading the texture into memory.

If all your sprites are 64x64 then your approach is fine - I use sourcerect for the sprites when they are not all the same size.

#9 You want to keep both dimensions the same[1], so 1024 square is fine. PVR will make a huge difference: The image takes 1MB in VRAM uncompressed, but PVR lets you keep it COMPRESSED in memory, at some potentially insignificant loss of quality. You will get it down to 128k or less.

[1]The texture will be padded to some larger size anyway if you use odd measurements.

#10 Thanks for the feedback. Good point about the filter pad and optimised settings, I had left those as default, which is filter pad ticked and optimised unticked, so that's good news as I might see some improvement there. Also, I was wondering about x-y dimensions of the sprite sheet. I guess mine will get padded out to 1024x512, right? I'm not too concerned about that right now though since I'm still adding more sprites, but eventually I will make that all dimensions are powers of 2.

Thanks,
Mark

#11 I have one sprite that is 128x64, but for that one I split the image up into 4x2 cells of 32x32 and pack those into the sprite sheet with all of the other sprites. Then, in the editor I create a tilemap with 4x2 tiles and use that to create the object.

Since I'm doing that for this particular object, I'm wondering if I should be doing something similar for my background images? Each level has a different background image and currently I use images of 480x320 pixels, and I just load the whole image as the background. However, those dimensions are not powers of 2, and I'm wondering if I should split the images into smaller chunks and use tilemaps?

How do you guys handle your background images?

#12 Hi Mark, 480x320 will be automatically expanded to 512x512 by Torque when the image is load and re-packed.

What I do is:

- I create an empty image 512 x 512
- Past in the 480x320 at 0,0
- Add in anything else that could be used in the extra space - use source rect to get it out.
- PVR it
- switch on optimise flag, switch off filterpad.

#13 Hi Scott, thanks for the feedback. Sounds like a good idea, I'll try doing the same thing.