TEST Check for patches in ci test #19
Closed
Conversation
This file contains 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
# Objective - no-longer-extant type `WinitConfig` referenced in comments - `mouse_button_input` refers to `KeyCode` input - "spacebar" flagged as a typo by RustRover IDE ## Solution - replace `WinitConfig` with `WinitSettings` in comments - rename `mouse_button_input` to just `button_input` - change "spacebar" to "space bar"
# Objective `System<f32>` currently does not implement `Eq` even though it should ## Solution Manually implement `Eq` like other traits are manually implemented
# Objective Fixes bevyengine#12064 ## Solution Prior to bevyengine#11326, the "global physical" translation of text was rounded. After bevyengine#11326, only the "offset" is being rounded. This moves things around so that the "global translation" is converted to physical pixels, rounded, and then converted back to logical pixels, which is what I believe was happening before / what the comments above describe. ## Discussion This seems to work and fix an obvious mistake in some code, but I don't fully grok the ui / text pipelines / math here. ## Before / After and test example <details> <summary>Expand Code</summary> ```rust use std::f32::consts::FRAC_PI_2; use bevy::prelude::*; use bevy_internal::window::WindowResolution; const FONT_SIZE: f32 = 25.0; const PADDING: f32 = 5.0; fn main() { App::new() .add_plugins( DefaultPlugins.set(WindowPlugin { primary_window: Some(Window { resolution: WindowResolution::default().with_scale_factor_override(1.0), ..default() }), ..default() }), //.set(ImagePlugin::default_nearest()), ) .add_systems(Startup, setup) .run(); } fn setup(mut commands: Commands, asset_server: Res<AssetServer>) { commands.spawn(Camera2dBundle::default()); let font = asset_server.load("fonts/FiraSans-Bold.ttf"); for x in [20.5, 140.0] { for i in 1..10 { text( &mut commands, font.clone(), x, (FONT_SIZE + PADDING) * i as f32, i, Quat::default(), 1.0, ); } } for x in [450.5, 700.0] { for i in 1..10 { text( &mut commands, font.clone(), x, ((FONT_SIZE * 2.0) + PADDING) * i as f32, i, Quat::default(), 2.0, ); } } for y in [400.0, 600.0] { for i in 1..10 { text( &mut commands, font.clone(), (FONT_SIZE + PADDING) * i as f32, y, i, Quat::from_rotation_z(FRAC_PI_2), 1.0, ); } } } fn text( commands: &mut Commands, font: Handle<Font>, x: f32, y: f32, i: usize, rot: Quat, scale: f32, ) { let text = (65..(65 + i)).map(|a| a as u8 as char).collect::<String>(); commands.spawn(TextBundle { style: Style { position_type: PositionType::Absolute, left: Val::Px(x), top: Val::Px(y), ..default() }, text: Text::from_section( text, TextStyle { font, font_size: FONT_SIZE, ..default() }, ), transform: Transform::from_rotation(rot).with_scale(Vec2::splat(scale).extend(1.)), ..default() }); } ``` </details> Open both images in new tabs and swap back and forth. Pay attention to the "A" and "ABCD" lines. <details> <summary>Before</summary> <img width="640" alt="main3" src="https://github.com/bevyengine/bevy/assets/200550/248d7a55-d06d-433f-80da-1914803c3551"> </details> <details> <summary>After</summary> <img width="640" alt="pr3" src="https://github.com/bevyengine/bevy/assets/200550/26a9d292-07ae-4af3-b035-e187b2529ace"> </details> --------- Co-authored-by: François Mockers <mockersf@gmail.com>
…evyengine#12369) # Objective Beginning of refactoring of light.rs in bevy_pbr, as per issue bevyengine#12349 Create and move light.rs to its own directory, and extract AmbientLight struct. ## Solution - moved light.rs to light/mod.rs - extracted AmbientLight struct to light/ambient_light.rs
# Objective Scaling `z` by anything but `1.0` in 2d can only lead to bugs and confusion. See bevyengine#4149. ## Solution Use a `Vec2` for the paddle size const, and add a scale of `1.0` later. This matches the way `BRICK_SIZE` is defined.
# Objective - Adds 3d grids, suggestion of bevyengine#9400 ## Solution - Added 3d grids (grids spanning all three dimensions, not flat grids) to bevy_gizmos --- ## Changelog - `gizmos.grid(...)` and `gizmos.grid_2d(...)` now return a `GridBuilder2d`. - Added `gizmos.grid_3d(...)` which returns a `GridBuilder3d`. - The difference between them is basically only that `GridBuilder3d` exposes some methods for configuring the z axis while the 2d version doesn't. - Allowed for drawing the outer edges along a specific axis by calling `.outer_edges_x()`, etc. on the builder. ## Additional information Please note that I have not added the 3d grid to any example as not to clutter them. Here is an image of what the 3d grid looks like: <img width="1440" alt="Screenshot 2024-03-12 at 02 19 55" src="https://github.com/bevyengine/bevy/assets/62256001/4cd3b7de-cf2c-4f05-8a79-920a4dd804b8"> --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective `Query::is_empty` does not mention the potential performance footgun of using it with non-archetypal filters. ## Solution Document it.
# Objective - Addresses bevyengine#12462 - When we serialize an enum, deserialize it, then reserialize it, the correct variant should be selected. ## Solution - Change `dynamic_enum.set_variant` to `dynamic_enum.set_variant_with_index` in `EnumVisitor`
# Objective - Closes bevyengine#11793 - Introduces a general API for aligning local coordinates of Transforms with given vectors. ## Solution - We introduce `Transform::align`, which allows a rotation to be specified by four pieces of alignment data, as explained by the documentation: ````rust /// Rotates this [`Transform`] so that the `main_axis` vector, reinterpreted in local coordinates, points /// in the given `main_direction`, while `secondary_axis` points towards `secondary_direction`. /// /// For example, if a spaceship model has its nose pointing in the X-direction in its own local coordinates /// and its dorsal fin pointing in the Y-direction, then `align(Vec3::X, v, Vec3::Y, w)` will make the spaceship's /// nose point in the direction of `v`, while the dorsal fin does its best to point in the direction `w`. /// /// More precisely, the [`Transform::rotation`] produced will be such that: /// * applying it to `main_axis` results in `main_direction` /// * applying it to `secondary_axis` produces a vector that lies in the half-plane generated by `main_direction` and /// `secondary_direction` (with positive contribution by `secondary_direction`) /// /// [`Transform::look_to`] is recovered, for instance, when `main_axis` is `Vec3::NEG_Z` (the [`Transform::forward`] /// direction in the default orientation) and `secondary_axis` is `Vec3::Y` (the [`Transform::up`] direction in the default /// orientation). (Failure cases may differ somewhat.) /// /// In some cases a rotation cannot be constructed. Another axis will be picked in those cases: /// * if `main_axis` or `main_direction` is zero, `Vec3::X` takes its place /// * if `secondary_axis` or `secondary_direction` is zero, `Vec3::Y` takes its place /// * if `main_axis` is parallel with `secondary_axis` or `main_direction` is parallel with `secondary_direction`, /// a rotation is constructed which takes `main_axis` to `main_direction` along a great circle, ignoring the secondary /// counterparts /// /// Example /// ``` /// # use bevy_math::{Vec3, Quat}; /// # use bevy_transform::components::Transform; /// let mut t1 = Transform::IDENTITY; /// let mut t2 = Transform::IDENTITY; /// t1.align(Vec3::ZERO, Vec3::Z, Vec3::ZERO, Vec3::X); /// t2.align(Vec3::X, Vec3::Z, Vec3::Y, Vec3::X); /// assert_eq!(t1.rotation, t2.rotation); /// /// t1.align(Vec3::X, Vec3::Z, Vec3::X, Vec3::Y); /// assert_eq!(t1.rotation, Quat::from_rotation_arc(Vec3::X, Vec3::Z)); /// ``` pub fn align( &mut self, main_axis: Vec3, main_direction: Vec3, secondary_axis: Vec3, secondary_direction: Vec3, ) { //... } ```` - We introduce `Transform::aligned_by`, the returning-Self version of `align`: ````rust pub fn aligned_by( mut self, main_axis: Vec3, main_direction: Vec3, secondary_axis: Vec3, secondary_direction: Vec3, ) -> Self { //... } ```` - We introduce an example (examples/transforms/align.rs) that shows the usage of this API. It is likely to be mathier than most other `Transform` APIs, so when run, the example demonstrates what the API does in space: <img width="1440" alt="Screenshot 2024-03-12 at 11 01 19 AM" src="https://github.com/bevyengine/bevy/assets/2975848/884b3cc3-cbd9-48ae-8f8c-49a677c59dfe"> --- ## Changelog - Added methods `align`, `aligned_by` to `Transform`. - Added transforms/align.rs to examples. --- ## Discussion ### On the form of `align` The original issue linked above suggests an API similar to that of the existing `Transform::look_to` method: ````rust pub fn align_to(&mut self, direction: Vec3, up: Vec3) { //... } ```` Not allowing an input axis of some sort that is to be aligned with `direction` would not really solve the problem in the issue, since the user could easily be in a scenario where they have to compose with another rotation on their own (undesirable). This leads to something like: ````rust pub fn align_to(&mut self, axis: Vec3, direction: Vec3, up: Vec3) { //... } ```` However, this still has two problems: - If the vector that the user wants to align is parallel to the Y-axis, then the API basically does not work (we cannot fully specify a rotation) - More generally, it does not give the user the freedom to specify which direction is to be treated as the local "up" direction, so it fails as a general alignment API Specifying both leads us to the present situation, with two local axis inputs (`main_axis` and `secondary_axis`) and two target directions (`main_direction` and `secondary_direction`). This might seem a little cumbersome for general use, but for the time being I stand by the decision not to expand further without prompting from users. I'll expand on this below. ### Additional APIs? Presently, this PR introduces only `align` and `aligned_by`. Other potentially useful bundles of API surface arrange into a few different categories: 1. Inferring direction from position, a la `Transform::look_at`, which might look something like this: ````rust pub fn align_at(&mut self, axis: Vec3, target: Vec3, up: Vec3) { self.align(axis, target - self.translation, Vec3::Y, up); } ```` (This is simple but still runs into issues when the user wants to point the local Y-axis somewhere.) 2. Filling in some data for the user for common use-cases; e.g.: ````rust pub fn align_x(&mut self, direction: Vec3, up: Vec3) { self.align(Vec3::X, direction, Vec3::Y, up); } ```` (Here, use of the `up` vector doesn't lose any generality, but it might be less convenient to specify than something else. This does naturally leave open the question of what `align_y` would look like if we provided it.) Morally speaking, I do think that the `up` business is more pertinent when the intention is to work with cameras, which the `look_at` and `look_to` APIs seem to cover pretty well. If that's the case, then I'm not sure what the ideal shape for these API functions would be, since it seems like a lot of input would have to be baked into the function definitions. For some cases, this might not be the end of the world: ````rust pub fn align_x_z(&mut self, direction: Vec3, weak_direction: Vec3) { self.align(Vec3::X, direction, Vec3::Z, weak_direction); } ```` (However, this is not symmetrical in x and z, so you'd still need six API functions just to support the standard positive coordinate axes, and if you support negative axes then things really start to balloon.) The reasons that these are not actually produced in this PR are as follows: 1. Without prompting from actual users in the wild, it is unknown to me whether these additional APIs would actually see a lot of use. Extending these to our users in the future would be trivial if we see there is a demand for something specific from the above-mentioned categories. 2. As discussed above, there are so many permutations of these that could be provided that trying to do so looks like it risks unduly ballooning the API surface for this feature. 3. Finally, and most importantly, creating these helper functions in user-space is trivial, since they all just involve specializing `align` to particular inputs; e.g.: ````rust fn align_ship(ship_transform: &mut Transform, nose_direction: Vec3, dorsal_direction: Vec3) { ship_transform.align(Ship::NOSE, nose_direction, Ship::DORSAL, dorsal_direction); } ```` With that in mind, I would prefer instead to focus on making the documentation and examples for a thin API as clear as possible, so that users can get a grip on the tool and specialize it for their own needs when they feel the desire to do so. ### `Dir3`? As in the case of `Transform::look_to` and `Transform::look_at`, the inputs to this function are, morally speaking, *directions* rather than vectors (actually, if we're being pedantic, the input is *really really* a pair of orthonormal frames), so it's worth asking whether we should really be using `Dir3` as inputs instead of `Vec3`. I opted for `Vec3` for the following reasons: 1. Specifying a `Dir3` in user-space is just more annoying than providing a `Vec3`. Even in the most basic cases (e.g. providing a vector literal), you still have to do error handling or call an unsafe unwrap in your function invocations. 2. The existing API mentioned above uses `Vec3`, so we are just adhering to the same thing. Of course, the use of `Vec3` has its own downsides; it can be argued that the replacement of zero-vectors with fixed ones (which we do in `Transform::align` as well as `Transform::look_to`) more-or-less amounts to failing silently. ### Future steps The question of additional APIs was addressed above. For me, the main thing here to handle more immediately is actually just upstreaming this API (or something similar and slightly mathier) to `glam::Quat`. The reason that this would be desirable for users is that this API currently only works with `Transform`s even though all it's actually doing is specifying a rotation. Upstreaming to `glam::Quat`, properly done, could buy a lot basically for free, since a number of `Transform` methods take a rotation as an input. Using these together would require a little bit of mathematical savvy, but it opens up some good things (e.g. `Transform::rotate_around`).
…ty (bevyengine#12469) # Objective Fixes bevyengine#12139 ## Solution - Derive `Debug` impl for `Entity` - Add impl `Display` for `Entity` - Add `entity_display` test to check the output contains all required info I decided to go with `0v0|1234` format as opposed to the `0v0[1234]` which was initially discussed in the issue. My rationale for this is that `[1234]` may be confused for index values, which may be common in logs, and so searching for entities by text would become harder. I figured `|1234` would help the entity IDs stand out more. Additionally, I'm a little concerned that this change is gonna break existing logging for projects because `Debug` is now going to be a multi-line output. But maybe this is ok. We could implement `Debug` to be a single-line output, but then I don't see why it would be different from `Display` at all. @alice-i-cecile Let me know if we'd like to make any changes based on these points.
# Objective
- Improve the code quality of the breakout example
- As a newcomer to `bevy` I was pointed to the breakout example after
the "Getting Started" tutorial
- I'm making this PR because it had a few wrong comments + some
inconsistency in used patterns
## Solution
- Remove references to `wall` in all the collision code as it also
handles bricks and the paddle
- Use the newtype pattern with `bevy::prelude::Deref` for resources
- It was already used for `Velocity` before this PR
- `Scoreboard` is a resource only containing `score`, so it's simpler as
a newtype `Score` resource
- `CollisionSound` is already a newtype, so might as well unify the
access pattern for it
- Added docstrings for `WallLocation::position` and `WallLocation::size`
to explain what they represent
# Objective - in example `axes`, the axes are sometime one frame late to follow their mesh ## Solution - System `move_cubes` modify the transforms, and `draw_axes` query them for the axes - if their order is not specified, it will be random and sometimes axes are drawn before transforms are updated - order systems
bevyengine#12482) # Objective Fixes bevyengine#12480 by removing the explicit mention of equally sized triangles from the doc for icospheres Co-authored-by: Emi <emanuel.boehm@gmail.com>
# Objective Add reflect for `std::any::TypeId`. I couldn't add ReflectSerialize/ReflectDeserialize for it, it was giving me an error. I don't really understand why, since it works for `std::path::PathBuf`. Co-authored-by: Charles Bournhonesque <cbournhonesque@snapchat.com>
…evyengine#12487) # Objective Originally proposed as part of bevyengine#8973. Adds `with_` methods for each side of `UiRect` ## Solution Add `with_left`, `with_right`, `with_top`, `with_bottom` to `UiRect`.
# Objective
The `example-showcase` command is failing to run.
```
cargo run --release -p example-showcase -- run --screenshot --in-ci
Updating crates.io index
Compiling example-showcase v0.14.0-dev (/Users/robparrett/src/bevy/tools/example-showcase)
Finished release [optimized] target(s) in 2.59s
Running `target/release/example-showcase run --screenshot --in-ci`
$ git apply --ignore-whitespace tools/example-showcase/remove-desktop-app-mode.patch
error: patch failed: crates/bevy_winit/src/winit_config.rs:29
error: crates/bevy_winit/src/winit_config.rs: patch does not apply
thread 'main' panicked at tools/example-showcase/src/main.rs:203:18:
called `Result::unwrap()` on an `Err` value: command exited with non-zero code `git apply --ignore-whitespace tools/example-showcase/remove-desktop-app-mode.patch`: 1
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
## Solution
Update `remove-desktop-app-mode.patch`.
# Objective - in bevyengine#12369, patched file changed location, so patch is failing ## Solution - fix patch
# Objective assets that don't load before they get removed are retried forever, causing buffer churn and slowdown. ## Solution stop trying to prepare dead assets.
…2435) Adoption of bevyengine#10617, resolved conflicts with main --------- Co-authored-by: Stepan Koltsov <stepan.koltsov@gmail.com>
# Objective - For some reason, we don't reflect the Default trait in colorspaces ## Solution - Reflect it. ---
…#12484) # Objective Give easy methods for uniform point sampling in a variety of primitive shapes (particularly useful for circles and spheres) because in a lot of cases its quite easy to get wrong (non-uniform). ## Solution Added the `ShapeSample` trait to `bevy_math` and implemented it for `Circle`, `Sphere`, `Rectangle`, `Cuboid`, `Cylinder`, `Capsule2d` and `Capsule3d`. There are a few other shapes it would be reasonable to implement for like `Triangle`, `Ellipse` and `Torus` but I'm not immediately sure how these would be implemented (other than rejection which could be the best method, and could be more performant than some of the solutions in this pr I'm not sure). This exposes the `sample_volume` and `sample_surface` methods to get both a random point from its interior or its surface. EDIT: Renamed `sample_volume` to `sample_interior` and `sample_surface` to `sample_boundary` This brings in `rand` as a default optional dependency (without default features), and the methods take `&mut impl Rng` which allows them to use any random source implementing `RngCore`. --- ## Changelog ### Added Added the methods `sample_interior` and `sample_boundary` to a variety of primitive shapes providing easy uniform point sampling.
# Objective Fixes typo by bevyengine#11341. Functionally doesn't change anything other than naming consistency and stop IDE's from screaming at you.
# Objective
- Even if we have `Laba` and `Oklcha` colorspaces using lightness as the
L field name, `Oklaba` doesn't do the same
- The shorthand function for creating a new color should be named
`Oklaba::lab`, but is named `lch`
## Solution
- Rename field l in `Oklaba` to lightness
- Rename `Oklaba::lch` to `Oklaba::lab`
---
## Changelog
### Changed
- Changed name in l field in `Oklaba` to lightness
- Changed method name `Oklaba::lch` to `Oklaba::lab`
## Migration Guide
If you were creating a Oklaba instance directly, instead of using L, you
should use lightness
```rust
// Before
let oklaba = Oklaba { l: 1., ..Default::default() };
// Now
let oklaba = Oklaba { lightness: 1., ..Default::default() };
```
if you were using the function `Oklaba::lch`, now the method is named
`Oklaba::lab`
# Objective Make `Transform` APIs more ergonomic by allowing users to pass `Dir3` as an argument where a direction is needed. Fixes bevyengine#12481. ## Solution Accept `impl TryInto<Dir3>` instead of `Vec3` for direction/axis arguments in `Transform` APIs --- ## Changelog The following `Transform` methods now accept an `impl TryInto<Dir3>` argument where they previously accepted directions as `Vec3`: * `Transform::{look_to,looking_to}` * `Transform::{look_at,looking_at}` * `Transform::{align,aligned_by}` ## Migration Guide This is not a breaking change since the arguments were previously `Vec3` which already implements `TryInto<Dir3>`, and behavior is unchanged. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: IQuick 143 <IQuick143cz@gmail.com>
# Objective - Make example align deterministic so that it's easier to check for regression ## Solution - Use a seeded random
…#12515) # Objective - Make example alien_cake_addict deterministic so that it's easier to check for regression ## Solution - Use a seeded random --------- Co-authored-by: Rob Parrett <robparrett@gmail.com>
# Objective Improve code quality involving fixedbitset. ## Solution Update to fixedbitset 0.5. Use the new `grow_and_insert` function instead of `grow` and `insert` functions separately. This should also speed up most of the set operations involving fixedbitset. They should be ~2x faster, but testing this against the stress tests seems to show little to no difference. The multithreaded executor doesn't seem to be all that much faster in many_cubes and many_foxes. These use cases are likely dominated by other operations or the bitsets aren't big enough to make them the bottleneck. This introduces a duplicate dependency due to petgraph and wgpu, but the former may take some time to update. ## Changelog Removed: `Access::grow` ## Migration Guide `Access::grow` has been removed. It's no longer needed. Remove all references to it.
# Objective `QueryState::archetype_component_access` is only really ever used to extend `SystemMeta`'s. It can be removed to save some memory for every `Query` in an app. ## Solution * Remove it. * Have `new_archetype` pass in a `&mut Access<ArchetypeComponentId>` instead and pull it from `SystemMeta` directly. * Split `QueryState::new` from `QueryState::new_with_access` and a common `QueryState::new_uninitialized`. * Split `new_archetype` into an internal and public version. Call the internal version in `update_archetypes`. This should make it faster to construct new QueryStates, and by proxy lenses and joins as well. `matched_tables` also similarly is only used to deduplicate inserting into `matched_table_ids`. If we can find another efficient way to do so, it might also be worth removing. The [generated assembly](james7132/bevy_asm_tests@main...remove-query-state-archetype-component-access#diff-496530101f0b16e495b7e9b77c0e906ae3068c8adb69ed36c92d5a1be5a9efbe) reflects this well, with all of the access related updates in `QueryState` being removed. --- ## Changelog Removed: `QueryState::archetype_component_access`. Changed: `QueryState::new_archetype` now takes a `&mut Access<ArchetypeComponentId>` argument, which will be updated with the new accesses. Changed: `QueryState::update_archetype_component_access` now takes a `&mut Access<ArchetypeComponentId>` argument, which will be updated with the new accesses. ## Migration Guide TODO
# Objective - Fixes bevyengine#12441 - check that patches are still working ## Solution - Apply all patches then build Bevy
# Objective the example `global_vs_local_translation` was removed in 3600c5a but this part of the documentation links to it ## Solution yeet it
…bevyengine#12419) # Objective Provide component access to `&'w T`, `Ref<'w, T>`, `Mut<'w, T>`, `Ptr<'w>` and `MutUntyped<'w>` from `EntityMut<'w>`/`EntityWorldMut<'w>` with the world `'w` lifetime instead of `'_`. Fixes bevyengine#12417 ## Solution Add `into_` prefixed methods for `EntityMut<'w>`/`EntityWorldMut<'w>` that consume `self` and returns component access with the world `'w` lifetime unlike the `get_` prefixed methods that takes `&'a self` and returns component access with `'a` lifetime. Methods implemented: - EntityMut::into_borrow - EntityMut::into_ref - EntityMut::into_mut - EntityMut::into_borrow_by_id - EntityMut::into_mut_by_id - EntityWorldMut::into_borrow - EntityWorldMut::into_ref - EntityWorldMut::into_mut - EntityWorldMut::into_borrow_by_id - EntityWorldMut::into_mut_by_id
# Objective I wanted to have reflection for BinaryHeap for a personal project. I'm running into some issues: - I wanted to represent BinaryHeap as a reflect::List type since it's essentially a wrapper around a Vec, however there's no public way to access the underlying Vec, which makes it hard to implement the reflect::List methods. I have omitted the reflect::List methods for now.. I'm not sure if that's a blocker? - what would be the alternatives? Simply not implement `reflect::List`? It is possible to implement `FromReflect` without it. Would the type be `Struct` then? --------- Co-authored-by: Charles Bournhonesque <cbournhonesque@snapchat.com>
# Objective - working with UI components in Bevy, I found myself wanting some of these common traits, like `PartialEq` for comparing simple types ## Solution - I added only (hopefully) uncontroversial `derive`s for some common UI types Note that many types, unfortunately, can't have `PartialEq` `derive`d for them, because they contain `f32`s and / or `Vec`s.
# Objective Fixes bevyengine#12549. WorldCell's support of everything a World can do is incomplete, and represents an alternative, potentially confusing, and less performant way of pulling multiple fetches from a `World`. The typical approach is to use `SystemState` for a runtime cached and safe way, or `UnsafeWorldCell` if the use of `unsafe` is tolerable. ## Solution Remove it! --- ## Changelog Removed: `WorldCell` Removed: `World::cell` ## Migration Guide `WorldCell` has been removed. If you were using it to fetch multiple distinct values from a `&mut World`, use `SystemState` by calling `SystemState::get` instead. Alternatively, if `SystemState` cannot be used, `UnsafeWorldCell` can instead be used in unsafe contexts.
Updates the requirements on [base64](https://github.com/marshallpierce/rust-base64) to permit the latest version. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/marshallpierce/rust-base64/blob/master/RELEASE-NOTES.md">base64's changelog</a>.</em></p> <blockquote> <h1>0.22.0</h1> <ul> <li><code>DecodeSliceError::OutputSliceTooSmall</code> is now conservative rather than precise. That is, the error will only occur if the decoded output <em>cannot</em> fit, meaning that <code>Engine::decode_slice</code> can now be used with exactly-sized output slices. As part of this, <code>Engine::internal_decode</code> now returns <code>DecodeSliceError</code> instead of <code>DecodeError</code>, but that is not expected to affect any external callers.</li> <li><code>DecodeError::InvalidLength</code> now refers specifically to the <em>number of valid symbols</em> being invalid (i.e. <code>len % 4 == 1</code>), rather than just the number of input bytes. This avoids confusing scenarios when based on interpretation you could make a case for either <code>InvalidLength</code> or <code>InvalidByte</code> being appropriate.</li> <li>Decoding is somewhat faster (5-10%)</li> </ul> <h1>0.21.7</h1> <ul> <li>Support getting an alphabet's contents as a str via <code>Alphabet::as_str()</code></li> </ul> <h1>0.21.6</h1> <ul> <li>Improved introductory documentation and example</li> </ul> <h1>0.21.5</h1> <ul> <li>Add <code>Debug</code> and <code>Clone</code> impls for the general purpose Engine</li> </ul> <h1>0.21.4</h1> <ul> <li>Make <code>encoded_len</code> <code>const</code>, allowing the creation of arrays sized to encode compile-time-known data lengths</li> </ul> <h1>0.21.3</h1> <ul> <li>Implement <code>source</code> instead of <code>cause</code> on Error types</li> <li>Roll back MSRV to 1.48.0 so Debian can continue to live in a time warp</li> <li>Slightly faster chunked encoding for short inputs</li> <li>Decrease binary size</li> </ul> <h1>0.21.2</h1> <ul> <li>Rollback MSRV to 1.57.0 -- only dev dependencies need 1.60, not the main code</li> </ul> <h1>0.21.1</h1> <ul> <li>Remove the possibility of panicking during decoded length calculations</li> <li><code>DecoderReader</code> no longer sometimes erroneously ignores padding <a href="https://github.com/marshallpierce/rust-base64/issues/226">#226</a></li> </ul> <h2>Breaking changes</h2> <ul> <li><code>Engine.internal_decode</code> return type changed</li> <li>Update MSRV to 1.60.0</li> </ul> <h1>0.21.0</h1> <h2>Migration</h2> <h3>Functions</h3> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/marshallpierce/rust-base64/commit/5d70ba7576f9aafcbf02bd8acfcb9973411fb95f"><code>5d70ba7</code></a> Merge pull request <a href="https://github.com/marshallpierce/rust-base64/issues/269">#269</a> from marshallpierce/mp/decode-precisely</li> <li><a href="https://github.com/marshallpierce/rust-base64/commit/efb6c006c75ddbe60c084c2e3e0e084cd18b0122"><code>efb6c00</code></a> Release notes</li> <li><a href="https://github.com/marshallpierce/rust-base64/commit/2b91084a31ad11624acd81e06455ba0cbd21d4a8"><code>2b91084</code></a> Add some tests to boost coverage</li> <li><a href="https://github.com/marshallpierce/rust-base64/commit/9e9c7abe65fed78c35a1e94e11446d66ff118c25"><code>9e9c7ab</code></a> Engine::internal_decode now returns DecodeSliceError</li> <li><a href="https://github.com/marshallpierce/rust-base64/commit/a8a60f43c56597259558261353b5bf7e953eed36"><code>a8a60f4</code></a> Decode main loop improvements</li> <li><a href="https://github.com/marshallpierce/rust-base64/commit/a25be0667c63460827cfadd71d1630acb442bb09"><code>a25be06</code></a> Simplify leftover output writes</li> <li><a href="https://github.com/marshallpierce/rust-base64/commit/9979cc33bb964b4ee36898773a01f546d2c6487a"><code>9979cc3</code></a> Keep morsels as separate bytes</li> <li><a href="https://github.com/marshallpierce/rust-base64/commit/37670c5ec224eec3af9778fb371c5529dfab52af"><code>37670c5</code></a> Bump dev toolchain version (<a href="https://github.com/marshallpierce/rust-base64/issues/268">#268</a>)</li> <li><a href="https://github.com/marshallpierce/rust-base64/commit/9652c787730e58515ce7b44fcafd2430ab424628"><code>9652c78</code></a> v0.21.7</li> <li><a href="https://github.com/marshallpierce/rust-base64/commit/08deccf7031b9c769a556cd9ebb0bc9cac988272"><code>08deccf</code></a> provide as_str() method to return the alphabet characters (<a href="https://github.com/marshallpierce/rust-base64/issues/264">#264</a>)</li> <li>Additional commits viewable in <a href="https://github.com/marshallpierce/rust-base64/compare/v0.21.5...v0.22.0">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 show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@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> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…ne#11115) Encountered it while implementing bevyengine#11109. Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective Resolves bevyengine#12431. ## Solution Added a `skip_taskbar` field to the `Window` struct (defaults to `false`). Used in `create_windows` if the target OS is Windows.
# Objective I was wondering why the `lighting` example was still looking quite different lately (specifically, the intensity of the green light on the cube) and noticed that we had one more color change I didn't catch before. Prior to the `bevy_color` port, `PINK` was actually "deep pink" from the css4 spec. `palettes::css::PINK` is now correctly a lighter pink color defined by the same spec. ```rust // Bevy 0.13 pub const PINK: Color = Color::rgb(1.0, 0.08, 0.58); // Bevy 0.14-dev pub const PINK: Srgba = Srgba::new(1.0, 0.753, 0.796, 1.0); pub const DEEP_PINK: Srgba = Srgba::new(1.0, 0.078, 0.576, 1.0); ``` ## Solution Change usages of `css::PINK` to `DEEP_PINK` to restore the examples to their former colors.
# Objective prevent gpu buffer allocations when running `as_bind_group` for assets with texture dependencies that are not yet available. ## Solution reorder the binding creation so that fallible items are created first.
…#12516) # Objective Currently in order to retrieve the inner values from direction types is that you need to use the `Deref` trait or `From`/`Into`. `Deref` that is currently implemented is an anti-pattern that I believe should be less relied upon. This pull-request add getters for retrieving the inner values for direction types. Advantages of getters: - Let rust-analyzer to list out available methods for users to understand better to on how to get the inner value. (This happens to me. I really don't know how to get the value until I look through the source code.) - They are simple. - Generally won't be ambiguous in most context. Traits such as `From`/`Into` will require fully qualified syntax from time to time. - Unsurprising result. Disadvantages of getters: - More verbose Advantages of deref polymorphism: - You reduce boilerplate for getting the value and call inner methods by: ```rust let dir = Dir3::new(Vec3::UP).unwrap(); // getting value let value = *dir; // instead of using getters let value = dir.vec3(); // calling methods for the inner vector dir.xy(); // instead of using getters dir.vec3().xy(); ``` Disadvantages of deref polymorphism: - When under more level of indirection, it will requires more dereferencing which will get ugly in some part: ```rust // getting value let value = **dir; // instead of using getters let value = dir.vec3(); // calling methods for the inner vector dir.xy(); // instead of using getters dir.vec3().xy(); ``` [More detail here](https://rust-unofficial.github.io/patterns/anti_patterns/deref.html). Edit: Update information for From/Into trait. Edit: Advantages and disadvantages. ## Solution Add `vec2` method for Dir2. Add `vec3` method for Dir3. Add `vec3a` method for Dir3A.
…2538) # Objective - Not all materials need shadow, but a queue_shadows system is always added to the `Render` schedule and executed ## Solution - Make a setting for shadows, it defaults to true ## Changelog - Added `shadows_enabled` setting to `MaterialPlugin` ## Migration Guide - `MaterialPlugin` now has a `shadows_enabled` setting, if you didn't spawn the plugin using `::default()` or `..default()`, you'll need to set it. `shadows_enabled: true` is the same behavior as the previous version, and also the default value.
# Objective
Simplify implementing some asset traits without Box::pin(async move{})
shenanigans.
Fixes (in part) bevyengine#11308
## Solution
Use async-fn in traits when possible in all traits. Traits with return
position impl trait are not object safe however, and as AssetReader and
AssetWriter are both used with dynamic dispatch, you need a Boxed
version of these futures anyway.
In the future, Rust is [adding
](https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html)proc
macros to generate these traits automatically, and at some point in the
future dyn traits should 'just work'. Until then.... this seemed liked
the right approach given more ErasedXXX already exist, but, no clue if
there's plans here! Especially since these are public now, it's a bit of
an unfortunate API, and means this is a breaking change.
In theory this saves some performance when these traits are used with
static dispatch, but, seems like most code paths go through dynamic
dispatch, which boxes anyway.
I also suspect a bunch of the lifetime annotations on these function
could be simplified now as the BoxedFuture was often the only thing
returned which needed a lifetime annotation, but I'm not touching that
for now as traits + lifetimes can be so tricky.
This is a revival of
[pull/11362](bevyengine#11362) after a
spectacular merge f*ckup, with updates to the latest Bevy. Just to recap
some discussion:
- Overall this seems like a win for code quality, especially when
implementing these traits, but a loss for having to deal with ErasedXXX
variants.
- `ConditionalSend` was the preferred name for the trait that might be
Send, to deal with wasm platforms.
- When reviewing be sure to disable whitespace difference, as that's 95%
of the PR.
## Changelog
- AssetReader, AssetWriter, AssetLoader, AssetSaver and Process now use
async-fn in traits rather than boxed futures.
## Migration Guide
- Custom implementations of AssetReader, AssetWriter, AssetLoader,
AssetSaver and Process should switch to async fn rather than returning a
bevy_utils::BoxedFuture.
- Simultaniously, to use dynamic dispatch on these traits you should
instead use dyn ErasedXXX.
# Objective Give Bevy a well-designed built-in color palette for users to use while prototyping or authoring Bevy examples. ## Solution Generate ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f7b3a3002fb7727db15c1197e0a1a373), [gist](https://gist.github.com/rust-play/f7b3a3002fb7727db15c1197e0a1a373)) consts from [Tailwind](https://tailwindcss.com/docs/customizing-colors) (mit license) json. ## Discussion Are there other popular alternatives we should be looking at? Something new and fancy involving a really long acronym like CIELUVLCh? I'm not a tailwind user or color expert, but I really like the way it's broken up into distinct but plentiful hue and lightness groups. It beats needing some shades of red, scrolling through the [current palette](https://docs.rs/bevy/latest/bevy/prelude/enum.Color.html), choosing a few of `CRIMSON`, `MAROON`, `RED`, `TOMATO` at random and calling it a day. The best information I was able to dig up about the Tailwind palette is from this thread: https://twitter.com/steveschoger/status/1303795136703410180. Here are some key excerpts: > Tried to the "perceptually uniform" thing for Tailwind UI. > Ultimately, it just resulted in a bunch of useless shades for colors like yellow and green that are inherently brighter. > With that said you're guaranteed to get a contrast ratio of 4.5:1 when using any 700 shade (in some cases 600) on a 100 shade of the same hue. > We just spent a lot of time looking at sites to figure out which colors are popular and tried to fill all the gaps. > Even the lime green is questionable but felt there needed to be something in between the jump from yellow to green 😅 --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
…ine#11237) # Objective - This is an adopted version of bevyengine#10420 - The objective is to help debugging the Ui layout tree with helpful outlines, that can be easily enabled/disabled ## Solution - Like bevyengine#10420, the solution is using the bevy_gizmos in outlining the nodes --- ## Changelog ### Added - Added debug_overlay mod to `bevy_dev_tools` - Added bevy_ui_debug feature to `bevy_dev_tools` ## How to use - The user must use `bevy_dev_tools` feature in TOML - The user must use the plugin UiDebugPlugin, that can be found on `bevy::dev_tools::debug_overlay` - Finally, to enable the function, the user must set `UiDebugOptions::enabled` to true Someone can easily toggle the function with something like: ```rust fn toggle_overlay(input: Res<ButtonInput<KeyCode>>, options: ResMut<UiDebugOptions>) { if input.just_pressed(KeyCode::Space) { // The toggle method will enable if disabled and disable if enabled options.toggle(); } } ``` Note that this feature can be disabled from dev_tools, as its in fact behind a default feature there, being the feature bevy_ui_debug. # Limitations Currently, due to limitations with gizmos itself, it's not possible to support this feature to more the one window, so this tool is limited to the primary window only. # Showcase  Ui example with debug_overlay enabled  And disabled --------- Co-authored-by: Nicola Papale <nico@nicopap.ch> Co-authored-by: Pablo Reinhardt <pabloreinhardt@gmail.com> Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective - Allow configuring of platform-specific panic handlers. - Remove the silent overwrite of the WASM panic handler - Closes bevyengine#12546 ## Solution - Separates the panic handler to a new plugin, `PanicHandlerPlugin`. - `PanicHandlerPlugin` was added to `DefaultPlugins`. - Can be disabled on `DefaultPlugins`, in the case someone needs to configure custom panic handlers. --- ## Changelog ### Added - A `PanicHandlerPlugin` was added to the `DefaultPlugins`, which now sets sensible target-specific panic handlers. ### Changed - On WASM, the panic stack trace was output to the console through the `BevyLogPlugin`. Since this was separated out into `PanicHandlerPlugin`, you may need to add the new `PanicHandlerPlugin` (included in `DefaultPlugins`). ## Migration Guide - If you used `MinimalPlugins` with `LogPlugin` for a WASM-target build, you will need to add the new `PanicHandlerPlugin` to set the panic behavior to output to the console. Otherwise, you will see the default panic handler (opaque, `unreachable` errors in the console).
# Objective Implements border radius for UI nodes. Adopted from bevyengine#8973, but excludes shadows. ## Solution - Add a component `BorderRadius` which contains a radius value for each corner of the UI node. - Use a fragment shader to generate the rounded corners using a signed distance function. <img width="50%" src="https://github.com/bevyengine/bevy/assets/26204416/16b2ba95-e274-4ce7-adb2-34cc41a776a5"></img> ## Changelog - `BorderRadius`: New component that holds the border radius values. - `NodeBundle` & `ButtonBundle`: Added a `border_radius: BorderRadius` field. - `extract_uinode_borders`: Stripped down, most of the work is done in the shader now. Borders are no longer assembled from multiple rects, instead the shader uses a signed distance function to draw the border. - `UiVertex`: Added size, border and radius fields. - `UiPipeline`: Added three vertex attributes to the vertex buffer layout, to accept the UI node's size, border thickness and border radius. - Examples: Added rounded corners to the UI element in the `button` example, and a `rounded_borders` example. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Zachary Harrold <zac@harrold.com.au> Co-authored-by: Pablo Reinhardt <126117294+pablo-lua@users.noreply.github.com>
# Objective - Fixes bevyengine#12202 ## Solution - This PR implements componentwise (including alpha) addition, subtraction and scalar multiplication/division for some color types. - The mentioned color types are `Laba`, `Oklaba`, `LinearRgba` and `Xyza` as all of them are either physically or perceptually linear as mentioned by @alice-i-cecile in the issue. --- ## Changelog - Scalar mul/div for `LinearRgba` may modify alpha now. ## Migration Guide - Users of scalar mul/div for `LinearRgba` need to be aware of the change and maybe use the `.clamp()` methods or manually set the `alpha` channel.
# Objective - Many types in bevy_render doesn't reflect Default even if it could. ## Solution - Reflect it. --- --------- Co-authored-by: Pablo Reinhardt <pabloreinhardt@gmail.com>
# Objective Fixes bevyengine#12224. ## Solution - Expand `with_` methods for the `Oklch` to their full names. - Expand `l` to `lightness` in `Oklaba` comments. ## Migration Guide The following methods have been renamed for the `Oklch` color space: - `with_l` -> `with_lightness`. - `with_c` -> `with_chroma`. - `with_h` -> `with_hue`.
…yengine#12592) # Objective - bevyengine#12500 broke images and background colors in UI. Try examples `overflow`, `ui_scaling` or `ui_texture_atlas` ## Solution - Makes the component `BorderRadius` optional in the query, as it's not always present. Use `[0.; 4]` as border radius in the extracted node when none was found
# Objective - Currently the fps_overlay affects any other ui node spawned. This should not happen ## Solution - Use position absolute and a ZIndex of `i32::MAX - 32` - I also modified the example a little bit to center it correctly. It only worked previously because the overlay was pushing it down. I also took the opportunity to simplify the text spawning code a little bit.
# Objective Allow converting from `Dir2` to `Vec2` in generic code. Fixes bevyengine#12529. ## Solution Added a `From<Dir2>` impl for `Vec2`.
# Objective - since bevyengine#12500, text is a little bit more gray in UI ## Solution - don't multiply color by alpha. I think this was done in the original PR (bevyengine#8973) for shadows which were not added in bevyengine#12500
…2601) # Objective - bevyengine#12500 use the primary window resolution to do all its calculation. This means bad support for multiple windows or multiple ui camera ## Solution - Use camera driven UI (bevyengine#10559)
rparrett
force-pushed
the
check-for-patches-in-ci-test
branch
from
5c7080c
to
4a5fd3d
Compare
rparrett
force-pushed
the
check-for-patches-in-ci-test
branch
from
4a5fd3d
to
5c7e4ec
Compare
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.
Test