Ren'Py 6.11.0 Pre-Released

[PyTom]

You can change the layer order using the config.layers variable.

[PyTom]

I've just pre-released 6.11.0d. This should fix all of the bugs reported here. If you have an issue, please make me aware of it. Changes include:

- The "call screen" statement uses an interaction type of "screen".
- In GL-mode, most code is now shared between fullscreen and displayable videos.
- Imagedissolve uses the correct texture units.
- The Mesa GLX Indirect renderer is now blacklisted.
- The screen language can deal with non-English strings.
- Textures are now deallocated on shutdown (rather than relying on the system to collect them).
- $foo = 1 works again.
- Prevent "zombie" compile errors.
- Use "button_text" as the style for button text.

I've been working on making sample screens, and that led to a few changes:
- Fixed bugs in various actions.
- Added the "has" statement, to include a container inside a displayable without an extra level of indentation.
- Added the "group" property, which automatically assigns style names to displayables.
- Added the layout.yesno_screen function, for create screen-friendly yes/no prompting.
- Added automatic creation of styles, eliminating much manual style declaration.

Finally, holding down the control key while Ren'Py starts up will cause it to disable the OpenGL renderer, and revert to software rendering.

I'd like to thank everyone who tested the first three pre-releases of 6.11.0, and especially those who helped me track down often inscrutable bugs. Your help has made this a far more solid release, and your continued support is what will help us make it to a 6.11 final.

Non est ad astra mollis e terris via.

[Mihara]

- In GL-mode, most code is now shared between fullscreen and displayable videos.

Ummm....

Tutorial still fails to display anything but a black screen during renpy.movie_cutscene on Eee 901/Linux. Displayable plays fine, although, with an extra 0.5s delay before start which wasn't there previously.

When trying it in non-GL rendering mode, the situation is reversed - displayable is black, while fullscreen cutscene movie plays fine.

Here's a fresh opengl.txt...

[PyTom]

Can you try replacing renpy-6.11.0/audio/audio.py with the attached version?

[adelhaid]

I've found a bug in 6.10, which probably exists in 6.11 as well.
The problem occurs when adding RTL support with the following code:

Code: Select all

    config.rtl = True
    style.default.xalign = 1.0
    style.default.text_align = 1.0

The RTL works fine, but this is what you get when pressing Shift + D:



The last two lines in this code don't work in 6.11, so maybe it was solved. I guess there's some other way to add RTL now, and I'll be glad to know it.

[Mihara]

Can you try replacing renpy-6.11.0/audio/audio.py with the attached version?

Done. No change whatsoever from previously reported -- GL mode plays displayable and fails to play fullscreen, non-GL mode plays fullscreen and fails to play in a displayable.

[backansi]

One minor problem here:
Can't move bars in theme test menu of developer menu.

[Spiky Caterpillar]

Starting and quitting the tutorial game in 6.11.0d no longer leaks resident memory noticeably, but still causes Xorg's virtual memory use to go up on my main machine. xrestop doesn't show anything leaking, but xrestop didn't show anything leaking before. I'm vaguely wondering if perhaps the memory use is something to do with my graphics card being an integrated graphics chip that steals main memory, but I'm not sure what to do to bring it under control if it is.

If I start Ren'Py with the control key held down, I have to place the window twice, and (oddly) Xorg's VM use goes down a tiny bit.

[Spiky Caterpillar]

I suspect that the leak's in Debian's X server rather than in Ren'Py, since I see discussions of what looks like it may be the same problem over in Ubuntu bug#565981.

[jack_norton]

If I understood correctly the font "g" bug isn't yet fixed, right? (just asking since I tried new version and still see the g letter sligthly "corrupted".
About this bug I noticed a strange thing: if there's not line below the one in which the "g" is displayed I see the corruption, instead if there's another line below, I see the letter g just fine!
Sent you an email with a bug report from an user on W7 netbook (in mine works fine!).

[Spiky Caterpillar]

It looks like the rendering performance check isn't working quite right, as 6.11.0d is happily using the Mesa Project Software Rasterizer instead of falling back to actual software rendering. (Control works, though it looks like it goes ahead and initializes the GL renderer before checking to see if control is pressed.)

[jack_norton]

I have another tester with a bug on startup, was using old version 6.11c, so not sure if yo have already fixed this. Here is the openGL error.

[Spiky Caterpillar]

I've figured out a bit more about the leak. With debugfs mounted, memory eaten up by GL objects is listed in /sys/kernel/debug/dri/0/gem_names . If I start the launcher, two 2097152-byte objects will show up. (The very first time I start the launcher, a 16777216-byte object will show up; this will never die, but there is only ever one of them so I suspect that it's used internally by X and simply not initially created until it actually initializes GL.)

If I start the tutorial from the launcher, it'll allocate a pair of 4meg objects. These will persist after I quit the tutorial, *and* quitting the launcher will not free the 2meg objects if the tutorial has been started from it.

If I quit the launcher without having first started the tutorial, the 2meg objects it created will be freed.

If I run './renpy.sh tutorial', it will create two 4meg objects that go away when I quit the tutorial.

I tried fiddling about with the GL code to see if I could make the leak go away, but so far haven't been able to do anything useful to it.

[PyTom]

I have another tester with a bug on startup, was using old version 6.11c, so not sure if yo have already fixed this. Here is the openGL error.

Define "bug on startup". This is a user without OpenGL support - we should be falling back to software rendering. Is that not working. (And is there a traceback.txt file?)

[jack_norton]

Unfortunately not, she didn't had it. The weird thing is that she tried again, and that time worked. It might be a bug on my code (maybe the autoupdater) so I think you can maybe discard this. I have a new bug though:
if I use fastskip, the texture of the sprite doesn't get displayed correctly, and if I move the mouse over the place "where it's supposed to be" it gets drawn on screen!

Just as reference, below is the normal image, that shows if you don't skip:

also, I was testing and I hit shift+R to reload and got a crash with the renpy.exe.log file containing:

Code: Select all

Traceback (most recent call last):
  File "renpy.py", line 140, in <module>
    
  File "C:\- indie dev -\games\renpy\renpy\bootstrap.py", line 263, in bootstrap
    renpy.display.draw.deinit()
AttributeError: 'SWDraw' object has no attribute 'deinit'

Edit: I get the above message VERY often if I do shift+R when coding/debugging. In version 6.11c I never saw that.