Apel is a library that brings particle animations to the table with flexible behaviour and a clean developer interface. It promises also lots of predefined shapes & paths to help the developer on their particle scene
Convert all animators to use builders for construction. They often have even more properties than particle objects, so this should be a greater benefit here. I think these are at a good starting point, but they could benefit from some usage and subsequent feedback.
Details:
PathAnimatorBase - mimics ParticleObject in being generic, subclassed, mostly final, etc.
PointAnimator - change origin to point for clarity.
Circular/Ellipse - Straightforward conversion. Should consider whether revolutions, trimming, etc. can be changed, since they're directly used in scheduling steps, and this all happens almost immediately when calling beginAnimation.
Bezier Curve - uses List to build the internal curve collection, this is easier than arrays. Also, trims on t value instead of steps, since using renderingInterval may result in an unknown number of steps.
Linear - mimics Bezier changes. Also allows for steps or interval per segment. It is up to the builder user to set these correctly. This is one area where some trial/usage is needed to helped solidify the API. I like the idea of steps or interval, need to refine the API, I think.
Clean up unused methods/constructors in all animators.
Parallel/Sequential - give each child animator a configurable delay. In Parallel, this is relative to the ParallelAnimator starting, in Seqeuential, this is relative to the previous child animator. These delays are before any child animator frame delays are processed.
If there are trivial fixes/changes, happy to incorporate here. If there is more extensive change/feedback, probably best in a follow-up. These have all been tested, and they do work the way they are as far as I can tell.
Fixes https://github.com/GitBrincie212/Apel-Mod/issues/36
Convert all animators to use builders for construction. They often have even more properties than particle objects, so this should be a greater benefit here. I think these are at a good starting point, but they could benefit from some usage and subsequent feedback.
Details:
origintopointfor clarity.revolutions,trimming, etc. can be changed, since they're directly used in scheduling steps, and this all happens almost immediately when callingbeginAnimation.Listto build the internal curve collection, this is easier than arrays. Also, trims ontvalue instead of steps, since usingrenderingIntervalmay result in an unknown number of steps.If there are trivial fixes/changes, happy to incorporate here. If there is more extensive change/feedback, probably best in a follow-up. These have all been tested, and they do work the way they are as far as I can tell.