Ren'Py 6.9.0 Released

[PyTom]

The new rendering code had some framerate issues --- of course, not when I was first testing it. I'm uploading 6.9.0d, which is much faster in most cases.

I've also upped the framerate cap to 100fps. 60 was proving to be a problem, as it could synchronize with the monitor's vertical refresh, which could lead to tearing remaining in the same place all the time, and hence looking bad. 100fps doesn't have that problem so much.

I've reverted my windows build chain and rebuilt the windows dependencies, which hopefully will fix the vista problems.

[Watercolorheart]

I'm really starting to hate all the updates now ... I've had no problem updating Always Darkest Before Dawn to each new version, but now I'm getting error after error along the lines of "variable is undefined" ... it's no problem in a smaller oneshot NaNoReno game, but how do I handle that in a massive multi-path game where player may not have encountered something and the variable was empty but still checked for?

I'm also having difficulty using ==True/==False for menu options, and it worked the versions before 6.8, I believe.

Code: Select all

D:\Ren'Py\Always Darkest Before Dawn\renpy-6.8.1\Always Darkest/game/script.rpy:6611 'nave !== True' could not be compiled as a python expression, in the if clause of a menuitem.

D:\Ren'Py\Always Darkest Before Dawn\renpy-6.8.1\Always Darkest/game/script.rpy:6611 'narthex !== True' could not be compiled as a python expression, in the if clause of a menuitem.

[Wintermoon]

I don't think '!==' was ever valid syntax. '==' means "equal", '!=' means "not equal".

Also, you should never compare a boolean for equality. Instead of "x != True" or "x == False", write "not x". Instead of "x == True" or "x != False", write "x".

[jack_norton]

I downloaded the latest build and now works without problems even on my Vista pc. The transform works too, very nice! with some python coding is possible to do even arcade games within renpy now
The movements seems much smoother now. If I wasn't so close to a release I might be tempted to try it directly on my new game.

[Jake]

Also, you should never compare a boolean for equality. Instead of "x != True" or "x == False", write "not x". Instead of "x == True" or "x != False", write "x".

Actually, comparing a boolean for equality is standard practice in several places, because it's easier to understand at a glance. There's certainly nothing wrong with it!

(Although I'd expect "nave == False" rather than "nave != True", certainly...)

[Counter Arts]

Yes! It's working!

So like did you get it to autodetect or something?

In anycase... for the ui.autobar(), for greater smoothness the range,old value and however the new value needs to be multiplied by like 60 or so.

[PyTom]

If I wasn't so close to a release I might be tempted to try it directly on my new game.

I think sticking with 6.8.1 (with the patches on the website) is fine. Unlike most releases, I can't really think of any bug fixes in 6.9.0. That might be part of why 6.9.0 took so long... it's very hard to go through a week-long release campaign when there's nothing wrong with the previous version.

So like did you get it to autodetect or something?

Not in any meaningful sense. The main thing I did was to tweak the drawing code so that Ren'Py draws as little as possible as fast as possible. This was made possible by some test code that I wrote to directly measure the framerate, per delta's nudging. I had been previously measuring the redraw time, which wasn't right. I don't want to release the code itself because the output is hard to interpret... for example, it can say that the framerate is 1000+ fps, which is nonsense caused by the scene graph not changing enough to warrant a screen redraw.

6.9.0d is a big change from 6.9.0c, on the order of 300 new/changed lines of code.

In anycase... for the ui.autobar(), for greater smoothness the range,old value and however the new value needs to be multiplied by like 60 or so.

Or by 1.0. I'll probably make this change in e, and release that as final if nothing else goes wrong.

Thanks again to everyone who's been testing this release. Your work helps ensure the technical quality of future Ren'Py games.

[PyTom]

I just added renpy.partial to 6.9.0. This is just exposing existing functionality, rather than anything new, so I feel pretty secure adding it so late in the release process.

[Jo'ogn]

So far I no problems migrating my project to 6.9.0.d on M$ XP sp3

Subpixel does improve very slow movements, however very small displayables (a bunch of pixels) become blurred.

Sound panning works. However the "delay" only works from center to one side. i.e. the delay should be able to pan from -1 to 1, or vice versa. I tried 'stacking' set_pan, but only the last one pans from 'center out'.

Code: Select all

play sound "lalala.ogg"
renpy.sound.set_pan(-1,0, channel=0) # is 'ignored' (likely overwritten by the following)
renpy.sound.set_pan( 1,2, channel=0)

[PyTom]

Subpixel does improve very slow movements, however very small displayables (a bunch of pixels) become blurred.

This is normal, as the way subpixel drawing works is by spreading a single pixel out over four adjacent pixels.

Sound panning works. However the "delay" only works from center to one side. i.e. the delay should be able to pan from -1 to 1, or vice versa. I tried 'stacking' set_pan, but only the last one pans from 'center out'.

I just fixed this.

[PyTom]

I've released 6.9.0e with two very low risk fixes, and am officially dubbing it 6.9.0.

Enjoy, and thanks to everyone for the thorough testing this release received. I can say, without a doubt, that this is a far better release due to everyone's efforts.

[Jo'ogn]

With the lastest Version. I get a sort of random crash from "Visual C++ Runtime". It might be related to a move(repeat=True).

[PyTom]

Is this 6.9.0? And is this with a subpixel move? And can you isolate it into a test script?

[Jo'ogn]

Is this 6.9.0? And is this with a subpixel move? And can you isolate it into a test script?

Yes, it says 6.9.0d, but should be your 'e' release.

[Preludian]

confirmed with 6.9.0.e here too. Setting suxpixel to False works though, no crash.