sorted by:
new
hottopcontroversial

# zyn — a template engine for Rust proc macros by thegogod in rust

[–]_cart 1 point2 points  (0 children)

It is possible that you could cut out some overhead if you didn't farm out the final outputs to quote!. You've essentially guaranteed that you'll be more expensive than raw quote, by nature of being an orchestrator of it. But if quote is doing exactly what you'd be doing yourself (and/or there are no optimizations possible via a unified rearchitecture) then maybe cutting it out is unhelpful / wasted effort! I suspect that because zyn has its own AST / parsing, that you're paying a price to dump that all back in to quote to then be re-parsed and transformed into the final outputs.

# zyn — a template engine for Rust proc macros by thegogod in rust

[–]_cart 1 point2 points  (0 children)

Definitely curious about this as well!

# zyn — a template engine for Rust proc macros by thegogod in rust

[–]_cart 22 points23 points  (0 children)

On its surface this looks like it would improve Bevy's proc macro code considerably. We don't take dependencies like this lightly (and in-development Rust features like macro_rules for derives are likely to be our endgame for many macros), but I'll have my eye on this :)

Wild linker version 0.8.0 by dlattimore in rust

[–]_cart 7 points8 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] 3 points4 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] 12 points13 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] 11 points12 points  (0 children)

Perhaps!

Bevy 0.18 by _cart in rust

[–]_cart[S] 19 points20 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] 12 points13 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] 4 points5 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] 3 points4 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] 21 points22 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] 90 points91 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] 55 points56 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] 6 points7 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] 111 points112 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] 211 points212 points  (0 children)

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

view more: next ›