Extract emitter shape so it no longer depens on a View.#98
Open
pserwylo wants to merge 1 commit into
Open
Conversation
Now, the interface just specifies x, y, width and height. This allows for either a Android `View` object, or alternatively an arbitrary rectangle to be used for emission locations. It maintains backward compatibility with the current API by overloading each method which accepts a `View`. The new method accepts an `Emitter`, and the old method delegates to the new method, by passing in a `new ViewEmitter(view)` whenever the new method expects an `Emitter`. In the future, this could be further refactored to expose even more flexibility. For example, the entire calculation for initial particle locations into the new `Emitter` interface. That is to say, instead of it being hard coded to use `x`, `y`, `width`, `height` (and hence a rectangle emission area), we could instead have an interface which exposes a method `generateParticleLocation()`. Some emitters may choose to use a rect, others could use a circle. Others could do even more interesting things such as from a point, but randomly distributed around the point according to a Gaussian distribution. Another future refactoring would be to attach the `gravity` argument to the `Emitter` itself. That way the `ParticleSystem` itself doesn't need to care about whether to anchor particles to the top or bottom of a rectangle area. Instead you would configure this on the emitter object before passing it to the particle system.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Now, the interface just specifies x, y, width and height. This allows for either
a Android
Viewobject, or alternatively an arbitrary rectangle to be used for emissionlocations.
It maintains backward compatibility with the current API by overloading each method which accepts a
View. The new method accepts anEmitter, and the old method delegates to the new method, by passing in anew ViewEmitter(view)whenever the new method expects anEmitter.In the future, this could be further refactored to expose even more flexibility. For example, the entire calculation for initial particle locations into the new
Emitterinterface. That is to say, instead of it being hard coded to usex,y,width,height(and hence a rectangle emission area), we could instead have an interface which exposes a methodgenerateParticleLocation(). Some emitters may choose to use a rect, others could use a circle. Others could do even more interesting things such as from a point, but randomly distributed around the point according to a Gaussian distribution.Another future refactoring would be to attach the
gravityargument to theEmitteritself. That way theParticleSystemitself doesn't need to care about whether to anchor particles to the top or bottom of a rectangle area. Instead you would configure this on the emitter object before passing it to the particle system.