RMMZ processTouch() called twice per frame in Sprite_Button?

[MushroomCake28]

Hi,

I've noticed that the processTouch() function is called twice per frame in the update method in Sprite_Button and was wondering if it's intended? If so, why is it called twice?

So the function is being called once from the Sprite_Clickable.prototype.update and once from the update method in Sprite_Button. Take a look:

Update in Sprite_Clickable:

Sprite_Clickable.prototype.update = function() {
    Sprite.prototype.update.call(this);
    this.processTouch(); // First time
};

Update in Sprite_Button, which is a subclass of Sprite_Clickable:

Sprite_Button.prototype.update = function() {
    Sprite_Clickable.prototype.update.call(this);
    this.checkBitmap();
    this.updateFrame();
    this.updateOpacity();
    this.processTouch(); // Second time!!!
};

Also, I've tested to confirm that it does call the processTouch function and it really does.

Thanks!

 

[Mewgles]

My guess is that they did this because you can click other sprites than just buttons. If you look into the Sprite_Clickable function you can see that they use it to scan where you click on the screen. Some sub-functions are set up, but not filled with code yet. So that looks like you can use them to add your own code for more dynamic handling of touch/mouse inputs.
And since buttons are static on the screen and mostly deal with menus, they are handled a bit differently as you can see in the function. They are still sprites though and thus it makes sense to let it use the Sprite_Clickable to inherit from.

At least that's how I think to understand it. Haven't really looked into mouse/touch controls that much yet.

 

[MushroomCake28]

The processTouch function is not redefinited in Sprite_Button, it's exactly the same as in Sprite_Clickable. I still don't see the reason why it needs to be called twice inside the same function. I get that Sprite_Button is a sub class of Sprite_Clickable, but that second call doesn't add anything from what I can see. They could just remove the second call in Sprite_Button and leave it in Sprite_Clickable.

 

[Mewgles]

Could be due to possible execution issues. Wouldn't be the first time that things behave a little strange and not the way they should, based on the code. But that's just wild guessing. Could also be a leftover from their testing.

 

[MushroomCake28]

I've tried removing the second call and there didn't seem to have any issues from my testing. I'll leave it in for now as it might have a purpose, but three functions called in between the two executions doesn't seem to interfere with the process touch execution. My bet would be that it's unintentional.

 

[Mewgles]

I'm currently working on something where I'll need quite a few button processes later on. Will remove it too and see what happens when I start testing and then share my results here But I guess you're right with it being unintentional since there is so little going on in the other functions.

 

[caethyril]

I think it's mostly a safety thing, to catch edge cases like if the new frame, for whatever reason, no longer encompasses the cursor. The second check ensures that the button's new state (which is what will appear to the player this frame), not its prior state, is what determines its hover/click status.

By default I think all cold/hot frames are equally-sized, but maybe this kind of thing also applies to slow-loading images?