diff --git a/content/learn/book/getting-started/plugins/_index.md b/content/learn/book/getting-started/plugins/_index.md index 9cb8638ff0..812d112fe7 100644 --- a/content/learn/book/getting-started/plugins/_index.md +++ b/content/learn/book/getting-started/plugins/_index.md @@ -32,7 +32,7 @@ Once again run `cargo run`. You should hopefully notice two things: -* **A window should pop up**. This is because we now have {{rust_type(type="struct" crate="bevy_window" name="WindowPlugin")}}, which defines the window interface (but doesn't actually know how to make windows), and {{rust_type(type="struct" crate="bevy_winit" name="WinitPlugin")}} which uses the [winit library](https://github.com/rust-windowing/winit) to create a window using your OS's native window api. +* **A window should pop up**. This is because we now have {{rust_type(type="struct" crate="bevy_window" name="WindowPlugin")}}, which defines the window interface (but doesn't actually know how to make windows), and {{rust_type(type="struct" crate="bevy_winit" name="WinitPlugin")}} which uses the [winit library](https://github.com/rust-windowing/winit) to create a window using your OS's native window API. * **Your console is now full of "hello" messages**: This is because {{rust_type(type="struct" crate="bevy" name="DefaultPlugins")}} adds an "event loop" to our application. Our App's ECS Schedule now runs in a loop once per "frame". We will resolve the console spam in a moment. Note that `add_plugins(DefaultPlugins)` is equivalent to the following: diff --git a/content/learn/migration-guides/0.6-0.7/_index.md b/content/learn/migration-guides/0.6-0.7/_index.md index 464f5c962d..e34d468749 100644 --- a/content/learn/migration-guides/0.6-0.7/_index.md +++ b/content/learn/migration-guides/0.6-0.7/_index.md @@ -206,7 +206,7 @@ fn camera_system(cameras: Query<&Camera, With>) { } ``` -### [Remove the config api](https://github.com/bevyengine/bevy/pull/3633) +### [Remove the config API](https://github.com/bevyengine/bevy/pull/3633) ```rs // 0.6 diff --git a/content/learn/migration-guides/0.9-0.10/_index.md b/content/learn/migration-guides/0.9-0.10/_index.md index 4bb052e4b2..0d232c71bc 100644 --- a/content/learn/migration-guides/0.9-0.10/_index.md +++ b/content/learn/migration-guides/0.9-0.10/_index.md @@ -506,7 +506,7 @@ fn clear_events(mut reader: EventReader) { `Archetype` indices and `Table` rows have been newtyped as `ArchetypeRow` and `TableRow`. -### [Round out the untyped api s](https://github.com/bevyengine/bevy/pull/7009) +### [Round out the untyped APIs](https://github.com/bevyengine/bevy/pull/7009)
ECS
@@ -1059,7 +1059,7 @@ Removed `SetShadowViewBindGroup`, `queue_shadow_view_bind_group()`, and `LightMe
Assets
-No api changes are required, but it's possible that your gltf meshes look different +No API changes are required, but it's possible that your gltf meshes look different ### [Send emissive color to uniform as linear instead of sRGB](https://github.com/bevyengine/bevy/pull/7897) diff --git a/content/news/2020-08-10-introducing-bevy/index.md b/content/news/2020-08-10-introducing-bevy/index.md index 3a2aa4490a..ba2a50066d 100644 --- a/content/news/2020-08-10-introducing-bevy/index.md +++ b/content/news/2020-08-10-introducing-bevy/index.md @@ -1127,7 +1127,7 @@ Right now Bevy can render plenty fast for most use cases, but when it comes to r ### Canvas -Right now the only way to draw UI and 2D scenes is via sprites and rectangles. Bevy needs an immediate-mode drawing api capable of drawing anti-aliased curves and shapes. This can then be used to do code-driven drawing of things like rounded corners in Bevy UI, performance graphs in the editor, etc. It's very possible that we will integrate projects like [pathfinder](https://github.com/servo/pathfinder) or [lyon](https://github.com/nical/lyon) for this. +Right now the only way to draw UI and 2D scenes is via sprites and rectangles. Bevy needs an immediate-mode drawing API capable of drawing anti-aliased curves and shapes. This can then be used to do code-driven drawing of things like rounded corners in Bevy UI, performance graphs in the editor, etc. It's very possible that we will integrate projects like [pathfinder](https://github.com/servo/pathfinder) or [lyon](https://github.com/nical/lyon) for this. ### Animation diff --git a/content/news/2020-09-19-bevy-0.2/index.md b/content/news/2020-09-19-bevy-0.2/index.md index 8f503408d9..6424a176a4 100644 --- a/content/news/2020-09-19-bevy-0.2/index.md +++ b/content/news/2020-09-19-bevy-0.2/index.md @@ -68,7 +68,7 @@ fn system(pool: Res, mut query: Query<&mut Transform>) { } ``` -This provides a nice functional api (similar to Rayon) that runs on top of the new `bevy_tasks` system. It breaks the query up into 32 "batches" and runs each batch as a different task in the bevy task system. +This provides a nice functional API (similar to Rayon) that runs on top of the new `bevy_tasks` system. It breaks the query up into 32 "batches" and runs each batch as a different task in the bevy task system. ## Transform System Rewrite @@ -97,7 +97,7 @@ However this approach also has some pretty serious downsides: * Very hard to reason about. There are 5 components users need to think about and they all interact with each other differently. * Setting a Transform to a specific matrix value (ex: `Mat4::look_at()`) was extremely cumbersome, and the value would be immediately overwritten unless the user explicitly disabled component syncing. -Given these issues, we decided to move to a single unified local-to-parent `Transform` component as the source of truth, and a computed `GlobalTransform` component for world-space transforms. We think this api will be much easier to use and to reason about. [Unity is also considering a similar Transform rework for their ECS](https://gist.github.com/joeante/79d25ec3a0e86436e53eb74f3ac82c0c) and a lot of discussion on this topic happened in this [Amethyst Forum Thread](https://community.amethyst.rs/t/legion-transform-design-discussion). +Given these issues, we decided to move to a single unified local-to-parent `Transform` component as the source of truth, and a computed `GlobalTransform` component for world-space transforms. We think this API will be much easier to use and to reason about. [Unity is also considering a similar Transform rework for their ECS](https://gist.github.com/joeante/79d25ec3a0e86436e53eb74f3ac82c0c) and a lot of discussion on this topic happened in this [Amethyst Forum Thread](https://community.amethyst.rs/t/legion-transform-design-discussion). ## Joystick/Gamepad Input diff --git a/content/news/2020-11-03-bevy-0.3/index.md b/content/news/2020-11-03-bevy-0.3/index.md index 4dc62674d2..4931ba32b0 100644 --- a/content/news/2020-11-03-bevy-0.3/index.md +++ b/content/news/2020-11-03-bevy-0.3/index.md @@ -148,7 +148,7 @@ let mesh = asset_server.load("my_scene.gltf#Mesh0/Primitive0"); ### AssetIo Trait -The `AssetServer` is now backed by the `AssetIo` trait. This allows us to load assets from whatever storage we want. This means on desktop we now load from the filesystem, on Android we use the Android Asset Manager, and on the web we make HTTP requests using the `fetch()` api. +The `AssetServer` is now backed by the `AssetIo` trait. This allows us to load assets from whatever storage we want. This means on desktop we now load from the filesystem, on Android we use the Android Asset Manager, and on the web we make HTTP requests using the `fetch()` API. ### Asset Dependencies @@ -156,7 +156,7 @@ Assets can now depend on other assets, which will automatically be loaded when t ### Removed AssetServer::load_sync() -This might rustle some feathers, but `AssetServer::load_sync()` had to go! This api wasn't WASM friendly, encouraged users to block game execution for the sake of convenience (which causes "hitching"), and was incompatible with the new AssetLoader api. Asset loading is now always asynchronous. Users of `load_sync()` should instead `load()` their assets, check load status in their systems, and change game state accordingly. +This might rustle some feathers, but `AssetServer::load_sync()` had to go! This API wasn't WASM friendly, encouraged users to block game execution for the sake of convenience (which causes "hitching"), and was incompatible with the new AssetLoader API. Asset loading is now always asynchronous. Users of `load_sync()` should instead `load()` their assets, check load status in their systems, and change game state accordingly. ## GLTF Scene Loader @@ -226,7 +226,7 @@ _Why did this take so long? Why would removing a single `&mut` be hard?_ It's a long story! In summary: -* The old api looked the way it did for a reason. It was the result of good design choices that protect against unsafe memory access in a parallel environment. +* The old API looked the way it did for a reason. It was the result of good design choices that protect against unsafe memory access in a parallel environment. * `query.iter()` didn't actually return an iterator. It returned a _wrapper_ that held an atomic lock on the component storages. The same was true for the type returned by `query.entity()` * Removing these "wrapper types" would have allowed unsafe behavior because another Query could access the same components in a way that violated Rust's mutability rules. * Due to the iterator implementation and quirks in the rust compiler, removing the wrapper type _tanked_ iteration performance by about ~2-3x. @@ -283,7 +283,7 @@ Note: these numbers are for getting a component 100,000 times, not for an indivi This is where the big wins were. By removing locks and safety checks from Query systems, we were able to _significantly_ reduce the cost of retrieving a specific entity's component from within a system. -I included a comparison to [Legion ECS](https://github.com/amethyst/legion) (another great archetypal ECS with a parallel scheduler) to illustrate why Bevy's new approach is so cool. Legion exposes a direct "world like" api (called a SubWorld) in its systems. The SubWorld's entry api _cannot_ know ahead of time what types will be passed into it, which means it _must_ do (relatively) expensive safety checks to ensure the user doesn't request access to something they shouldn't. +I included a comparison to [Legion ECS](https://github.com/amethyst/legion) (another great archetypal ECS with a parallel scheduler) to illustrate why Bevy's new approach is so cool. Legion exposes a direct "world like" API (called a SubWorld) in its systems. The SubWorld's entry API _cannot_ know ahead of time what types will be passed into it, which means it _must_ do (relatively) expensive safety checks to ensure the user doesn't request access to something they shouldn't. Bevy's scheduler pre-checks `Queries` once ahead of time, which allows systems to access their results without any additional checks. @@ -294,7 +294,7 @@ The test was to lookup (and modify) a specific entity's component 100,000 times * legion (world): Direct `World` access using `let entry = world.entry(entity); entry.get_component_mut::()` * legion (system): A system with `SubWorld` access using `let entry = world.entry(entity); entry.get_component_mut::()` -It's worth noting that using `query.get_component::(entity)` instead of `query.get(entity)` does require safety checks, for the same reason the legion entry api does. We cannot know ahead of time what component type a caller will pass into the method, which means we _must_ check it to make sure it matches the `Query`. +It's worth noting that using `query.get_component::(entity)` instead of `query.get(entity)` does require safety checks, for the same reason the legion entry API does. We cannot know ahead of time what component type a caller will pass into the method, which means we _must_ check it to make sure it matches the `Query`. Additionally, here are some relevant [ecs_bench_suite](https://github.com/rust-gamedev/ecs_bench_suite) results (omitted benchmarks had no significant change): @@ -354,17 +354,17 @@ Rendering meshes often involves using vertex "indices" to cut down on duplicate Transforms are important to get right. They are used in many slices of the engine, user code touches them constantly, and they are relatively expensive to compute: especially transform hierarchies. -In the last release, we vastly simplified Bevy's transform system to use a consolidated `Transform` and `GlobalTransform` instead of multiple separate `Translation`, `Rotation`, and `Scale` components (which were synced to `Transform` and `GlobalTransform`). This made the user-facing api/dataflow simpler, as well as the underlying implementation. The `Transform` component was backed by a 4x4 matrix. I pressed the big green "merge" button ... happy that we had solved the Transform problem once and for all! +In the last release, we vastly simplified Bevy's transform system to use a consolidated `Transform` and `GlobalTransform` instead of multiple separate `Translation`, `Rotation`, and `Scale` components (which were synced to `Transform` and `GlobalTransform`). This made the user-facing API/dataflow simpler, as well as the underlying implementation. The `Transform` component was backed by a 4x4 matrix. I pressed the big green "merge" button ... happy that we had solved the Transform problem once and for all! -It turns out there was still more work to be done! [@AThilenius pointed out](https://github.com/bevyengine/bevy/issues/229#issuecomment-698953161) that using a 4x4 matrix as the source of truth for an affine transform accumulates error over time. Additionally, the Transform api was still a little cumbersome to use. [At the suggestion of @termhn](https://github.com/bevyengine/bevy/issues/229#issuecomment-699172675) we decided to investigate using a "similarity" as the source of truth. This had the following benefits: +It turns out there was still more work to be done! [@AThilenius pointed out](https://github.com/bevyengine/bevy/issues/229#issuecomment-698953161) that using a 4x4 matrix as the source of truth for an affine transform accumulates error over time. Additionally, the Transform API was still a little cumbersome to use. [At the suggestion of @termhn](https://github.com/bevyengine/bevy/issues/229#issuecomment-699172675) we decided to investigate using a "similarity" as the source of truth. This had the following benefits: 1. no more error accumulation -2. we could directly expose translation/rotation/scale fields, which simplified the api significantly +2. we could directly expose translation/rotation/scale fields, which simplified the API significantly 3. cheaper to store and cheaper to compute hierarchies in some cases We collectively decided this was a good path forward and now we have a re-rewrite that is even better. Yes this is _another_ breaking change, but thats why we label Bevy as being in the "experimentation phase". Now is the time to break things as often as possible to ensure that we find good apis that will stand the test of time. -This is what the new `Transform` api looks like in a Bevy ECS system: +This is what the new `Transform` API looks like in a Bevy ECS system: ```rust fn system(mut transform: Mut) { @@ -444,7 +444,7 @@ app.add_plugins(HelloWorldPlugins);
authors: @mockersf
-Bevy provides a backend-agnostic windowing api. Up until this point, window settings could only be set once at app startup. If you wanted to set window settings dynamically, you had to directly interact with window backends (ex: winit). +Bevy provides a backend-agnostic windowing API. Up until this point, window settings could only be set once at app startup. If you wanted to set window settings dynamically, you had to directly interact with window backends (ex: winit). In this release we added the ability to dynamically set window properties at runtime using the Bevy window abstraction: diff --git a/content/news/2020-12-19-bevy-0.4/index.md b/content/news/2020-12-19-bevy-0.4/index.md index 0b26cd8ec3..5e6cbac61f 100644 --- a/content/news/2020-12-19-bevy-0.4/index.md +++ b/content/news/2020-12-19-bevy-0.4/index.md @@ -481,7 +481,7 @@ The new text layout system uses glyph_brush_layout, which fixes the layout bugs
authors: @cart
-Bevy's render api was built to be easy to use and extend. I wanted to nail down a good api first, but that resulted in a number of performance TODOs that caused some pretty serious overhead. +Bevy's render API was built to be easy to use and extend. I wanted to nail down a good API first, but that resulted in a number of performance TODOs that caused some pretty serious overhead. For **Bevy 0.4** I decided to resolve as many of those TODOs as I could. There is still plenty more to do (like instancing and batching), but Bevy already performs _much_ better than it did before. @@ -733,7 +733,7 @@ There is still a bit more work to be done here. While Bevy UI renders images and Bevy's Timer component/resource got a number of quality-of-life improvements: pausing, field accessor methods, ergonomics improvements, and internal refactoring / code quality improvements. Timer Components also no longer tick by default. Timer resources and newtyped Timer components couldn't tick by default, so it was a bit inconsistent to have the (relatively uncommon) "unwrapped component Timer" auto-tick. -The timer api now looks like this: +The timer API now looks like this: ```rust diff --git a/content/news/2021-04-06-bevy-0.5/index.md b/content/news/2021-04-06-bevy-0.5/index.md index 2cc8c4e54b..3b424c2951 100644 --- a/content/news/2021-04-06-bevy-0.5/index.md +++ b/content/news/2021-04-06-bevy-0.5/index.md @@ -158,7 +158,7 @@ You may have noticed that **Bevy 0.5 (Table)** is also _way_ faster than **Bevy 3. Incrementally build up state * When new archetypes are added, we only process the new archetypes (no need to rebuild state for old archetypes) -As a result, the direct {{rust_type(type="struct" crate="bevy_ecs" mod="world" version="0.5.0" name="World" no_mod=true)}} query api now looks like this: +As a result, the direct {{rust_type(type="struct" crate="bevy_ecs" mod="world" version="0.5.0" name="World" no_mod=true)}} query API now looks like this: ```rust let mut query = world.query::<(&A, &mut B)>(); @@ -434,7 +434,7 @@ We are also actively seeking feedback on the new executor. We believe that the n Global change detection, the ability to run queries on the Changed/Added status of any ECS component or resource, just got a major usability boost: changes are now detected across frames/updates: ```rust -// This is still the same change detection api we all know and love, +// This is still the same change detection API we all know and love, // the only difference is that it "just works" in every situation. fn system(query: Query>) { // iterates all entities whose A component has changed since @@ -458,7 +458,7 @@ The [last Bevy release](https://bevyengine.org/news/bevy-0-4) added States, whic The old implementation largely worked, but it had a number of quirks and limitations. First and foremost, it required adding a new `StateStage`, which cut down on parallelism, increased boilerplate, and forced ordering where it wasn't required. Additionally, some of the lifecycle events didn't always behave as expected. -The new {{rust_type(type="struct" crate="bevy_ecs" mod="schedule" version="0.5.0" name="State" no_mod=true)}} implementation is built on top of the new parallel executor's SystemSet and RunCriteria features, for a much more natural, flexible, and parallel api that builds on existing concepts instead of creating new ones: +The new {{rust_type(type="struct" crate="bevy_ecs" mod="schedule" version="0.5.0" name="State" no_mod=true)}} implementation is built on top of the new parallel executor's SystemSet and RunCriteria features, for a much more natural, flexible, and parallel API that builds on existing concepts instead of creating new ones: ```rust #[derive(Debug, Clone, Eq, PartialEq, Hash)] @@ -526,7 +526,7 @@ fn system(mut reader: EventReader) { } ``` -There is also now a symmetrical `EventWriter` api: +There is also now a symmetrical `EventWriter` API: ```rust fn system(mut writer: EventWriter) { @@ -551,7 +551,7 @@ Text can now have "sections", each with their own style / formatting. This makes ![rich_text](rich_text.png) -This is accomplished using the new "text section" api: +This is accomplished using the new "text section" API: ```rust commands @@ -767,7 +767,7 @@ This example serves as a quick introduction to building 3D games in Bevy. It sho
authors: @kokounet
-The {{rust_type(type="struct" crate="bevy_core" version="0.5.0" name="Timer" no_mod=true)}} struct now internally uses {{rust_type(type="struct" crate="std" mod="time" name="Duration" no_mod=true)}}s instead of using `f32` representations of seconds. This both increases precision and makes the api a bit nicer to look at. +The {{rust_type(type="struct" crate="bevy_core" version="0.5.0" name="Timer" no_mod=true)}} struct now internally uses {{rust_type(type="struct" crate="std" mod="time" name="Duration" no_mod=true)}}s instead of using `f32` representations of seconds. This both increases precision and makes the API a bit nicer to look at. ```rust fn system(mut timer: ResMut, time: Res| { This temporarily removes the `A` resource from `World`, provides mutable pointers to both, and re-adds A to World when finished. Thanks to the move to ComponentIds/sparse sets, this is a cheap operation. -If multiple resources are required, scopes can be nested. We could also consider adding a "resource tuple" to the api if this pattern becomes common and the boilerplate gets nasty. +If multiple resources are required, scopes can be nested. We could also consider adding a "resource tuple" to the API if this pattern becomes common and the boilerplate gets nasty. ### Query Conflicts Use ComponentId Instead of ArchetypeComponentId @@ -1284,7 +1284,7 @@ A huge thanks to the **88 contributors** that made this release (and associated * [add scene instance entity iteration][1058] * [Make Commands and World apis consistent][1703] * [Add `insert_children` and `push_children` to EntityMut][1728] -* [Extend AppBuilder api with `add_system_set` and similar methods][1453] +* [Extend AppBuilder API with `add_system_set` and similar methods][1453] * [add labels and ordering for transform and parent systems in POST_UPDATE stage][1456] * [Explicit execution order ambiguities API][1469] * [Resolve (most) internal system ambiguities][1606] diff --git a/content/news/2021-08-10-bevys-first-birthday/index.md b/content/news/2021-08-10-bevys-first-birthday/index.md index 53374e395a..3f66a7d90e 100644 --- a/content/news/2021-08-10-bevys-first-birthday/index.md +++ b/content/news/2021-08-10-bevys-first-birthday/index.md @@ -39,7 +39,7 @@ For those who don't know, Bevy is a refreshingly simple data-driven game engine * **December 19**: [Bevy 0.4](/news/bevy-0-4/) * We somehow still managed to keep up the "approximately once a month" release cadence. We added a WebGL2 render backend, cross platform main functions, live shader reloading, flexible ECS parameter orders, simplified query filters, system inputs, outputs, and chaining, a more featureful and flexible ECS schedule implementation, "fixed timesteps", states, gltf improvements, spawning scenes as children, dynamic linking for _drastically_ faster iterative compile times, a new text layout implementation, renderer optimizations, a new rust reflection crate (filling a major gap in the rust ecosystem), 3d texture assets, logging and profiling, hidpi rendering, timer improvements, task system improvements, and apple silicon support. * **April 6**: [Bevy 0.5](/news/bevy-0-5/) - * The almost-one-release-a-month streak finally ended. But thats not because we slowed down our pace! This release was a big one. It added Physically Based Rendering (PBR), GLTF asset improvements, Bevy ECS V2: a complete from-scratch rewrite with a novel archetype/sparse-set hybrid storage model, an "archetype graph" for faster archetype changes, query caching, uber fast for-each iterators, a new system executor with system labels, explicit system ordering/dependencies, system sets, and increased parallelism, "reliable" change detection, and a full rewrite of the State system). We also added a rich text api, hidpi and 2d-world space text, world-to-screen coordinate conversions, a 3d orthographic camera and new scaling modes, flexible camera bindings in shaders, render layers, sprite flipping, color spaces, wireframe rendering, and more smaller tweaks that I don't have room for here. + * The almost-one-release-a-month streak finally ended. But thats not because we slowed down our pace! This release was a big one. It added Physically Based Rendering (PBR), GLTF asset improvements, Bevy ECS V2: a complete from-scratch rewrite with a novel archetype/sparse-set hybrid storage model, an "archetype graph" for faster archetype changes, query caching, uber fast for-each iterators, a new system executor with system labels, explicit system ordering/dependencies, system sets, and increased parallelism, "reliable" change detection, and a full rewrite of the State system). We also added a rich text API, hidpi and 2d-world space text, world-to-screen coordinate conversions, a 3d orthographic camera and new scaling modes, flexible camera bindings in shaders, render layers, sprite flipping, color spaces, wireframe rendering, and more smaller tweaks that I don't have room for here. * **April 14**: [The Bevy RFC process is unveiled](https://github.com/bevyengine/rfcs) * Inspired by the Rust RFC process, we added a way to collaboratively design and review Bevy APIs prior to implementing them. This generally isn't required, but for bigger changes it ensures we think deeply about what we are building, mitigates risk, and encodes designs and intents for future Bevy developers. * **June 1**: [First public release of Bevy Assets](https://twitter.com/BevyEngine/status/1399891316939448320) @@ -171,7 +171,7 @@ Immediately after the initial Bevy release, I [said we needed to focus](https:// * [**Scenes**](https://github.com/bevyengine/bevy/issues/255): better scene format, inline assets, enabling / disabling systems * [**PBR / Clustered Forward Rendering**](https://github.com/bevyengine/bevy/issues/179): PBR shaders, HDR, bloom, shadowing, all using clustered-forward rendering -* [**Editor-Ready UI**](https://github.com/bevyengine/bevy/issues/254): iterate on the current Bevy UI, add a canvas style drawing api, implement core widgets, theme-ability +* [**Editor-Ready UI**](https://github.com/bevyengine/bevy/issues/254): iterate on the current Bevy UI, add a canvas style drawing API, implement core widgets, theme-ability If you have been paying any attention to what we've built over the past year, we clearly _haven't_ focused exclusively on these things, and in some cases chose to go in completely different directions. Here is what we _actually_ focused on (at various points during the year): diff --git a/content/news/2022-01-08-bevy-0.6/index.md b/content/news/2022-01-08-bevy-0.6/index.md index 7632fa62ee..7a9ff60937 100644 --- a/content/news/2022-01-08-bevy-0.6/index.md +++ b/content/news/2022-01-08-bevy-0.6/index.md @@ -135,7 +135,7 @@ However, initially there were a couple of reasons not to make it our "public fac _Almost immediately_ after we voiced these concerns, @kvark kicked off a [relicensing effort](https://github.com/gfx-rs/wgpu/issues/392) that switched wgpu to the Rust-standard dual MIT/Apache-2.0 license. They also removed gfx-hal in favor of a [much simpler and flatter architecture](https://gfx-rs.github.io/2021/08/18/release-0.10.html). Soon after, @zicklag [added a WebGL2 backend](https://github.com/gfx-rs/wgpu/pull/1686). Having resolved all of my remaining hangups, it was clear to me that @kvark's priorities were aligned with mine and that I could trust them to adjust to community feedback. -The New Bevy Renderer tosses out our old intermediate GPU abstraction layer in favor of using wgpu directly as our "low-level" GPU api. The result is a simpler (and faster) architecture with full and direct access to wgpu. Feedback from Bevy Renderer feature developers so far has been _very positive_. +The New Bevy Renderer tosses out our old intermediate GPU abstraction layer in favor of using wgpu directly as our "low-level" GPU API. The result is a simpler (and faster) architecture with full and direct access to wgpu. Feedback from Bevy Renderer feature developers so far has been _very positive_. Bevy was also updated to use the latest and greatest wgpu version: [0.12](https://github.com/gfx-rs/wgpu/blob/master/CHANGELOG.md#wgpu-012-2021-12-18). diff --git a/content/news/2022-04-15-bevy-0.7/index.md b/content/news/2022-04-15-bevy-0.7/index.md index 9b55c4db05..2d4134e223 100644 --- a/content/news/2022-04-15-bevy-0.7/index.md +++ b/content/news/2022-04-15-bevy-0.7/index.md @@ -65,7 +65,7 @@ fn start_dancing(mut query: Query<(&Animations, &mut AnimationPlayer)>) { This critical feature has been a long time coming, but we wanted to build it in a way that meshed nicely with the [new Bevy renderer](/news/bevy-0-6/#the-new-bevy-renderer) and didn't just "hack things in". This builds on our new [Flexible Mesh Vertex Layouts](/news/bevy-0-7/#flexible-mesh-vertex-layouts), [Shader Imports](/news/bevy-0-6/#shader-imports), and [Material](/news/bevy-0-6/#materials) systems, which ensures that this logic is flexible and reusable, even with non-standard meshes and custom render pipelines. -And we're just getting started! Multi-track animation blending and higher level animation state management should arrive in the very near future. Now is a great time to start contributing animation features to Bevy. We've smashed through most of the foundational technical hurdles and what remains is largely high level api design choices. We already have a couple of draft RFCs open in these areas: [Animation Composition](https://github.com/bevyengine/rfcs/pull/51) and [Animation Primitives](https://github.com/bevyengine/rfcs/pull/49). Feel free to join the conversation! +And we're just getting started! Multi-track animation blending and higher level animation state management should arrive in the very near future. Now is a great time to start contributing animation features to Bevy. We've smashed through most of the foundational technical hurdles and what remains is largely high level API design choices. We already have a couple of draft RFCs open in these areas: [Animation Composition](https://github.com/bevyengine/rfcs/pull/51) and [Animation Primitives](https://github.com/bevyengine/rfcs/pull/49). Feel free to join the conversation! [`AnimationPlayer`]: https://docs.rs/bevy/0.7.0/bevy/animation/struct.AnimationPlayer.html [`AnimationClip`]: https://docs.rs/bevy/0.7.0/bevy/animation/struct.AnimationClip.html @@ -970,7 +970,7 @@ A huge thanks to the **123 contributors** that made this release (and associated * [Increment last event count on next instead of iter][2382] * [Obviate the need for `RunSystem`, and remove it][3817] * [Cleanup some things which shouldn't be components][2982] -* [Remove the config api][3633] +* [Remove the config API][3633] * [Deprecate `.system`][3302] * [Hide docs for concrete impls of Fetch, FetchState, and SystemParamState][4250] * [Move the CoreStage::Startup to a seperate StartupSchedule label][2434] diff --git a/content/news/2022-07-30-bevy-0.8/index.md b/content/news/2022-07-30-bevy-0.8/index.md index aaae8c6e54..3c04e0d445 100644 --- a/content/news/2022-07-30-bevy-0.8/index.md +++ b/content/news/2022-07-30-bevy-0.8/index.md @@ -1203,7 +1203,7 @@ Being a "maintainer" now works like this: 1. **Maintainers now have no (hard) limits on the "area" of PRs they can merge**. No more limits on "docs only", "rendering only", etc. It is now each maintainers' responsibility to evaluate their areas of comfort. This does increase risk to an extent, but I think it's an important step to allow maintainers to grow organically. 2. **Maintainers can merge "relatively uncontroversial" PRs with at least two community approvals**. Maintainers will collectively decide and enforce what is uncontroversial. Controversial PRs should be labeled with the `S-Controversial` label. Note that "two community approvals" is the minimum requirement. Maintainers are responsible for ensuring the appropriate people have approved a PR. -3. **Maintainers can merge "completely trivial" PRs without two community approvals**. Some examples of "completely trivial": typo fixes, removing unused dependencies or code, and small "api consistency" fixes. +3. **Maintainers can merge "completely trivial" PRs without two community approvals**. Some examples of "completely trivial": typo fixes, removing unused dependencies or code, and small "API consistency" fixes. 4. **Controversial Decision Making on a Timer**: For all controversial PRs (including RFCs), if two maintainers approve, the PR can be labeled with a `S-Ready-For-Final-Review` label. As soon as this label is added and I have been pinged, a clock starts. If I have not responded with actionable feedback, a "snooze button" / "we aren't ready for this yet", or a veto within a month and a half (45 days), maintainers are free to merge the PR. This gives me the ability to dictate project direction in areas where that is important while also empowering maintainers to move things forward in parallel when that makes sense. We will be calibrating this approach as we go to make sure we strike the right balance between progress, quality, and consistent vision. 5. **I still reserve the right to veto all code changes and make unilateral code changes**. This includes reverting "controversial changes" merged via (4). diff --git a/content/news/2022-08-10-bevys-second-birthday/index.md b/content/news/2022-08-10-bevys-second-birthday/index.md index 857026b727..0b01353619 100644 --- a/content/news/2022-08-10-bevys-second-birthday/index.md +++ b/content/news/2022-08-10-bevys-second-birthday/index.md @@ -178,7 +178,7 @@ For our last birthday, I [made some predictions for the next year](/news/bevys-f * **Break Ground on The Bevy Editor**: We did not break ground on the Bevy Editor. As mentioned above, we _need_ to start prioritizing this work. * **Predicted Scene Improvements**: We did not get support for nested scenes, make the scene format prettier, or add property overloading. We have a new PR for a [prettier scene format](https://github.com/bevyengine/bevy/pull/4561) that builds on all of the Bevy Reflect work we did last year, but we are still reviewing it. * **The New Bevy Book**: We did make progress on the new Bevy Book, but we have not released it yet. -* **Predicted Bevy ECS Features**: We invested heavily in Bevy ECS, but we did not get "reactive ECS" / entity-relationship indexing. The parallel system scheduling api _was_ improved, but we did not make it more granular (ex: "stageless ECS" is nearly ready, but we haven't merged it yet). +* **Predicted Bevy ECS Features**: We invested heavily in Bevy ECS, but we did not get "reactive ECS" / entity-relationship indexing. The parallel system scheduling API _was_ improved, but we did not make it more granular (ex: "stageless ECS" is nearly ready, but we haven't merged it yet). * **Unified Property Animation System**: We did do some design work ([RFC 49](https://github.com/bevyengine/rfcs/pull/49), [RFC 51](https://github.com/bevyengine/rfcs/pull/51)) and there were some proposed implementations ([PR 1429](https://github.com/bevyengine/bevy/pull/1429)), but we have not merged an implementation yet. * **Predicted 2D Features**: We did implement sprite batching and sprite render layers! We didn't meaningfully add tileset workflow improvements (3rd party crates like [bevy_ecs_tilemap](https://github.com/StarArawn/bevy_ecs_tilemap) are often still preferable). And we also didn't add visual editor workflows (because the Bevy Editor doesn't exist yet). * **Predicted 3D Features**: We did implement skeletal animation, configurable / flexible / good looking shadows, and added a few more PBR Material configuration options! We did not add a global illumination implementation (although 3rd party plugins like [bevy-hikari](https://github.com/cryscan/bevy-hikari) now exist). We also didn't add visual editor workflows (again, because the Bevy Editor doesn't exist yet). diff --git a/content/news/2022-11-12-bevy-0.9/index.md b/content/news/2022-11-12-bevy-0.9/index.md index 04c1b159fe..97abac1c0e 100644 --- a/content/news/2022-11-12-bevy-0.9/index.md +++ b/content/news/2022-11-12-bevy-0.9/index.md @@ -897,7 +897,7 @@ if let ReflectOwned::Struct(owned) = value.reflect_owned() { } ``` -Arrays in the "reflection path api" can now use list syntax: +Arrays in the "reflection path API" can now use list syntax: ```rust #[derive(Reflect)] diff --git a/content/news/2023-03-06-bevy-0.10/index.md b/content/news/2023-03-06-bevy-0.10/index.md index d3e493d295..cf04989224 100644 --- a/content/news/2023-03-06-bevy-0.10/index.md +++ b/content/news/2023-03-06-bevy-0.10/index.md @@ -2182,7 +2182,7 @@ Bevy is made by a [large group of people](/community/people/). A huge thanks to * [ECS: Make `Query` fields private][7149] * [ECS: make `ScheduleGraph::initialize` public][7723] * [ECS: Make boxed conditions read-only][7786] -* [ECS: Make RemovedComponents mirror EventReaders api surface][7713] +* [ECS: Make RemovedComponents mirror EventReaders API surface][7713] * [ECS: Mark TableRow and TableId as repr(transparent)][7166] * [ECS: Most APIs returning `&UnsafeCell` now returns `TickCells` instead, which contains two separate `&UnsafeCell` for either component ticks.][6547] * [ECS: Move MainThreadExecutor for stageless migration.][7444] diff --git a/content/news/2023-07-09-bevy-0.11/index.md b/content/news/2023-07-09-bevy-0.11/index.md index ff241b7a4d..203e011942 100644 --- a/content/news/2023-07-09-bevy-0.11/index.md +++ b/content/news/2023-07-09-bevy-0.11/index.md @@ -1497,7 +1497,7 @@ Bevy is made by a [large group of people](/community/people/). A huge thanks to * [Add parallax mapping to bevy PBR][5928] * [Add port of AMD's Robust Contrast Adaptive Sharpening][7422] * [Add RenderGraphApp to simplify adding render nodes][8007] -* [Add screenshot api][7163] +* [Add screenshot API][7163] * [Add morph targets][8158] * [Screenshots in wasm][8455] * [Add ViewNode to simplify render node management][8118] diff --git a/generate-assets/src/github_client.rs b/generate-assets/src/github_client.rs index a9dab80b25..8bca535df8 100644 --- a/generate-assets/src/github_client.rs +++ b/generate-assets/src/github_client.rs @@ -71,7 +71,7 @@ impl GithubClient { } /// Gets the license from a github repo - /// Technically, github supports multiple licenses, but the api only returns one + /// Technically, github supports multiple licenses, but the API only returns one #[allow(unused)] pub fn get_license(&self, username: &str, repository_name: &str) -> anyhow::Result { let response: GithubLicenseResponse = self diff --git a/generate-release/src/github_client.rs b/generate-release/src/github_client.rs index fba7ce953b..848ab3febe 100644 --- a/generate-release/src/github_client.rs +++ b/generate-release/src/github_client.rs @@ -175,7 +175,7 @@ impl GithubClient { let mut prs = vec![]; let mut page = 1; - // The github rest api is limited to 100 prs per page, + // The github rest API is limited to 100 prs per page, // so to get all the prs we need to iterate on every page available. loop { let mut prs_in_page = self.get_merged_prs_by_page(since, page, label)?; diff --git a/templates/index.html b/templates/index.html index 8efb9033d4..8b669ef5fd 100644 --- a/templates/index.html +++ b/templates/index.html @@ -80,7 +80,7 @@

Render Graph

  • Parallel: Render Graphs are automatically rendered in parallel
  • Modular: Build composable and reusable render logic using Render Graph nodes
    • -
  • Backend Agnostic: Not tied to a specific graphics api
    • +
  • Backend Agnostic: Not tied to a specific graphics API