Ren'Py 6.11.0 Pre-Released

[PyTom]

Jack, for these last errors, are you in software rendering mode? (No maximize button, can't scale window.)

[jack_norton]

Yes exactly! Lol I didn't notice it, because to start renpy from Scite I use CTRL+0 In GL mode, everything works.

[PyTom]

Where we're sitting right now:

Mihara >>> I have one more thing to try when it comes to your video bug, and then I'm willing to call it a system-specific problem and move on.

adelhaid >>> Fixed.

backansi >>> Fixed.

Spiky >>> It seems that you have a driver problem. When a driver fails to release memory once the program that uses it terminates, then that's a bug in the driver - regardless of what the program's behavior is. (I'm treating the X server as a device driver here.) Now, I'm willing to make reasonable changes to Ren'Py in order to work around driver bugs. But in this case, I don't know if it's even possible to fix the bug - so I'm not sure what change to make.

The only possibility I can think of is that the problem might be triggered by having an OpenGL program fork and exec another program. You can test this by launching the launcher in non-GL mode, and the game in GL mode, and seeing if the leak still occurs.

The test for GL support has to map a window, before we can give up on GL. So you're going to be stuck mapping windows twice if you have a system that doesn't support OpenGL. (You could also set RENPY_RENDERER=sw to force software rendering mode.)

I have yet to implement the rendering performance check, as I've been trying to design it.

Jack >>> The g problem was due to a slightly corrupt font, but I've changed Ren'Py so it will deal with it. (The font metrics didn't add up to the font height.)

I've also fixed the SWDraw deinit problem.

I've switched the no-GL key from ctrl to shift, to try to prevent no-gl mode from being invoked accidentally.

[jack_norton]

I have another bug, I am not sure if is wrong implementation of language or a real bug... anyway I made a video to explain it better.

The video: http://www.winterwolves.net/PS_wrong2.avi

Explanation of the bug:
I have added small numbers to indicate the damage done as suggested by many people. Before this new screen language I don't really know how I would have done it

Code: Select all

screen b_enemies:
    zorder 0
    frame xalign 0.5 yalign 0.6 style "default":
        hbox spacing 4:
            $ ToTEnemy=0
            for i in range(len(tmpEnemy)):    
                if int(tmpEnemy[i][3])>0:
                    $ ToTEnemy+=1
            for i in range(len(tmpEnemy)):    
                if int(tmpEnemy[i][3])>0:
                    fixed area(0,50,400,200):
                        add  "gfx/shadow.png" zoom float(tmpEnemy[i][22]) align (.5, 1.0)
                        $ enim="gfx/rpg/%s.png" % tmpEnemy[i][1]
                        add  (enim) zoom float(tmpEnemy[i][22]) align (.5, 1.4)
                        if Ehit[i][0]>0:
                            add  (im.MatrixColor(enim,im.matrix.saturation(1.6)*im.matrix.tint(1.0,.25,.25)*im.matrix.brightness(0.2))) at shake zoom float(tmpEnemy[i][22]) alpha 1.0
                            text ("%d" % Ehit[i][1] ) at flyup(.3+renpy.random.random()*.3,renpy.random.random()*.3) style "tip2"

the last 3 lines: in my main battle loop I use the value Ehit to store which enemy was it, and by which amount (Ehit[1]). Then I display a text with the new command text, using the transform flyup:

Code: Select all

transform flyup(x,y):
    align (x, y)
    alpha 1.0
    linear 2.0 alpha 0.0 ypos -35

so you see a floating text that slowly goes up and also fades to alpha 0.0.
Problem: if I click on attack button once, the effect doesn't work (not sure why, the other effect in the line above that makes the enemy red works!). Instead if I click attack and then click again, to skip the pause in the game, it works!
Any clue if there's something wrong in renpy or if is a bug on my side (but in this case I don't really know what it could be...)

[Spiky Caterpillar]

(... odd, clicking what I thought would be the 'delete' button for this post instead deleted the delete button.)

[Spiky Caterpillar]

Spiky >>> It seems that you have a driver problem. When a driver fails to release memory once the program that uses it terminates, then that's a bug in the driver - regardless of what the program's behavior is. (I'm treating the X server as a device driver here.) Now, I'm willing to make reasonable changes to Ren'Py in order to work around driver bugs. But in this case, I don't know if it's even possible to fix the bug - so I'm not sure what change to make.

The only possibility I can think of is that the problem might be triggered by having an OpenGL program fork and exec another program. You can test this by launching the launcher in non-GL mode, and the game in GL mode, and seeing if the leak still occurs.

Starting games in GL from a non-GL launcher hides the leak, yes.
I'll poke around some more and see if I can find a satisfactory workaround (or get Debian to apply some variation of Ubuntu's fix for the real bug, which might be a better project.)

The test for GL support has to map a window, before we can give up on GL. So you're going to be stuck mapping windows twice if you have a system that doesn't support OpenGL. (You could also set RENPY_RENDERER=sw to force software rendering mode.)

I have yet to implement the rendering performance check, as I've been trying to design it.

I suppose that explains why it didn't seem to be working.

[backansi]

I think a first_indent property has something that needs to be fixed.

[Spiky Caterpillar]

ATL parallel seems broken in 6.11.0d:

Code: Select all

            show virginia happy:
                parallel:
                    ease 1.0 xpos 990
                parallel:
                    ease 1.0 xanchor 1.0

seems to only update xanchor; switching it around so xpos is last will update xpos but doesn't appear to update xanchor.

'eastasian', 'western', and 'line breaking' or 'breaking (text)' should probably be
in the index and lead to the language style property.

renpy.block_rollback() and renpy.utter_restart() aren't in the index.

slideawayright and slideawayleft reset at least some ATL state, as seen in

Code: Select all

    show expression Solid('#f00'):
        alpha 1.0
        linear 1.0 alpha 0.0
    "Let this fade..."
    show expression Text('fnord') as fnord
    hide fnord with slideawayleft

(Although I don't actually need a fix for that, as I was only using slideaway by accident to begin with)

[jack_norton]

Ah, then wasn't my fault, I tried some parallel (haven't used ATL much so far) and had same behaviour! I can confirm that bug here too then.

[jack_norton]

I think I found another bug in screen language. I have this code:

Code: Select all

screen b_enemies:
    zorder 0
    frame xalign 0.5 yalign 0.5 style "default":
        hbox spacing 4:
            $ ToTEnemy=0
            for i in range(len(tmpEnemy)):    
                if int(tmpEnemy[i][3])>0:
                    $ ToTEnemy+=1
            for i in range(len(tmpEnemy)):    
                if int(tmpEnemy[i][3])>0:
                    fixed area(0,0,256,320):
                        add  "gfx/shadow.png" zoom float(tmpEnemy[i][22]) align (.5, 1.2)
                        $ enim="gfx/rpg/%s.png" % tmpEnemy[i][1]
                        add  (enim) zoom float(tmpEnemy[i][22]) align (.5, 1.4)
                        if Ehit[i][0]>0:
                            add  (im.MatrixColor(enim,im.matrix.saturation(1.6)*im.matrix.tint(1.0,.25,.25)*im.matrix.brightness(0.2))) at shake zoom float(tmpEnemy[i][22]) alpha 1.0
                            text ("%d" % Ehit[i][1] ) at flyup(.5,.0) style "tip2" size 28
                            #damage type?
                            if Ehit[i][0]==1:
                                add "b_shock" align (.2, .25) rotate renpy.random.randint(0,90) zoom float(tmpEnemy[i][22])
                            if Ehit[i][0]==2:
                                add "b_explode" align (.2, .25) rotate renpy.random.randint(0,90) zoom float(tmpEnemy[i][22])
                            if Ehit[i][0]==3:
                                add "b_shock" align (.2, .25) rotate renpy.random.randint(0,90) zoom float(tmpEnemy[i][22])
                            if Ehit[i][0]==4:
                                add "b_shock" align (.2, .25) rotate renpy.random.randint(0,90) zoom float(tmpEnemy[i][22])
                            if Ehit[i][0]==5:
                                add "b_vortex" align (.5, .2) around(128,180) zoom float(tmpEnemy[i][22])[code]

[/code]
in particular damage type: shows a different effect based on the damage type.
The problem is: if I attack with explosive (should trigger b_explode animation) it shows NOTHING (while shows b_shock).
If I swap the first two damage type lines:

Code: Select all

                            if Ehit[i][0]==2:
                                add "b_explode" align (.2, .25) rotate renpy.random.randint(0,90) zoom float(tmpEnemy[i][22])
                            if Ehit[i][0]==1:
                                add "b_shock" align (.2, .25) rotate renpy.random.randint(0,90) zoom float(tmpEnemy[i][22])

b_explode plays correctly but b_shock shows nothing!!!
It's a renpy bug, right? I think I did everything correctly...

[PyTom]

Jack, you really need to include more complete code with your examples. I don't when/if you're calling renpy.restart_interaction(). The screen language only changes things as the result of renpy.restart_interaction(), or the start of a new interaction.

[jack_norton]

Hah the problem is that the complete code is over 200 lines it's the whole battle engine main loop...
I try to explain it but otherwise let me know if you want me to email it.
The main loop is:

Code: Select all

label battleloop:        
    show screen b_enemies
    python:

there follows a LOT of stuff for the battle, and if is the player attacking turn, I do:

Code: Select all

                    Ehit[tar][0]=Item[Inv[ex][0][0]][6]+1;Ehit[tar][1]=dmg
                ui.text(rs,size=18,xalign=0.5)
                renpy.pause(3.0)
                Ehit[tar][0]=0

and of course at the end I have:

Code: Select all

    jump battleloop

maybe it's the pause the problem ? the first line sets the Ehit variable that triggers the animation/FX in the b_enemies screen.

Maybe I can try reducing lot of stuff and make a test app? I don't call renpy.restart_interaction, I tried adding that now but the bug is still there.
Actually, both the 1st and last case works, but all the other in middle not.

[jack_norton]

Ok sorry, I've made a VERY SHORT example now:

Code: Select all

label quickbattle:
    show screen b_enemies
    python:
        renpy.scene()
        renpy.show(bkg)
        i=renpy.random.randint(1,5)
        Ehit[tar][0]=i;Ehit[tar][1]=i
        ui.text("TEST!",size=18,xalign=0.5)
        renpy.pause(3.0)
        Ehit[tar][0]=0
        renpy.pause(1.0)
    jump quickbattle

variable "i" sets a random damage but also type of FX. Only fx 1 and 5 (the first and the last in the b_screen) are displayed on screen. All the others not.

[Kinsman]

I was checking out a personal project in the new version, and found an issue with 6.11.0d that had me stumped for a while.

My project was showing all of its scene backgrounds slightly smaller than the window, unless I explicitly added some directives after the scene statement, such as "xpos 0.0 ypos 0.0".

After some detective work, I discovered that I had redefined the transform 'center' for my own purposes. But apparently, the default action of the "scene" statement makes use of a transform named 'center', and used my redefinition of it.

Could you please make it so the scene statement doesn't use named transforms, and just writes out its defaults in plain properties?

[PyTom]

I just updated to 6.11.0e. Changes include:

- The disable GL key has been changed to shift. (Instead of ctrl.)
- GL now performs a performance test on startup, and will disable itself if it can't render 4 dissolve frames in .25 seconds.
- GL is now disabled in the launcher.

- A problem with parsing if statements in screen language code has been fixed. You may need to make a change to your file (causing it to be recompiled) to have this change take effect.
- A problem with ATL over-computing changes has been fixed. This manifested as a problem with the ATL parallel statement.

- Fixed a potential (but unlikely) race condition in the video playback code.
- Stopped defining the default transform in terms of named transforms. (Per Kinsman, above.)
- Fixed problems with broken fonts.
- Fixed problems with indentation.
- Fixed crashes with software rendering involving a missing deinit method.
- Changed the placement of the developer-mode window to be compatible with RTL languages.

Once again, thanks to all the testers.