Ren'Py 6.11.0 Pre-Released

[shahab96]

ok, i just noticed this a few minutes ago and i dont really know if someone has already told you about this, and it probably isnt really a hard thing to fix, but when i use the

Code: Select all

show text

function without a background, renpy will use that light and dark grey tiled screen which represents transparent layers as the background. a minor thing yeah, but hey why not strive for absolute perfection?

[Jake]

renpy will use that light and dark grey tiled screen

That's actually intentional - it's pointing out to the developer that they haven't set a background. IIRC, if you turn config.developer off, it should go back to the old hall-of-mirrors effect.

[PyTom]

Once the page clears, FPS is back, and the cycle immediately repeats as a new wall of text is printed. It's as if RenPy is rendering the entire text window from scratch with every new character, but even if that is what it does, it probably shouldn't be so slow as to cause FPS to drop to 5-6...

Unfortunately, we have to do a texture load each time a character is typed. Loading a fullscreen texture takes a while, especially on a slower computer. Your best bet is to break the text up into small blocks, which are shown one at a time.

[Jake]

Unfortunately, we have to do a texture load each time a character is typed.

I'm kind of curious - why does this result in the char-by-char typing effect getting slower the more text there is on the screen? I'm guessing you're drawing a sub-section of a big all-my-letters texture onto a big fullscreen all-my-typed-text-so-far texture, but shouldn't you be able to keep the work-in-progress text-so-far texture between frames, so if you're adding the same number of characters to it in one frame and the next, it should take the same amount of time?

[PyTom]

Mihara, that code works for me. Is there anything special about how you're showing or hiding things?

[jack_norton]

I am not sure if works still this way (has been some years since I did any low-level progrmaming): I remember that some old / cheap videocards had a texture limit of 1024x1024 (and sometimes 512x512) when rendering transparent PNGs... so the only option was to split the image in smaller parts.

[Mihara]

Mihara, that code works for me. Is there anything special about how you're showing or hiding things?

The displayable in question is a big filmstrip animation, declared in the ATL block of the image statement.

Code: Select all

    image goldenfroth:
        anim.Filmstrip("gold.png",(188,240),(1,30), delay=0.06,frames=None,loop=True)
        # ATL on what to do with it follows, but I simply want to alpha it in and out in ATL.

There is little special about showing or hiding it, just 'show goldenfroth at center'. "on show" is not getting triggered, and neither is "on hide".

There's an imagedissolve going on while that alpha change is in progress. It works as expected if I just hardcode delays into image definition ATL instead, but it would be much more convenient to use if I could just "on show" and "on hide".

[Mihara]

Unfortunately, we have to do a texture load each time a character is typed. Loading a fullscreen texture takes a while, especially on a slower computer. Your best bet is to break the text up into small blocks, which are shown one at a time.

But then FPS would be constantly low, wouldn't it? If you load a fullscreen texture every time a character is typed, it should not depend on the number of lines on screen, when it clearly does.

[PyTom]

Yes, investigating it a bit more, the problem is drawing the text, not sending it to the GPU. I now have a good idea of what's going wrong here - unfortunately, I have to rewrite the Text class to fix it. So I'm going to ask people live with this for 6.11, and I'll rewrite Text sometime soon.

[PyTom]

There is little special about showing or hiding it, just 'show goldenfroth at center'. "on show" is not getting triggered, and neither is "on hide".

The "at center" is what did it. I've modified the behavior so that we now pass ATL events through nested transforms.

[PyTom]

6.11.0f is out. Please use the public pre-release thread to discuss it. Thanks!

http://lemmasoft.renai.us/forums/viewto ... 39#p104139

[PyTom]

I am not sure if works still this way (has been some years since I did any low-level progrmaming): I remember that some old / cheap videocards had a texture limit of 1024x1024 (and sometimes 512x512) when rendering transparent PNGs... so the only option was to split the image in smaller parts.

Ren'Py is pretty conservative - it uses textures of size 64, 128, 256, and 512. (It will also use mixes of these sizes, like 512x64.) It also likes to leave a 1 pixel border on each side of the image, so 254 and 510 are the most efficient sizes, while going up to, say, 511 will cause it to spit your image between two textures.

[shizuka]

Text seems to have gotten a pixel taller since 6.10.2 - stuff that used to fit no longer does without stretching the text box. Buttons are now also a pixel taller than before.

EDIT: workaround is

Code: Select all

style.default.line_spacing  = -1

In 6.10.2, the {fast} tag works inside a menu block.
In 6.11.0f, the {fast} tag doesn't work inside a menu block. Text displays slowly.
(The {fast} tag works normally if not in a menu block.)

Code: Select all

menu:
    "Choose a video to watch.\n* means the video has subtitles.{fast}"

[PyTom]

6.11 changes the way we render fonts a little. If the font's ascent+descent are bigger than the font's reported height, we now use ascent+descent as the basic spacing. (This ensures that we don't crop the top or bottom of lines.)