Fix cameraprojection crash - Merge and conflict fix of bevy/main
#3
Conversation
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
# 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
# Objective It's useful to have access to render pipeline statistics, since they provide more information than FPS alone. For example, the number of drawn triangles can be used to debug culling and LODs. The number of fragment shader invocations can provide a more stable alternative metric than GPU elapsed time. See also: Render node GPU timing overlay bevyengine#8067, which doesn't provide pipeline statistics, but adds a nice overlay. ## Solution Add `RenderDiagnosticsPlugin`, which enables collecting pipeline statistics and CPU & GPU timings. --- ## Changelog - Add `RenderDiagnosticsPlugin` - Add `RenderContext::diagnostic_recorder` method --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective - Resolves bevyengine#12463 ## Solution - Added `ClampColor` Due to consistency, `is_within_bounds` is a method of `ClampColor`, like `is_fully_transparent` is a method of `Alpha` --- ## Changelog ### Added - `ClampColor` trait --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective Whenever a nodes size gets changed, its texture slices get updated a frame later. This results in visual glitches when animating the size of a node with a texture slice. See this video: [Screencast from 17-03-24 14:53:13.webm](https://github.com/bevyengine/bevy/assets/46689298/64e711f7-a1ec-41e3-b119-dc8d7e1a7669) ## Solution Compute texture slices after the layout system has finished.
…yengine#12519) # Objective - Make example font_atlas_debug deterministic so that it's easier to check for regression ## Solution - Use a seeded random
# Objective fix bevyengine#12344 ## Solution use existing machinery in track_assets to determine if the asset is unused before firing Asset::Unused event ~~most extract functions use `AssetEvent::Removed` to schedule deletion of render world resources. `RenderAssetPlugin` was using `AssetEvent::Unused` instead. `Unused` fires when the last strong handle is dropped, even if a new one is created. `Removed` only fires when a new one is not created. as far as i can see, `Unused` is the same as `Removed` except for this "feature", and that it also fires early if all handles for a loading asset are dropped (`Removed` fires after the loading completes). note that in that case, processing based on `Loaded` won't have been done anyway. i think we should get rid of `Unused` completely, it is not currently used anywhere (except here, previously) and i think using it is probably always a mistake. i also am not sure why we keep loading assets that have been dropped while loading, we should probably drop the loader task as well and remove immediately.~~
# Objective The current example showcase site URLs have white-space and caps in them which looks ugly as an URL. Fixes bevyengine/bevy-website#736 ## Solution To fix this the example showcase tool now makes the category used for the site sections lowercase, separated by a hyphen rather than white-space, and without parentheses. --------- Co-authored-by: Rob Parrett <robparrett@gmail.com> Co-authored-by: vero <email@atlasdostal.com>
…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://redirect.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://redirect.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://redirect.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://redirect.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.
…vyengine#12998) # Objective Fixes bevyengine#12900 ## Solution Added comment to example indicating that additional audio formats are supported when the feature is added. --------- Co-authored-by: James Liu <contact@jamessliu.com>
# Objective - Fixes bevyengine#13024. ## Solution - Run `cargo clippy --target wasm32-unknown-unknown` until there are no more errors. - I recommend reviewing one commit at a time :) --- ## Changelog - Fixed Clippy lints for `wasm32-unknown-unknown` target. - Updated `bevy_transform`'s `README.md`.
# Objective - The docs says the WireframeColor is supposed to override the default global color but it doesn't. ## Solution - Use WireframeColor to override global color like docs said it was supposed to do. - Updated the example to document this feature - I also took the opportunity to clean up the code a bit Fixes bevyengine#13032
…functions (bevyengine#13044) # Objective Fix bevyengine#2128. Both `Query::new_archetype` and `SystemParam::new_archetype` do not check if the `Archetype` comes from the same World the state is initialized from. This could result in unsoundness via invalid accesses if called incorrectly. ## Solution Make them `unsafe` functions and lift the invariant to the caller. This also caught one instance of us not validating the World in `SystemState::update_archetypes_unsafe_world_cell`'s implementation. --- ## Changelog Changed: `QueryState::new_archetype` is now an unsafe function. Changed: `SystemParam::new_archetype` is now an unsafe function. ## Migration Guide `QueryState::new_archetype` and `SystemParam::new_archetype` are now an unsafe functions that must be sure that the provided `Archetype` is from the same `World` that the state was initialized from. Callers may need to add additional assertions or propagate the safety invariant upwards through the callstack to ensure safety.
# Objective The warning mentions the function `add_state` which doesn't exist; replaced with `init_state`
# Objective - `MeshPipelineKey` use some bits for two things - First commit in this PR adds an assertion that doesn't work currently on main - This leads to some mesh topology not working anymore, for example `LineStrip` - With examples `lines`, there should be two groups of lines, the blue one doesn't display currently ## Solution - Change the `MeshPipelineKey` to be backed by a `u64` instead, to have enough bits
Adjusted the documentation to better describe the performance cost of `ButtonInput::any_just_pressed|any_just_released|any_pressed`. Each function iterates the full input, but each check is expected constant cost. It was described previously as a full input check, and a full internal list iteration, which I believe is incorrect.
# Objective Makes crate module docs render correctly in the docs for the monolithic library. Fixes bevyengine#13055. ## Solution Swap from ```rust pub mod foo { pub use bevy_foo::*; } ``` to ```rust pub use bevy_foo as foo; ```
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.20.8 to 1.20.9. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/releases">crate-ci/typos's releases</a>.</em></p> <blockquote> <h2>v1.20.9</h2> <h2>[1.20.9] - 2024-04-16</h2> <h3>Fixes</h3> <ul> <li>Don't correct the unit <code>dBA</code> (as an identifier to limit to that case)</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/blob/master/CHANGELOG.md">crate-ci/typos's changelog</a>.</em></p> <blockquote> <h2>[1.20.9] - 2024-04-16</h2> <h3>Fixes</h3> <ul> <li>Don't correct the unit <code>dBA</code> (as an identifier to limit to that case)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/crate-ci/typos/commit/44548ad17abdc3e4ebfa53252764e3ff21dbfa0f"><code>44548ad</code></a> chore: Release</li> <li><a href="https://github.com/crate-ci/typos/commit/73fb2cad756df30f27730df4ec7abb6e8088f682"><code>73fb2ca</code></a> docs: Update changelog</li> <li><a href="https://github.com/crate-ci/typos/commit/21838b0e7d8402e8ede4de677fbfb84b6e226d5e"><code>21838b0</code></a> Merge pull request <a href="https://redirect.github.com/crate-ci/typos/issues/1000">#1000</a> from epage/dba</li> <li><a href="https://github.com/crate-ci/typos/commit/ee32d77aba122c27b38006345490647394f2b699"><code>ee32d77</code></a> fix(dict): Don't correct dBA</li> <li><a href="https://github.com/crate-ci/typos/commit/56df0bd8d66ef3cc9f4c7e99f0b228cc5ff8dd47"><code>56df0bd</code></a> test(dict): Show dBA behavior</li> <li>See full diff in <a href="https://github.com/crate-ci/typos/compare/v1.20.8...v1.20.9">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) 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>
# Objective Allow parallel iteration over events, resolve bevyengine#10766 ## Solution - Add `EventParIter` which works similarly to `QueryParIter`, implementing a `for_each{_with_id}` operator. I chose to not mirror `EventIteratorWithId` and instead implement both operations on a single struct. - Reuse `BatchingStrategy` from `QueryParIter` ## Changelog - `EventReader` now supports parallel event iteration using `par_read().for_each(|event| ...)`. --------- Co-authored-by: James Liu <contact@jamessliu.com> Co-authored-by: Pablo Reinhardt <126117294+pablo-lua@users.noreply.github.com>
# Objective Add support so bevy_ui can correctly handle an UI hierarchy without a camera present. - Fixes bevyengine#12184 ## Solution As there was no default behavior for what should happen when a camera is not present in a UI hierarchy, the solution was based in defining that default behavior and improving the overall handling of this "exception". ## Changelog - Create default values to be used in upsert_node - Add flag to control warnings about no camera present - Create unit test no_camera_ui (to test if ui handles no camera present)
# Objective - rust-lang/rust#123905 has been merged, so the workaround introduced in bevyengine#12913 is no longer necessary. - Closes bevyengine#12968 ## Solution - Remove unecessary `allow` attribute - This is currently blocked until Rust beta updates. - Last tested with `rustc 1.78.0-beta.7 (6fd191292 2024-04-12)`.
# Objective Closes bevyengine#13017. ## Solution - Make `AppExit` a enum with a `Success` and `Error` variant. - Make `App::run()` return a `AppExit` if it ever returns. - Make app runners return a `AppExit` to signal if they encountered a error. --- ## Changelog ### Added - [`App::should_exit`](https://example.org/) - [`AppExit`](https://docs.rs/bevy/latest/bevy/app/struct.AppExit.html) to the `bevy` and `bevy_app` preludes, ### Changed - [`AppExit`](https://docs.rs/bevy/latest/bevy/app/struct.AppExit.html) is now a enum with 2 variants (`Success` and `Error`). - The app's [runner function](https://docs.rs/bevy/latest/bevy/app/struct.App.html#method.set_runner) now has to return a `AppExit`. - [`App::run()`](https://docs.rs/bevy/latest/bevy/app/struct.App.html#method.run) now also returns the `AppExit` produced by the runner function. ## Migration Guide - Replace all usages of [`AppExit`](https://docs.rs/bevy/latest/bevy/app/struct.AppExit.html) with `AppExit::Success` or `AppExit::Failure`. - Any custom app runners now need to return a `AppExit`. We suggest you return a `AppExit::Error` if any `AppExit` raised was a Error. You can use the new [`App::should_exit`](https://example.org/) method. - If not exiting from `main` any other way. You should return the `AppExit` from `App::run()` so the app correctly returns a error code if anything fails e.g. ```rust fn main() -> AppExit { App::new() //Your setup here... .run() } ``` --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective Fixes bevyengine#12470 This adds a examples for `ButtonInput` with `KeyCode`, `MouseButton`, and `GamepadButton`. It also includes an example of checking a multi-key combination, and checking multiple keys to mean roughly the same thing.
) # Objective Fixes bevyengine#12539 Improve [this CI output](https://github.com/bevyengine/bevy/actions/runs/8367408952/job/22909715870#step:7:11). ## Solution - Don't stop after the first failure. - Print the filename of the patch(es) that failed. - Clean up an unused package install while we're at it. Tested over here: rparrett#20 --------- Co-authored-by: BD103 <59022059+BD103@users.noreply.github.com>
…13065) # Objective Adds a few extra `#[doc(alias)]` entries to the `bevy_math::primitives::WindingOrder` enum and its variants to improve searchability. ## Solution - Add "Orientation" for `WindingOrder` itself - Add "AntiClockwise" for `CounterClockwise` variant - Add "Collinear" for `Invalid` variant These alternate terms seem to be quite common, especially in the contexts of rendering and collision-detection. Signed-off-by: Nullicorn <git@nullicorn.me>
Bumps `async-task` to 4.7.0 , note this is what Cargo.lock has as well.
Building as a dependency gives the following:
```
Compiling async-channel v1.8.0
Compiling futures-lite v1.12.0
error[E0432]: unresolved import `async_task::Builder`
--> /Users/daniel/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-executor-1.8.0/src/lib.rs:46:18
|
46 | use async_task::{Builder, Runnable};
| ^^^^^^^ no `Builder` in the root
|
= help: consider importing this struct instead:
std::thread::Builder
For more information about this error, try `rustc --explain E0432`.
error: could not compile `async-executor` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
```
With this change, builds correctly
# Objective - Some CI jobs specifically use `macos-14`, as compared to the default `macos-latest`. - `macos-latest` is equivalent to `macos-12`, but may be updated in the future. - The CI job that tests on the minimum supported Rust version (MSRV) uses environmental variables to save the toolchain version. - This specific usage is what step outputs were designed for. - Both do the same thing, but step outputs can be checked by the [Github Actions VSCode Extension](https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-github-actions). - Some workflows have a `NIGHTLY_TOOLCHAIN` variable that let us pin the nightly version, in case a new release breaks CI. ## Solution - Document why certain actions required `macos-14`. - Switch MSRV step to use step outputs. - Add a small comment documenting the purpose of the `NIGHTLY_TOOLCHAIN` environmental variable.
# Objective Allow `Gizmos` to work in `FixedUpdate` without any changes needed. This changes `Gizmos` from being a purely immediate mode api, but allows the user to use it as if it were an immediate mode API regardless of schedule context. Also allows for extending by other custom schedules by adding their own `GizmoStorage<Clear>` and the requisite systems: - `propagate_gizmos::<Clear>` before `update_gizmo_meshes` - `stash_default_gizmos` when starting a clear context - `pop_default_gizmos` when ending a clear context - `collect_default_gizmos` when grabbing the requested gizmos - `clear_gizmos` for clearing the context's gizmos ## Solution Adds a generic to `Gizmos` that defaults to `Update` (the current way gizmos works). When entering a new clear context the default `Gizmos` gets swapped out for that context's duration so the context can collect the gizmos requested. Prior work: bevyengine#9153 ## To do - [x] `FixedUpdate` should probably get its own First, Pre, Update, Post, Last system sets for this. Otherwise users will need to make sure to order their systems before `clear_gizmos`. This could alternatively be fixed by moving the setup of this to `bevy_time::fixed`? PR to fix this issue: bevyengine#10977 - [x] use mem::take internally for the swaps? - [x] Better name for the `Context` generic on gizmos? `Clear`? --- ## Changelog - Gizmos drawn in `FixedMain` now last until the next `FixedMain` iteration runs.
|
Welcome, new contributor! Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨ |
Zoomulator
force-pushed
the
fix-cameraprojection-crash
branch
from
5e6fdfe to
d618dbf
Compare
|
Something went wrong here if you look at the diff, making it basically impossible for doonv to review this PR. |
Zoomulator
force-pushed
the
fix-cameraprojection-crash
branch
from
01ecd5e to
518f1e6
Compare
Yeah, rebasing someone else's PR wasn't the best move. Done a simple merge with the fixed conflicts now. |
Zoomulator
changed the title
bevy/main
|
Yeah I think I'll try rebasing it myself. |
|
I don't think rebasing is the right thing to do, I'll just do a regular merge. |
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.
Objective
Merged and fixed conflicts to be up-to-date with
bevy/mainNotable conflicts
CameraProjectionPlugin<T>got new trait boundsT: CameraProjection + Component + GetTypeRegistration, which conflicted with a doc comment above it.CameraUpdateSystemstruct definition was moved to the line belowCameraProjectionPlugincheck_visibilityis now genericcheck_visibility::<WithMesh>(view/visibility/mod.rs)