Major Optimization Success

In my last dev log I detailed the new display class that is responsible for most of the heavy lifting  of displaying multiple characters. Towards the end of the post I discussed the performance, which I described as "between poor and acceptable ", which wasn't exactly a glowing review of the system. Unsatisfied with that, I decided to revisit the animation code and see what improvements could be made.

tl;dr - Animation is now much more efficient, as much as x4 as fast.

I wasn't very optimistic starting off; the code that makes the animation possible is a mix of 3rd party shader support that hasn't been updated for two years and my own additions of jank to get it running at all. The basic operation is to take a character Displayable and pass it into Ren'py's screenshot function (which is normally used to produce the thumbnails for save slots), then take the resulting Surface and save it as a .png file temporarily, and pass that file to the shader code to manipulate using openGL shaders.

After some poking around I had a realization: the screenshot produced by Ren'py is always the same size as your physical screen (2560 x 1440 for me), and the character is placed on the left side of that screenshot (taking up about 25% of it, depending on the pose). The resulting surface is cropped to only contain the character, but the entire (mostly black) screenshot is still being loaded into memory and manipulated! After diving into some Ren'py documentation, and eventually just reading through the source code on github, I was able to take a subsurface of the screenshot, passing only the interesting parts of it to the animation code. The total change is one new line of code and tweaks to some book keeping variables.

The improvements from that change have been massive. Previously a single animated character took the frame rate from 100 (capped by Ren'py) down to 30, and if two people were having clothing fade away it dropped to a very noticeably jittery 8. After the change a single person being displayed drops my FPS down to 90, and I have tested up to 3 people stripping down (meaning 6 rendered character images) while maintaining smooth animations and an FPS floating around 18. Before the change there was a delay when displaying a character of between 0.12 and 0.14 seconds while the surface was saved as a .png. With the properly cropped subsurface that is now a 0.03 to 0.035 second process, which has reduced the animation display delay to a very minor level.  On average it seems like a 300% increase in performance, which seems to line up proportionally with the decrease in Surface size.

As an extra bonus I have now properly tied the Surface size into the scaling code, eliminating the need for a manually set animation scale factor to support some high res displays. This improvement has also opened up the path for a future quality setting that scales the size of the image being screenshot-ed to reduce the size of the resulting Surface. I may use one of the bug testing weeks after a release to experiment with this and see if the performance gain stays linear with decreasing Surface size.

For now I am happy enough with the performance to turn my attention to adding some new content!