Possible bug: slowdown on show

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.
Message
Author
bg_nocturnal
Regular
Posts: 25
Joined: Thu Feb 13, 2014 9:45 am
Contact:

Possible bug: slowdown on show

#1 Post by bg_nocturnal »

As I'm trying to finish a small game I've been making, some issues have cropped up. The most serious of them is a tiny slowdown I've noticed and would like to get rid of, if possible. Here's what happens:

I've shown a couple of images on the screen. I'd like to manipulate them with ATL transforms, so they appear to be interacting with each other. However, I need each of the two images to go through two different animation transforms with different lengths. So my code starts with the following:

Code: Select all

show image1 at first_anim_for_image1
show image2 at first_anim_for_image2
And this works well, both animations start simultaneously.

But then, one of the images needs to switch to a different animation, while the other image is still playing its first one. I achieve it like this:

Code: Select all

show image1 at first_anim_for_image1
show image2 at first_anim_for_image2
$ renpy.pause(lenght_of_the_first_anim_for_image2)
show image2 at second_anim_for_image2
Later I would add another pause statement and switch image1 to its second animation, but the problem appears even at this stage:

There's a noticeable delay in starting the second animation for image2 and by the point it actually starts, the timings I have arranged for the two images have gone out of sync.

I've attached a small demo project illustrating this. The delay is very small and it may not be possible to avoid it, it may be the result of a bug in Ren'Py or it may just be a problem with the particular way I'm doing things. Whichever the case, I'd very much like to know.

Oh, and in case it helps, the reason I've cut up the animations for each image in two is because I need one of the images to be on top of the other for the first part and the other way around for the second part. If there's a way to change an image's zorder while it's being animated, that would help, too!
Attachments
slowdown_on_show_demo.zip
(488.2 KiB) Downloaded 31 times

User avatar
nyaatrap
Crawling Chaos
Posts: 1824
Joined: Mon Feb 13, 2012 5:37 am
Location: Kimashi Tower, Japan
Contact:

Re: Possible bug: slowdown on show

#2 Post by nyaatrap »

I can only see the delay only when I disabled hardware acceleration.
So I guess it's related to power of GPU.

bg_nocturnal
Regular
Posts: 25
Joined: Thu Feb 13, 2014 9:45 am
Contact:

Re: Possible bug: slowdown on show

#3 Post by bg_nocturnal »

I see it regardless of renderer, on a pretty powerful PC. A little experimenting with different lengths for renpy.pause() showed the delay in the demo to be about 0.05 seconds long. I guess I could change my timings to account for that time, but that would work only if the delay was constant.

User avatar
nyaatrap
Crawling Chaos
Posts: 1824
Joined: Mon Feb 13, 2012 5:37 am
Location: Kimashi Tower, Japan
Contact:

Re: Possible bug: slowdown on show

#4 Post by nyaatrap »

renpy.pause proceed rollback and other functions, so it'll have more calculation than just transform. Just my guess. (anyway, I never see any delay on my PC with OpenGL turned on)

bg_nocturnal
Regular
Posts: 25
Joined: Thu Feb 13, 2014 9:45 am
Contact:

Re: Possible bug: slowdown on show

#5 Post by bg_nocturnal »

That's a good point, but I also tried to use "with Pause()", which shouldn't do such things and the delay remained.

Is there any other way to pause the execution of code?

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: Possible bug: slowdown on show

#6 Post by xela »

I watched it about 15 times in Software, Ange/DirectX and OpenGL, there was no visible delay at all...

Edit: Clearly visible delay with 10 secs on rendered on Software... however still invisible to the naked eye on Hardware.
Like what we're doing? Support us at:
Image

User avatar
nyaatrap
Crawling Chaos
Posts: 1824
Joined: Mon Feb 13, 2012 5:37 am
Location: Kimashi Tower, Japan
Contact:

Re: Possible bug: slowdown on show

#7 Post by nyaatrap »

Sorry this is not a topic issue, but I met another bug with your game.
When I click F.skip, the game crashes. Is there someone who met this issue?

edit: ah, it's just F.skip is searching where to end and never find where, so it fallen endless loop.

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: Possible bug: slowdown on show

#8 Post by xela »

Code: Select all

transform straight_to_green:
    10.0
    "green"

label demo:
    
    scene none
    
    show red1 at left_start
    show red2 at right_start

    show red1 at red_to_green
    show red2 at straight_to_green
    $ renpy.pause(10.0, hard=True)
Is your gamecode to complex to be restructured in this manner? This will clear the delay while preserving behavior? There might be other ways to go here as well.
Like what we're doing? Support us at:
Image

bg_nocturnal
Regular
Posts: 25
Joined: Thu Feb 13, 2014 9:45 am
Contact:

Re: Possible bug: slowdown on show

#9 Post by bg_nocturnal »

Trouble is that after the pause there are going to be two more show statements for the second parts of each animation, which need to start immediately after the first two. So the situation reverts back to the one in the demo.

In other news, I'm becoming more and more convinced that I've chosen a bad way to illustrate the delay. Here's a reworked demonstration project that uses motion instead of color change:
screenshot0005.png
edit: Oops, I forgot to modify the text in the demo, as seen in the screen above. This time the images should be overlapping during the second half of the movement, but the green one lags behind, because of the "show" delay.
Attachments
slowdown_on_show_demo_v2.zip
(765.93 KiB) Downloaded 32 times

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: Possible bug: slowdown on show

#10 Post by xela »

I am not fuzzy on the issue of delay in itself, I still cannot figure out why you have the need for renpy.pause since ATL supports pause of it's own... Can you provide an example where you believe it to be required? Because figuring out why it's out of sync might be fun but it'll be very time consuming and I want to put some of that into my own project :)

Right now the issue is still very easy to solve with ATL.
Like what we're doing? Support us at:
Image

bg_nocturnal
Regular
Posts: 25
Joined: Thu Feb 13, 2014 9:45 am
Contact:

Re: Possible bug: slowdown on show

#11 Post by bg_nocturnal »

Sorry, my thoughts are a bit scattered because I've been banging my head against this for quite awhile. I can see now that the demo shows what the problem is, but doesn't show very well why it's a problem. My previous explanations haven't been very good either, and I've figured out some new things since. Let me try again.

Here's some sample code:

Code: Select all

show image1 at complete_anim_for_image1
show image2 at part1_anim_for_image2

# ??? something to make Ren'Py wait while the first part of the animation finishes ???

show image2 at part2_anim_for_image2
Now, if I run the code like this, without a pause between the two parts of the animation, Ren'Py ignores/doesn't have time to execute the first part and displays only the second. In the previous demo, I basically skipped showing the first part of the animation, because there weren't any problems with it, and showed only the second. I've attached another, hopefully final demo, to remedy this.

And, of course, if I do use renpy.pause(), I get the slowdown which ruins the synchronization between image1 and image2's animations.

P.S.: I remembered that I could use a single show statement with a list of transforms (which results in a smaller, but still present delay, btw), however this doesn't actually help me, because that way I can't change the zorder for the second part of the animation. And me being able to change the zorder is the initial reason I decided to split the image2 animation into two parts. So, yeah... Complicated.
Attachments
slowdown_on_show_demo_v3.zip
(858.36 KiB) Downloaded 29 times

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: Possible bug: slowdown on show

#12 Post by xela »

I still do not understand the actual problem here, you keep posing code that is fixed with three lines of code at it's face value. Can you present a situation that actually mimics the issue as it stands in your game?
Like what we're doing? Support us at:
Image

bg_nocturnal
Regular
Posts: 25
Joined: Thu Feb 13, 2014 9:45 am
Contact:

Re: Possible bug: slowdown on show

#13 Post by bg_nocturnal »

I understand what you mean, but just look at how many words it took me to describe the generic situation here. Now imagine how much more I would have to write in order to get into specifics. :D

On a more serious note, I'll try to do what you're asking after getting some sleep, but if you can fix that last demo with three lines of code, I would be very interested to see them!

Just keep in mind that the green sprite's xcenter value needs to go from 0.25 to 0.5 because of the first transform (left_to_center) and from 0.5 to 0.75 because of the second (center_to_right).

I got very excited at a certain point while experimenting, because it seemed like I'd made it work, only to later find out that the second transform had ended up handling all the movement and the first wasn't actually being used (that's why I inserted initial xcenter values in each transform this time around, regardless of the ones set by start).

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: Possible bug: slowdown on show

#14 Post by xela »

Code: Select all

# You can place the script of your game in this file.

# Declare images below this line, using the image statement.
image none = "#000"
image red = "control_red.png"
image green = "control_green.png"

transform start:
    xcenter 0.25 ycenter 0.5
    
transform left_to_right:
    xcenter 0.25
    linear 2.0 xcenter 0.75
    
transform green:
    left_to_center
    center_to_right
    
transform left_to_center:
    xcenter 0.25
    linear 1.0 xcenter 0.5
    
transform center_to_right:
    xcenter 0.5
    linear 1.0 xcenter 0.75

# The game starts here.
label start:
    
    scene none
    
    show red at start
    show green at start
    
    "Click to start the demo!\n(The green and red sprites both start from the same position.\nGreen is on top for the first half of the movement, red for the second.\nGreen's movement is composed by 2 animations, red's from 1.\nNote how green lags behind after the second animation is shown.)"
    
label demo:
    
    scene none
    
    show red at start
    show green at start
    
    show red at left_to_right
    show green at green
    $ renpy.pause(2.0)
        
    "Click to restart the demo!\n(The green and red sprites both start from the same position.\nGreen is on top for the first half of the movement, red for the second.\nGreen's movement is composed by 2 animations, red's from 1.\nNote how green lags behind after the second animation is shown.)"
    jump demo
It's exactly the same fix as I suggested in previous post (follows your instructions to the letter, first l2c transform then c2r transform). Good luck solving your issue on the fresh head tomorrow morning.
Like what we're doing? Support us at:
Image

bg_nocturnal
Regular
Posts: 25
Joined: Thu Feb 13, 2014 9:45 am
Contact:

Re: Possible bug: slowdown on show

#15 Post by bg_nocturnal »

Yes, this uses both transforms, but doesn't allow changing zorder for the second part of the animation. That's why I need the second show statement.

Post Reply

Who is online

Users browsing this forum: Google [Bot]