jump in sprite resolution = significant jump in memory usage..?

Previous topic - Next topic

Falstaff

My artist and I have recently decided to try out our code using higher res versions of our graphics, essentially targetting retina display resolution 640x960 instead of 320x480.

In doing so, we apparently somehow increased our memory usage drastically. Basically if I run my game with the old 32x32'ish sprites (some are a bit bigger, but not by much), under windows my game is taking up around 40 megs of ram. When I load in the double sized media, my game shoots up to around 214 megs. It's almost as if the sprites are somehow being loaded in ram, and somehow taking up megs and megs of ram?

I don't notice any impact on my PC, but on my iPhone even though the game somehow still runs, it has 30 FPS instead of 60.. and my artist's iPad crashes out altogether shortly after starting up (maybe while loading the increased graphics size I guess?)

I'm not really sure how or why this is happening? We basically are just using standard LoadAnim and DrawAnim commands.

The biggest sprite sheets we're loading are around 456x684.. well within the limits I've seen looking around online (which are apparently around 1024x1024)

Anyone have any ideas? How big are the sprite sheets you guys are using in your games? how many frames do you have in them?

Edit: I guess I should mention I'm also using ampos' method of drawing to a virtual screen using the CREATESCREEN commands.. perhaps that's contributing too?

Edit x2: Also, is anyone else able to get the Instruments stuff working in xcode 4.2? Specifically the Leaks instrument?

Crivens

Just for a note they shouldn't be twice the size, they should be four times the pixel size. So 40mb of sprites should give you approx 160mb of sprites on Retina. And it doesn't matter how you compress them I believe they are fully uncompressed when loaded into memory.

Depending on the hardware I'm guessing that you are running out of memory if it's crashing out. Try and load graphics in when you need them and unload them when you don't.

You can use my generic resize code instead if you want (see snippets). The only advantage on Retina (apart from speed) would probably be saving some memory for not using the createscreen (at a guess requires internally to store the full screen as an image). The advantage on pre-retina is the sprites are all resized for the screen and only the resized ones are loaded. If it crashes out on devices with less memory (I'm thinking my 2G iPOD with 128mb RAM would be stuffed if you have 160mb of sprites) then my routine should resize them and give it a better chance of working (assuming the screen res is less on the device). So my 2G iPOD would then have 40mb of sprites loaded, hopefully meaning it doesn't run out of RAM and crash out. Would be good if iOS used the drive as virtual memory like a PC. Hohum...

Good point about XCode 4.2. I've checked it out but still haven't moved over. Think I will after my current project. Everything looks completely different so I'd rather start from scratch when I'm ready. Note XCode 3.2 still runs fine for my apps on ios5.

Cheers
Current fave quote: Cause you like musicians and I like people with boobs.

Falstaff

Ah.. I found the culprit, I forgot I was re-loading my main animation state for each of my characters over and over for all the different animation states we were planning on having.. looks like we'll just tone down on the amount of animations a bit.. Admittedly I didn't consider the consequences of a few measly MB of compressed graphics!

Falstaff

Ok so I guess just as that explains the massive memory jump, what about the framerate drop?

Should I assume that drawing full screen tile maps in iphone 4 means I should target 30 fps instead of 60? Or what is everyone else's experience like? Oddly enough, it seems I get back to 60 fps if I take out the CREATESCREEN usage.. Maybe I'll have to look into your code after all Crivens..!

When I check time in my code, it looks as though all my logic stuff is executing in about 1-2 ms, whereas the drawing commands can take upwards of 3-6 ms, but SHOWSCREEN takes anywhere from 26-44 ms when I've used a CREATESCREEN'd screen, or anywhere from 12-29 ms if I'm just doing a straight up draw -> SHOWSCREEN.

44 ms for a single SHOWSCREEN? that seems harsh!

Kitty Hello

some grphics drivers do the work in the background. But the flipping of the buffers requires the program to wait until the graphics are done. So, it seems like showscreen is te bottleneck, but the drawings take that long in reality.

Crivens

QuoteMaybe I'll have to look into your code after all Crivens..!
It's worth a try. It's more complicated to use but in the end it should be faster (and use less memory for lower resolutions). There is also other code lying about on the forum that inserts a simple progress bar while it resizes the images. It only does it for the first run, after that it will use the newly created graphics, or until you change a version flag in a file (ver.txt). Obviously it will take up more room on your storage (doesn't overwrite existing graphics as they are write protected in the media directory of iOS) but you could I suppose do the configuration every time loading and sizing directly to memory without saving the smaller versions (bit annoying and slow though when storage space is pretty large these days compared to RAM).

Cheers
Current fave quote: Cause you like musicians and I like people with boobs.