How Does Ren'Py Handle Framerate?

[LateWhiteRabbit]

Okay, so I'm hoping PyTom or some Ren'Py code veterans can answer some questions about how Ren'Py handles framerate.

I've been getting some weird results when I test frames per second in Ren'Py games. The framerate is quite literally all over the place. Anywhere from 3-55 frames per second. Now, I know that Ren'Py 'sleeps' and automatically drops the framerate when it doesn't think it is needed, i.e. on a static screen, etc. and tries to ramp it back up when needed in a way that won't be noticeable.

Most of the time, this seems to work and makes sense - a visual novel displaying static images and advancing one click at a time doesn't need a high frame rate, and perceptually 5 frames per second works as well as 60 frames per second.

However, in games with a lot of input and rapid clicks between screens - i.e. large map interfaces, nested image maps, etc. the responsiveness does NOT feel good. It makes the input feel sluggish.

So, is there a way to turn off the framerate management that Ren'Py is doing? I know I can use:

Code: Select all

renpy.maximum_framerate(t)

To make it run at the maximum number of frames I've defined in config.framerate, where t is the number of seconds to make it do this. Could I just theoretically put in like 86400 seconds for t, so the game would constantly run at the defined framerate (if the player's device is capable) even if they left the game running for 24 hours? Or would this introduce Bad Things™?

I'm also curious why even though I am running a Ren'Py game on an Nvidia 980TI, with an i7-4700K CPU, on a solid state drive, with a 60hz monitor (Windows 8.1), none of my tests hit 60 FPS? I should note that these tests have all been on demos that are not of my own creation, just some of the most demanding Ren'Py games I could find, stuff like Hanako Games titles, Jack's Winter Wolves games, and the Pirate Mermaid demo. I don't think any of them have used the latest build of Ren'Py (6.99.13.2919 as of the time of making this post).

As I've stated, my only concern with the framerate is that the response time does not feel good. There is often (not all the time) a perceptible delay between clicking and something happening. While monitoring the framerate, I can see this is when Ren'Py (apparently) does not spin up out of 'sleep mode' quickly enough. Or isn't predicting needing to? I don't know exactly how it works - that's why I'm asking.

Apologies, but the last thread I found on a similar topic was from 2008, and I know Ren'Py has come a very long way in that time and had many changes since then.

Thanks for reading this wall of text. I appreciate any insights on the topic.

[PyTom]

However, in games with a lot of input and rapid clicks between screens - i.e. large map interfaces, nested image maps, etc. the responsiveness does NOT feel good. It makes the input feel sluggish.

My guess is that a lot of this would have to to do with unpredicted image loading. You can see this by hitting shift+D to get to the developer menu, and telling Ren'Py to show the image load log. A problem as of late is that people seem to be using some of the dynamic things Ren'Py allows as their main ways of updating character art. For example, one can do:

Code: Select all

image eileen = "eileen [emotion].png"

label start:
    $ emotion = "concerned"
    show eileen
    "Eileen" "I'm concerned"

    $ emotion = "happy"
    "Eileen" "I'm happy."

But the problem is that since we're updating a python variable, Ren'Py can't predict into the future and decide to load eileen_happy.png. By contrast, if we were to do:

Code: Select all

label start:
    show eileen concerned
    "Eileen" "I'm concerned"

     show eileen happy
    "Eileen" "I'm happy."

Ren'Py can load the "eileen happy.png" image from disk while it's waiting for the player to click. Until 6.99.13, there was a similar issue with audio files - a looping audio file would block the main thread.

I think we've moved to a style where it's hard to predict images, which is causing more of these problems. I have some ideas on how to fix that, which I think will fundamentally involve adding more predictability to image loading by allowing creators to move back to images with attributes rather than python images.

So, is there a way to turn off the framerate management that Ren'Py is doing? I know I can use:

Code: Select all

renpy.maximum_framerate(t)

To make it run at the maximum number of frames I've defined in config.framerate, where t is the number of seconds to make it do this. Could I just theoretically
put in like 86400 seconds for t, so the game would constantly run at the defined framerate (if the player's device is capable) even if they left the game running for 24 hours? Or would this introduce Bad Things™?

That will work for testing purposes. Ren'Py doesn't persist maximum_framerate into saves or anything like that, so you might want to make sure it's called frequently. (For example, in an interact_callaback.)

config.framerate is obsolete (or rather, it's only used by the obsolete software renderer).

I'm also curious why even though I am running a Ren'Py game on an Nvidia 980TI, with an i7-4700K CPU, on a solid state drive, with a 60hz monitor (Windows 8.1), none of my tests hit 60 FPS? I should note that these tests have all been on demos that are not of my own creation, just some of the most demanding Ren'Py games I could find, stuff like Hanako Games titles, Jack's Winter Wolves games, and the Pirate Mermaid demo. I don't think any of them have used the latest build of Ren'Py (6.99.13.2919 as of the time of making this post).

I'm not sure. I'll note that something seems weird about your framerate measurements - Ren'Py should never go below 5 fps, and I'm pretty sure we can hit that consistently. So I wonder if the measurement can be off by a few fps.

As I've stated, my only concern with the framerate is that the response time does not feel good. There is often (not all the time) a perceptible delay between clicking and something happening. While monitoring the framerate, I can see this is when Ren'Py (apparently) does not spin up out of 'sleep mode' quickly enough. Or isn't predicting needing to? I don't know exactly how it works - that's why I'm asking.

This gives me an idea, actually. I'm wondering if it's taking a few frames to push things through the GPU and out onto the screen. I'm going to look at making Ren'Py "Throttle up" for a few frames when the user causes the screen to redraw, to see if that can help. (That should be in 6.99.13.1, with a prerelease due out todayish.)

[LateWhiteRabbit]

My guess is that a lot of this would have to to do with unpredicted image loading. You can see this by hitting shift+D to get to the developer menu, and telling Ren'Py to show the image load log. A problem as of late is that people seem to be using some of the dynamic things Ren'Py allows as their main ways of updating character art.
[snip]
I think we've moved to a style where it's hard to predict images, which is causing more of these problems. I have some ideas on how to fix that, which I think will fundamentally involve adding more predictability to image loading by allowing creators to move back to images with attributes rather than python images.

Ah, so maybe some of this could be relieved with different scripting practices?

So, is there a way to turn off the framerate management that Ren'Py is doing? I know I can use:

Code: Select all

renpy.maximum_framerate(t)

To make it run at the maximum number of frames I've defined in config.framerate, where t is the number of seconds to make it do this. Could I just theoretically
put in like 86400 seconds for t, so the game would constantly run at the defined framerate (if the player's device is capable) even if they left the game running for 24 hours? Or would this introduce Bad Things™?

That will work for testing purposes. Ren'Py doesn't persist maximum_framerate into saves or anything like that, so you might want to make sure it's called frequently. (For example, in an interact_callaback.)

I've got my graphics options in their own .rpy file, and right now for testing purposes, it really doesn't have anything in it except for the renpy.maximum_framerate(86400) line, but that throws an error and tells me it was expecting a statement. I'm not sure what I'm doing incorrectly with it.

config.framerate is obsolete (or rather, it's only used by the obsolete software renderer).

Argh. I knew that. And I had forgotten it.

I'm not sure. I'll note that something seems weird about your framerate measurements - Ren'Py should never go below 5 fps, and I'm pretty sure we can hit that consistently. So I wonder if the measurement can be off by a few fps.

I've definitely seen my FPS counter hit 3 multiple times. For reference, I'm using Nvidia's Shadowplay to monitor FPS while running the Ren'Py games. It happens most often when the game is sitting on a map screen where you can highlight and pick different locations. The 'sleep mode' drops the framerate to 5 when sitting on that screen (natural, since nothing is moving and everything is static for the moment), but when you move the cursor over the hotspots and the hover images swap in, the framerate drops to 3 for a second before hitting 5 again. This is where the unresponsiveness feeling becomes noticeable.

This gives me an idea, actually. I'm wondering if it's taking a few frames to push things through the GPU and out onto the screen. I'm going to look at making Ren'Py "Throttle up" for a few frames when the user causes the screen to redraw, to see if that can help. (That should be in 6.99.13.1, with a prerelease due out todayish.)

While the "throttle up" and "throttle down" behavior is impressive and seems to work well for the most part - is there an option to disable the throttle down completely? I know 2D games can sometimes be deceptively demanding, but forcing a 1080p game made of mostly static images to run at 30 FPS or 60 FPS constantly shouldn't be that demanding to any desktop from the last few years. It seems like it would be worth opening up as a preference option for players. Some people may have less powerful laptops and want to run a Ren'Py game in a window while they do other things, and some players like myself have beastly desktop systems with processing to spare, and want to max the performance out of every application we are running.

[jack_norton]

Wouldn't be the easiest solution to allow developer to pre-load textures/images as needed? what the old texture_cache was doing? I mean, Ren'Py is great for loading things on the fly with zero loading times, but sometimes in particular situations you might want to preload 50 small textures like in the map example to have a smooth experience?

[LateWhiteRabbit]

Wouldn't be the easiest solution to allow developer to pre-load textures/images as needed? what the old texture_cache was doing? I mean, Ren'Py is great for loading things on the fly with zero loading times, but sometimes in particular situations you might want to preload 50 small textures like in the map example to have a smooth experience?

That would probably work well too. I think any interface, menu, inventory, or map screen graphics need to stay pre-loaded.

The slight delay in response time isn't noticeable when you are simply clicking through dialogue, or doing something like saving the game, but once you start opening screens with multiple hover images, where the player is expected to make multiple nested clicks in short order, this becomes very noticeable. This actually gets worse/more noticeable the longer a player interacts with the game, simply because the player becomes more familiar with the menus and maps and is interacting with them faster and faster.

Ideally, I'd like to see 100ms delays or less with things like hover images and click responses. I think the general professional consensus is that 150ms is the largest latency in response before it becomes noticeable and affects enjoyment or performance. I'm pretty sure I've seen PyTom mention this number as a goal in the past.

It is a weird situation, where some Ren'Py games FEEL like they are running badly on my system - but in reality it is just the predictive framerate jumping up and down. For instance, The Pirate Mermaid demo was where I first noticed that something really odd was going on, because Arowana and team have included a menu option to swap between full animations and simple animations. I was getting what felt like MUCH better performance from the game when the full animations were enabled, and what felt like delays and stuttering when the full animations were disabled. What I discovered monitoring the FPS with Shadowplay was that Ren'Py kept the framerate a lot higher on the full animation setting, and didn't drop down so low before throttling back up as it did with the simple animation setting.

I still think the best option would be to put the decision in the hands of the players, via a Preferences option about what they would like Ren'Py to do - either favor the less taxing predictive framerate behavior, or tell Ren'Py they prefer maximum performance. Or / and as Jack said, perhaps introducing a way for developers to tell Ren'Py that certain graphics need to always be pre-loaded in the texture cache while the game is running, but I'm not sure this would entirely solve the responsiveness issue when the framerate is jumping between 3-50+.

[SeventhHeart]

Hello everyone!

I'm not sure if this is the right place to ask this question, or if I should start a new thread, but my curiosity is the following:

Ren'py behavior currently limits the fps to 60 fps, but given the rise of smartphones and monitors with high refresh rates, I was curious if there is any setting that could enable it to go higher, like 120 Hz / fps?

[Imperf3kt]

For what purpose? A screen refresh merely deletes everything on the screen, then draws the next frame. When the frame is identical to the previous one it is essential to limit frames to preserve battery life on devices like Android, since you offer absolutely no advantage and only negative impact on the device life.

It'd be like typing a document, printing it, then editing it with no changes and reprinting it. Why? All you'll accomplish is wasting ink and paper.

[PyTom]

Ren'Py doesn't limit the framerate to 60hz if your monitor supports higher.

[SeventhHeart]

@imperf3kt - The point of trying to enable higher refresh rates is for animations to look smoother. I use a lot of animation while programming and I was curious if it would be possible for renpy to sync with the refresh rate of the display when a device shows 120Hz or 144hz so that there is no screen tearing during animation, and generally to experiment with it and see what is the best resource / aesthetic balance

@PyTom - Thanks a lot! I've been following the updates, but since VNs are more static in nature, while no transition happens, I never noticed if refresh rate was tackled.

I agree that higher refresh rates are not useful when the display shows the same image, for example a static scene, but transitions, especially long animated parts, I was curious how Ren'Py behaves with higher refresh rates.

Is it possible for Ren'py to force the framerate to be limited to a certain number? For example, for Android devices, to always limit it to 60Hz, or it always renders at the display refresh rate?

[Imperf3kt]

I still don't really see the benefit and adding animations at 120 frames per second will use a considerable amount of memory / may not even be possible.
If you truly must use higher framerates, use a video format, but just food for thought, all animation done by large anime studios like Studio Ghibli etc only use 10 frames per second of animation (despite the standardised bluray format being 24fps)
You really don't need 120fps+ for smooth animations.