RPG Maker Forums

If you aren't working on a custom transition, then this article may not hold much value for you. I'm also a new to MV, so take this with a grain of salt.


In other web projects, you might get your progress with some basic math. `durationElapsed / durationTotal = progress`. Animation is a pain, so maybe you have jQuery, D3, or Greensock doing some heavy lifting for you. So if we were running over the course of 24 frames, you might expect something like this:



Since 0 is itself a frame, we actually have 25 frames here. `durationElapsed === 0` doesn't actually run in RPG Maker MV, and I haven't yet come across any event that looks like "durationDone", which could be used as that last frame. This makes sense, but it is clear as mud, so I'm going to try to clear the water here.


The math in `Scene_Base.prototype.updateFade` confused me when I first saw it. It looked like no timing function I had ever seen. There is no easing going on here. The math works out to be linear.


Scene_Base.prototype.updateFade = function() {
    if (this._fadeDuration > 0) {
        var d = this._fadeDuration;
        if (this._fadeSign > 0) {  //FadeIn = decrease opacity
            this._fadeSprite.opacity -= this._fadeSprite.opacity / d;
        } else { //FadeOut = increase opacity
            this._fadeSprite.opacity += (255 - this._fadeSprite.opacity) / d;
        }
        this._fadeDuration--;
    }
};




The change on every step equals `10.625`, despite the value of the numerator and denominator changing every time. I later found this to equal `(1/24) * 255` or the progress of one frame over the maximum duration, multiplied by the maximum value. In this case, the fade sprite clamps opacity between `0` and `255`.


# The wrong way


I thought I was _so_ smart. I would calculate progress in a way that was easier to follow.


Scene_Base.prototype.startFadeIn = function(duration, white) {
    this.createFadeSprite(white);
    this._fadeSign = 1;
    this._fadeDuration = duration || 30;
    this._fadeSprite.opacity = 255;
    this._transitionDuration = this._fadeDuration; // NEW //
};

Scene_Base.prototype.startFadeOut = function(duration, white) {
    this.createFadeSprite(white);
    this._fadeSign = -1;
    this._fadeDuration = duration || 30;
    this._fadeSprite.opacity = 0;
    this._transitionDuration = this._fadeDuration;  // NEW //
};

// NEW METHOD //
Scene_Base.prototype.fadeProgress = function(){
    var durationRemaining = this._fadeDuration;
    var durationTotal     = this._transitionDuration;
    var durationElapsed   = durationTotal - durationRemaining;
    var progress          = durationElapsed / durationTotal;
    return (Number.isFinite(progress))? progress : 0;
};

Scene_Base.prototype.updateFade = function() {
    if (this._fadeDuration > 0) {
        var opacityChange = this.fadeProgress() * 255; // MODIFIED //
        if (0 < this._fadeSign) {  // MODIFIED // I reversed the order of the comparison, because it made sense to me. It still has the same meaning.
            this._fadeSprite.opacity = 255 - opacityChange; // MODIFIED // Notice the subtraction changed locations.
        } else {
            this._fadeSprite.opacity = opacityChange; // MODIFIED //
        }
        this._fadeDuration--;
    }
};




`_transitionDuration` doesn't change, so it gives me a maximum value I can compare `_fadeDuration` against. I use the term "transition" because not all transitions need to involve a fade, even if a fade is the most common kind of transition and it is what RPG Maker uses by default.


Clever right? Not so much. The final step ends up being:



Remember, `_fadeDuration === 0` never triggers `updateFade`.


Do you see my mistake? I was considering the first execution of `updateFade` to be the initialization, or zero progress, frame. Both sets of math always incremented by the same number. But zero progress happens in `startFadeIn` and `startFadeOut`. My math leaves the final value one step behind and the transition itself is not quite complete.


RPG Maker MV accomplishes this in much fewer lines of code. What if the numerator and denominator for the next property I want to work with doesn't happen to line up so conveniently? Is this the reason 255 was chosen instead of a value between 0 and 1? The fadeSprite converts the 0-255 number to a 0-1 number automatically. 


I'm still not convinced the MV way is the best or most flexible way, so I revisit my code.


# A better way


Scene_Base.prototype.fadeProgress = function(){
    return (this._transitionDuration - this._fadeDuration + 1 ) / this._transitionDuration;
};




Now our progress is based on the amount of time that has passed relative to the total amount of time. This feels far more reliable than numerators and denominators that (happen to?) play nice at any given step. I'm not going to dissect MV's math and try to say it is right or wrong. I'm just saying it didn't work for me.


The zero progress step (`startFadeIn` or `startFadeOut`) IS our first frame and it gives us our floor, where the `+1` allows our ceiling to reach 100% and is effectively the same as MV's math.


I'm down to a single line of code and just a couple more math operations than MV's native code. I could get rid of a couple operations, but that would mean changing more of the code base which relies on `_fadeDuration` being `0` to indicate busy-ness. Its important to other parts of RPG Maker MV. I'll take the tiny performance hit for the increased flexibility in developing a custom transition and having code that is easier for me to understand and maintain.


If I really wanted to, it would probably be simple enough to add support for an easing function from here. It gets you thinking ... "what could I do next?"