Add warp paintings by Koopa1018 · Pull Request #176 · Redux-Team/Legacy_SM63Redux

Koopa1018 · 2023-05-30T00:30:38Z

Description of changes

Adds enterable warp paintings, complete with a fancy entry animation.

Under the hood, paintings are based on the same class as doors and warp pipes. Press "enter" button -> play entry animation -> go to new scene, or elsewhere in the current scene.

The entry animation is quite involved, featuring a shader with a painting-ripple effect, as well as an entirely new type of screen transition (see white_warp.gd). The specifics of the animation depend on if the painting leads to a new scene:

If going to a new scene, the animation is several seconds long. When the player hits the painting, the UI disappears, and the camera zooms in on the rippling painting until it fills the screen. At that point, the painting appears to "burn through" to white, and the screen then fades into the next scene.
If going somewhere in the current scene, the animation only lasts one second. The painting ripple settles down quickly, and none of the other effects happen at all before the player reappears in their warp destination. (The way transitions currently work means there's not even a standard WindowWarp transition.)

Before review:

It needs to be possible to change the position of the trigger area relative to the painting.
After the 0.1.6 update, Mario needs a new jumping-in animation.
Sound design. (Though this can theoretically be added later, in a separate PR.)
Would be lovely to decouple choice of animation from whether the scene is changing. This would open the door for much more varied entry animations, e.g. the painting plays an animation before the camera zooms in.
Unique entry animation when player is swimming.
Probably some others.

Very important to have a function you can be 100% sure will run at the very end of the animation (rather than remembering if the animation ends one frame before _animation_length() or not). Also, I notice a common theme with InteractableWarp animations: frame 0 set player graphics, all other frames do special logic. _begin_animation() makes that pattern a little more elegant.

Docstring is much more formalized and much more readable now. Also clears up some ambiguities that existed about animation timing, etc.

Found in the pause menu's star map graphics. These will be nice when proportioning the thing.

Bout what you'd expect it to be.

Very important to have a function you can be 100% sure will run at the very end of the animation (rather than remembering if the animation ends one frame before _animation_length() or not). Also, I notice a common theme with InteractableWarp animations: frame 0 set player graphics, all other frames do special logic. _begin_animation() makes that pattern a little more elegant.

Docstring is much more formalized and much more readable now. Also clears up some ambiguities that existed about animation timing, etc.

Painting is an InteractableWarp, like doors and pipes. It responds to the "up" input. Animation is not at all complete.

...Which actually directly calls player jump logic! Makes for a very accurate jump.

Feels weird to modify the player script to make cutscenes work nicer, but it's still a whole lot more elegant than copying the actual velocity-modify logic into the painting script.

now that I have that ability.

Was allowing player to jump in when solidly outside the frame.

Not implemented yet

Makes the painting entry look serviceable, at least.

...also remove the 99999x99999 water polygon so the game doesn't crash when the test map runs XP

For smaller paintings.

Need to be able to set the graphic, eh? ;) Picture and Frame are separately configurable. The idea is, picture has to be able to ripple without rippling the frame as well. This will be the simplest way to do that, I think--separate picture and frame sprites.

...so that we can mark child classes as Tool without causing on-scene-load problems.

Can't use toolscripts, blah.

This reverts commit 335912b. Feel like it's not my place to make a change to Interactable.

Annoying if you're passing by and you jump and accidentally get sucked into the painting.

I figured I would have to write this from scratch, but. Turns out it was here all along and I just didn't know it 🤦

Burnaway clips the troughs of the painting away to white. It's definitely a very particular effect.

Decays away slowly if changing scenes, fast if not.

- Longer entry animation in both cases. - Slow down ripple decay rate in scene-change mode. - Calculate ripple origin from player position. - Use burnaway during entry flash. - Ensure all shader params are reset at the proper times.

First, it's now truly branchless. Second, the burnaway mask is actually used (that took some work to get locked into a (0,1) slider range). And third, let's separate the timing for the burnaway half of the flash from the non-burnaway half!

And a stronger effect still looks nicer for in-level warping.

Creyon suggested. Does indeed look nicer. Designed so the player doesn't land in the exact center, but rather on an imaginary line across the center.

If the burnaway lags on the final frame, the transition looks pretty awful--freezing on a frame with a little painting left, then smashing to a frame where the scene has already started reappearing, meaning there's no frames of solid white in between. Easiest way to avoid this is to have the burnaway end before scene loading is even thinking of beginning.

Having the material constantly attached to all paintings, as I feared, leads to every painting rippling in sync. Easiest fix is to just keep most paintings' materials unset by default, and only load it onto the ones which are about to come active. If multiplayer is needed, each painting could instantiate a copy of the material before it uses it. This works fine for now, though.

I'm expecting non-square paintings to show up in at least one spot, so it'd be a good idea to explicitly keep the shape's outline from rippling.

Here's hoping I'll be able to manual-merge this sheet when the time comes to merge in the pound-spin windup pose from the pound feedback branch!

These may hopefully become tooltips one day. In the meantime, there should be some documentation on how to use these.

Proper tooltips! Yaaaaay

extension change for shader--tiny papercuts all over the place, aaaaah (also load the material in GD4)

GTcreyon · 2023-12-11T12:16:44Z

How's the progress on this? Is a new jump-in animation needed? If so, I'll need to notify the art team.

"don't" is correct instead of "doesn't" in this case.

Been a while since I made this change, but IIRC Godot 4.1 is not fond of this construction (reading `PlayerCharacter` constants from `body` instead of `PlayerCharacter`).

Koopa1018 · 2023-12-12T11:10:34Z

Stopped work because the 4.1 upgrade broke interactables which respond to "up"; see #235. The workaround I used for pipes doesn't seem to work for paintings, which means I might be waiting on #244 before I can make the necessary bugfixes.

Jump-in animation needed for sure, but due to the above, priority is debatable.

Mercifully, it seems like there was no data loss this time. I also moved Mario to the end of the hierarchy, in an attempt to fix paintings' not responding. Didn't end up doing anything, but it was worth a shot.

Koopa1018 added 30 commits November 25, 2022 21:06

Use begin/end fns, also rewrite docstring

21f7e7a

Docstring is much more formalized and much more readable now. Also clears up some ambiguities that existed about animation timing, etc.

Save these graphics in a usable form

8aeff84

Found in the pause menu's star map graphics. These will be nice when proportioning the thing.

Create painting.tscn

a66e477

Bout what you'd expect it to be.

Use begin/end fns, also rewrite docstring

432c171

Docstring is much more formalized and much more readable now. Also clears up some ambiguities that existed about animation timing, etc.

Create and attach painting script

afb2ff0

Painting is an InteractableWarp, like doors and pipes. It responds to the "up" input. Animation is not at all complete.

Sort painting behind player

cd93d24

Proper jump-in animation

ed0d99b

...Which actually directly calls player jump logic! Makes for a very accurate jump.

Make "hold jump longer" a callable function

b1643f0

Feels weird to modify the player script to make cutscenes work nicer, but it's still a whole lot more elegant than copying the actual velocity-modify logic into the painting script.

Make painting-entry jump a little longer

3db8586

now that I have that ability.

Retune jump end time a little

96e13b8

Reduce painting's response area width

623df61

Was allowing player to jump in when solidly outside the frame.

Add white flash to painting prefab

314c1a6

Not implemented yet

Properly implement white flash

da862ff

Makes the painting entry look serviceable, at least.

Add paintings to the test map

2442bc6

...also remove the 99999x99999 water polygon so the game doesn't crash when the test map runs XP

Configurable detection radius

02c6e32

For smaller paintings.

Unroll Interactable's sprite-assign behavior

335912b

...so that we can mark child classes as Tool without causing on-scene-load problems.

Make image swapping not crash

365023d

Can't use toolscripts, blah.

Revert "Unroll Interactable's sprite-assign behavior"

e95d817

This reverts commit 335912b. Feel like it's not my place to make a change to Interactable.

Only accept standstill jumps

7d6f940

Annoying if you're passing by and you jump and accidentally get sucked into the painting.

Style-conformity line edits

c8b2bfa

Use flash shader instead of white overlay

a1c1e17

I figured I would have to write this from scratch, but. Turns out it was here all along and I just didn't know it 🤦

First draft of painting ripple shader

73e3aa5

Add burnaway to the painting shader

33ffa03

Burnaway clips the troughs of the painting away to white. It's definitely a very particular effect.

Implement ripple in painting animation

eb387b0

Decays away slowly if changing scenes, fast if not.

Dangit I crammed a bunch into one again

f5cb56b

- Longer entry animation in both cases. - Slow down ripple decay rate in scene-change mode. - Calculate ripple origin from player position. - Use burnaway during entry flash. - Ensure all shader params are reset at the proper times.

Major burnaway improvements

30ab0a7

First, it's now truly branchless. Second, the burnaway mask is actually used (that took some work to get locked into a (0,1) slider range). And third, let's separate the timing for the burnaway half of the flash from the non-burnaway half!

Hmm, don't want pre-rippled paintings

61b9470

Koopa1018 added 19 commits December 5, 2022 11:30

Named constants for decay exponents

dac891d

And a stronger effect still looks nicer for in-level warping.

Always jump toward painting center

b694a28

Creyon suggested. Does indeed look nicer. Designed so the player doesn't land in the exact center, but rather on an imaginary line across the center.

Remove debug logging

04c9cbc

Add paintings in both modes (scene and level warp)

739e6bd

Don't ripple painting's alpha channel

51c2ec7

I'm expecting non-square paintings to show up in at least one spot, so it'd be a good idea to explicitly keep the shape's outline from rippling.

Add painting-jump animation+pose

f684dae

Here's hoping I'll be able to manual-merge this sheet when the time comes to merge in the pound-spin windup pose from the pound feedback branch!

Implement jump-back animation

e438ebc

Merge branch 'master' into warp_paintings

a4ab49f

API updates: scene change

7bffcec

API updates: player object

5492b0c

Comment export variables

bb88d93

These may hopefully become tooltips one day. In the meantime, there should be some documentation on how to use these.

Merge branch 'repo-godot-4-1' into feature-warp-paintings

3f604e0

Let GD4 update merged painting files

8c73240

Fix painting.gd for GD4

b074961

Proper tooltips! Yaaaaay

Update painting shader+material

cee9df2

extension change for shader--tiny papercuts all over the place, aaaaah (also load the material in GD4)

Styleguide conform painting shader

0d658c2

Open painting in Godot 4

ff88cbe

Koopa1018 changed the base branch from master to repo-godot-4-1 July 24, 2023 00:11

Koopa1018 added the update-needed Needs to be changed to match project's current state label Sep 22, 2023

Base automatically changed from repo-godot-4-1 to master September 24, 2023 15:25

GTcreyon added enhancement New feature or request help wanted Extra attention is needed labels Dec 11, 2023

Koopa1018 added 3 commits December 12, 2023 03:51

Merge branch 'master' into feature-warp-paintings

d8a5fd7

Minor grammar fix in a comment

d1e97e5

"don't" is correct instead of "doesn't" in this case.

Read constant from type, not body variable

50eaa71

Been a while since I made this change, but IIRC Godot 4.1 is not fond of this construction (reading `PlayerCharacter` constants from `body` instead of `PlayerCharacter`).

Let Godot 4 update test level

3ac8050

Mercifully, it seems like there was no data loss this time. I also moved Mario to the end of the hierarchy, in an attempt to fix paintings' not responding. Didn't end up doing anything, but it was worth a shot.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add warp paintings - #176

Add warp paintings#176
Koopa1018 wants to merge 74 commits into
masterfrom
feature-warp-paintings

Koopa1018 commented May 30, 2023 •

edited

Loading

Uh oh!

GTcreyon commented Dec 11, 2023

Uh oh!

Koopa1018 commented Dec 12, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Koopa1018 commented May 30, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of changes

Before review:

Uh oh!

GTcreyon commented Dec 11, 2023

Uh oh!

Koopa1018 commented Dec 12, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Koopa1018 commented May 30, 2023 •

edited

Loading