Avoiding 'Out of Memory' Crashes and Slow Performance

[marigoldsofthenight]

I've decided to animate all of my character sprites for my game, and on the initial 'trial run' of the experiment, I got repeated 'out of memory' crashes in Renpy.

Essentially, I had Renpy display a PNG Sequence of 494 frames set on repeat, so I had about a 12 second loop of my character in a 'standing' animation. This led to crash after crash, so I figured I needed to reduce the filesize of what I needed the engine to load.

The original filesize was around 98 MBs for the PNG sequence, and I have now reduced the resolution and trimmed around the edges of the animation, bringing the filesize down to about 65 MBs in total. Now the image sequence actually WILL load, and it looks beautiful. The only problem I now have is that it takes Renpy a good 12 seconds or so to load everything on the screen.

So now that I've got the crashes under control, how can I get this image sequence to initialize faster? Is there some way to get the images set in Renpy's memory before hand, or a loading screen or something?

Any help would be appreciated.

[Gear]

@_@ Wow. And I thought an animation of 3 frames was a lot.

I know Ren'Py automatically creates a cache of images, but I've only seen it work on imagemaps.

Maybe a workaround is to create a loading 'screen', then have it stay there until it's replaced by the animation in question. For example:

Code: Select all

show char loading
with dissolve
show char bryan
with dissolve

If you use a prefix (I've recently learned) before an image, then declaring a new image with the same prefix will replace the other without need for hiding it. If "bryan" is your animated image, and 'loading' is an image of the word "LOADING" you can overlay on your scene, then it will automatically disappear when 'bryan' starts. Very simple workaround, and probably not the prettiest.

[PyTom]

Ren'Py has an image preloader, which tries to get images into memory before they are used. (This is in addition to the imagemap caching that Ren'Py has.) It's controlled by the config.image_cache_size variable, which is in uinit of "screens worth of pixels". So if we have an image_cache_size of 8, and a screen size of 800x600, Ren'Py is willing to preload about 3.8 million pixels. Alternatively, think of it as 8 800x600 images, 16 400x600 images, 32 400x300 images, and so on - or any combination thereof.

494 frames blows this out of the water.

In memory, Ren'Py stores images in uncompressed form. Each image is stored twice, first as an RGBA SDL surface and then as a premultiplied RGBA texture in "video memory" (the latter can also be stored in main memory, thanks to OpenGL). The upshot is that we take 8 bytes to store each pixel, plus a small amount of per-image overhead. As a wild-ass guess, I'll assume you're animating a 400x600 character, so you have 400 * 600 * 494 * 8 = 904 megabytes of memory tied up in images. That's alot.

I'm curious - what are you trying to do that takes so many frames? I'm guessing that you didn't generate them all by had - is there some sort of animation program you're exporting from?

[marigoldsofthenight]

As a wild-ass guess, I'll assume you're animating a 400x600 character, so you have 400 * 600 * 494 * 8 = 904 megabytes of memory tied up in images. That's alot.

Heh... close. They were originally 1377x768 images, but I've squished them down to about 768x768 or so after removing expendable stuff.

I'm curious - what are you trying to do that takes so many frames? I'm guessing that you didn't generate them all by had - is there some sort of animation program you're exporting from?

I'm a 3d Animator, and I've created a 3d model for each of my characters that has their own type of 'busy' animation that loops. I don't really like static images for my characters...blame it on personal preference, but I like seeing them 'alive' on screen so to speak. I've made several loops in Autodesk Maya that last for around 400-500 frames each of each character looking and standing around, slightly shifting their weight, etc.

I've actually tried removing every other frame and changing the wait time between images, and the movement on the characters still looks fluid. So that removes about half of the workload. Only uses 247 frames, now. I'm sitting at about 9-10 seconds wait time currently. Interestingly enough, after I've displayed the character once, the load time becomes non-existent for when I cut back and show it again.

[PyTom]

What sorts of formats could you export into easily - for 3d and 2d? Although I won't have time to work on it for months and months, I'm wondering if there is an easy to implement 3d animation format. (I don't know much about 3d animation, having been so thoroughly involved in the 2d world.)

I'm also thinking we need a means of creating a movie with an alpha channel - but our movie playback is currently poor enough that this won't be an option for a while.

Playing back 100-frame animations is a bit outside the design criteria of Ren'Py, unfortunately.

[marigoldsofthenight]

Success! I altered the config.image_cache_size variable to equal 120, and now save for a small 2 second hiccup in the scene previous, the characters load instantly.

I'm assuming there's some kind of downside to this, right? Do you think there will be stability issues, or will Renpy just use up more of my computer's resources than before?

[PyTom]

Using a gig of ram for images isn't enough of a downside for you?

Kids these days. Why, I remember when I had a computer with 64kb of memory - and half of that was overlaid with ROM.
Curmudgeon Curmudgeon

More seriously, I think there are a large number of computers (netbooks and tablets) that would begin to choke on that many images.

[Soraminako]

Can the human eye even recognize the difference to the point that makes it worth having hundreds of frames for a few seconds of animation? O_o Or am I reading this wrong and the animation is actually longer?

I'm primarily into 2D myself so perhaps that's a necessary thing for 3D and I'm just not used to it or something. ^^;

[jack_norton]

LOL that's a crazy idea, not just for Ren'Py but for any 2d engine. You simply can't expect many people to be able to run your game
The best solution for that would be indeed video+alpha, a friend of mine has done that on his C++ 2d engine and showed me a demo, works quite well.

[bink]

Just curious... what kind of animation requires that many frames? Usually you need about 10 or maybe 20, not 200+. That's something you would expect from a modern fighting game with a large moveset for each character. Is this a 30 second long idle animation? Or is there something I'm misunderstanding here?

[marigoldsofthenight]

Using a gig of ram for images isn't enough of a downside for you?

Kids these days. Why, I remember when I had a computer with 64kb of memory - and half of that was overlaid with ROM.
Curmudgeon Curmudgeon

More seriously, I think there are a large number of computers (netbooks and tablets) that would begin to choke on that many images.

Hahaha...it's not much of a downside for me, but then again I am using a fairly fast system with 9GB of RAM.

It's probably true that netbooks and tablets wont be able to run the game, but I'm okay with that. I'm really just making the game of a visual quality that I will enjoy playing, and I'd rather not sacrifice some of these great graphics just for lower end systems.

Just curious... what kind of animation requires that many frames? Usually you need about 10 or maybe 20, not 200+. That's something you would expect from a modern fighting game with a large moveset for each character. Is this a 30 second long idle animation? Or is there something I'm misunderstanding here?

Originally I rendered out the loop at the standard 30 fps, but I've since gone back and made some alterations. It now plays at about 14 frames per second, for 20 seconds, equaling 280 total frames.

By putting in a small 'loading' screen that pops up only occasionally, I've now avoided any long freezes and glitches.

[Desu_Cake]

Originally I rendered out the loop at the standard 30 fps

I thought so. 60 and 30 fps is only standard in games, since they need to respond to the player instantly, and for calculating physics and other stuff like that. What you're doing is more akin to movies, where the max fps is 24, and then only for big-name movies, smaller movies, and most animated series use 12 fps, so technically, you could bring it down even more.

[marigoldsofthenight]

Originally I rendered out the loop at the standard 30 fps

I thought so. 60 and 30 fps is only standard in games, since they need to respond to the player instantly, and for calculating physics and other stuff like that. What you're doing is more akin to movies, where the max fps is 24, and then only for big-name movies, smaller movies, and most animated series use 12 fps, so technically, you could bring it down even more.

Yup yup. 12 fps was just a BIT too stuttery for me, but 14 works alright. I'll be testing a demo out on some lower end systems to see if there are any major performance issues tomorrow.