Support for easing on any path object #1507
Conversation
|
Everything works fine with the "platform" object, but not with moving tilemaps. There are a few problems when Tux in standing on a downwards-accelerating platform (as a tilemap). Sometimes, Tux tends to move "into" the platform, and eventually either jumps or dies. However, this is a known issue regarding moving platforms, and is related to issue #401 on which I've been working lately. In other words: it doesn't have to be fixed in this PR. There's just one comment I would make: I suggest you remove the "elastic" mode, because Tux either goes right through it or gets killed by it (when it's slower), so it's pretty useless:
Apart from that, I made recordings of the other bugs I've seen, but again, the fundamental problem here is the collision mechanism. I'm about to write a fix for that and submit a PR soon. I don't know if it should be merged in the meantime (as it doesn't affect platform objects), or if we should wait for #401 to be fixed. @tobbi @weluvgoatz, what do you guys thinks ? But anyway, here's what went wrong:
|
|
Ah, that's problematic. I'd still like to retain easing as it can be used correctly if, for example, it is used on non-solid tilemaps or on solid tilemaps on which Tux can't be standing when it moves (like a tile-based door that only moves during a scripted animation). But I get your point, it can easily be misused and it's not necessarily obvious to an unexperienced or unaware level designer, and it can be a very frustrating bug to encounter as a player. I can make a few temporary changes while the bug is being fixed :
Would any of them be useful? Also, if you want some help to fix that bug, I'm all in :) |
|
You forgot one option:
|
@mbernard2 said he was working on it; Imma wait for his reply, so we don't do the same fix twice :) |
|
I think the included files are "small" enough to be put in an appropriate subdirectory of |
|
That's true, plus the files have been heavily modified, and I never managed to find how to include them without typing "#include "../external..."" so it would be good if I moved it to src/math. I'll ask around a bit, and if people approve it I'll do that! |
src/math/easing.hpp
Outdated
| double BounceEaseInOut(double p); | ||
|
|
||
| typedef double(*easing)(double); | ||
| easing getEasingByName(EasingMode ease_type); |
There was a problem hiding this comment.
change the signature to getEasingByName(const EasingMode& easy_type)
src/math/easing.hpp
Outdated
|
|
||
| typedef double(*easing)(double); | ||
| easing getEasingByName(EasingMode ease_type); | ||
| const char* getEasingName(EasingMode ease_type); |
src/math/easing.hpp
Outdated
|
|
||
| } | ||
|
|
||
| EasingMode EasingMode_from_string(std::string ease_name); |
There was a problem hiding this comment.
I corrected the signatures in easing.cpp and easing.hpp, GCC told me nothing else had to be changed (it didn't print any warning). I'll wait for the current build to finish, so that if there's any other error clang finds, I'll correct it in the same commit to save some time.
* Support for easing on any path object (platforms, tilemaps, etc.) * Attempt #1 to fix Travis build errors (easing) * Attempt #2 at fixing the Travis build (easing) * Remade the easing system with a WTFPL-Licensed library * Fixed the double-to-flat implicit conversions in easing * Changed 'std::string' with 'const char*' in C-linked functions in easing * Reordered easing methods so that the names actually match the easing functions * Moved easing to src/math * Fixed include paths, oops * Fixed some magic includes * Deleted unreachable code in easing.cpp * Improved coding style and fixed building problem on macOS Co-authored-by: Semphris <invalid@example.com>
Instead of the mandatory flat linear movement, platforms and tilemaps can now move at varying speed more easily with easing!
Demo : https://youtu.be/gmWf3KeeiSs