Update FlashTransitionPainter.json

[tristanbob]

Added many new transitions and options. I want to discuss this design before putting more time into it.

Topics to discuss:

1. Should we keep the tweaks created by @westboy31.
   I left the existing special tweaks including:

• Draw the object 5 times with increasing opacity and size (to smooth edges)
• Adding + (3*TimeDelta()) to timers

2. There is some repeated code in the "Start transition..." actions for each animation.
   Should this be refactored so that most of it is only written once? Or is it fine how it is?

3. Most of the animations require the camera to be at the default position (i.e. SceneWindowWidth()/2).
   It makes sense for the transition layer to be on top of all other layers with nothing else on it, so we could just make this a requirement and tell the user not to move the camera (already mentioned in the description).

The alternative is to change everything to be based on the camera position (which is doable, but also a lot of work).

How to use:
 * Create a new layer on top of all other layers
 * Create shape-painter object and place it on the top layer
 * Assign this behavior to the shape-painter object
 * Use one of the "Start transition..." actions

Transition actions:
  * Fade to color:  Solid color that fades in or out.
  * Vertical wipe:  Solid color that comes from left or right side then moves back.
  * Horizontal wipe: Solid color that comes from top or bottom side then moves back.
  * Circle wipe:  Solid colored circle starts in center and grows to cover entire screen then shrinks to center (1 to 5 circles)
  * Rectangle wipe: Solid colored rectangle starts in center and grows to cover entire screen then shrinks to center (1 to 5 circles)
  * Star wipe: Solid colored star starts in center and grows to cover entire screen then shrinks to center (3 or more points)
  * Vertical split: Solid colors come from top and bottom and meet in center, then return.
  * Horizontal split: Solid colors come from left and right and meet in center, then return.
  * Four-way split: Solid colors come from each corner and meet in center, then return.

Conditions:
 * Transition ended:  Detects when a transition has completed

Tips:
 * Each action can be run "Forward" (end of scene), "Backward" (start of scene), or "Both" (visual effect) 
 * Use condition "Transition ended" to signal when the transition is complete
 * Use two shape-painters to enable transitions at the beginning and end of a scene
 * For multiple simultaneous transitions, use multiple shape-painter objects
 * Do not move the camera of the transition layer

Video

https://twitter.com/VictrisGames/status/1483220151889629191

Example game Project files

TransitionPainterExampleSourceFiles.zip

[D8H]

Draw the object 5 times with increasing opacity and size (to smooth edges)

I don't know if the Graphics mask handles shape opacity. Checking this could help to take a decision. Is the effect better with it?

Most of the animations require the camera to be at the default position (i.e. SceneWindowWidth()/2). It makes sense for the transition layer to be on top of all other layers with nothing else on it, so we could just make this a requirement and tell the user not to move the camera (already mentioned in the description).

The alternative is to change everything to be based on the camera position (which is doable, but also a lot of work).

I think that shape painter based extensions should be either:

• be absolute to the scene and force the absolute position with the shape painter property
• be relative to the object and either move the object itself or let users do it

But, it should never calculate translations or rotations itself (unless it's on one part of the drawing).

[tristanbob]

I don't know if the Graphics mask handles shape opacity. Checking this could help to take a decision. Is the effect better with it?

Yes, it handles opacity correctly. For instance, this is something I use for the halo of the draggable slider.

I think that shape painter based extensions should be either:

• be absolute to the scene and force the absolute position with the shape painter property
• be relative to the object and either move the object itself or let users do it

I agree 100%. For the slider/toggle/checkbox extensions, it makes sense to be relative to the shape painter's position. (I'm not certain if we force the object to use relative coordinates, but I think so)

For this transition painter extension, I think it makes more sense to be absolute. All of the transitions are calculated to cover the entire size of the screen (currently using SceneWindowWidth, but I wonder if CameraWidth would be better since it includes zoom?).

If we made this extension use relative positions, the game dev would need to place and keep the shape painter object in the center of the screen. If not, the transitions could look funny because they didn't cover the entire screen.

Secondly, it would be annoying because the shape painter would always get in the way while using the scene editor. You could hide the layer, but I often forget to unhide it when I publish the game.

Do you agree we should make this extension use absolute coordinates, and require the game dev to use a layer with default camera values?

[D8H]

I don't know if the Graphics mask handles shape opacity. Checking this could help to take a decision. Is the effect better with it?

Yes, it handles opacity correctly. For instance, this is something I use for the halo of the draggable slider.

I meant when using the shape painter with the object mask extension to add a texture like the next scene 1st frame for instance.

Do you agree we should make this extension use absolute coordinates, and require the game dev to use a layer with default camera values?

I think that the behavior should uses the position action to center the object on screen instead of adding CameraX() everywhere. It even allows to do animated thumbnail for a demo and quick testing.

[tristanbob]

I meant when using the shape painter with the object mask extension to add a texture like the next scene 1st frame for instance.

Oh, I have not tested that. I'm also not sure how you could render the next screen automatically?

I think that the behavior should uses the position action to center the object on screen instead of adding CameraX() everywhere. It even allows to do animated thumbnail for a demo and quick testing.

What are the benefits of using your method? If we are going to move the object to always be in the center, why not just skip that step and use CameraX()? They have the same outcome but fewer steps.

I'm also not sure how the animated thumbnail would work?

[D8H]

Oh, I have not tested that. I'm also not sure how you could render the next screen automatically?

I'm not sure. I wonder if we could cheat and:

• put the last frame of a scene in a global sprite object with the "render in sprite" extension (but I don't know if this extension can keep a frame or not)
• play the inverted transition to mask this sprite
  • at the beginning of the transition, the shape will take all the screen and show the previous image
  • at the end the transition, the shape painter won't draw anything

I think that the behavior should uses the position action to center the object on screen instead of adding CameraX() everywhere. It even allows to do animated thumbnail for a demo and quick testing.

What are the benefits of using your method? If we are going to move the object to always be in the center, why not just skip that step and use CameraX()? They have the same outcome but fewer steps.

Sorry, I misunderstood. I though you wanted to draw at the right place. Yes, I guess a still layer works too. In fact, it's letting the user positioning the shape painter (with a layer or a position) so our solutions are the same, I guess.

I'm also not sure how the animated thumbnail would work?

The extension user could change the dimensions either with properties of the behavior or the scaling action (but if the dimensions are always the window dimension, it needs a small calculus). This could allow integration if the animation must not take the whole screen.

[tristanbob]

1. I don't think we should consider advanced usages such as re-creating the previous frame pixel by pixel (at least for this PR).

2. What do you think about adding some parameters to define the four corners of the drawing? (This should enable your "thumbnail" idea)

By default they will use these values:

Public parameters:

xMin = 0 xMax = SceneWindowWidth* yMin = 0 yMax = SceneWindowHeight*

*Using SceneWindowWidth instead of CameraWidth should let users zoom out/in if they want (I think)

Private parameters or shared functions: (I think these might be helpful, but I'm not certain if we should include them)

TransitionWidth = xMax - xMin TransitionHeight = yMax - yMin TransitionCenterX = xMin + TransitionWidth/2 TransitionCenterY = yMin + TransitionHeight/2

3. Like we discussed and agreed in the Animation System extension, I think we should convert each transition to its own behavior.

[VegeTato]

I would like to suggest to add a new condition to the extension. Condition: Effect of Object is playing its very useful in many cases 👍