Page 12 of 12
Re: Ren'Py 6.11.0 Pre-Released
Posted: Sun Jul 25, 2010 10:57 am
by 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
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?
Re: Ren'Py 6.11.0 Pre-Released
Posted: Sun Jul 25, 2010 11:25 am
by Jake
shahab96 wrote: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.
Re: Ren'Py 6.11.0 Pre-Released
Posted: Sun Jul 25, 2010 12:51 pm
by PyTom
Mihara wrote: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.
Re: Ren'Py 6.11.0 Pre-Released
Posted: Sun Jul 25, 2010 12:56 pm
by Jake
PyTom wrote:
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?
Re: Ren'Py 6.11.0 Pre-Released
Posted: Sun Jul 25, 2010 1:04 pm
by PyTom
Mihara, that code works for me. Is there anything special about how you're showing or hiding things?
Re: Ren'Py 6.11.0 Pre-Released
Posted: Sun Jul 25, 2010 1:21 pm
by 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.
Re: Ren'Py 6.11.0 Pre-Released
Posted: Sun Jul 25, 2010 1:24 pm
by Mihara
PyTom wrote: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".
Re: Ren'Py 6.11.0 Pre-Released
Posted: Sun Jul 25, 2010 1:27 pm
by Mihara
PyTom wrote: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.
Re: Ren'Py 6.11.0 Pre-Released
Posted: Sun Jul 25, 2010 1:38 pm
by 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.
Re: Ren'Py 6.11.0 Pre-Released
Posted: Sun Jul 25, 2010 2:01 pm
by PyTom
Mihara wrote: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.
Re: Ren'Py 6.11.0 Pre-Released
Posted: Sun Jul 25, 2010 8:27 pm
by 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
Re: Ren'Py 6.11.0 Pre-Released
Posted: Sun Jul 25, 2010 8:30 pm
by PyTom
jack_norton wrote: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.
Big Fat Bug Report
Posted: Mon Jul 26, 2010 1:28 am
by 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
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}"
Re: Ren'Py 6.11.0 Pre-Released
Posted: Mon Jul 26, 2010 10:08 am
by 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.)