Transition: First frame not rendered

[Ghabry]

Noticed this while implementing the proper version of the Mosaic transition:

It starts with "current_frame = 1" because Update is called before Draw.

See #3440

[Lt-knb]

I tested all transitions.
There's a lot of issues, but I need to take more screenshots (some of them are hard to explain).

For now, I'll report these two:

Mosaic:
Random offset is too much, it causes stretching (extension)

I know why: The range is (0, m_size + 1) right now, because you're adding 1 instead of subtracting here:

		for (int i = 0; i < total_frames; ++i) {
			const int initial_scale = 2;
			const int excl_interval = -1;
			// by default i 0..39 for scale 2..41
			mosaic_random_offset[i] = Rand::GetRandomNumber(0, i + initial_scale - excl_interval);
		}

The correct range is (0, m_size - 1).
Somehow, I only noticed the issue now, my bad.

Raster Scroll (Wave):
The "background" (behind the wave) isn't black, it has the same trailing Mosaic had.
(EasyRPG, RPG_RT)

[Lt-knb]

I've been taking screenshots to make comparisons, but the two issues I reported above make the Mosaic and Wave ones less useful.
To make better comparisons, we need to fix those first.

For the second issue, we need to generate a black background behind Wave

[Lt-knb]

Now that comparisons are easy, I found two more issues in Wave:
The vertical movement (phase) is wrong in half of the frames, due to the integer truncation in percentage.
In WaveOut, the horizontal movement (depth) is 30 fps, for the same reason.

The new commit fixes them.
This is the remaining difference (in Mosaic and Wave):
The off-by-one error is still there, but Wave is missing the last two frames, because it's 41 frames in RPG_RT 👀

I'll make comparisons of all transitions to make a good ol' table.

Also, it seems most of them are plagued by truncation.
Hor/Ver Stripes are 30 fps for that reason.

Blind "starts" 4 frames late rather than ending 6 frames early.

There's a bug in RPG_RT:
The crop resolution is wrong (slightly bigger and not centered) in BorderToCenter, so it's not exactly a reversed CenterToBorder.
I won't implement that difference