Ren'Py [Req] Help figuring out proper use of semi-complex transforms.

[79flavors]

Okay. So I'm doing some... let's call them "dream images".
The images float around the screen. Fading in and then fading out again.
What I've got works... but I can't help but feel I'm doing it wrong. Or at least, I should be doing it better.

... yeah, yeah... "if it works, so it's not wrong".
Okay.. yeah. But since this is the first time I've tried this... and it "feels" wrong... I figure mention it here to those people who've done it other ways and see if my "feeling" is misplaced.

So I have this...

    scene black with dissolve
    show pic_ch3_dream1 with Pause(4.0):
        xalign 0.5 yalign 1.0 alpha 0.2
        linear 2 yalign 0.25 alpha 1.0
        linear 2 yalign -0.5 alpha 0.0

    pause

    scene black
    show pic_ch3_dream2 with Pause(4.0):
        xalign 1.0 yalign 1.0 alpha 0.2
        linear 2 xalign 0.375 yalign 0.25 alpha 1.0
        linear 2 xalign -0.25 yalign -0.5 alpha 0.0

    pause

The first image starts at the bottom of the image and fades in then out again, whilst moving to the top of the image and slightly beyond.
The second image starts in the upper right corner and fades in and out while travelling towards the bottom left. Again, moving slightly further than needed.

I suppose my biggest "feels wrong" is the "with Pause(4.0)". It was the only way I could get the transition to stay on screen for 4 seconds.
I've had a look at a couple of other RenPy games and obviously nobody quite does it the same way.

Any thoughts? Any obvious improvements, insights or pointers?

 

[anne O'nymous]

Any thoughts? Any obvious improvements, insights or pointers?

Well, it's probable that I would have done it in the same way.

Like you said yourself, "if it works, so it's not wrong", and it's even more true with Ren'py and its multiple way to do the same thing. If it works and you understand why and how it works, then it's the right way for you, point.

 

[Rich]

I suppose my biggest "feels wrong" is the "with Pause(4.0)". It was the only way I could get the transition to stay on screen for 4 seconds.
I've had a look at a couple of other RenPy games and obviously nobody quite does it the same way.

Any thoughts? Any obvious improvements, insights or pointers?

As @anne O'nymous says, "if it ain't broke..."

If I'd been doing this, I probably would have done something like:

image pic_ch3_dream1_moving:
    "pic_ch3_dream1"
    xalign 0.5 yalign 1.0 alpha 0.2
    linear 2 yalign 0.25 alpha 1.0
    linear 2 yalign -0.5 alpha 0.0

image pic_ch3_dream2_moving:
    "pic_ch3_dream2"
    xalign 1.0 yalign 1.0 alpha 0.2
    linear 2 xalign 0.375 yalign 0.25 alpha 1.0
    linear 2 xalign -0.25 yalign -0.5 alpha 0.0

...

    scene black
    show pic_ch3_dream1_moving
    pause

    scene black
    show pic_ch3_dream2_moving
    pause

but this is purely a stylistic thing, since I tend to separate image setup from dialog. Not because it's "better," just because.

If the issue is that people can click through the "pause" before the image has done its thing, I might have done

    scene black
    show pic_ch3_dream1_moving
    $ renpy.pause(4.0, hard=True)
    pause

    scene black
    show pic_ch3_dream2_moving
    $ renpy.pause(4.0, hard=True)
    pause

The "hard pause" (

You must be registered to see the links

) can't be interrupted by a click, so that's a guaranteed 4-second "wait right here", and then the second pause requires a click to advance after the image has done its thing.

But, as @anne O'nymous has said many times in this forum, there are almost always multiple ways to accomplish something in Ren'py, and whatever method "feels right" to you (and that you understand) is the best one, since you are the one that will be maintaining the code. Somebody else's "tricky" solution to something may have you coming back in six months going "now what the heck is this code doing again?" (Done that to myself many times when I forget what my own "tricky code" is doing. LOL)

 

[79flavors]

Cheers both.

Yeah, the image solution that @Rich is talking about "feels" closer to what I was originally aiming for.
Right now, I'm thinking that keeping a transform that take 4 seconds and the "with Pause(4.0)" together is untidy but maybe clearer to understand in the future. My sense of "tidy" is likely to win the argument though.

At the time I wrote the post I hadn't really absorbed the fact that animations will play at their own pace and take their own time (according to whatever transforms are laid out) until another scene (or something similar) starts. Therefore the with Pause(4.0) is as good an answer as any other to delay things until it has finished (or nearly finished if you want the dialogue to continue while the animation is still finishing up). I don't want to impose a hard pause, as much as it might be necessary - mainly because testing and retesting sometimes means fast-forwarding repeatedly though the same code... and anything that slows me down is going to bug me.

As a programmer (in another language) for a lot of years, my eye is always on the "write it in a way that the next poor sucker that looks at this code will understand". I suppose that was at the heart of my "feels wrong" statement at the beginning.
I've seen way too much code in the past that was "way too clever". Yeah, it works, but maintaining it was a nightmare.

"Everything should be made as simple as possible, but no simpler."
-attributed to Albert Einstein​

 

[anne O'nymous]

The "hard pause" (

You must be registered to see the links

) can't be interrupted by a click,

I dislike hard pause, but mostly because it's misused by too many devs. Here, it's really needed even if I would have preferred something more interruptible.
What would be ideal, is the possibility to speed-up the process when the player click. But it's probably only possible, if it's possible, by using screens with a timer. Ideally something like (WARNING, will absolutely not works as it, it's just the spirit of the thing):

screen myAnimate( pict, effect, time ):

    default counter = time

    timer 0.5 repeat True action If( counter > 0, counter - 0.5, Return() )

    add pict at effect

    #  Transparent button that take all the screen to
    # intercept player's click.
    imagebutton:
        idle Solid ( "#00000000" )
        posx 0 posy 0
        sizex config.screen_width
        sizey config.screen_height
        # Player had enough, play the accelerated version.
        action [ Hide( "myAnimate" ), Show( "myAnimateFast", pict, effect, time ) ]

screen myAnimateFast( pict, effect, time ):

    default counter = time

    # Important to keep the 0.5 step for the decrease.
    # With a timer step at 0.05 it now goes 10 times faster
    timer 0.05 repeat True action If( counter > 0, counter - 0.5, Return() )

    add pict at effect

label blabla:
    call screen myAnimate( "pic_ch3_dream1", WHATEVER_ATL, 4.0 )

If Ren'py don't like the screen change with the call/Return() couple, then something based on :

     default toUse = "myAnimate"

     [...]

     use toUse

As a programmer (in another language) for a lot of years, my eye is always on the "write it in a way that the next poor sucker that looks at this code will understand".

Well, being so often in the place of "the poor sucker", and like @Rich sometimes with my own code, I can't disagree with this.
But as anyone, sometimes I forgot this important rule. I changed my computer in December, and had to clean the mess of my hard drives (I had 3 Tio almost full)... There's pieces of code for which I don't have a single clue of what they can eventually do. I would probably retrieve it if I dedicate enough time, but still it's hard to deal with the feeling that even myself can't say quickly what I wrote.