Mirrors/bevy
2
0
Fork 0
mirror of https://github.com/bevyengine/bevy synced 2024-11-23 05:03:47 +00:00
Code Issues Projects Releases Packages Wiki Activity
bevy/crates/bevy_sprite/Cargo.toml

42 lines
1.2 KiB
TOML
Raw Normal View History

sprite: create sprite crate. center 2d camera (split from ui camera). add 2d camera movement
2020-05-30 19:31:04 +00:00
[package]
name = "bevy_sprite"
Release 0.13.0 (#11920) Bump Bevy crates to 0.13.0 in preparation for release. (Note that we accidentally skipped the `0.13.0-dev` step this cycle)
2024-02-17 09:24:25 +00:00
version = "0.13.0"
Update to edition 2021 on master (#3028) Objective During work on #3009 I've found that not all jobs use actions-rs, and therefore, an previous version of Rust is used for them. So while compilation and other stuff can pass, checking markup and Android build may fail with compilation errors. Solution This PR adds `action-rs` for any job running cargo, and updates the edition to 2021.
2021-10-27 00:12:14 +00:00
edition = "2021"
add crate metadata
2020-08-10 00:24:27 +00:00
description = "Provides sprite functionality for Bevy Engine"
homepage = "https://bevyengine.org"
repository = "https://github.com/bevyengine/bevy"
Relicense Bevy under the dual MIT or Apache-2.0 license (#2509) This relicenses Bevy under the dual MIT or Apache-2.0 license. For rationale, see #2373. * Changes the LICENSE file to describe the dual license. Moved the MIT license to docs/LICENSE-MIT. Added the Apache-2.0 license to docs/LICENSE-APACHE. I opted for this approach over dumping both license files at the root (the more common approach) for a number of reasons: * Github links to the "first" license file (LICENSE-APACHE) in its license links (you can see this in the wgpu and rust-analyzer repos). People clicking these links might erroneously think that the apache license is the only option. Rust and Amethyst both use COPYRIGHT or COPYING files to solve this problem, but this creates more file noise (if you do everything at the root) and the naming feels way less intuitive. * People have a reflex to look for a LICENSE file. By providing a single license file at the root, we make it easy for them to understand our licensing approach. * I like keeping the root clean and noise free * There is precedent for putting the apache and mit license text in sub folders (amethyst) * Removed the `Copyright (c) 2020 Carter Anderson` copyright notice from the MIT license. I don't care about this attribution, it might make license compliance more difficult in some cases, and it didn't properly attribute other contributors. We shoudn't replace it with something like "Copyright (c) 2021 Bevy Contributors" because "Bevy Contributors" is not a legal entity. Instead, we just won't include the copyright line (which has precedent ... Rust also uses this approach). * Updates crates to use the new "MIT OR Apache-2.0" license value * Removes the old legion-transform license file from bevy_transform. bevy_transform has been its own, fully custom implementation for a long time and that license no longer applies. * Added a License section to the main readme * Updated our Bevy Plugin licensing guidelines. As a follow-up we should update the website to properly describe the new license. Closes #2373
2021-07-23 21:11:51 +00:00
license = "MIT OR Apache-2.0"
add crate metadata
2020-08-10 00:24:27 +00:00
keywords = ["bevy"]
sprite: create sprite crate. center 2d camera (split from ui camera). add 2d camera movement
2020-05-30 19:31:04 +00:00
Fix 2d_shapes and general 2D mesh instancing (#10051) # Objective - Fix #10050 ## Solution - Push constants needed to be defined in the pipeline layout and `bevy_sprite` needed to have a `webgl` feature.
2023-10-08 20:17:01 +00:00
[features]
webgl = []
Update to wgpu 0.19 and raw-window-handle 0.6 (#11280) # Objective Keep core dependencies up to date. ## Solution Update the dependencies. wgpu 0.19 only supports raw-window-handle (rwh) 0.6, so bumping that was included in this. The rwh 0.6 version bump is just the simplest way of doing it. There might be a way we can take advantage of wgpu's new safe surface creation api, but I'm not familiar enough with bevy's window management to untangle it and my attempt ended up being a mess of lifetimes and rustc complaining about missing trait impls (that were implemented). Thanks to @MiniaczQ for the (much simpler) rwh 0.6 version bump code. Unblocks https://github.com/bevyengine/bevy/pull/9172 and https://github.com/bevyengine/bevy/pull/10812 ~~This might be blocked on cpal and oboe updating their ndk versions to 0.8, as they both currently target ndk 0.7 which uses rwh 0.5.2~~ Tested on android, and everything seems to work correctly (audio properly stops when minimized, and plays when re-focusing the app). --- ## Changelog - `wgpu` has been updated to 0.19! The long awaited arcanization has been merged (for more info, see https://gfx-rs.github.io/2023/11/24/arcanization.html), and Vulkan should now be working again on Intel GPUs. - Targeting WebGPU now requires that you add the new `webgpu` feature (setting the `RUSTFLAGS` environment variable to `--cfg=web_sys_unstable_apis` is still required). This feature currently overrides the `webgl2` feature if you have both enabled (the `webgl2` feature is enabled by default), so it is not recommended to add it as a default feature to libraries without putting it behind a flag that allows library users to opt out of it! In the future we plan on supporting wasm binaries that can target both webgl2 and webgpu now that wgpu added support for doing so (see https://github.com/bevyengine/bevy/issues/11505). - `raw-window-handle` has been updated to version 0.6. ## Migration Guide - `bevy_render::instance_index::get_instance_index()` has been removed as the webgl2 workaround is no longer required as it was fixed upstream in wgpu. The `BASE_INSTANCE_WORKAROUND` shaderdef has also been removed. - WebGPU now requires the new `webgpu` feature to be enabled. The `webgpu` feature currently overrides the `webgl2` feature so you no longer need to disable all default features and re-add them all when targeting `webgpu`, but binaries built with both the `webgpu` and `webgl2` features will only target the webgpu backend, and will only work on browsers that support WebGPU. - Places where you conditionally compiled things for webgl2 need to be updated because of this change, eg: - `#[cfg(any(not(feature = "webgl"), not(target_arch = "wasm32")))]` becomes `#[cfg(any(not(feature = "webgl") ,not(target_arch = "wasm32"), feature = "webgpu"))]` - `#[cfg(all(feature = "webgl", target_arch = "wasm32"))]` becomes `#[cfg(all(feature = "webgl", target_arch = "wasm32", not(feature = "webgpu")))]` - `if cfg!(all(feature = "webgl", target_arch = "wasm32"))` becomes `if cfg!(all(feature = "webgl", target_arch = "wasm32", not(feature = "webgpu")))` - `create_texture_with_data` now also takes a `TextureDataOrder`. You can probably just set this to `TextureDataOrder::default()` - `TextureFormat`'s `block_size` has been renamed to `block_copy_size` - See the `wgpu` changelog for anything I might've missed: https://github.com/gfx-rs/wgpu/blob/trunk/CHANGELOG.md --------- Co-authored-by: François <mockersf@gmail.com>
2024-01-26 18:14:21 +00:00
webgpu = []
Fix 2d_shapes and general 2D mesh instancing (#10051) # Objective - Fix #10050 ## Solution - Push constants needed to be defined in the pipeline layout and `bevy_sprite` needed to have a `webgl` feature.
2023-10-08 20:17:01 +00:00
sprite: create sprite crate. center 2d camera (split from ui camera). add 2d camera movement
2020-05-30 19:31:04 +00:00
[dependencies]
add "0.1" version to all bevy crate references
2020-08-10 00:39:28 +00:00
# bevy
Release 0.13.0 (#11920) Bump Bevy crates to 0.13.0 in preparation for release. (Note that we accidentally skipped the `0.13.0-dev` step this cycle)
2024-02-17 09:24:25 +00:00
bevy_app = { path = "../bevy_app", version = "0.13.0" }
bevy_asset = { path = "../bevy_asset", version = "0.13.0" }
bevy_core_pipeline = { path = "../bevy_core_pipeline", version = "0.13.0" }
bevy_ecs = { path = "../bevy_ecs", version = "0.13.0" }
bevy_log = { path = "../bevy_log", version = "0.13.0" }
bevy_math = { path = "../bevy_math", version = "0.13.0" }
bevy_reflect = { path = "../bevy_reflect", version = "0.13.0", features = [
Standardize toml format with taplo (#10594) # Objective - Standardize fmt for toml files ## Solution - Add [taplo](https://taplo.tamasfe.dev/) to CI (check for fmt and diff for toml files), for context taplo is used by the most popular extension in VScode [Even Better TOML](https://marketplace.visualstudio.com/items?itemName=tamasfe.even-better-toml - Add contribution section to explain toml fmt with taplo. Now to pass CI you need to run `taplo fmt --option indent_string=" "` or if you use vscode have the `Even Better TOML` extension with 4 spaces for indent --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
2023-11-21 01:04:14 +00:00
"bevy",
Replace old renderer with new renderer (#3312) This makes the [New Bevy Renderer](#2535) the default (and only) renderer. The new renderer isn't _quite_ ready for the final release yet, but I want as many people as possible to start testing it so we can identify bugs and address feedback prior to release. The examples are all ported over and operational with a few exceptions: * I removed a good portion of the examples in the `shader` folder. We still have some work to do in order to make these examples possible / ergonomic / worthwhile: #3120 and "high level shader material plugins" are the big ones. This is a temporary measure. * Temporarily removed the multiple_windows example: doing this properly in the new renderer will require the upcoming "render targets" changes. Same goes for the render_to_texture example. * Removed z_sort_debug: entity visibility sort info is no longer available in app logic. we could do this on the "render app" side, but i dont consider it a priority.
2021-12-14 03:58:23 +00:00
] }
Release 0.13.0 (#11920) Bump Bevy crates to 0.13.0 in preparation for release. (Note that we accidentally skipped the `0.13.0-dev` step this cycle)
2024-02-17 09:24:25 +00:00
bevy_render = { path = "../bevy_render", version = "0.13.0" }
bevy_transform = { path = "../bevy_transform", version = "0.13.0" }
bevy_utils = { path = "../bevy_utils", version = "0.13.0" }
bevy_derive = { path = "../bevy_derive", version = "0.13.0" }
add texture atlases
2020-06-06 07:12:38 +00:00
add "0.1" version to all bevy crate references
2020-08-10 00:39:28 +00:00
# other
Replace old renderer with new renderer (#3312) This makes the [New Bevy Renderer](#2535) the default (and only) renderer. The new renderer isn't _quite_ ready for the final release yet, but I want as many people as possible to start testing it so we can identify bugs and address feedback prior to release. The examples are all ported over and operational with a few exceptions: * I removed a good portion of the examples in the `shader` folder. We still have some work to do in order to make these examples possible / ergonomic / worthwhile: #3120 and "high level shader material plugins" are the big ones. This is a temporary measure. * Temporarily removed the multiple_windows example: doing this properly in the new renderer will require the upcoming "render targets" changes. Same goes for the render_to_texture example. * Removed z_sort_debug: entity visibility sort info is no longer available in app logic. we could do this on the "render app" side, but i dont consider it a priority.
2021-12-14 03:58:23 +00:00
bytemuck = { version = "1.5", features = ["derive"] }
Visibilty Inheritance, universal ComputedVisibility and RenderLayers support (#5310) # Objective Fixes #4907. Fixes #838. Fixes #5089. Supersedes #5146. Supersedes #2087. Supersedes #865. Supersedes #5114 Visibility is currently entirely local. Set a parent entity to be invisible, and the children are still visible. This makes it hard for users to hide entire hierarchies of entities. Additionally, the semantics of `Visibility` vs `ComputedVisibility` are inconsistent across entity types. 3D meshes use `ComputedVisibility` as the "definitive" visibility component, with `Visibility` being just one data source. Sprites just use `Visibility`, which means they can't feed off of `ComputedVisibility` data, such as culling information, RenderLayers, and (added in this pr) visibility inheritance information. ## Solution Splits `ComputedVisibilty::is_visible` into `ComputedVisibilty::is_visible_in_view` and `ComputedVisibilty::is_visible_in_hierarchy`. For each visible entity, `is_visible_in_hierarchy` is computed by propagating visibility down the hierarchy. The `ComputedVisibility::is_visible()` function combines these two booleans for the canonical "is this entity visible" function. Additionally, all entities that have `Visibility` now also have `ComputedVisibility`. Sprites, Lights, and UI entities now use `ComputedVisibility` when appropriate. This means that in addition to visibility inheritance, everything using Visibility now also supports RenderLayers. Notably, Sprites (and other 2d objects) now support `RenderLayers` and work properly across multiple views. Also note that this does increase the amount of work done per sprite. Bevymark with 100,000 sprites on `main` runs in `0.017612` seconds and this runs in `0.01902`. That is certainly a gap, but I believe the api consistency and extra functionality this buys us is worth it. See [this thread](https://github.com/bevyengine/bevy/pull/5146#issuecomment-1182783452) for more info. Note that #5146 in combination with #5114 _are_ a viable alternative to this PR and _would_ perform better, but that comes at the cost of api inconsistencies and doing visibility calculations in the "wrong" place. The current visibility system does have potential for performance improvements. I would prefer to evolve that one system as a whole rather than doing custom hacks / different behaviors for each feature slice. Here is a "split screen" example where the left camera uses RenderLayers to filter out the blue sprite. ![image](https://user-images.githubusercontent.com/2694663/178814868-2e9a2173-bf8c-4c79-8815-633899d492c3.png) Note that this builds directly on #5146 and that @james7132 deserves the credit for the baseline visibility inheritance work. This pr moves the inherited visibility field into `ComputedVisibility`, then does the additional work of porting everything to `ComputedVisibility`. See my [comments here](https://github.com/bevyengine/bevy/pull/5146#issuecomment-1182783452) for rationale. ## Follow up work * Now that lights use ComputedVisibility, VisibleEntities now includes "visible lights" in the entity list. Functionally not a problem as we use queries to filter the list down in the desired context. But we should consider splitting this out into a separate`VisibleLights` collection for both clarity and performance reasons. And _maybe_ even consider scoping `VisibleEntities` down to `VisibleMeshes`?. * Investigate alternative sprite rendering impls (in combination with visibility system tweaks) that avoid re-generating a per-view fixedbitset of visible entities every frame, then checking each ExtractedEntity. This is where most of the performance overhead lives. Ex: we could generate ExtractedEntities per-view using the VisibleEntities list, avoiding the need for the bitset. * Should ComputedVisibility use bitflags under the hood? This would cut down on the size of the component, potentially speed up the `is_visible()` function, and allow us to cheaply expand ComputedVisibility with more data (ex: split out local visibility and parent visibility, add more culling classes, etc). --- ## Changelog * ComputedVisibility now takes hierarchy visibility into account. * 2D, UI and Light entities now use the ComputedVisibility component. ## Migration Guide If you were previously reading `Visibility::is_visible` as the "actual visibility" for sprites or lights, use `ComputedVisibilty::is_visible()` instead: ```rust // before (0.7) fn system(query: Query<&Visibility>) { for visibility in query.iter() { if visibility.is_visible { log!("found visible entity"); } } } // after (0.8) fn system(query: Query<&ComputedVisibility>) { for visibility in query.iter() { if visibility.is_visible() { log!("found visible entity"); } } } ``` Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2022-07-15 23:24:42 +00:00
fixedbitset = "0.4"
update dependencies (#470)
2020-09-10 19:54:24 +00:00
guillotiere = "0.6.0"
Replace old renderer with new renderer (#3312) This makes the [New Bevy Renderer](#2535) the default (and only) renderer. The new renderer isn't _quite_ ready for the final release yet, but I want as many people as possible to start testing it so we can identify bugs and address feedback prior to release. The examples are all ported over and operational with a few exceptions: * I removed a good portion of the examples in the `shader` folder. We still have some work to do in order to make these examples possible / ergonomic / worthwhile: #3120 and "high level shader material plugins" are the big ones. This is a temporary measure. * Temporarily removed the multiple_windows example: doing this properly in the new renderer will require the upcoming "render targets" changes. Same goes for the render_to_texture example. * Removed z_sort_debug: entity visibility sort info is no longer available in app logic. we could do this on the "render app" side, but i dont consider it a priority.
2021-12-14 03:58:23 +00:00
thiserror = "1.0"
rectangle-pack = "0.4"
update bitflags to 2.3 (#8728) # Objective - Update bitflags to 2.3
2023-06-01 08:41:42 +00:00
bitflags = "2.3"
Use radsort for Transparent2d PhaseItem sorting (#9882) # Objective Fix a performance regression in the "[bevy vs pixi](https://github.com/SUPERCILEX/bevy-vs-pixi)" benchmark. This benchmark seems to have a slightly pathological distribution of `z` values -- Sprites are spawned with a random `z` value with a child sprite at `f32::EPSILON` relative to the parent. See discussion here: https://github.com/bevyengine/bevy/issues/8100#issuecomment-1726978633 ## Solution Use `radsort` for sorting `Transparent2d` `PhaseItem`s. Use random `z` values in bevymark to stress the phase sort. Add an `--ordered-z` option to `bevymark` that uses the old behavior. ## Benchmarks mac m1 max | benchmark | fps before | fps after | diff | | - | - | - | - | | bevymark --waves 120 --per-wave 1000 --random-z | 42.16 | 47.06 | 🟩 +11.6% | | bevymark --waves 120 --per-wave 1000 | 52.50 | 52.29 | 🟥 -0.4% | | bevymark --waves 120 --per-wave 1000 --mode mesh2d --random-z | 9.64 | 10.24 | 🟩 +6.2% | | bevymark --waves 120 --per-wave 1000 --mode mesh2d | 15.83 | 15.59 | 🟥 -1.5% | | bevy-vs-pixi | 39.71 | 59.88 | 🟩 +50.1% | ## Discussion It's possible that `TransparentUi` should also change. We could probably use `slice::sort_unstable_by_key` with the current sort key though, as its items are always sorted and unique. I'd prefer to follow up later to look into that. Here's a survey of sorts used by other `PhaseItem`s #### slice::sort_by_key `Transparent2d`, `TransparentUi` #### radsort `Opaque3d`, `AlphaMask3d`, `Transparent3d`, `Opaque3dPrepass`, `AlphaMask3dPrepass`, `Shadow` I also tried `slice::sort_unstable_by_key` with a compound sort key including `Entity`, but it didn't seem as promising and I didn't test it as thoroughly. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Robert Swain <robert.swain@gmail.com>
2023-09-21 17:53:20 +00:00
radsort = "0.1"
Add [lints] table, fix adding `#![allow(clippy::type_complexity)]` everywhere (#10011) # Objective - Fix adding `#![allow(clippy::type_complexity)]` everywhere. like #9796 ## Solution - Use the new [lints] table that will land in 1.74 (https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#lints) - inherit lint to the workspace, crates and examples. ``` [lints] workspace = true ``` ## Changelog - Bump rust version to 1.74 - Enable lints table for the workspace ```toml [workspace.lints.clippy] type_complexity = "allow" ``` - Allow type complexity for all crates and examples ```toml [lints] workspace = true ``` --------- Co-authored-by: Martín Maita <47983254+mnmaita@users.noreply.github.com>
2023-11-18 20:58:48 +00:00
[lints]
workspace = true
Reference in a new issue Copy permalink