Closed ilexp closed 7 years ago
Note: Should the basic SpriteRenderer
already expose properties for two simultaneously displayed, blended frames and just ignore them, while subclasses may use that functionality?
Note: Alternatively, should there be an interface between SpriteRenderer
and SpriteAnimator
that exposes these properties, which is used instead of a direct SpriteRenderer
implementation?
If none of the above was implemented, this new design would be limited to hard, instantaneous switches between a finite number of animation states, which is likely insufficient in some advanced cases such as smooth animation. It would also be possible to introduce a new SpriteIndexBlend
struct with two indices and a float blend.
Note: Should the API be consciously limited to hard, instantaneous switches as described above?
SpriteAnimator
class.AnimSpriteRenderer
class.ICmpSpriteRenderer
component interface that allows to set a SpriteIndexBlend
.SpriteRenderer
component now exposes a SpriteIndex
property of the above index blend type.SpriteIndexBlend
property editor that uses a horizontal layout in a single line, rather than the default expandable sub editor.SpriteRenderer
, but doesn't touch animation at all anymore.SpriteIndex
state when adjusting SpriteAnimator
properties. Previously it was done on every draw and update. Now that draw is no longer there, adjusting properties in the editor has no visible effect. Fix this!
SpriteRenderer
docs that SpriteIndex
does not support displaying blended indices and thus, blending values will be ignored.SpriteRenderer
sprite index or find a way to not expose the full SpriteIndexBlend
struct due to lack of blend support. Having it there while not being able to edit it feels a bit buggy / unpolished.
VectorPropertyEditor
s more appealing? Color-coding individual editors, adding optional labels? Would be something for the master branch to be merged back to the dev-3.0.SpriteAnimator
.ActorRenderer
in the tilemaps sample to implement ICmpSpriteRenderer
.ActorAnimator
to target an ICmpSpriteRenderer
rather than an ActorRenderer
.develop-3.0
.SpriteAnimator
.SpriteRenderer.SpriteIndex
in the property grid, as it's sort of a nice2have feature that requires a bigger systemic change to be introduced properly. Postponing this.SpriteRenderer.SpriteIndex
XML docs to indicate that the base class does not evaluate blending states. It also no longer removes blending info, so subclasses can use it.SpriteIndexBlend
property editor to hide blend and next editors by default, unless blend is non-zero, or a checkbox in the editor is set.
VectorPropertyEditor
s more appealing? Color-coding individual editors, adding optional labels? Would be something for the master branch to be merged back to the dev-3.0.SpriteAnimator
.ActorRenderer
in the tilemaps sample to implement ICmpSpriteRenderer
.ActorAnimator
to target an ICmpSpriteRenderer
rather than an ActorRenderer
.develop-3.0
.SpriteAnimator
.SpriteIndexBlend
property editor to hide blend and next editors by default, unless blend is non-zero, or a checkbox in the editor is set.
VectorPropertyEditor
s more appealing? Color-coding individual editors, adding optional labels? Would be something for the master branch to be merged back to the dev-3.0.SpriteAnimator
properties. Now that it's a distinct component there's no reason for them all to begin with Anim
.SpriteAnimator
so it could replace the Tilemaps samples' ActorAnimator
ActorRenderer
in the tilemaps sample to implement ICmpSpriteRenderer
.ActorAnimator
to target an ICmpSpriteRenderer
rather than an ActorRenderer
.develop-3.0
.RequiredComponent
to be able to handle interfaces and abstract classes, combined with a "default type" that will be used for auto-created dependency components. That way, the SpriteAnimator
can, by default, auto-generate a SpriteRenderer
. This addition can be done in master
and then merged back up.int
to SpriteIndexBlend
, update all usages and add a comment regarding this to the SpriteIndex
property.SpriteAnimator
properties. Now that it's a distinct component there's no reason for them all to begin with Anim
.ActorRenderer
in the tilemaps sample to implement ICmpSpriteRenderer
.ActorAnimator
to target an ICmpSpriteRenderer
rather than an ActorRenderer
.SpriteAnimator
so it could replace the Tilemaps samples' ActorAnimator
SpriteIndexBlend
property editor to hide blend and next editors by default, unless blend is non-zero, or a checkbox in the editor is set.
VectorPropertyEditor
s more appealing? Color-coding individual editors, adding optional labels? Would be something for the master branch to be merged back to the dev-3.0.develop-3.0
.Note: Consider getting rid of SpriteIndexBlend
completely, as flipbook animation is just the way more common case and the smooth animation sample can do a custom subclass implementation of both renderer and animator. This would simplify a lot of things, including user experience / learning.
When doing this, update FlapOrDie and DualStickSpaceShooter accordingly.
SpriteIndexBlend
and make the SpriteIndex
property a simple int
.
SpriteRenderer
and SpriteAnimator
RequiredComponent
to be able to handle interfaces and abstract classes, combined with a "default type" that will be used for auto-created dependency components. That way, the SpriteAnimator
can, by default, auto-generate a SpriteRenderer
. This addition can be done in master
and then merged back up.SpriteAnimator
properties. Now that it's a distinct component there's no reason for them all to begin with Anim
.ActorRenderer
in the tilemaps sample to implement ICmpSpriteRenderer
.ActorAnimator
to target an ICmpSpriteRenderer
rather than an ActorRenderer
.SpriteAnimator
so it could replace the Tilemaps samples' ActorAnimator
develop-3.0
.Moved RequiredComponent
extension to issue #464.
ICmpSpriteRenderer.SpriteIndex
is now a regular int.ICmpSpriteRenderer.ApplySpriteAnimation
method that provides additional info.SpriteAnimator
properties and fields, so they don't all contain the anim
prefix for no good reason anymore.ActorRenderer
in the tilemaps sample to implement ICmpSpriteRenderer
.ActorAnimator
to target an ICmpSpriteRenderer
rather than an ActorRenderer
.SpriteAnimator
and ActorAnimator
with a RequiredComponent
attribute.develop-3.0
.Done.
Summary
Having
AnimSpriteRenderer
derive fromSpriteRenderer
is bad design from a component-based perspective and annoying when introducing a new subclass, as there always have to be two of them - one animated and one not. To fix this, get rid ofAnimSpriteRenderer
entirely and letSpriteRenderer
expose a sprite index property.Analysis
SpriteAnimator
component that requires aSpriteRenderer
and sets the displayed sprite index accordingly. This is a much cleaner design the separates these features horizontally, rather than stacking them vertically.