Hi
In a game I want to hide fuel cells behind a wall. When I fade the level in with gotoScene and fade effect the fuel cells are visible for the duration of the fade in, because all objects make a transition in the alpha channel (so for a short time everything is transparent and visible).
How can I solve this issue?
Thanks
Olivier
Hi Olivier,
One solution would be insert all of your scene objects into a snapshot. A snapshot basically treats everything within it as one “unit”, so an alpha fade transition would apply to the entire thing, not to each individual child.
https://docs.coronalabs.com/guide/graphics/snapshot.html
Another method (perhaps easier) would be to just capture the entire screen, display the captured image on top of everything else, remove all of the objects behind (those that made up the contents of the capture), and then fade in/out the captured image.
https://docs.coronalabs.com/api/library/display/captureScreen.html
Best regards,
Brent
if your “previous” scene doesn’t have any such alpha layering problems, then you could define a new crossfade effect that fades only the previous scene while it sits above the new/current scene which is always at full opacity. it’s still a proper crossfade effect, but only one of the scenes (the one without the layered alpha problem) would actually be fading.
just after including composer for the first time, presumably in main.lua, you’d define something like this, once:
composer.effectList["fadeAbove"] = { ["from"] = { alphaStart = 1.0, alphaEnd = 0.0, }, ["to"] = { -- essentially "do nothing" alphaStart = 1.0, alphaEnd = 1.0 }, concurrent = true, sceneAbove = false, }
then in your code, use it just like any other named effect:
-- in SceneWithoutAlphaProblem: composer.gotoScene( "SceneWithAlphaProblem", "fadeAbove", 1000 )Many thanks to both! I’ll try which solution works best hiding my fuel cells 
@davebollinger: I tried your method, but the transition only works in simulator, on my s3 the above scene is getting darker and when black, the ScenewithAlphaProblem is showing directely.
Also in simulator the effect is that Above Scene is getting more and more transparent while the ScenewithAlphaProblem is beginning to shine through, But it should be: Above darker to black, then AlphaProblem brighter to full brightness.
Your method would be quite elegant, I’d like to implement it.
Olivier
the effect i posted is a *cross*fade, not a fade (to black). as implemented in Corona, and as you’ve seen, the fade effect is an alpha effect which produces all sorts of undesirable artifacts if you nitpick it – you may not even have noticed it yet, but if fading from, for example, a title screen with buttons drawn over a background, you’ll be able to see through your buttons to your background – same cause/reason as your wall-hiding-fuel alpha problem.
in short, you can’t do Corona-style fade-with-alpha on the scene contents if your scenes have layered graphics that must preserve opacity. you need to do that alpha fade on something “simpler” that isn’t layered. brent’s suggestion of a snapshot is one such approach, another is…
to do a “proper” fade-out-to-black, fade-in-from-black, without any alpha problems on EITHER scene, you actually need TWO custom effects AND an in-between cut scene:
the cut scene will only have a single full-screen black rectangle at full opacity.
the effects you’ll need are:
previous scene under, alpha constant 1; current scene above, alpha from 0 to 1
previous scene above, alpha from 1 to 0; current scene below, alpha constant 1
(alternatively, you could do it “manually” with each scene having its own black rectangle, first scene transitions it to full alpha then on complete goes to the next scene WITHOUT a effect, next scene’s black rect starts out fully opaque, and transitions to transparent)
Thank you very much! I already had a cutscene and implementing it was easy! Greetings Olivier
Hi Olivier,
One solution would be insert all of your scene objects into a snapshot. A snapshot basically treats everything within it as one “unit”, so an alpha fade transition would apply to the entire thing, not to each individual child.
https://docs.coronalabs.com/guide/graphics/snapshot.html
Another method (perhaps easier) would be to just capture the entire screen, display the captured image on top of everything else, remove all of the objects behind (those that made up the contents of the capture), and then fade in/out the captured image.
https://docs.coronalabs.com/api/library/display/captureScreen.html
Best regards,
Brent
if your “previous” scene doesn’t have any such alpha layering problems, then you could define a new crossfade effect that fades only the previous scene while it sits above the new/current scene which is always at full opacity. it’s still a proper crossfade effect, but only one of the scenes (the one without the layered alpha problem) would actually be fading.
just after including composer for the first time, presumably in main.lua, you’d define something like this, once:
composer.effectList["fadeAbove"] = { ["from"] = { alphaStart = 1.0, alphaEnd = 0.0, }, ["to"] = { -- essentially "do nothing" alphaStart = 1.0, alphaEnd = 1.0 }, concurrent = true, sceneAbove = false, }
then in your code, use it just like any other named effect:
-- in SceneWithoutAlphaProblem: composer.gotoScene( "SceneWithAlphaProblem", "fadeAbove", 1000 )Many thanks to both! I’ll try which solution works best hiding my fuel cells
@davebollinger: I tried your method, but the transition only works in simulator, on my s3 the above scene is getting darker and when black, the ScenewithAlphaProblem is showing directely.
Also in simulator the effect is that Above Scene is getting more and more transparent while the ScenewithAlphaProblem is beginning to shine through, But it should be: Above darker to black, then AlphaProblem brighter to full brightness.
Your method would be quite elegant, I’d like to implement it.
Olivier
the effect i posted is a *cross*fade, not a fade (to black). as implemented in Corona, and as you’ve seen, the fade effect is an alpha effect which produces all sorts of undesirable artifacts if you nitpick it – you may not even have noticed it yet, but if fading from, for example, a title screen with buttons drawn over a background, you’ll be able to see through your buttons to your background – same cause/reason as your wall-hiding-fuel alpha problem.
in short, you can’t do Corona-style fade-with-alpha on the scene contents if your scenes have layered graphics that must preserve opacity. you need to do that alpha fade on something “simpler” that isn’t layered. brent’s suggestion of a snapshot is one such approach, another is…
to do a “proper” fade-out-to-black, fade-in-from-black, without any alpha problems on EITHER scene, you actually need TWO custom effects AND an in-between cut scene:
the cut scene will only have a single full-screen black rectangle at full opacity.
the effects you’ll need are:
previous scene under, alpha constant 1; current scene above, alpha from 0 to 1
previous scene above, alpha from 1 to 0; current scene below, alpha constant 1
(alternatively, you could do it “manually” with each scene having its own black rectangle, first scene transitions it to full alpha then on complete goes to the next scene WITHOUT a effect, next scene’s black rect starts out fully opaque, and transitions to transparent)
Thank you very much! I already had a cutscene and implementing it was easy! Greetings Olivier
Just tryring to do the same thing. The best solution so far is as davebollinger says - to effectively fade up a rect - change scenes then fade out another rec over the next scene. But what you get on larger scenes with multiple images is quite a long pause between scenes of just black.
What would be better is some solution that uses a custom composer transition. The “fade” effect doesn’t work as indicated with the alpha of individiual images. But is there some way of adding a rectangle to composer somehow and controlling it by passing in to the effectsList?
https://coronalabs.com/blog/2014/12/23/tutorial-controlling-composer-scene-transitions/
that sort of stall is caused by the load/create of a new scene during the transition. if you think your cut scene is the culprit then simply pre-load it. but that’s unlikely to be the problem, because your cut scene should be trivially simple. instead, what you probably need to do is pre-load your heavily image-laden scene - as it’s far more likely that that scene is the one causing the stall.
you could isolate your stall testing by just using the existing “crossFade” effect (and temporarily ignoring alpha problems). if “crossFade” experiences the same stall (in the absence of any cut scene at all) then it’s your image-laden scene causing the stall.
changing “who owns” the rectangle (from a cutscene to composer) shouldn’t significantly affect the pause you’re experiencing. composer does already have a touch overlay rect that is present during transitions to intercept clicks, which in theory could be pressed into service to do this just by changing it’s visibility/color and transitioning its alpha, except that its private and composer is closed-source, so forget it. (you could do it with open-sourced storyboard though)
btw, if you DO use crossFade for anything, you might instead want a version like this:
https://forums.coronalabs.com/topic/48146-legacy-storyboard-adding-a-proper-crossfade/
it presents a crossfade where the underlying scene remains opaque (eliminating a REALLY glitchy-looking in-between state of the built-in crossFade where BOTH scenes are partially transparent) it was written for use with storyboard, but composer uses the exact same mechanism, so it’s easily ported. (it will not, however, eliminate any intra-scene layered-alpha problems in the new scene as discussed here in this thread)
Thanks Dave.
Yes, the freeze is totally to do with the size of the next scene. In the app we’re doing, the user selects a page to goto so if preloading is being used it has to happen before the scene starts to transition. The problem is that there is no way to know when the preload has finished to start the transition. You could guess but either way, all this does is put a freeze or pause before the transition rather than in the middle as is currently happening.
Depending on the size of scenes, crossFade never works as advertised. When it is called, it must preload the next scene and then call the transition immediately so you get that thing where the code starts before the images have loaded. This results in a jerky or non-existent effect, just the next scene suddenly appearing.
Having investigated further, the issue seems to happen when using:
concurrent = true
But when using “fade” for instance when concurrent=false, there is no issue of jerky or unfinished transitions. The first scene fades out then the next fades in just fine. It must be preloading the next scene before starting the transition rather than at the same time as “crossFade” does…
This leads me to think about associating the fade in and out of our black rectangle with the alpha transition of the scenes used by Composer in “fade”. Using an enterFrame listener, it would be possible to check when the scene begins to fade and tether that to the alpha properties of the black rectangle. I’ve yet to try that but did hear Ed talking about seeing someone doing something similar. I’ve asked if he remembers specifically where he saw it here if anyone has seen anything similar:
btw aside, and just fwiw, cuz i’m NOT trying to steal any credit for Ingemar’s work, but I’m the one who showed him that trick. ;)
https://forums.coronalabs.com/topic/48659-missing-composer-transition-effects/
re the scene-owned rects approach: see my 5/19/2015 post above for the last sentence beginning “(alternatively…” – that approach does (or _can, _in the right circumstances) work, just using transitions (and thoughtful use of onComplete to trigger an immediate scene change half-way through WITHOUT its own transition – because this isn’t a “concurrent” effect - ie fade to black THEN fade from black).
the problem STILL though, is you don’t want to be stalling for a scene load at any time during a transition - whether composer’s or your own diy approach. What you may want to consider is when user selects a scene, immediately transition to a permanently preloaded “loading” scene, passing it a parameter of the next scene to load, and have it do the work of load/create the next scene, THEN transition from your loading scene to the fully loaded/created game scene.
hth
Just tryring to do the same thing. The best solution so far is as davebollinger says - to effectively fade up a rect - change scenes then fade out another rec over the next scene. But what you get on larger scenes with multiple images is quite a long pause between scenes of just black.
What would be better is some solution that uses a custom composer transition. The “fade” effect doesn’t work as indicated with the alpha of individiual images. But is there some way of adding a rectangle to composer somehow and controlling it by passing in to the effectsList?
https://coronalabs.com/blog/2014/12/23/tutorial-controlling-composer-scene-transitions/
that sort of stall is caused by the load/create of a new scene during the transition. if you think your cut scene is the culprit then simply pre-load it. but that’s unlikely to be the problem, because your cut scene should be trivially simple. instead, what you probably need to do is pre-load your heavily image-laden scene - as it’s far more likely that that scene is the one causing the stall.
you could isolate your stall testing by just using the existing “crossFade” effect (and temporarily ignoring alpha problems). if “crossFade” experiences the same stall (in the absence of any cut scene at all) then it’s your image-laden scene causing the stall.
changing “who owns” the rectangle (from a cutscene to composer) shouldn’t significantly affect the pause you’re experiencing. composer does already have a touch overlay rect that is present during transitions to intercept clicks, which in theory could be pressed into service to do this just by changing it’s visibility/color and transitioning its alpha, except that its private and composer is closed-source, so forget it. (you could do it with open-sourced storyboard though)