Re: RenPy 6.99.13 Prereleased
Posted: Sat Oct 21, 2017 10:48 pm
6.99.13.2890)
https://www.renpy.org/release/6.99.13
This release has a single change in it - and it's a doozy.
Ren'Py has a function, called audio.periodic, that's basically responsible for playing sound and music. This function is called 20 times a second, and checks to see if any music needs to be played. It also does thing like loading up queued music when the music loops.
The problem happens when scanning for and opening sound files. Usually, this is quite fast. But until now, it's been running in the main Ren'Py thread, which is what's responsible for drawing the screed without a glitch. If there was extra disk access, things like that, opening the music file could take unacceptably long and you could see that in certain animations. It me most of a year to identify the cause of this issue, mostly because I use solid state drives that are fast enough that it is rarely a problem. (Thanks go to Morgan Willcock for figuring out the cause.)
The fix is to create a second thread of execution for the periodic sound task. This way, loading files can take as long as necessary, and drawing the screen isn't affected. But this is a major change very late in the release process. I've been testing quite a bit here, and will test more. But I ask people to also try this with their own games, and see if there is any change in behavior.
Thanks for everyone who's tested so far - your contributions, as always, have massively improved Ren'Py.
https://www.renpy.org/release/6.99.13
This release has a single change in it - and it's a doozy.
Ren'Py has a function, called audio.periodic, that's basically responsible for playing sound and music. This function is called 20 times a second, and checks to see if any music needs to be played. It also does thing like loading up queued music when the music loops.
The problem happens when scanning for and opening sound files. Usually, this is quite fast. But until now, it's been running in the main Ren'Py thread, which is what's responsible for drawing the screed without a glitch. If there was extra disk access, things like that, opening the music file could take unacceptably long and you could see that in certain animations. It me most of a year to identify the cause of this issue, mostly because I use solid state drives that are fast enough that it is rarely a problem. (Thanks go to Morgan Willcock for figuring out the cause.)
The fix is to create a second thread of execution for the periodic sound task. This way, loading files can take as long as necessary, and drawing the screen isn't affected. But this is a major change very late in the release process. I've been testing quite a bit here, and will test more. But I ask people to also try this with their own games, and see if there is any change in behavior.
Thanks for everyone who's tested so far - your contributions, as always, have massively improved Ren'Py.
