Transitions

[aphadeon]

Transitions are half-implemented. Basic "fade" support is in, but we also need the "file" transition types, which snap a bitmap of the screen, render that, then eat it away based on a supplied "transition" image file.

[felixjones]

I propose we do something like this; http://simonschreibt.de/gat/sacred-2-burning-map/

But with even more efficiency.

Idea is to process the transition image into a float array describing the "height" of the transition with the RGB components;

typedef struct colour_s {
    float    r;
    float    g;
    float    b;
} colour_t;

float depth[][]; // Depth map
colour_t image[][]; // Image
int width, height; // Image dimensions

for ( int x = 0; x < width; x++ ) {
    for ( int y = 0; y < height; y++ ) {
        depth[x][y] = image[x][y].r / ( 765.0f ) ); // r * ( 1 / ( 255 * 3 ) )
        depth[x][y] = max( depth[x][y], image[x][y].g * ( 2.0f / ( 765.0f ) ) ); // g * ( 2 / ( 255 * 3 ) )
        depth[x][y] = max( depth[x][y], image[x][y].b * ( 3.0f / ( 765.0f ) ) ); // b * ( 3 / ( 255 * 3 ) )

        // depth[x][y] now has the largest RGB component as its float value from 0.0 to 1.0
    }
}

// Upload depth map to a bound depth texture, storing as GL_DEPTH_COMPONENT, converting to GL_DEPTH_COMPONENT, reading as GL_FLOAT array
glTexImage2D( GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT, width, height, 0, GL_DEPTH_COMPONENT, GL_FLOAT, depth );

Key question:

How are the RGB components use? I presumed they were max, but are they read from BGR into a 24-bit integer? In which case, that makes things easier as we can divide by (2^24)-1 rather than doing something like a max function on each component.

[Glitchfinder]

I dealt with transitions ages ago, and I never did manage to figure out exactly how they handled it. I suspect it is some variant of luminosity, however, since the transitions are primarily intended to use grayscale graphics. It's also hard to describe how they handled fade, because, again, I never managed to perfectly mimic it last time I tried.

[Glitchfinder]

I just did some experimentation again in this area, and noticed something interesting. With transitions, blue completes first, followed by red, then green last. Theoretically, this behavior could be mimicked via taking the BBGGRRAA pixel values in the transition image, rearranging them into GGRRBBAA order, casting the entire combined value to an int, and then using that int as the value for the transition, where the lower values are the first to transition. It's not 100% accurate, but it's notably closer than my older attempts.

On a related subject, the transition is not actually smooth. If you make a slow transition (I was testing with a 256 frame transition), you'll notice it is actually applied via what appears to be a grainy texture. It's consistent, and shows up even when vague is set to zero.