Many a game will provide some sort of video settings where a window mode option is a common inclusion. I ran into problems, however, with [egui's](https://github.com/emilk/egui) `combo_box` that imposes a `PartialEq` necessity. Deriving the trait would fix this problem, and as this does not break any existing API it should be a non-controversial change.
`Color` can now be from different color spaces or representation:
- sRGB
- linear RGB
- HSL
This fixes#1193 by allowing the creation of const colors of all types, and writing it to the linear RGB color space for rendering.
I went with an enum after trying with two different types (`Color` and `LinearColor`) to be able to use the different variants in all place where a `Color` is expected.
I also added the HLS representation because:
- I like it
- it's useful for some case, see example `contributors`: I can just change the saturation and lightness while keeping the hue of the color
- I think adding another variant not using `red`, `green`, `blue` makes it clearer there are differences
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Fixes#1100
Implementors must make sure that `Reflect::any` and `Reflect::any_mut` both return the `self` reference passed in (both for logical correctness and downcast safety).
fixes#1161, fixes#1243
this adds two systems:
- first is keeping an hashmap of textures and their containing color materials, then listening to events on textures to select color materials that should be updated
- second is chained to send a modified event for all color materials that need updating
An alternative to StateStages that uses SystemSets. Also includes pop and push operations since this was originally developed for my personal project which needed them.
Error message noticed in #1475
When an asset type hasn't been added to the app but a load was attempted, the error message wasn't helpful:
```
thread 'IO Task Pool (0)' panicked at 'Failed to find AssetLifecycle for label Some("Mesh0/Primitive0"), which has an asset type 8ecbac0f-f545-4473-ad43-e1f4243af51e. Are you sure that is a registered asset type?', /.cargo/git/checkouts/bevy-f7ffde730c324c74/89a41bc/crates/bevy_asset/src/asset_server.rs:435:17
```
means that
```rust
.add_asset::<bevy::render::prelude::Mesh>()
```
needs to be added.
* type name was not given, only UUID, which may make it hard to identify type across bevy/plugins
* instruction were not helpful as the `register_asset_type` method is not public
new error message:
```
thread 'IO Task Pool (1)' panicked at 'Failed to find AssetLifecycle for label 'Some("Mesh0/Primitive0")', which has an asset type "bevy_render::mesh::mesh::Mesh" (UUID 8ecbac0f-f545-4473-ad43-e1f4243af51e). Are you sure this asset type has been added to your app builder?', /bevy/crates/bevy_asset/src/asset_server.rs:435:17
```
As mentioned in #1609.
I'm not sure if this is desirable, but on top of factoring the `set` and `set_untracked` methods I added a warning when the return value of `set` isn't used to mitigate similar issues.
I silenced it for the only occurence where it's currently done 68606934e3/crates/bevy_asset/src/asset_server.rs (L468)
This removes the `GltfError::UnsupportedMinFilter` error.
I don't think this error should have existed in the first place, because it prevents users from using assets that bevy could totally render (without mipmap support as of yet).
It's much better to load the asset properly and then render it (even if it looks a little ugly), than to refuse to load the asset at all, giving users a confusing error.
it's a followup of #1550
I think calling explicit methods/values instead of default makes the code easier to read: "what is `Quat::default()`" vs "Oh, it's `Quat::IDENTITY`"
`Transform::identity()` and `GlobalTransform::identity()` can also be consts and I replaced the calls to their `default()` impl with `identity()`
Fixes all warnings from `cargo doc --all`.
Those related to code blocks were introduced in #1612, but re-formatting using the experimental features in `rustfmt.toml` doesn't seem to reintroduce them.
These are largely targeted at beginners, as `Entity`, `Component` and `System` are the most obvious terms to search when first getting introduced to Bevy.
Idea being this would be easier to grasp for end-users. Problem with the logical defaults is this breaks current setups, because light will become 20 times less bright. But most folks won't have customized this resource or will not have used `..Default::default()` due to lack of other fields.
That override was added to support pre 1.45 Versions of Rust, but Bevy requires currently the latest stable rust release.
This means that the reason for the override doesn't apply anymore.
1. The instructions in the main README used to point users to the git main version. This has likely misdirected and confused many new users. Update to direct users to the latest release instead.
2. Rewrite the notice in the examples README to make it clearer and more concise, and to show the `latest` git branch.
See also: https://github.com/bevyengine/bevy-website/pull/109 for similar changes to the website and official book.
Removes `get_unchecked` and `get_unchecked_mut` from `Tables` and `Archetypes` collections in favor of safe Index implementations. This fixes a safety error in `Archetypes::get_id_or_insert()` (which previously relied on TableId being valid to be safe ... the alternative was to make that method unsafe too). It also cuts down on a lot of unsafe and makes the code easier to look at. I'm not sure what changed since the last benchmark, but these numbers are more favorable than my last tests of similar changes. I didn't include the Components collection as those severely killed perf last time I tried. But this does inspire me to try again (just in a separate pr)!
Note that the `simple_insert/bevy_unbatched` benchmark fluctuates a lot on both branches (this was also true for prior versions of bevy). It seems like the allocator has more variance for many small allocations. And `sparse_frag_iter/bevy` operates on such a small scale that 10% fluctuations are common.
Some benches do take a small hit here, but I personally think its worth it.
This also fixes a safety error in Query::for_each_mut, which needed to mutably borrow Query (aaahh!).
* Adds labels and orderings to systems that need them (uses the new many-to-many labels for InputSystem)
* Removes the Event, PreEvent, Scene, and Ui stages in favor of First, PreUpdate, and PostUpdate (there is more collapsing potential, such as the Asset stages and _maybe_ removing First, but those have more nuance so they should be handled separately)
* Ambiguity detection now prints component conflicts
* Removed broken change filters from flex calculation (which implicitly relied on the z-update system always modifying translation.z). This will require more work to make it behave as expected so i just removed it (and it was already doing this work every frame).
Should fix https://github.com/bevyengine/bevy/issues/1516.
I don't have any devices available to test this tbh but I feel like this was the only spot that could be causing a panic.
@ptircylinder since you posted this issue, could you please try to run the example on this branch and check if you get the same behavior while using your device? Thank you!
This is an effort to provide the correct `#[reflect_value(...)]` attributes where they are needed.
Supersedes #1533 and resolves#1528.
---
I am working under the following assumptions (thanks to @bjorn3 and @Davier for advice here):
- Any `enum` that derives `Reflect` and one or more of { `Serialize`, `Deserialize`, `PartialEq`, `Hash` } needs a `#[reflect_value(...)]` attribute containing the same subset of { `Serialize`, `Deserialize`, `PartialEq`, `Hash` } that is present on the derive.
- Same as above for `struct` and `#[reflect(...)]`, respectively.
- If a `struct` is used as a component, it should also have `#[reflect(Component)]`
- All reflected types should be registered in their plugins
I treated the following as components (added `#[reflect(Component)]` if necessary):
- `bevy_render`
- `struct RenderLayers`
- `bevy_transform`
- `struct GlobalTransform`
- `struct Parent`
- `struct Transform`
- `bevy_ui`
- `struct Style`
Not treated as components:
- `bevy_math`
- `struct Size<T>`
- `struct Rect<T>`
- Note: The updates for `Size<T>` and `Rect<T>` in `bevy::math::geometry` required using @Davier's suggestion to add `+ PartialEq` to the trait bound. I then registered the specific types used over in `bevy_ui` such as `Size<Val>`, etc. in `bevy_ui`'s plugin, since `bevy::math` does not contain a plugin.
- `bevy_render`
- `struct Color`
- `struct PipelineSpecialization`
- `struct ShaderSpecialization`
- `enum PrimitiveTopology`
- `enum IndexFormat`
Not Addressed:
- I am not searching for components in Bevy that are _not_ reflected. So if there are components that are not reflected that should be reflected, that will need to be figured out in another PR.
- I only added `#[reflect(...)]` or `#[reflect_value(...)]` entries for the set of four traits { `Serialize`, `Deserialize`, `PartialEq`, `Hash` } _if they were derived via `#[derive(...)]`_. I did not look for manual trait implementations of the same set of four, nor did I consider any traits outside the four. Are those other possibilities something that needs to be looked into?
* Systems can now have more than one label attached to them.
* System labels no longer have to be unique in the stage.
Code like this is now possible:
```rust
SystemStage::parallel()
.with_system(system_0.system().label("group one").label("first"))
.with_system(system_1.system().label("group one").after("first"))
.with_system(system_2.system().after("group one"))
```
I've opted to use only the system name in ambiguity reporting, which previously was only a fallback; this, obviously, is because labels aren't one-to-one with systems anymore. We could allow users to name systems to improve this; we'll then have to think about whether or not we want to allow using the name as a label (this would, effectively, introduce implicit labelling, not all implications of which are clear to me yet wrt many-to-many labels).
Dependency cycle errors are reported using the system names and only the labels that form the cycle, with each system-system "edge" in the cycle represented as one or several labels.
Slightly unrelated: `.before()` and `.after()` with a label not attached to any system no longer crashes, and logs a warning instead. This is necessary to, for example, allow plugins to specify execution order with systems of potentially missing other plugins.
This only affected 2 Examples:
* `generic_reflection`: For some reason, a `pub use` statement was used. This was removed, and alphabetically ordered.
* `wireframe`: This example used the `bevy_internal` crate directly. Changed to use `bevy` instead.
All other Example Imports are correct.
One potential subjective change is the `removel_detection` example.
Unlike all other Examples, it has its (first) explanatory comment before the Imports.
Adds `get_unique` and `get_unique_mut` to extend the query api and cover a common use case. Also establishes a second impl block where non-core APIs that don't access the internal fields of queries can live.
Bumps [github/super-linter](https://github.com/github/super-linter) from v3.15.1 to v3.15.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/github/super-linter/releases">github/super-linter's releases</a>.</em></p>
<blockquote>
<h2>Release v3.15.2</h2>
<h2>Changelog</h2>
<ul>
<li>Fix issue with grabbing history</li>
</ul>
<h2>Bugs</h2>
<p>we found a bad one...</p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="16f5c4067d"><code>16f5c40</code></a> Updating action.yml with new release version</li>
<li><a href="68c8bf9f11"><code>68c8bf9</code></a> fix, checkout DEFAULT_BRANCH for diff base (<a href="https://github.com/github/super-linter/issues/1308">#1308</a>)</li>
<li><a href="11720172cb"><code>1172017</code></a> Fix get file diff on pr event (<a href="https://github.com/github/super-linter/issues/1305">#1305</a>)</li>
<li><a href="5294082063"><code>5294082</code></a> Bump golangci/golangci-lint from v1.37.1 to v1.38.0 (<a href="https://github.com/github/super-linter/issues/1301">#1301</a>)</li>
<li><a href="4f51c7dd03"><code>4f51c7d</code></a> Bump cljkondo/clj-kondo from 2021.02.28-alpine to 2021.03.03-alpine (<a href="https://github.com/github/super-linter/issues/1300">#1300</a>)</li>
<li><a href="505a708ba3"><code>505a708</code></a> Bump snakemake from 6.0.0 to 6.0.2 in /dependencies (<a href="https://github.com/github/super-linter/issues/1302">#1302</a>)</li>
<li><a href="bbb3b6c4cd"><code>bbb3b6c</code></a> Bump markdownlint-cli from 0.26.0 to 0.27.1 in /dependencies (<a href="https://github.com/github/super-linter/issues/1293">#1293</a>)</li>
<li><a href="779c472cfa"><code>779c472</code></a> Bump @typescript-eslint/parser from 4.15.2 to 4.16.1 in /dependencies (<a href="https://github.com/github/super-linter/issues/1290">#1290</a>)</li>
<li><a href="a648a4e067"><code>a648a4e</code></a> Bump @typescript-eslint/eslint-plugin in /dependencies (<a href="https://github.com/github/super-linter/issues/1291">#1291</a>)</li>
<li><a href="46df94844c"><code>46df948</code></a> Add debug info for multi status api calls (<a href="https://github.com/github/super-linter/issues/1287">#1287</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/github/super-linter/compare/v3.15.1...16f5c4067d70b7e90445a32524a96d02f973ca4b">compare view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
This allows users to write systems that do not panic if a resource does not exist at runtime (such as if it has not been inserted yet).
This is a copy-paste of the impls for `Res` and `ResMut`, with an extra check to see if the resource exists.
There might be a cleaner way to do it than this check. I don't know.
This adds a `EventWriter<T>` `SystemParam` that is just a thin wrapper around `ResMut<Events<T>>`. This is primarily to have API symmetry between the reader and writer, and has the added benefit of easily improving the API later with no breaking changes.
Super simple and straight forward. I need this for the tilemap because if I need to update all chunk indices, then I can calculate it once and clone it. Of course, for now I'm just returning the Vec itself then wrapping it but would be nice if I didn't have to do that.
Since 89217171b4, some birds in example `contributors` where not colored.
Fix is to use `flip_x` of `Sprite` instead of setting `transform.scale.x` to `-1` as described in #1407.
It may be an unintended side effect, as now we can't easily display a colored sprite while changing it's scale from `1` to `-1`, we would have to change it's scale from `1` to `0`, then flip it, then change scale from `0` to `1`.
Silence those [annoying rustfmt config warnings](https://github.com/bevyengine/bevy/pull/1499/checks?check_run_id=1950282111#step:5:66) that happen because we have unstable rustfmt options in `rustfmt.toml`, but we run it in stable on CI. Thanks to @Ratysz for [calling it out](https://github.com/bevyengine/bevy/pull/1499#issuecomment-783190586). 😄
The final approach we settled on was to comment out the unstable options in `rustfmt.toml`. Those who are using `nightly` may uncomment the unstable options locally if they wish. Once the options stabilize, we can uncomment them again.
We also decided that instead of fixing the alias, we would remove the alias entirely so that we do not introduce a custom `.cargo/config.toml` that would conflict with users' custom version of the same file. This means that instead of using a `cargo ci` alias you should use `cargo run -p ci` or `cargo run --package ci` instead.
<details><summary>Original Approach (abandoned)</summary>
<p>
_We decided **not** to go this way..._
In my quest to find a portable way to filter out the warnings I switched the library used to execute commands from `xshell` to `duct` (as advised by the `xshell` project itself when you want to do less simple things). This still uses the "xtask" pattern of using a cargo command alias and a rust project for what would have usually been done with a bash script (on posix), just a different helper library is being used internally.
NOTE 1: Also, thanks to some sleuthing by @DJMcNab we were able to fix the broken cargo alias. The issue turned out to be that `.cargo/config.toml` was being ignored because of `.gitignore`.
NOTE 2: This is a [known breaking change](https://github.com/bevyengine/bevy/pull/1309#discussion_r564023753) for anyone working on bevy who has their own local `.cargo/config.toml`.
</p>
</details>
I've also added a clearer description of what bundles are used for, and explained that you can't query for bundles (a very common beginner confusion).
Co-authored-by: MinerSebas <scherthan_sebastian@web.de>
Co-authored-by: Renato Caldas <renato@calgera.com>
I was fiddling with creating a mesh importer today, and decided to write some more docs.
A lot of this is describing general renderer/GL stuff, so you'll probably find most of it self explanatory anyway, but perhaps it will be useful for someone.
