Ren'Py How to add a transition to imagebutton hover image?

[Corrupt King]

Is there a way to have an imagebutton go from idle image to hover image with a dissolve transition?

Thanks.

 

[Palanto]

Hmmm never tested or tried it but it should usually work if you add this to the button:

imagebutton auto "/gui/main_menu%s.png":
    on "hovered" action With(dissolve) # <---
    on "unhovered" action With(dissolve) # <---
    action MainMenu()

 

[Corrupt King]

Thanks, but it seems there can be only one "action" in a imagebutton statement.

 

[anne O'nymous]

Absolutely no idea if it will works, but what if you use an external screen ? Keeping what @Palanto wrote :

screen myButton:
   on "hovered" action With(dissolve) # <---
   on "unhovered" action With(dissolve) # <---

   imagebutton auto "/gui/main_menu%s.png":
       action MainMenu()

screen yourScreen:

    [...]
    use myButton
    [...]

 

[Corrupt King]

Didn't work for me (no errors nor effect). I decided for a workaround by creating a transform with easein/alpha, and just using two separate pictures, one on top of the other, like so:

transform PhoneButton:
    on idle:
        easein 0.2 alpha 0.0
    on hover:
        easein 0.2 alpha 1.0

screen phone_active:
    image "Icon_Off.png" xalign 0.193 yalign 0.235
    imagebutton:
        xalign 0.193 yalign 0.235
        idle "Icon_On.png"
        action ui.callsinnewcontext("phone_contacts_call")
        at PhoneButton

Thanks.

 

[Rich]

Good solution. I had thought about ATL, but I got hung up on ATL-ing between two images within a single "image" definition, as opposed to ATL-ing the front image and then letting the underlying one show thru when appropriate. (I wasn't sure my solution wasn't going to have a "when the screen is first shown" artifact.)

Only question is whether the transform should (for paranoia's sake) have an "on show" that just sets the alpha to zero, just to make sure you didn't have some spurious activation of the "on idle" transition when a screen was first shown, restored from a save or whatever. (I don't know the exact sequence of events that Renpy screens emit under all circumstances.) But if ain't broke...

 

[anne O'nymous]

A solution like I like them

Just a little thing :

image "Icon_Off.png" xalign 0.193 yalign 0.235

You are really precise for your alignment, so, aren't

You must be registered to see the links

more suitable for this ?

Only question is whether the transform should (for paranoia's sake) have an "on show" that just sets the alpha to zero, just to make sure you didn't have some spurious activation of the "on idle" transition when a screen was first shown, restored from a save or whatever. (I don't know the exact sequence of events that Renpy screens emit under all circumstances.) But if ain't broke...

Normally it shouldn't be a problem. I mean, we never heard of problems with the "hovered" button's property and there's no reason for the "on hover" thing to works differently.

 

[Rich]

Normally it shouldn't be a problem. I mean, we never heard of problems with the "hovered" button's property and there's no reason for the "on hover" thing to works differently.

That actually wasn't what I meant. My concern was that when Ren'py initially put together the screen to show it, it was probably going to set up both images with alphas of 1.0. Meaning that the "Icon_on.png" (the "hover" image) would be showing on top of the idle image. Then (possibly) Ren'py would issue an "idle" event, which might mean that you'd have an 0.2 second flicker of the "Icon_on.png" fading out just as the screen was shown. So the idea that was in my head was either to include an "on show" handler that would force the "Icon_on.png" image to 0.0 alpha immediately in that case, or possibly just to start it with alpha 0.0.

With an 0.2 second transition, the startup problem might not really be visible. But if the transition effect was longer, it might.

Of course, since I haven't tested it myself, this may be completely off base...

 

[anne O'nymous]

My concern was that when Ren'py initially put together the screen to show it, it was probably going to set up both images with alphas of 1.0. Meaning that the "Icon_on.png" (the "hover" image) would be showing on top of the idle image.

To be sure that I understood this time, your meaning is : Is the transition applied before the display, in this case the "on idle" will apply from the start. Or applied after the display, in this case there's a alpha 1.0, then the "on idle". And depending on many factors (time to display the screen, charge of the computer at this time, speed of the computer), the alpha 1.0 can stay long enough to create a glitch.
I haven't took the time to trace the whole process, but I assume that the transition is applied before the display since it have an on show property.

But it don't change the fact that the button will fade out when displayed first, which isn't necessarily the best effect, since it's not supposed to be seen yet ; even if here it's a really fast thing. So the cleanest way is to force the alpha at start :

transform PhoneButton:
   on show: 
       alpha 0.0
   on idle:
       easein 0.2 alpha 0.0
   on hover:
       easein 0.2 alpha 1.0

Then, the easein can even be a little longer to make the effect more visible.

 

[Corrupt King]

Good prediction, Rich.

While this wasn't visible in my "phone" screen (which was called with a dissolve itself), when I applied the same transform to another icon in my proper game scenes, the hidden image popped up for a brief moment - it was very annoying and noticeable while skipping text. It had to be corrected. Well, I actually ended up keeping both versions. The initial one was better for me in the "phone" screen, because I have a little bit of glow and shadow on "on/off" icons, which gets more pronounced on hover. If I had reverted it, it would be more pronounced on idle.