supertux
supertux copied to clipboard
SuperTux
Proper Teleport Transition
What if instead of simply fading to black (using doors) or no transition at all (using Level.spawn();) we could use transition effect closer to entering a level, the circular one.
Now for doors it should become the new default and only play if the door is actually being entered (currently the transition effect happens even if I run away from the door in the process), same for scripted level teleports. However, for scripting the transition-less teleport should remain an option.
I wonder if we could adjust the current Level.spawn(); script in a way so that it asks for an optional third parameter, a string, to specifiy a transition style. So for example: Level.spawn("[sector]", "[spawnpoint]", "[transition_type]");
As for transition types we could have "fade" for a simple fading in and out and "circle" for a similar effect when entering a level where the screen circles in and out. If the "transition_type" is left empty is, it would just ignore the empty space and have no transition play. That way past instances of the script should still work as before. Just teleport without any transition.
Interesting idea. Optional parameters don't really work with Squirrel, I think, so the function for this will need a new name.
Additionally, using enumerators for this would probably be a better approach. But the base idea is the same.
Interesting idea. Optional parameters don't really work with Squirrel, I think, so the function for this will need a new name.
I guessed so. Wasn't sure so I tried asking anyway :P But yeah, it seems like we do. What about, uh, calling it something like Level.spawn_transition();? Nice and easy :D
I am playing around with that for some time, but this needs some tweaking though. Beside a small glitch that the new level sector can already been seen when changing from shrinkfade (that is what the circular effect is called in code) fading out to in which need to be fixed, I tried to take #2649 into account. My idea was to freeze the game during the shrinkfade so that (of course in combination with appropriate level design) Tux will not get harmed during the effect. Unfortunately the fading effects are dependent on the gamespeed, so the game must at least run (very slow) to make the effect happen. So maybe having some time of invincibility might indeed be better.
@Vankata453 : When adding the scripting part, I was not sure how to add an enumeration as function parameter. Should the enumeration be defined in the default.nut? Possibly by assigning either Integer or String values and parsing them in the script wrapper. For now I started just with a normal string parameter (instead of an enumeration) which is just being parsed and evaluated.
Another aspect I need to take into account is to add a delay to the teleportation by the time the fadeout animation needs to finish. Hopefully I can provide some preview soon.
When adding the scripting part, I was not sure how to add an enumeration as function parameter. Should the enumeration be defined in the default.nut? Possibly by assigning either Integer or String values and parsing them in the script wrapper. For now I started just with a normal string parameter (instead of an enumeration) which is just being parsed and evaluated.
About enumerators, they should be added to the Squirrel const table, just like it's done with ANCHOR_POINTS. #2792 makes this way easier to achieve, so if you want, you can leave a TODO for this, and it could be done after that PR is merged.
Thanks. I'll focus on getting the other things done first and finish the scripting part later.
Interesting idea. Optional parameters don't really work with Squirrel, I think, so the function for this will need a new name.
Additionally, using enumerators for this would probably be a better approach. But the base idea is the same.
http://squirrel-lang.org/squirreldoc/reference/language/functions.html#default-paramaters ? Once the simplesquirrel thing is merged, this will be much easier, no?
Interesting idea. Optional parameters don't really work with Squirrel, I think, so the function for this will need a new name. Additionally, using enumerators for this would probably be a better approach. But the base idea is the same.
http://squirrel-lang.org/squirreldoc/reference/language/functions.html#default-paramaters ? Once the simplesquirrel thing is merged, this will be much easier, no?
I was wrong: simplesquirrel does not support method overloading.