This PR adds two updates.
It updates the flame_forge2d to latest version i.e on pub.dev in examples and padracing projects.
Adds a bouncing ball example in the collision detection examples demonstrating a simple example of collision and bouncing of a ball from the walls around it.
Updated docs about priority as we chat at #1457 (comment). I reused the same sentence as @st-pasha as it was easy to understand and I am not a native speaker.
This PR introduces RecycledQueue class, which is similar to a regular FIFO Queue except that it supports recycling of objects instead of having to create/delete them all the time.
This class will be used to build more efficient component lifecycle queues.
A lot of the time it is useful to be able to ignore certain hitboxes, if you are for example casting rays from within the hitbox of one of your components. This PR adds this functionality to raycast, raycastAll and raytrace.
Changes:
Container for ColoredBox
Container for SizedBox.shrink
Rationale:
Avoid unnecessary checks.
Be more implicit on the desired effect by using more specific widgets.
Remove unnecessary checks made by Flutter by not following the above point.
SizedBox can be const and won't even create a new instance during runtime.
This PR implements raytracing and raycasting for the built-in hitboxes.
If you pass in your own collision detection system to the HasCollisionDetection mixin you have to change the signature of that to: CollisionDetection<ShapeHitbox>instead of CollisionDetection<Hitbox>.
Class _ActiveOverlays renamed into OverlayManager and move into its own file. The class is still marked as internal.
In GameWidget.controlled constructor the properties initialActiveOverlays and mouseCursor were missing, now added.
Created class OverlayRoute for encapsulating an overlay-handling logic within the RouterComponent.
New overlay builders can now be added to the game at runtime.
The OverlaysManager._activeOverlays property is now a list instead of a set, so that the overlays would be displayed in the specific order requested by the user.
This PR adds the decorator property to PositionComponent, and makes decorators chain-able. That is, decorators function as linked lists, and a new decorator can be appended to the end of such list, and later removed.
The PositionComponent starts with the default decorator: the Transform2DDecorator, which encapsulates the functionality which previously resided within the PositionComponent.renderTree. This allows to:
apply/remove additional visual effects via .decorator.addLast()/.removeLast();
replace the Transform2DDecorator with another one -- for example supporting skew, or isometric coordinates, or 3d rotations.
HasDecorator mixin can no longer be applied to a PositionComponent because it already has the decorator "built in".
The decorators Shadow3DDecorator and Rotate3DDecorator, when added to the PositionComponent, will now apply after the coordinate transform of the PositionComponent, as desired. This means that, for example, the shadow's base and rotation pivot point can be specified using the local coordinates of the component.
This PR introduces class ValueRoute<T> that can be used together with the RouterComponent in order to create routes that return a value. The most common example of such routes are dialog boxes.
This PR introduces the notions of structured text, and text styles, to support rendering of rich text bodies.
Specifically, we recognize that sometimes in games one needs to render pieces of text that are larger than a single word or even a single paragraph. These pieces may include: books, quest descriptions, mission objectives, tutorials, in-game help system, dialogues, etc. Rendering such a piece of text is non-trivial, however. In order to tackle this problem, I break into the following parts:
Text structure, represented as a tree of Nodes. The nodes describe the logical structure of the text, for example the document may contain a header, and then several paragraphs, and a list, where the list contains some list items, some of which having possibly several paragraphs, etc. This structure is similar to how in HTML the text is marked up with HTML tags.
Text styles are struct-like classes that contain properties describing how the text is to be styled: font size, font renderer, borders, backgrounds, margins, padding, etc. This representation is also tree-like, so that for example text inside paragraphs can have different style than text within headers, and paragraphs within lists can have different margins. A text style is similar to a stylesheet in HTML.
Text elements are the result of applying the document style to a document node: they are the "prepared" and laid out pieces, ready to be rendered. Elements are a bit like mini-components, or perhaps text "particles" in a particle system.
There was an unnecessary offset applied to the canvas while processing image layers. It was causing the image to render outside the view. This PR removes that offset.
add an event listener to the docs site to listen everytime on load, then
expand the first expandable section ("flame") if the current page is
home page.
add an event listener to the docs site to listen everytime on load, then
expand the first expandable section ("flame") if the current page is
home page.
This PR expands the functionality of RenderableTileMap to include support for more than just simple TileLayer layers. Adding support for:
ImageLayer rendering (note that tiled.dart was loading non-tile layers in the incorrect order until 0.8.4)
layer parallaxX / parallaxY
layer opacity
map backgroundColor
tiled dependency
This PR relies on changes and bug fixes in tiled.dart 0.8.4
TextElement is a class that caches the layout of a particular string of text. When drawing any text on the screen, it is important to convert it to text-elements and then cache those, especially if there are many text fragments being displayed simultaneously.
This PR changes the TextComponent class so that it computes and stores a TextElement instead of using TextRenderer.render() directly. This improves the performance of a game, as it avoids costly recalculations of the text layout on every game tick.
The new class allows applying visual filters to canvas drawing operations. It is conceptually similar to the LayerProcessor class, except that it applies directly to a canvas instead of a Picture.
This functionality was extracted from PR #1755.
NB: the guitar image was taken from here, which is a public domain image, i.e. licensed under CC0 1.0.
