Discuss how to use the Ren'Py engine to create visual novels and story-based games. New releases are announced in this section.
Forum rules
This is the right place for Ren'Py help. Please ask one question per thread, use a descriptive subject like 'NotFound error in option.rpy' , and include all the relevant information - especially any relevant code and traceback messages. Use the code tag to format scripts.
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?
The true measure of a man is what he does with his power.
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.
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.
Supporting creators since 2004 (When was the last time you backed up your game?)
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?
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.
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".
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.
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.
Supporting creators since 2004 (When was the last time you backed up your game?)
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.
Supporting creators since 2004 (When was the last time you backed up your game?)
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.
Supporting creators since 2004 (When was the last time you backed up your game?)
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.
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.)
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.)
Supporting creators since 2004 (When was the last time you backed up your game?)