Ren'Py 6.11.0 Pre-Released

[PyTom]

When putting together some sample screens, I noticed that there's a lot of times when one wants to put, for example, a vbox into a frame. This is a little clunky, as it means there's going to be extra indentation. So I added a new has statement to the screen language, one that lets us specify the container to use inside frames, windows, and buttons.

The old code (which still works) looks like:

Code: Select all

screen display_pref:
    frame:
        vbox:
            label "Display"
            textbutton "Window" action Preference("display", "window")
            textbutton "Fullscreen" action Preference("display", "fullscreen")

Now, it looks like:

Code: Select all

screen display_pref:
    frame:
        has vbox

        label "Display"
        textbutton "Window" action Preference("display", "window")
        textbutton "Fullscreen" action Preference("display", "fullscreen")

[Mihara]

- Make the video playback texture transient, hopefully fixing movie playback problems.

I'm afraid that didn't fix it for cutscene playback on Eee 901/Linux. Playing as a displayable still works fine.

[tpgames]

I'm in the process of learning Ren'Py and making a game. This brought me to a question: Will 6.11.0 work well with code that contains older code as well as newer code? I'm trying to learn the newer code, but as documents examples are sketchy. Thats a bit hard.


Also...When the documentation wiki is made more complete, can someone please post images that show what the code does? Thanks!

Running off to fix my game code so I can test it in the 6.11.0.

[PyTom]

I'm afraid that didn't fix it for cutscene playback on Eee 901/Linux. Playing as a displayable still works fine.

Can you try editing the size of the Movie displayable? I'm wondering if there's a particular size at which this happens, or if it happens at all sizes. Also, if you can post your opengl.txt, I'd appreciate it - if you already did, I'm sorry, I couldn't find it.

I'm in the process of learning Ren'Py and making a game. This brought me to a question: Will 6.11.0 work well with code that contains older code as well as newer code? I'm trying to learn the newer code, but as documents examples are sketchy. Thats a bit hard.

The answer is yes - but. There have been a few incompatible changes in the way transforms work. You'll need to deal with those, either by enabling compatibility, or by updating your code.

The documentation is still a bit sketchy, but I wanted to get this into testing while I'm still working on it.

[Spiky Caterpillar]

6.11 is making X leak virtual memory - when I start X, it uses about 122 megs virtual / 22 resident. After a lengthy development session X was up to over 900 megs virtual (I forget exactly how much resident).

The simplest replication is to run top and use the launcher to repeatedly start and quit the tutorial game. (Up over 300/46 when I stopped.). The leak occurs in 6.11.0c and 6.11.0b; it doesn't seem to show up in 6.10.2e; haven't checked 6.11.0a.

Also, it appears to be using GL regardless of whether or not hardware acceleration is actually available. On an OLPC running Debian, the 6.11.0c launcher shoves Xorg's CPU use up to 97-99% while the framerate drops to somewhere around .1fps; the 6.9.3 launcher is fine on the same hardware. While performance is fine on my main machine (dual-core 64-bit Pentium E5200), CPU usage seems higher than I'd expect for hardware GL - the tutorial's Gratuitous Rock Concert sequence peaked at 45% CPU (Python)/10% (Xorg). On my 64-bit Arch box (Sempron 2600+), just running the launcher is enough to push xorg to 50% CPU - more if I resize the window.

[Spiky Caterpillar]

Booting the Sempron 2600+ into Win2K, the Gratuitous Rock Concert appears to take up less processor time. If I fullscreen it, during some of the transitions a strip about a line of text high will be cut off the bottom of the dialog window, and much or all of the time the dialog window won't extend all the way to the bottom, exposing a one-pixel line of the background. Fullscreening it in Debian seems to be drawing the dialog window with 1px of margin on bottom, left, and right (possibly also top, but that wouldn't be detectable.) at all times.

[PyTom]

6.11 is making X leak virtual memory - when I start X, it uses about 122 megs virtual / 22 resident. After a lengthy development session X was up to over 900 megs virtual (I forget exactly how much resident).

The simplest replication is to run top and use the launcher to repeatedly start and quit the tutorial game. (Up over 300/46 when I stopped.). The leak occurs in 6.11.0c and 6.11.0b; it doesn't seem to show up in 6.10.2e; haven't checked 6.11.0a.

I'm unable to replicate this on my system. Can you use xrestop to figure out what kind of resources are leaking? Also, please attach the opengl.txt file from 6.11.0c.

Also, it appears to be using GL regardless of whether or not hardware acceleration is actually available. On an OLPC running Debian, the 6.11.0c launcher shoves Xorg's CPU use up to 97-99% while the framerate drops to somewhere around .1fps; the 6.9.3 launcher is fine on the same hardware. While performance is fine on my main machine (dual-core 64-bit Pentium E5200), CPU usage seems higher than I'd expect for hardware GL - the tutorial's Gratuitous Rock Concert sequence peaked at 45% CPU (Python)/10% (Xorg). On my 64-bit Arch box (Sempron 2600+), just running the launcher is enough to push xorg to 50% CPU - more if I resize the window.

Hm... is Mesa telling us it's capable enough to run the new Ren'Py? I'm using the presence or absence of certain GL extensions to tell if we can run Ren'Py. That's because the test for hardware acceleration is broken - on my system, it reports False, even though things are certainly accelerated.

Again, opengl.txt files would be nice.

Also, is vblank-synchronization turned on? If you have it off, we can easily use a lot of CPU.

[Spiky Caterpillar]

The tutorial claims to be using 3 Wins, 1 GC, 2 Pxms, 6 Misc, 368K Pxm mem, and 240B of Other. One of those Miscs will occasionally disappear when I switch into and out of fullscreen.

I suspect that querying extension presence is not a safe way to distinguish between hardware and software rendering - even if there's something that Mesa doesn't currently support, they may well add it to future versions. Is there any way to measure actual render speed (as opposed to how long it took to handoff the textures to the renderer)?

exporting GL_SYNC_TO_VBLANK=1 and __GL_SYNC_TO_VBLANK=1 has no significant effect on either the OLPC or my main box.

[Mihara]

Can you try editing the size of the Movie displayable? I'm wondering if there's a particular size at which this happens, or if it happens at all sizes. Also, if you can post your opengl.txt, I'd appreciate it - if you already did, I'm sorry, I couldn't find it.

Kept raising the displayable size up until it was 800x600, displayable plays fine regardless of size as far as I can see, cutscene still shows a black screen.

I did post opengl.txt, but here's one from 6.11c anyway.

[PyTom]

Spiky>>>
To deal with the performance issue, I'm considering:

- Blacklisting the "Mesa GLX Indirect" renderer, on the grounds that it's very unlikely to ever be accelerated.
- Add a small peformance test to startup, to cache other totally broken GLX renderers.

To deal with the memory leak, I'm going to actively deallocate textures on shutdown. Right now, I'm not doing that, as I rely on them being automatically deallocated when the process quits. I'll do it by hand - even though really, it's probably a bug in the driver if memory is kept around after a process quits.

(And this is why I waited six years before creating OpenGL Ren'Py.)

Mihara >>> Thanks. I think I'll probably just set things up so that the fullscreen movie playing in GL-Ren'Py uses a fullscreen-sized movie displayable.

[backansi]

Oh no.

I already tested it with another font files... and had same problem.

[Mihara]

Mihara >>> Thanks. I think I'll probably just set things up so that the fullscreen movie playing in GL-Ren'Py uses a fullscreen-sized movie displayable.

May I offer a more general purpose idea? It may be more work, but will be useful for other things as well.

1. Create a "cutscene" block statement, which, when any user input occurs inside, skips to the end immediately, possibly based on a condition (like whether the cutscene was seen before or not), whatever is going on inside, be it movie playing or normal statements.
2. Create some syntactic sugar to play a movie fullscreen using a displayable, and divorce movie playing from the concept of interaction.
3. Make the existing cutscene function do 1+2 and call it deprecated.

I.e. if you want a fullscreen movie working as it usually did, you'd do something like this:

Code: Select all

label start:
    cutscene:
        play movie "moviefile.ogv" fullscreen

But then you'd be able to make skippable engine cutscenes like this:

Code: Select all

label start:
    cutscene:
        show bg something
        pause 1
        show bg somethingelse with dissolve
        ...

[PyTom]

A new feature I just added in what will be come 6.11.0d:

When a style doesn't exist, Ren'Py will strip off everything up to and including the first underscore in the style name. If what remains exists as a style, Ren'Py will create a new style that inherits from the existing style.

For example, if I do:

Code: Select all

init python:
    style.pref_vbox.box_spacing = 100

The pref_vbox style will be created if it doesn't already exist.

I expect that this will mostly be used with the screen language's new group property. The group property lets one specify a prefix for the style of this displayable and its children. For example, I can now write:

Code: Select all

screen display_preference:
    frame:
        group "pref"
        has vbox

        label "Display"
        textbutton "Window" action Preference("display", "window")
        textbutton "Fullscreen" action Preference("display", "fullscreen")

This will use the pref_frame, pref_vbox, pref_label, pref_label_text, pref_button and pref_button_text styles automatically, if they exist.

(I'm not sure I like group as the keyword for this last feature, so if someone wants to make a suggestion, I'd consider it.)

backansi >>> your bug will be fixed in the next Ren'Py.

[jack_norton]

I think this is a bug:
I call a label to show a new character:

Code: Select all

label shownewchar(ch):
    show expression ("%s" % ch) at scale(.5),baseleft
    show text_b "Tom Shatz{p}{size=32}LIEUTENANT (GUARDIAN){/size}" with dissolve
    $  renpy.pause(4)
    hide text_b with dissolve
    
    return

ch in this case is "i_tom". I have already on screen the image defined in the old-way: i_tom angry
Before it would replace the old one, now it shows both:

It's a bug right? One Tom is enough...

Also sorry but I'm having troubles to understand why this screen doesnt' work:

Code: Select all

screen shownewchar:
    add "%s" % ch xalign 0.5 yalign 0.0
    add "gfx/i_tom.png":
        xalign 2.5 yalign 0.8
        easein 4.0 xalign 0.5

I call it from main code with

Code: Select all

call screen shownewchar(ch="i_tom")

the error is on the %s:

Code: Select all

On line 787 of C:\- indie dev -\games\renpy.new\Planet Stronghold\game/script.rpy: expected a keyword argument, colon, or end of line.
add "%s" % ch xalign 0.5 yalign 0.0
         ^

[PyTom]

If it's a bug, it was in the old Ren'Py. show expression doesn't use a tag, unless you give it one explicitly with the as clause. Use renpy.show if you want the tag magic to work.