This:
* Deprecates the NoiseEffectController that is based on the deprecated
vector_math library impl
* Adds a new bridge package `flame_noise` to bridge fast noise
Note: the *goal* of this PR is to allow the immediate deprecation of the
old NoiseEffectController by providing an experimental, suitable
replacement. I believe the package flame_noise will look nothing like
this at all if I am able to land [some improvements to the underlying
fast_noise lib](https://github.com/frankpepermans/fast_noise/pull/5). We
will be able to have for example a generic NoiseEffectController.
However I believe we should merge this as an experimental package for
now to unblock removing the current implementation from Flame which is
negatively affecting our scores on pub. Therefore I would advise we
don't spend any time discussing specifics of how the API/impl provided
for the flame_noise, and just go with _something_ instead of nothing.
This PR adds first layout component: AlignComponent, an equivalent of Align widget in Flutter.
AlignComponent sizes itself to its parent, and then keeps its child aligned to the specified anchor within its own bounding box.
Also adding onParentResize() lifecycle method, which is similar to onGameResize, but fires whenever the parent of the current component changes its size for any reason. (FlameGame is assumed to have the size canvasSize, and will invoke onParentResize whenever the canvas size changes).
Additional layout components are planned to be added in future PRs.
# Description
This does two things:
## Use double quotes for SDK constraints
Standardize the usage of single or double quotes to specify sdk
constraints across pubspecs
I see no reason this should not be kept consistent
I also see no reason to prefer one over the other, so I searched the
code base and there are 7 instances of single quote vs 32 of double
quotes, so I favored the later
## Update all SDK constraints to 2.18
Let me know if there are any issues with it, but I believe we should
keep this consistent across all packages.
Also there is a pubspec on root which imply all should be on 2.18
anyway.
## Checklist
- [x] I have followed the [Contributor Guide] when preparing my PR.
- [x] I have updated/added tests for ALL new/updated/fixed
functionality.
- [x] I have updated/added relevant documentation in `docs` and added
dartdoc comments with `///`.
- [x] I have updated/added relevant examples in `examples` or `docs`.
## Breaking Change?
- [ ] Yes, this PR is a breaking change.
- [x] No, this PR is not a breaking change.
<!-- Links -->
[Contributor Guide]:
https://github.com/flame-engine/flame/blob/main/CONTRIBUTING.md
[Conventional Commit]: https://conventionalcommits.org/
[CHANGELOG]:
https://github.com/flame-engine/flame/blob/main/CHANGELOG.md
Co-authored-by: Lukas Klingsbo <me@lukas.fyi>
This PR ensures that all component rebalancing operations are resolved from a single location, after the update stage but before the render stage (thus, components may get reordered during the update, and these changes will go into effect during the rendering step on the same game tick).
This also fixes the problem where the child changing the priorities of its parent would cause a ConcurrentModificationError.
A number of methods that were used to handle rebalancing are now marked as deprecated. From the user's perspective, the only API they should be using is the .priority setter.
As-is
As mentioned in #2321, the user needs to propagate double-tap events to the component tree using DoubleTapDetector & propagateToChildren until now.
To-be
Any components that are mixed into the DoubleTapCallbacks receive double-tap-related events.
Same as DragCallbacks, there is no need to add mixin to the game like HasDoubleTapCallbaks as before.
This creates a new component HardwareKeyboardDetector, which is a more advanced version of the KeyboardEvents mixin:
HardwareKeyboardDetector is a component instead of a mixin, which means it can be added/removed by the user at any point;
multiple such detectors can be attached to a game - for example, in a 2-player game one component may be paying attention to arrow keys, while another to WASD keys;
the new component uses Flutter's HardwareKeyboard interface, bypassing the need for a Focus widget;
the component keeps the ordered list of keys that are currently being pressed, which is helpful for games where this order is important;
there is the ability to temporarily pause the reception of key events using keyEventsPaused property.
The new property camera.visibleWorldRect gives the Aabb of the world region visible through the camera. This can be useful for culling the render pipeline, or similar purposes.
Before this PR, the return type of onLoad() was Future<void>?, after this PR the return type is FutureOr<void> -- both for classes Component and Game.
Reasons:
The use of FutureOr is more idiomatic in Dart, this class was specifically created in order to be used in situations like ours.
This makes learning Flame easier for beginners, since you no longer need to explain what asynchronous programming is from the start (and onLoad() is one of the first methods the user encounters in Flame).
The code can be cleaner in case when onLoad doesn't need to be async.
With new approach, the onLoad() method can be overridden as either
@override
Future<void> onLoad() async { ... }
or
@override
void onLoad() { ... }
Of course, it can also be overridden as
@override
FutureOr<void> onLoad() { ... }
but this is rare, only for components that are designed to be further subclassed, or for mixins.
The documentation was updated to show the new recommended usage.
This adds a proposal for a new API for flame, the ComponentNotifier.
This API offers the user change notifiers classes that are tied to FlameGame and its components so the user can be notified when a component is added, removed or updated.
This will enable users to:
Take the benefit of reactive programming inside the game
Have a simple way of watching certain states from the game, on Flutter Widgets
One important note here is that this proposal does not mean to replace integrations like flame_bloc, but rather provider an simple and out of the box solution, without any need of additional packages, since change notifiers are provided by flutter itself.
Opening this as draft for now to get feedback on the implementation, will write tests and docs once we have the final implementation.
The root level .gitignore file already works for all sub-repositories, so they are all actually unnecessary.
This PR leaves only the gitignore at the root of the repo, removing all others.
Adding a bridge library for integral_isolates adding support for components to run CPU intensive code with a function similar to Flutter's compute function, but with a long lived isolate. Lifecycle is handled by the game loop, where the isolate would live between onMount and onRemove.
This PR continues the work for enabling rich text support within Flame.
Here I add support for different text fragments having different TextStyles, and allow those styles to be inheritable within the text node tree.
This PR adds the SpriteFont class, which encapsulates reusable information about a sprite font. Text renderers / text formatters can be created based on this SpriteFont.
In addition:
GlyphInfo removed (was internal), and GlyphData deprecated -- instead, there is now a consolidated Glyph class;
Sprite font now supports extended Unicode characters and ligatures (when a combination of letters is represented as a single glyph)
This feature can also be used to define simple name substitutions. For example, you can declare that "[gp]" or "&gp;" would represent a gold coin icon;
Sprite font supports variable-width fonts;
Sprite font supports glyphs where the source rect is different from the logical rect;
Sprite font renderer can now control the color of the text rendered.
This PR adds an optional parameter to raycast API called maxDistance. Using this parameter users can control the limit within which raycast scans for hits.
This PR adds a new method called lookAt for PositionComponent. It is a convenience method which rotates the component to make it point towards/look at the given target position.
Additionally, this PR also adds a angleTo method which can be used to get the calculated angle for lookAt. It will be useful if someone want to smoothly rotate towards target using effects or manual lerping.
