KillerKobolds
patreon
Behind the scenes: Optimising
🕑 Added 2014-12-31 03:31:57 +0000 UTC Here's a brief look into the world of programming with Lennian! This is a long update post so be wary! • Introduction • To give a little insight in what we've done in the past month and a bit, we want to discuss two problems that kept us quite busy. • Explanation • An issue that came to light rather quickly when working on the first public release of Amorous, was the build size. When things are still in PNG format, size is OK. About 100MB for the Coby-sexscene (625 files), about 25MB all customization parts (325 files). All of these files are HD resolution or higher, for the utmost possible quality before Unity (our engine) crushes it down somewhat. Consider the following: Most of our textures have an alpha channel, for making things partially transparent, this is also called a RGBA texture. That means that in uncompressed form, a texture takes up have width * height * 4 bytes of memory, in case of an HD texture that's 1920 * 1080 * 4 = 8294400 bytes, which comes down to about 7,9MB. Unity allows us to select a compression for textures (uncompressed, DXT5 or worse which we won't even touch). Keeping the HD example above in mind, uncompressed would leave a texture in 7,9MB state. DXT5-compression would turn that into about 2MB, at the expense of some of the quality. So why is this exactly an issue? Let's do the math: (625 files * 2MB) + (325 files * 2MB) = 1250MB + 650MB= 1900MB Or better said, just the textures from the customization and a single sexscene, bring the total build size to 1.9GB! With at least 10 sexscenes and all the location and NPC textures, the projected size would be near 13GB... Ouch, problem #1. To counter this problem for the first build, we ran it through a 7z compression, which gets the whole build down to 100MB. Yet, it still requires 2GB of space when you want to play it, so this is still far from ideal. As a lot of people noticed, the Coby-sexscene was really slow, or simply crashed on most machines. That's because at least 500 textures of 2MB each (or all of them in worst case), are loaded into the memory at once to perform a multilayered animation. That's 1GB of memory just to show you some sexy time, on top of what the game and your system is already using. Problem #2 was born... • Fixing the problems • Problem #1 had a lot to do with Problem #2. Sex-scenes exist out of 60 HD textures for each layer in the animation. If a sexscene with all customization accounted for has 8 layers, that would mean 60*8*2 = 960MB of space is used on your harddrive for installation, as well as memory when it's being shown. We were wondering why Unity's build remained so big, whereas a simple 7z compression cuts down the size by about 90%. Upon investigating we found out that for a PC build, Unity does NOT compress its packages, with the excuse that PC's generally have more than enough space available (unlike mobile), and therefore don't have to suffer the slowdown caused by having to decompress at runtime. This seems fair, but what blew our minds was that there is literally no way to overrule this, whereas this is default behavior when packaging for Web or Mobile. When you build for PC, you are stuck with uncompressed packages, final. Damn... On top of that, we also found out that no matter how much of a texture is transparent, it does not affect the 2MB size. Given a lot of our textures have over 60% transparency, that's a lot of wasted space over literally nothing. This meant we had to implement our own runtime decompression. We decided to start working on something for the sexscenes, as those are the cause for the massive increase in file-size as well as memory use. • In conclusion • After a few weeks of trying tenths of different compression methods, as well as throwing in some custom-made compression tricks, we are very proud to say we actually managed to drastically decrease file-size! When packaging a sexscene into our custom package format, it's about the same size as they are in PNG format. So Coby's sexscene went from 1250MB to just 100MB! But that's not all, because we are now using a custom image-format, we could also optimize the sexscene. By adding a small loading-screen before it (which in our defense is still a much shorter wait than how it currently works in the public release anyway), we also got memory usage down to about 200-300MB during the loading screen, but just 100MB after loading! Which makes the animation play as you would expect, without any stuttering. • Last but not least • On top of these breakthroughs on two of the most glaring issues we had in Amorous, we also worked on a toolset to make managing our extensive dialogues much easier. The Beat 'em Up was also not left untouched, we ran some Spine-test and implemented a few mechanics and are very happy with the results so far. So two games are being worked on simultaneously now. Does the good news ever stop? No! We are aiming for a new public release somewhere after halfway through January 2015!
