Welcome to the sponsor-exclusive content for the Ren'Py Patreon. Sponsors like you ensure this page exists. Thank you.
Welcome to the Ren’Py developer update for June 2021. Within a few hours of this being posted, we’ll be halfway through 2021, and I’m proud of what I’ve been able to accomplish this year so far. We’ve had six releases of Ren’Py so far, with a seventh being made ready, and plans for the rest of the year firmly in hand.
As usual in this update, I’ll talk about what I’ve accomplished in June, and what to expect. I’ll also talk a bit about a new feature that will help you with web releases of your game.
One of the more interesting things I did this month was to add the camera
statement, which provides a way to apply transforms to a layer in a way that
show layer was having problems with.
The camera statement is meant for use with 3D stage, and has the advantage
that it persists past a scene statement, which clears the transforms set
with show layer. I had a lot of feedback from creators that the change in
show layer was a bit too much for them, and so I chose to introduce a
similar but different statement.
While I was at it, I decided to make some improvements. Since camera operations
are generally applied to the master layer, but not the screens, the camera
statement applies to the master layer by default.
So now, it’s possible to set up the 3D Stage at the start of your game with a simple:
label start:
camera:
perspective True
scene bg whitehouse
show eileen happy:
zpos 100
Which I think looks pretty reasonable.
The next big thing was getting 7.4.6 out the door. While it took maybe a bit longer than I’d expected, the release process went smoothly, and it contains a number of bug fixes.
There’s one known regression in 7.4.6, which is that in some cases, the show event isn’t being generated properly. I’m going to be looking at this over over the next few days, but I wanted to develop for a week or so before going back to fixing issues.
What I spent that week on was a rewrite of the way sound is handled in the web version of Ren’Py, to fix the longstanding issue of the sound ‘crackling’ when played in a web browser.
A problem with web browsers is that they generally only let a web page use a single core of your computer. (While there is a technology, web workers, that allows multiple cores to be used, web workers aren’t really compatible with the way the Ren’Py port works.) However, there’s an exception to this, which is that audio is played on a second core.
What I’ve managed to get working is a second copy of the portion of Ren’Py responsible for playing audio. This second copy passes the audio files to the browser’s audio playback API, which can generally play the files without stuttering. The result, assuming the files are supported properly, is a nice improvement - the really obvious audio stuttering is gone, and since Ren’Py isn’t playing back sound itself, Ren’Py has more time to render the screen and load images.
There is one problem this introduces, which is that for this to work, the web browser has to support the audio file format. This isn’t a problem in Firefox, Chrome, and other Chromium derived browsers (Edge, Opera, etc), as these browsers support mp3, ogg vorbis, and opus, which are the three most popular audio formats in Ren’Py games. However, of those three, the only one that is supported in Webkit-based browsers, like Safari, is mp3.
To deal with this, I added a feature that makes it possible to substitute one audio file for another. I’ll describe how to use this below.
At least on some platforms, Ren’Py may not begin playing sound until it has been clicked once. That’s to prevent ads from playing sound by default, and is something we may need to accept.
You can see the new version of Ren’Py running The Question here <https://share.renpy.org/tq/>, and if you want to try it with your own game, the nightly builds <https://nightly.renpy.org/> are the way to go.
Continuing on the web topic, I’ve been tracking a bug in Webkit-based browsers on Arm platforms, like Safari on Apple Silicon, as described last month. This is now being tracked in the Webkit-based bug tracker, and 7.4.7 will come with a slightly better error message when this problem is detected.
Hopefully, this will be addressed in future releases of macOS and iOS, so games can run on those platforms.
Right now, I’m thinking about the next couple of releases of Ren’Py. 7.4.7, apart from the webaudio improvements, is going to be focused on fixes in general, with only a couple of small features.
While I haven’t started work on it, 7.4.8 is probably going to be focused on making sure Ren’Py can release packages in the Android App Bundle format, which is going to be required for new games on the Play Store starting August 1. While I’m not sure I’ll hit that deadline, my hope is to at least have a nightly ready to go.
Finally, a new feature coming in 7.4.7 is config.audio_filename_callback.
If set, this is a function that’s called with every audio filename being played, and is expected to return a second filename that replaces it. For example, to only play .mp3s, as a Webkit-based browser would require, you can add to your game:
init python:
def audio_filename_callback(fn):
base, dot, ext = fn.rpartition(".")[0]
return base + ".mp3"
config.audio_filename_callback = audio_filename_callback
If you then go through converting all of your .ogg and .opus files to .mp3 files, you can package your game for the web and have it work in all supported browsers.
This is also useful to convert a game that used .mp3s to a more modern format, like opus. You can write:
init python:
def audio_filename_callback(fn):
base, dot, ext = fn.rpartition(“.”)[0] return base + “.opus”config.audio_filename_callback = audio_filename_callback
And now the opus files will be played.
That’s it for this month’s update. Thank you for your support, and I look forward to keeping up the pace of Ren’Py development in the second half of this year.