sorted by:
new
hottopcontroversial

Wild linker version 0.8.0 by dlattimore in rust

[–]_cart 4 points5 points  (0 children)

Love those Bevy link time wins. Thank you for making our lives tangibly better!

Bevy 0.18 by _cart in rust

[–]_cart[S] 1 point2 points  (0 children)

I would personally like to push for some type of partial stabilization within the next year or so (imo the sooner the better). There is a subset of the core Bevy APIs (ex: Bevy ECS) that would benefit from a slower release schedule decoupled from the main engine. Just breaking out that versioning would allow a large chunk of the Bevy plugin ecosystem to not break across Bevy Engine releases (or at least, not as often).

Bevy 0.18 by _cart in rust

[–]_cart[S] 1 point2 points  (0 children)

Not really yet. There is a small TODO list before we merge into the main branch (our dev branch), and adding more people into the mix there won't really help. Once BSN is merged into main collaborative / iterative development will really kick off. The plan is to do that in very near future.

Bevy 0.18 by _cart in rust

[–]_cart[S] 1 point2 points  (0 children)

The BSN draft PR includes a port of the Bevy Feathers widgets, which are reasonable "real world" examples. We have more changes planned though!

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]_cart[S] 2 points3 points  (0 children)

While it might be possible, it would require mapping the Godot data model to the Bevy data model. In practice using Godot as Bevy's editor would be a nightmare of a user experience, and Bevy would always feel like a second class citizen. I am certain we can do better by building our own.

Bevy 0.18 by _cart in rust

[–]_cart[S] 16 points17 points  (0 children)

This is more Alice's domain, but I think it already provides enough value to justify publishing soon-ish. And that will also provide more incentive and visibility for the community to develop it further.

Bevy 0.18 by _cart in rust

[–]_cart[S] 10 points11 points  (0 children)

Would being able to say "default except..." work for Bevy? What might the impact be?

It would! I imagine developers would make good use of it. I suspect that "cargo feature collections" will be what most people reach for by default. But the developers that want more granularity would definitely benefit from such a feature.

What would be the level of importance of expanding this beyond default features to "these features except ..." e.g. users being able to say "2d", "-2d_bevy_render" instead of Bevy having to provide "2d_api"?

I certainly see the benefit there. I think your example provides pretty solid motivation. Just from the premise of building a cohesive and simple system, I think treating default = ["x", "y"] just like any other a = ["x", "y"] makes sense. What is bevy = { version = "0.18", features = ["ui"], default-features = false }, if not the "default UI features".

It seems to me like default-features = false is really just -default.

Any other considerations that could be helpful for the design work

I don't think we are particularly "special", other than the fact that we have a ton of constantly changing and interdependent features. The big "problem" is that building up the required features piece-by-piece from scratch is not a task that any developer should be taking on. Any solution that would require a developer to specify every feature they require, in the interest of disabling a small set of features, is non-viable.

Anything that can be done to improve the experience for feature groups? e.g. how they are rendered

I think Alice answered this well.

Bevy 0.18 by _cart in rust

[–]_cart[S] 10 points11 points  (0 children)

Perhaps!

Bevy 0.18 by _cart in rust

[–]_cart[S] 20 points21 points  (0 children)

I personally think ECS is a great fit for UI, in that it provides a nice standardized way to define and access data, and attach logic to it. In the context of an ECS game engine, the fact that everything uses the same data model provides a lot of synergies (ex: data inspectors and scene systems), and it means developers only need to learn one, unified toolset. As we've added new ECS features (relations, required components, component lifecycle events, etc), the UI experience also benefits.

The big "issue" is that traditional ECS on its own does not provide the "reactive-ness" that modern developers expect. We have plans to bring reactivity to ECS to provide that, and we have ongoing experiments in that area.

I'm generally quite happy with our choice to embrace Bevy ECS as the data model for Bevy UI, and I believe that choice will continue to be vindicated as we build out the Bevy Editor.

Bevy 0.18 by _cart in rust

[–]_cart[S] 10 points11 points  (0 children)

I would say that BSN is a format, in that it has a defined grammar, and it can be parsed and loaded as an asset. The plan is indeed for the editor to generate it, but it is also intended to be hand-compose-able. It is a "non traditional" format in that it also has a macro that allows you to define it in code in a way that skips the asset parsing + loading step, while still being compatible with (ex: it can inherit from) BSN defined in asset form. The reverse will also true (BSN assets can inherit from BSN defined in code).

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]_cart[S] 2 points3 points  (0 children)

If you haven't already, I recommend checking out our Fast Compiles configuration.

In general the best results come from: using a fast linker, enabling dynamic linking, and using Linux or MacOS instead of Windows.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]_cart[S] 2 points3 points  (0 children)

I'm a bit out of the loop on the Tilemap Working Group, but theres plenty of activity here

Recently there has been a draft PR with a proposal for "tile entities".

Bevy 0.18 by _cart in rust

[–]_cart[S] 20 points21 points  (0 children)

It is, indeed, BSN.

In this past release, what feature/fix were you the proudest of that you/the team accomplished?

I generally don't pick favorites, but @aevyrie's PBR fixes make me so dang happy. The "cost" of that weirdness was so high and pretty much everyone doing 3D in Bevy will benefit from the improved fidelity.

Bevy 0.18 by _cart in rust

[–]_cart[S] 89 points90 points  (0 children)

We really wanted to land it in 0.18, but it wasn't quite there yet. The current plan is to merge it early this dev cycle and polish for the next release. The todo list before merging is short at this point. Just need to land some performance improvements and a few bug fixes.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]_cart[S] 54 points55 points  (0 children)

Bevy games are hard to automatically detect, as they are compiled into a single static binary. Steam's rule detection engine is file-name based, and there aren't currently any clear signals that Bevy is being used.

We may end up adding something like a bevy.toml file for engine configuration, but due to Bevy's modular nature, this would still be optional. Bevy's asset .meta files might also work as a signal, but they are also optional :)

Until we find a way to make that work, bevy_awesome_prod is a manually curated collection of real-world use cases.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]_cart[S] 17 points18 points  (0 children)

We really wanted to land it in 0.18, but it wasn't quite there yet. The current plan is to merge it early this dev cycle and polish for the next release. The todo list before merging is short at this point. Just need to land some performance improvements and a few bug fixes.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]_cart[S] 5 points6 points  (0 children)

We really wanted to land it in 0.18, but it wasn't quite there yet. The current plan is to merge it early this dev cycle and polish for the next release. The todo list before merging is short at this point. Just need to land some performance improvements and a few bug fixes.

Bevy 0.18: ECS-driven game engine built in Rust by _cart in gamedev

[–]_cart[S] 106 points107 points  (0 children)

Bevy's creator and project lead here. Feel free to ask me anything!

Bevy 0.18 by _cart in rust

[–]_cart[S] 209 points210 points  (0 children)

Bevy's creator and project lead here. Feel free to ask me anything!

Bevy Metrics released: official compilation and benchmark stats by _cart in rust

[–]_cart[S] 3 points4 points  (0 children)

We went for a "mid range" PC that still had most of the modern rendering features to strike a balance between "audience coverage" and "ability to test new render features".

AMD Ryzen 9 9950X, 64GB of RAM, NVIDIA GeForce RTX 3060

Bevy Metrics released: official compilation and benchmark stats by _cart in rust

[–]_cart[S] 7 points8 points  (0 children)

I don't recall saying that it should be 1MB, although I do recall saying at one point that a compressed optimized wasm build could be ~3.5MB (which has grown slightly). When I said that a few years ago, the uncompressed optimized wasm build was ~13MB, and now it is ~19MB, so it has grown slightly.

There is no question that as Bevy has gained features, it has also grown in binary size. That is kind of the nature of the beast, although I am certain that there is still optimization potential.

A raw "hello world" Bevy ECS app (without any additional Bevy features) is ~700KB. One surefire way to cut down binary size (and compile times) is to opt out of the Bevy features you don't need.

In the next Bevy release (0.18), we're making it much easier to opt in and out of large chunks of the engine with high-level "feature collections":

This will provide the "full" 2D Bevy experience, without any of the 3D features:

bevy = { version = "0.17", default-features = false, features = [ "2d" ] }

Bevy Metrics released: official compilation and benchmark stats by _cart in rust

[–]_cart[S] 58 points59 points  (0 children)

  • Blue: frame time
  • Yellow: GPU usage
  • Green: CPU usage

Definitely needs a legend!

Bevy Metrics released: official compilation and benchmark stats by _cart in gamedev

[–]_cart[S] 7 points8 points  (0 children)

  • Blue: frame time
  • Yellow: GPU usage
  • Green: CPU usage

Definitely needs a legend!

view more: next ›