v0.30.4 Release! Better Android Performance!

Whew, it's been a little longer than I planned since my last post! After the release of v0.30 I was getting consistent reports of issues with the Android build, including reports from people who have been able to play without any issues before. I decided to spend a day or two getting to the bottom of the issue, expecting it to be some sort of minor Android setting or permission that needed to get tweaked.

Before I dive into my story, here are the links to v0.30.4. The links on the pinned release post have also been updated.

PC
Mac
Android
 
This update includes some major performance improvements, particularly for low memory systems. If you're playing on Android the game will automatically launch into "low performance" mode. The default textures will be downsized from 4096x4096 to 2048x2048, and expensive menu animations will be skipped. The texture downscaling can take a minute or two to complete, but it only needs to be done the very first time the game is started. PC players can swap to low performance mode from the preferences menu.

As a quick benchmark, here's the RAM usage on the main menu (a worst-case situation, with six characters shown at once):

Now that the practical stuff is all out of the way, let's talk about why this took a week to get sorted out. Buckle up, it's going to get nerdy!

First up, I needed to get an Android testing environment set up to try and recreate the issue. Until now I've trusted Ren'py to spit out an Android version that worked equivalently to the PC version, but that wasn't going to cut it any more. I dove into the world of Android emulation and, after some trial and error, got A Very Full House running on the emulator BlueStacks.

With my emulated Android machine running A Very Full House, I needed to figure out how to get the crashing issue to trigger. I had been assuming there was some Android specific problem that my script-searching code was running into. Unfortunately, it seemed like everything was working as expected. I experimented with different emulator settings, different Ren'py settings, different device profiles, CPU counts, and rendering options. None of them produced the crash I was looking for.

After a day or two of digging through all of those options I stumbled on the cause: A Very Full House would crash (silently, to the home screen) if the Android device didn't have enough video memory+RAM. Setting my emulated system to a minimal amount of RAM I was able to finally get a reproducible crash.

Running out of memory for textures is an obvious crash source, but I had ruled it out right at the start. I had players who had played previous versions of AVFH, but were suddenly crashing on the new version. There shouldn't have been any increase in memory use between versions - the new additions for the MCILF all fit onto existing texture sheets. Why was the new version using more memory now?

Well, it turns out a Ren'py update had tweaked how Live2D textures were represented. Rather than storing Live2D textures as an "Image", which I had set to oversample (using less RAM), they were now being stored as an "UnoptimziedTexture", which you might guess is... unoptimized. The UnoptimizedTexture class still took the "oversample" parameter - so my didn't crash - but that parameter was ignored and full, uncompressed image was loaded into memory.

Once I figured out what was happening - which had taken four days at this point - swapping back to the Image class was fairly easy. This got us back to pre v0.30 levels of performance.

But I wasn't satisfied. Now that I had a solid test environment I decided to go further and trim the Android version down as much as possible. Most of the memory use for AVFH are the large texture sheets for the Live2D images. Oversampling the textures could reduce the memory use for the "surface" that Ren'py showed on the screen, but it couldn't help with the memory needed to read the file in in the first place. To do that I would need to downsize the textures themselves.

Luckily, Ren'py had added some tools for rendering out displayables to files. With some coding (which took two more days, including testing) I had Ren'py automatically generating it's own 2048x2048 texture set from the master textures included in the game. I considered including a pre-rendered set of 2048 textures to avoid the startup delay, but I wanted to avoid complications with exporting Live2D models. Having the smaller textures dynamically generated ensures only the most up-to-date textures get shipped along with the game, and keeps the file size small as an extra benefit.

So, that's what's been keeping me busy! I hope the new performance modes make for a smoother experience for all of you, particularly on lower resource machines. Tomorrow I'll be back with a patron focus poll, and we can get to work on v0.31!