How could the Graphics.translation's algorithm come out?

[yuwenhuisama]

I am studying the method of Graphics.transition(duration, filename, vague) in RGSS, and didn't know how it works especially the argument of vague. And then I find it seems to be simple from this project's source code, can it be able to tell me the method to get the algorithm?

[Ancurio]

Are you asking for the algorithm itself, or an explanation of why it works the way it does?

[yuwenhuisama]

Well, maybe I have said unclearly. What I want to know is the way you get the algorithm. From ASM or other ?

[Ancurio]

No, I have never disassembled Player.exe (that's probably illegal), I just studied how the transitions worked and then replicated it. It's not terribly complicated to be honest o.o

[yuwenhuisama]

Oh, if this you are much cleverer than me because I have thought about this method's algorithm for a long time without any useful result. Then, can you tell me the work of this algorithm? particularly the work of argument of vague. thanks.

[Ancurio]

Ok. Taking this minimalistic linear horizontal transition bitmap (a plain gradiant):

I will be transitioning from a red bitmap to a blue bitmap. It's easiest to describe the progress of the transition by normalizing and reversing it* (so it's counting down), ie. prog == 1.0 means the transition has just started, and prog == 0.0 means it has just about finished.

With a vague value close to zero, this is the result: at prog ~= 0.75:

at prog ~= 0.25:

I think you understand the basics of a transition, namely that with vague close to zero, all pixels of the transition bitmap with color value > prog are mapped to the new scene (blue), and all values < prog are mapped to the old one (red). This means for now a pixel is either completely sampled from the new scene, or completely from the old.

If we increase the vague value to eg. 10, we see a kind of "alpha blending wave" being pushed forward at the old/new boundary, like this at prog ~= 0.75:

Now, all pixels > prog are still sampled from the old scene, values < prog-x are sampled from the new one, but the ones between, ie. < prog && > prog-x are linearly interpolated, with ´x` being the value that determines the width of the "blending wave".

If we increase vague yet again to 40, the blending wave further widens:

So it's clear that x is derived from the vague parameter in a linear fashion. From there on out it's mostly guesswork. I initially settled on x being vague normalized over the range [0, 512], but as I looked at the wave width's again while writing this text, [0, 256] actually looks more correct (and vague clamped to [1, 256] so there is no division by zero in the shader should vague be zero).

* In the mkxp code, prog is only normalized and not reversed, so it goes from 0.0 to 1.0.

[yuwenhuisama]

Oh! What you said has help me a lot ! I have successfully completed this method in my engine(though I use Direct3D's shader) !! Thank you very much for your help !!!

[Ancurio]

No problem.