That went smoothly

Hi guys I hope you are all well.

First of all, I hope you all enjoyed the update. I know some of you may have had issues with it. I hope the fixes helped.

I've looked more into how Ren'py handles prediction, caching and what I can do to maybe help keep things stable.

First of all I thought I might explain how I implement the animations in Ren'py and why I don't use other ways (Like video files). It's not really important but I thought it might interest some of you. You can always just skip down to the sexy pictures.

So currently the frames for the animations are saved as individual jpegs and I use Ren'py's built in animation and transform language to play them in a loop. Typically it plays and loops perfectly smoothly. Ren'py holds all the images for the animation in memory and just displays them over and over. It's pretty low CPU usage and renpy will also start preloading the images into memory before it's even time to play the animation.

The alternative is a video file. Renpy handles these completely differently. There is no preloading or caching that I can tell. That means every time the video starts it has to load the video file. So if I create a video file with the same amount of frames as the jpeg animation, it will be reloading the file every half a second for so as the animation loops over and over. This creates a very noticeable stutter. I could make the video file longer, containing more loops of the animation, this means it would play longer before it gets reloaded and stutters. I tried this, but there are other issues. Ren'py doesn't use hardware decoding expect on android. So just high frame rate 1080p takes a significant amount of CPU usage.

As I said before, video's don't get cached, so switching between angles and speeds always produces a stutter. The first method on the other hand works great, at least for me. I thought the choice was clear.

Turns out the first solution has a major drawback. Ren'py stores the images in memory uncompressed. So I think about 120 frames takes up about 1GB of memory or so. My 4x interpolated animations were 80 frames each, cache 3 of those and that's 240 frames.

Not a problem when the system I'm testing on has 32GB but a problem for older systems, and especially mobile devices. Then add to the fact it seeming duplicates the images in Vram. Again, not a problem if you have a GPU with 11GB, but if it's an older GPU, or even worse, a integrated GPU that shares it's memory with main system ram. Not good.

So there is a option in Ren'py that can limit the amount of memory used for caching, I think for the future I will set this to 1GB, I'll only use 2x interpolation too, so only 40 frames per animation loop. This should give the best balance between smoothness and stutterlessness (Not sure that's a real word). For android I still may have to go back to just using 20 frames per animation. Oh well. If anyone knows a better way I'm all ears.

Another thing that I read a few reports about was all the animations playing at the same speed. This puzzled me at first as they worked fine for me and the code clearly had the frame times different for the different speeds.

It seems renpy doesn't like playing animations faster than the games refresh rate, or at least it slows them down somewhat. It sets this based on the monitors refresh rate. So the initial set of 4x animations ran at 90fps 120fps and 180fps. If played on a 60hz monitor they apparently would all look the same.

Even using the 2x interpolation they would be 45fps, 60fps and 90fps. The top two speed would appear the same. So going forward Ill play the top speed without using the interpolated frames, 45fps in this example. It should still play smooth because, it's still 45fps after all. Lots of lessons learned I guess.

Enough of that crap. Continuing with some renders commissioned but a few of my top lifetime supporters, we have Karen having some fun with Nikki. You can thank TheGreatCornholio for this one.

I hope you like them. There is also a third "Alternative" render that was requested. I'll only attach it below as it might not be for everyone.

That's all from me this week guys. Thank you all as always and take care.