Ren'Py Laggy loops in Ren'py

[KeklorGames]

When I put in an animation I recorded on a loop in my game, it always keeps stuttering. It is just a 100-120 frames loop that's smooth when I preview it in vegas and stutters in renpy. Any way around this?

 

[Rich]

How did you create the animation? As a video? Or is it a series of images that Ren'py animates using ATL?

If it's the latter, you're probably running into issues with Ren'py's image cache - Ren'py's image loading system isn't designed for this kind of thing (animations made with a very large number of large frames).

 

[KeklorGames]

How did you create the animation? As a video? Or is it a series of images that Ren'py animates using ATL?

If it's the latter, you're probably running into issues with Ren'py's image cache - Ren'py's image loading system isn't designed for this kind of thing (animations made with a very large number of large frames).

It's actually a video, rendered in vegas as a 1080p 30fps mp4 and converted to webm and ogv using vp8 and vp9 encoding. Both had the same results. I kind of resolved the issue where I put on around 4 loops of recorded video and then the stutters on the actual ren'py loop are much less noticable. Although still kind of noticable and it will make the game bigger in the end, which is kind of not ideal. Still looking for a fix though.

 

[polywog]

It's actually a video, rendered in vegas as a 1080p 30fps mp4 and converted to webm and ogv using vp8 and vp9 encoding. Both had the same results. I kind of resolved the issue where I put on around 4 loops of recorded video and then the stutters on the actual ren'py loop are much less noticable. Although still kind of noticable and it will make the game bigger in the end, which is kind of not ideal. Still looking for a fix though.

renpy uses ffplayer which can be scripted to loop frames of a video. loop starting at frame 20 - 59. You can actually play video forwards and backwards, and write in some interactivity for the player, if you wanted to. For example, moving the mouse can make the player fuck faster, or slower adjusting the frame rate, etc. I posted some scripts previously, but you can google the docs if you're interested.

 

[KeklorGames]

renpy uses ffplayer which can be scripted to loop frames of a video. loop starting at frame 20 - 59. You can actually play video forwards and backwards, and write in some interactivity for the player, if you wanted to. For example, moving the mouse can make the player fuck faster, or slower adjusting the frame rate, etc. I posted some scripts previously, but you can google the docs if you're interested.

That sounds really interesting, I will definitely look into the docs or try to stalk out the scripts from your history. I had no idea it could do something like that. Thank you for the help

 

[8873672413434]

You can also clear the Ren'Pys cache before the Animation starts. (This isn't always ideal, sort of a last resort.)
Also make sure that all the scenes/images in the script that have been "Shown" are "hidden" after that scene. As Ren'Py will still store it, which can cause potential lag in your animation and future scenes.

 

[Rich]

It's actually a video, rendered in vegas as a 1080p 30fps mp4 and converted to webm and ogv using vp8 and vp9 encoding. Both had the same results. I kind of resolved the issue where I put on around 4 loops of recorded video and then the stutters on the actual ren'py loop are much less noticable. Although still kind of noticable and it will make the game bigger in the end, which is kind of not ideal. Still looking for a fix though.

Hmmm. What kind of bitrate is the video using? If it's quite high, perhaps Ren'py is having trouble keeping up with the required decode rate. I don't have this kind of problem, but the videos I tend to create are probably substantially smaller than yours, being both 720p instead of 1080p, and also running at 24fps instead of 30fps. It might be an interesting experiment to re-code the video at a lower bitrate to see if that makes a difference. (Not that you may want to use the lower bitrate, since it'll be lower quality, but it might indicate where the problem potentially lies.)

Other speculation (and it's just guesswork) is that it might have something to do with the process via which you create the video - things like "how many p- and b-frames vegas generates" that cause the video to be harder for Ren'py to work with.

 

[KeklorGames]

Hmmm. What kind of bitrate is the video using? If it's quite high, perhaps Ren'py is having trouble keeping up with the required decode rate. I don't have this kind of problem, but the videos I tend to create are probably substantially smaller than yours, being both 720p instead of 1080p, and also running at 24fps instead of 30fps. It might be an interesting experiment to re-code the video at a lower bitrate to see if that makes a difference. (Not that you may want to use the lower bitrate, since it'll be lower quality, but it might indicate where the problem potentially lies.)

Other speculation (and it's just guesswork) is that it might have something to do with the process via which you create the video - things like "how many p- and b-frames vegas generates" that cause the video to be harder for Ren'py to work with.

I tried re-encoding them with HandBrake, so I don't think that's the problem, but I don't think I ever touched the bitrate settings, it's an interesting thing to take a look at. I thought that the problem might be that it could run better when you compile a build, but that didn't seem to be the case. I'll try to experiment with fps and the bitrate.

You can also clear the Ren'Pys cache before the Animation starts. (This isn't always ideal, sort of a last resort.)
Also make sure that all the scenes/images in the script that have been "Shown" are "hidden" after that scene. As Ren'Py will still store it, which can cause potential lag in your animation and future scenes.

If I read the documentation correctly "scene" should clear the current cache if I am not wrong, so cache hopefully isn't a problem in this case.

 

[8873672413434]

I tried re-encoding them with HandBrake, so I don't think that's the problem, but I don't think I ever touched the bitrate settings, it's an interesting thing to take a look at. I thought that the problem might be that it could run better when you compile a build, but that didn't seem to be the case. I'll try to experiment with fps and the bitrate.




If I read the documentation correctly "scene" should clear the current cache if I am not wrong, so cache hopefully isn't a problem in this case.

You can also do the clear.image cache, i don't fully recall the code. But it's in the Ren'Py docs.

 

[Rich]

If I read the documentation correctly "scene" should clear the current cache if I am not wrong, so cache hopefully isn't a problem in this case.

I don't think the "scene" command clears the cache - it clears images being displayed on a layer, but I don't think it directly involves the cache. As I understand things, Ren'py normally tries to predict the image(s) you're going to need a couple of statements ahead and tries to have those pre-loaded in the cache via a background process so that the user doesn't see any "loading the images off disk" lag when new images are called up. This is where ATL animations with a large number of images (which I know isn't your case) can run into problems - if Ren'py can't fit all those images into the cache, you get a lot of disk thrashing constantly loading images.

 

[anne O'nymous]

I don't think the "scene" command clears the cache

It don't. The only thing cleared by scene is the screen layer (perhaps a little more but I'm not sure right now). It wouldn't make sense that the (should be) most used image statement clear the cache when called, since it would make both the cache and the prediction mechanism totally useless.

As I understand things, Ren'py normally tries to predict the image(s) you're going to need a couple of statements ahead and tries to have those pre-loaded in the cache via a background process so that the user doesn't see any "loading the images off disk" lag when new images are called up. This is where ATL animations with a large number of images (which I know isn't your case) can run into problems - if Ren'py can't fit all those images into the cache, you get a lot of disk thrashing constantly loading images.

That's exactly that. And like, as far as I remember, movies aren't cached, clearing the cache would change nothing here.

The only thing that can perhaps works is to improvise your own cache-like feature. You use a screen, shown few interactions before you'll effective need the movie, to display the movie, but to do it outside of the game screen. Something like :

image myMovie = Movie( play="07_03_din.avi" )

screen myMovieCache:
    add "myMovie":
        xpos config.screen_width + 10
        ypos config.screen_height + 10

label start:

    show screen myMovieCache
    "blablabla"
    "blablabla"
    hide screen myMovieCache
    show myMovie

It will change nothing on Ren'py side, but it should put the movie inside either the cache of the hard disk or the one of the OS. By using parameters it's possible to reuse the same screen to cache any needed movies.


This said, here the problem seem to appear when the movie is played, not just when it start. So it's probably not that it take time to be loaded, but that it's too big for the game to fully load it. And there's no workaround for this except redoing the movie for it to be smaller.

 

[Canto Forte]

Is there a problem with the loops if they are in the images but do not ... errr ... loop?

This was reported early on for high rise climb ... the scene in the bathroom and several others, right at the beginning of the game, they never loop, there is a button for again - which basically does nothing as there is no functioning loop - and this seems to never have been addressed.

I am asking if this suggested work around that is supposedly necessary in all rpy scripts of the game has, at least theoretically, any chance to fix this problem.

Here is the proposed fix:

i think the bug with some renders not displaying at all, and ending 'animations' not replaying on Again button is when you jump to a label you may have scene pictures without dialogue and separated only by "pause 1" lines. i think pause doesnt work here and renpy skips all these pictures to the next one with dialogue.

what fixed it for me was adding a dummy character in script.rpy like so:
define filler = Character("")

open all rpys in np++.
then do two preliminary replacements (to avoid false hits in final stage):
pause 10 -> pause 20
pause 1.5 -> pause 1

finally replace in all rpys:
pause 1 -> filler " "

Hit Save All in np++.

 

[anne O'nymous]

Is there a problem with the loops if they are in the images but do not ... errr ... loop?

According to what I understood of the message you quoted, the actual animation look like this :

    scene frame01
    pause 1
    scene frame02
    pause 1
    scene frame03
    pause 1

Theorically, it shouldn't be a problem, since it use the pause statement ; it would have been different if it was $renpy.pause, the optimization would have attached them to the previous statement, and perhaps made the pause transparent.

This said, it's not how it should be done, and the "fix" that add a blank dialog between them is worse. An animation should be done by using the

You must be registered to see the links

(ATL). Something like this :

image myAnim:
    "image/frame01.png"
    pause 1
    "image/frame02.png"
    pause 1
    "image/frame03.png"

label whatever:
    show myAnim

 

[Canto Forte]

Thank you, o great one, for the help ... but as it were, the $#@#%@ is on the dev side:

Its fine actually the Angela animations didn't come out well enough last minute so I cut them and probably going to stop doing animations because they are costing me too much time so there was suppose to be Angela content but I get your point.

Ah! I saw the slower/faster options that did nothing, and was perplexed. Looking at the extracted images, I thought is saw that the frames are there... but using full page renders for animations seems like a resource sink, when sprites are probably a better option, for both render times and file size... Corrupting the Intern seems to do a ton of sprite based dev well-ish.

The problem with spirits is... they loose all shadows however slight the shadows may seem in most spots if you don't have them they become eye catching... or else the render time actually is nearly the same... I think the reason the art is the way it is, is because I don't use spirits, but you guys have fun or not have fun... download or don't download the 1GB... its up to you guys.

The catch is, actually, the sheer ego of the fact that, the very first scenes are botched animations that this dev chose to leave in his game, even though he got to actually implement animations through clips much later in the game.

Happy gaming!

 

[anne O'nymous]

The catch is, actually, the sheer ego of the fact that, the very first scenes are botched animations that this dev chose to leave in his game, even though he got to actually implement animations through clips much later in the game.

It happen too often. The games are released as update, and too many devs decide that what is already done shouldn't change. I can understand when it's the game mechanism, but when it's the CG it make less sense

 

[Deleted member 1952336]

Hi. I know this is an old thread but I had this problem and found a solution.

For me, if the video is greater than about 2mb's it will stutter between each loop.

So I changed them from 60fp to 30fps so that I could make them a little longer. I've found with webm, I'm usually able to do about a 4 second loop at 30fps, 1080p resolution.