legacy storyboard - adding a "proper" crossfade

Solar2D Composer
#1

fwiw: if you’re using the legacy storyboard source, you can add a “proper” crossFade for fullscreen scenes as follows…

 -- insert this into the effectsList -- just before the existing crossFade would be a good place -- (or adjust trailing commas if/as necessary when adding elsewhere) ["properCrossFade"] = { ["from"] = { -- essentially "do nothing" alphaStart = 1.0, alphaEnd = 1.0, }, ["to"] = { alphaStart = 0, alphaEnd = 1.0 }, concurrent = true, sceneAbove = true, -- forces current scene above previous scene },

why? existing fade/crossfade do the following:

fade: fades out (to black, or whatever ‘blank’ display objects you might have ‘under’ storyboard’s stage) previous scene, then fades in (from black/blank) current scene

crossFade: fades out previous scene, simultaneously fading in current scene underneath
(this will cause a partial dimming/bleedthru as the underlying black/blank screen will be visible during the transition while both previous/current scenes are partially transparent – this is the primary motivation for “properCrossFade”)

properCrossFade does:
leaves previous scene fully opaque underneath, fades in current scene over the top

hth

[edit to clarify intended use] a “full screen” scene fading in over another “full screen” scene, ie scenes that both have their own ‘background’, as this effect not really appropriate for a scene that doesn’t fully occupy screen (as underlying ‘previous’ scene would then appear to instantly vanish at end of transition), so if using a ‘shared’ background ‘under’ storyboard stage, then original crossFade is still what you’d want

#2

Hi. Do you mind if I add this to my OOP Composer library ? I actually borrowed the f/x from legacy Storyboard.

#3

sure, no problem, and further: I hereby relinquish any and all rights and place it in the public domain.

if you’re playing: it might also occur to you that there’s an “inverse” implied too - where you’d place current scene below w/ alpha=1 immediately, then on top fade previous to 0. they’re almost the same, unless really nitpicking a long-duration transition - then you might notice (due to rgb being non-linear perceptually, so a linear change in alpha, mixing non-linear rgbs, gives a non-linear fade, as written it’s “slow in, fast out”, the inverse would appear “fast in, slow out”) i prefer as written, and don’t need both myself, but… :slight_smile:

#4

a couple more semi-related thoughts, just to document for posterity - don’t know how may people actually experiment with this stuff, but…

wrt non-linear rgb’s - if using any kind of “fade” transition, you can get “smoother” results if you use a quad easing curve (which is a reasonable approximation of a gamma curve). for example, the original crossfade with gamma correction:

local storyboard = require("storyboard") local crossFadeGC = { ["from"] = { alphaStart = 1, alphaEnd = 0, transition = easing.inQuad -- in slower, reach perceptual 50% rgb~=187 slower }, ["to"] = { alphaStart = 0, alphaEnd = 1, transition = easing.outQuad -- in faster, reach perceptual 50% rgb~=187 quicker }, concurrent = true, } storyboard.effectList["crossFadeGC"] = crossFadeGC

compare it to original using full-screen scenes with long duration, there will be less perceived “dimming” as the power curves better “mesh” with each other.

fwiw, hth

[edit: the above techniques also *appear* to work with composer, but it’s “risky” since we can’t inspect the source for any potential differences in implementation, so caveat emptor, safer to suggest doing it with storyboard only]

#5

Hi. Do you mind if I add this to my OOP Composer library ? I actually borrowed the f/x from legacy Storyboard.

#6

sure, no problem, and further: I hereby relinquish any and all rights and place it in the public domain.

if you’re playing: it might also occur to you that there’s an “inverse” implied too - where you’d place current scene below w/ alpha=1 immediately, then on top fade previous to 0. they’re almost the same, unless really nitpicking a long-duration transition - then you might notice (due to rgb being non-linear perceptually, so a linear change in alpha, mixing non-linear rgbs, gives a non-linear fade, as written it’s “slow in, fast out”, the inverse would appear “fast in, slow out”) i prefer as written, and don’t need both myself, but… :slight_smile:

#7

a couple more semi-related thoughts, just to document for posterity - don’t know how may people actually experiment with this stuff, but…

wrt non-linear rgb’s - if using any kind of “fade” transition, you can get “smoother” results if you use a quad easing curve (which is a reasonable approximation of a gamma curve). for example, the original crossfade with gamma correction:

local storyboard = require("storyboard") local crossFadeGC = { ["from"] = { alphaStart = 1, alphaEnd = 0, transition = easing.inQuad -- in slower, reach perceptual 50% rgb~=187 slower }, ["to"] = { alphaStart = 0, alphaEnd = 1, transition = easing.outQuad -- in faster, reach perceptual 50% rgb~=187 quicker }, concurrent = true, } storyboard.effectList["crossFadeGC"] = crossFadeGC

compare it to original using full-screen scenes with long duration, there will be less perceived “dimming” as the power curves better “mesh” with each other.

fwiw, hth

[edit: the above techniques also *appear* to work with composer, but it’s “risky” since we can’t inspect the source for any potential differences in implementation, so caveat emptor, safer to suggest doing it with storyboard only]