bevy_new_2d

[tacit verge]

thoughts?

i don't even know if "target-specific rustflags are cumulative already" means they merge with env.RUSTFLAGS or if they only merge with other target-specific rustflags

[finite depot]

Oof this is all horrible

Especially considering that getting it wrong means silently nuking all of a user's rustflags

[tacit verge]

or a user's rustflags nuking ours 😄

[finite depot]

[tacit verge]

i really hope this does merge with environment

if it does, then we can probably get away with just moving config_fast_builds to config

if it doesn't, we'll have to add some documentation too....

[finite depot]

Could also patch the dependency to bushRAT's fork

Which has an escape hatch to set it for downstream users

[tacit verge]

too nuclear rn without a guarantee this is the approach bevy will want to take imo

[finite depot]

Fair

[tacit verge]

but it's on the table for sure

[finite depot]

Sounds good

[tacit verge]

ah it doesn't merge with environment 😄 hahahaha

i added --config.toml (invalid arg) to my rustflags in config.toml

[finite depot]

[tacit verge]

cargo run gives an error pointing at the invalid arg

RUSTFLAGS='' cargo run compiles happily

[finite depot]

So this would work, right?

[tacit verge]

what would work?

config.toml?

we'd have to avoid setting RUSTFLAGS in ci/cd and tell the user not to set RUSTFLAGS, in addition to moving config_fast_builds.toml to config.toml

[finite depot]

Yeah, the CI would need to use a ci_config.toml again

And overwrite the user's config.toml as a step

Dunno if that is too unexpected though

[tacit verge]

ci can still use the same config.toml as the user

both the user and ci need the rustflag setup

[finite depot]

How do we set the nightly flags then?

[tacit verge]

:')

[finite depot]

😄

[tacit verge]

replace user with ci

[finite depot]

I hate this so much, why can’t the getrandom people just be normal

[tacit verge]

did they even comment on the upstream RUSTFLAGS merging issue that this seems to be in protest of?

before doing this

well this seems to be in protest of both the RUSTFLAGS merging issue and something about wasm32-unknown-unknown being a bad target

[finite depot]

Their main protest is against the "abuse of the wasm32-unknown-unknown target"

[finite depot]

Ye it doesn’t tell you if JS is available

[tacit verge]

@violet osprey please save us

[finite depot]

So in theory, you cannot make ANY assumptions about that as a library

[violet osprey]

You need to set the RUSTFLAG and getrandom/wasm_js

[violet osprey]

I'm trying haha

[finite depot]

The end user is the only one who knows for sure, so getrandom forces them to set it

[finite depot]

Obligatory

[tacit verge]

our current issue is we're a template, so we want to fix this issue for the user, but that requires setting the rustflags in config.toml and not setting RUSTFLAGS in ci/cd, and warning the user not to set RUSTFLAGS

and config.toml is meant to be a place for the user's custom configuration like nightly flags etc., but we want to use the config.toml in ci/cd as well to fix the getrandom issue, but we don't want to pick up the user's configs

[violet osprey]

Any RUSTFLAGS you set in a library's config.toml will only apply to the examples/tests/etc.

[violet osprey]

Oof this sounds like an awful problem you're trying to solve that I absolutely do not envy

[tacit verge]

we might have to do config.toml + config_ci.toml for user vs ci configs, and then we have to hash the config_ci.toml file to prefix the cache key, and warn the user not to touch RUSTFLAGS

[finite depot]

Yeah @tacit verge I think the only way I see right now is pre-providing a config.toml and then swapping it with another one in CI
Which sucks because it silently disables global -Z flags in ~/.cargo/config.toml

[tacit verge]

oh yeah it does that too lol

docs/getrandom.md incoming

okay low key i think using the fork sounds less intrusive at this point until this is fixed somewhere upstream

[finite depot]

Agreed

@violet osprey is that viable?

Can we count on you not deleting your fork / branch that has a workaround?

Or do we fork your fork

Or do we hold a poll in #math-dev to fuel the drama?

😄

[tacit verge]

if we end up using the fork i'll probably comment on the getrandom issue explaining why this is our best option

[violet osprey]

The problem is dependencies like uuid won't be using the fork until the revolution is done lol.

[tacit verge]

even if we [patch]?

[violet osprey]

Oh yeah that'd work

Aside from the obvious horrors

[finite depot]

Please do, cart asked to non-aggressively tell them that a fork is mayyybe on the table

[violet osprey]

Yeah this is probably the most aggressive solution here haha

[finite depot]

So us already requiring it for this specific project may be a way to get the foot in the door

[violet osprey]

"I'd rather tell users to add a [patch.getrandom] entry to their existing Cargo.toml than explain the creation of config.toml and what a RUSTFLAGS is"

[finite depot]

https://youtu.be/jmaUIyvy8E8?si=d4tyqSJ4FB_E4LTA

[tacit verge]

we don't even have to tell users to add it, we're a template so our options are: 1. fix the issue for users automatically with a patch, or 2. add a ton of complexity and explain how to navigate this issue to the user

[finite depot]

Do I look like a know what a getrandom is? I just want a build of a god dang web game

[violet osprey]

I wonder, can you do target patches?

Like, a patch for a specific target?

[finite depot]

Good question

[tacit verge]

i would be surprised, but also i think it's fine to patch to your fork for native as well

we would only be enabling the feature for web builds anyways

[violet osprey]

True. It also looks like you can patch as a CLI argument if this is a problem specific to CI?

--config 'patch.crates-io.getrabdom.path="..."' is apparently a thing lol

[tacit verge]

fixing it only for CI can be done by setting env.RUSTFLAGS because that has the highest priority, fixing it for user builds as well is the hard part

[violet osprey]

Ahh ok

[finite depot]

We'd like to still be able to say "just use bevy run web and everything works out of the box"

[tacit verge]

yeah so without the patch, bevy run web would have to somehow enable the feature and the rustflags

with the latter being the hard part

with the patch it only has to enable the feature which is easy

[finite depot]

@tacit verge I'm gonna go to bed now, so feel free to merge the patch without an approval so that users don’t get broken builds

[tacit verge]

i'm gonna be a tyrant

the prs will continue until morale improves

[finite depot]

[tacit verge]

ok i published my manifesto: https://github.com/rust-random/getrandom/issues/671#issuecomment-2910818591

[tacit verge]

so @violet osprey, patching to your fork and enabling wasm_js when compiling to wasm32-unknown-unknown would look like this?

[target.wasm32-unknown-unknown.dependencies]
getrandom = { version = "0.3", features = ["wasm_js"] }

[patch.crates-io]
getrandom = { git = "https://github.com/bushrat011899/getrandom", branch = "custom_fallback" }

or do i need to enable the custom-fallback feature too

[violet osprey]

So to appease the getrandom maintainers I didn't change how wasm_js actually works. What you need to do now is take the wasm_js implementation they provide and expose it as a custom backend. This can just be another crate in the dependencies.

[target.wasm32-unknown-unknown.dependencies]
getrandom = { version = "0.3", features = ["custom-fallback"] }
my_wasm_js_implementation_of_getrandom = { ... }

[patch.crates-io]
getrandom = { git = "https://github.com/bushrat011899/getrandom", branch = "custom_fallback" }

If we really wanted to fork hard we'd also change how wasm_js works

But my fork is the "this might actually merge" level of tiny change

[tacit verge]

so is there an existing crate for my_wasm_js_... or i have to publish one?

[violet osprey]

You'd have to publish one sorry. Alternatively, you could just fork getrandom yourself and remove the compile_error check on the wasm_js RUSTFLAG check

diff --git a/src/backends.rs b/src/backends.rs
index dbe9345..e1079ec 100644
--- a/src/backends.rs
+++ b/src/backends.rs
@@ -25,19 +25,9 @@ cfg_if! {
     } else if #[cfg(getrandom_backend = "efi_rng")] {     
         mod efi_rng;
         pub use efi_rng::*;
-    } else if #[cfg(all(getrandom_backend = "wasm_js"))] {
-        cfg_if! {
-            if #[cfg(feature = "wasm_js")] {
-                mod wasm_js;
-                pub use wasm_js::*;
-            } else {
-                compile_error!(concat!(
-                    "The \"wasm_js\" backend requires the `wasm_js` feature \
-                    for `getrandom`. For more information see: \
-                    https://docs.rs/getrandom/", env!("CARGO_PKG_VERSION"), "/#webassembly-support"
-                ));
-            }
-        }
+    } else if #[cfg(feature = "wasm_js")] {
+        mod wasm_js;
+        pub use wasm_js::*;
     } else if #[cfg(getrandom_backend = "unsupported")] {
         mod unsupported;
         pub use unsupported::*;

[tacit verge]

i don't get why they can't just have wasm_js feature alone enable the backend, and then require exactly 1 backend feature enabled or a compile error is thrown

do they assume the backend based on target for every other target?

if so they could use that setup only for wasm32-unknown-unknown

[violet osprey]

They had this idea in the development cycle from 0.2 to 0.3 that they could remove all backend feature flags and just use target to determine what backend to use. But then they realised that wouldn't work for Wasm + Web, and it wouldn't let you override it for special platforms, so they added custom and wasm_js features, but then got complaints that libraries would just unconditionally enable wasm_js on wasm32-unknown-unknown

So now they have the RUSTFLAGS solution

[tacit verge]

wait so what was wrong with the previous approach in 0.2?

and why not keep the 0.2 approach for wasm32-unknown-unknown only

or.. could they not use a custom environment variable like GETRANDOM_BACKEND instead of co-opting RUSTFLAGS?

[violet osprey]

The two problems they decided to solve were:

1. They wanted to ban libraries from choosing the backend implementation (bad IMO, HAL crates like agb should be able to choose it for the user)
2. They wanted no features for backends, since they want to be included in std in the future, and that would require the crate to "just work"

[violet osprey]

I'm guessing they couldn't control optional dependencies with ENV?

[tacit verge]

lmao there's no way getrandom is being included in std while requiring rustflags

like that's not better than requiring features

although currently it requires features and rustflags

[violet osprey]

Yeah I think the RUSTFLAGS idea is "well let's force Rust to solve this issue by making ergonomics bad"

If they're bad enough, surely it'll force the community to come up with a better solution

[tacit verge]

hm they don't use the cfg in their Cargo.toml though

it's only in .rs files where you could access env instead

they wouldn't be able to use an env variable in #[cfg] to fully compile things out / in though

[violet osprey]

Oh I think it's because a library could modify env via build.rs but it couldn't modify RUSTFLAGS

I think

[tacit verge]

really? RUSTFLAGS is an env variable too

is there some special-casing?

[violet osprey]

Once you start compiling I think rustc and cargo lock it down specially

[tacit verge]

imo they should have just taken this as evidence that getrandom is not yet fit for std and accepted it

whether that's rust's fault or getrandom's is irrelevant

[violet osprey]

Yeah part of the problem is this was a rushed decision too. Rand 0.9 was about to release, and the choice was either use this RUSTFLAGS option, or Rand 0.9 would depend on getrandom 0.2, kicking the problem down the road for another year+

[tacit verge]

https://laughingsquid.com/wp-content/uploads/2016/11/different.png?resize=750,322

[violet osprey]

So instead of taking more time it looks like they rushed into a new API (also largely shaped by a handful of Wasm non-web users who complained about libraries being hard to use)

Most of the web users had no idea this change was happening and thus couldn't proportionately voice their concerns

[tacit verge]

ok i think i'm going to make my own fork that just rips out the compilation error with no other changes and call it good for the jam

[violet osprey]

I think that's for the best tbh

[tacit verge]

as in your suggestion

[finite depot]

When I commented something similar they were like "lol go lobby harder for additive rustflags in cargo"

Ah, thanks for pointing out that we needed to fork!

[normal shale]

So does rustflags not merge at all or does only the env one not merge with the cargo.config one?
Would it help if the CLI didn't use the env but injected it via --config? I think we already have an issue for that

[violet osprey]

I think certain ways of specifying flags can merge, but it seems more like an API inconsistency than intended functionality

[finite depot]

Context: https://github.com/rust-lang/cargo/issues/5376#issuecomment-2163350032

(click to see hack)

[tacit verge]

ok i got the fork+patch confirmed working in my template and updated the pr https://github.com/TheBevyFlock/bevy_new_2d/pull/423

[finite depot]

Nice!

[tranquil breach]

@tacit verge I noticed how you said the linter was the biggest bottleneck at the present. What’s your thoughts on skipping binstall and simply shipping a tarball with all the files needed?

The linter action can worry about downloading the tarball and moving the files to the correct places

[finite depot]

Times ^

[finite depot]

Who would provide the tarball? The CLI repo on releases?

[viral blaze]

With the Bevy CLI which comes with bevy_new_2d, how can I specify the WGPU backend. I am trying to include bevy_hanabi in my project but the web build fails.
Bevy Hanabi documents it here but I am not sure how to pass this setting to the CLI

[finite depot]

No need for special CLI args, it’s just a cargo feature 🙂

[finite depot]

specifically, --features "bevy/webgpu" if you want to try it only once

Otherwise, add it to your default features in Cargo.toml

[finite depot]

Also, there was a short window of time yesterday where the release build of the template was broken. Ping me if your error message says something about "rustflags", "getrandom", or "wasm_js" 😉

[finite depot]

@foggy relic Hmm, I would prefer to have it "just work" in time for the jam. There's AFAIK no technical downside to adding the patch, and it's very easy to accidentally pull in a dependency that will give you a really intimidating error message if you're new. I also don't see how documenting this as the "blessed" fix instead of what getrandom wants and tells you to do is any less endorsement than putting it in Cargo.toml by default. Also, isn't it really janky to tell the user "Please remember, if you run into this really weird issue, please add a magic incantation to your Cargo.toml"?

There's also some wiggle room in the optics department regarding where the fork is located

Currently it's @tacit verge's fork. If it was a fork in TheBevyFlock, it would be more endorsed imo

If you disagree, we will defer to your judgement of course 🙂

Would also like @trim zealot's opinion on this, as I think you have a good grasp on what new users find scary or confusing

(tell me if you need more context)

[viral blaze]

Thanks, yea actually that's all I had to do. I have another issue where Hanabi won't work together with my Serde library for some reason on web, but that's a separate issue.

[finite depot]

glad I could help 😄

[tacit verge]

yeah that would be great as well, it doesn't have to be binstall, if the github action can install without compiling from source then that's problem solved

[foggy relic]

Do users run into this just building the template / making a game from scratch?

Or only when they pull in an extra crate?

[finite depot]

Only when pulling in a crate

[foggy relic]

I'd much rather add basic RNG support to the template with the right versions of rand / getrand to avoid 90% of the issues

I really hate the getrandom situation, but I don't want to escalate quickly

[finite depot]

But the issue comes up when a transient dependency uses the new getrandom, that's the mean part of it :/
For example, bevy_seedling used to accidentally pull in rand v0.9, so a user depending on bevy_seedling would run into this issue when doing their first web build

[foggy relic]

I mean yeah, this is terrible

But if 90% of the users aren't going to hit it, I'd rather play it safe

Most jam users are going to pull in only a few dependencies

And we've checked the most common ones

If we add rand itself with a comment to the issue thread explaining why we're using an old version, I think that's enough

I know that this is only quasi-official, but the getrandom maintainers and the Rust community more broadly aren't going to distinguish between "Bevy community" and "Bevy itself"

Especially when I've been very vocal about what a dumb idea I think their move is

[finite depot]

I still disagree, but I see that the situation is delicate and that we don't want to antagonize anyone.
If you came to the conclusion that this is better, I'll trust you 🙂
Were should we put the link to the fork? Inside the Cargo.toml in a comment? Inside the readme.md that is generated for the user? Inside our readme that you need to hop onto GitHub to look at?

Or should we not mention the fork at all?

Also ping @tacit verge

[foggy relic]

In the Cargo.toml commented out please!

Then folks can decide to uncomment it for a simple fix

[tacit verge]

#1278871953721262090 message

[finite depot]

Something like

# We recommend using rand 0.8 instead of 0.9 because of https://github.com/rust-random/getrandom/issues/671
# If a dependency accidentally pulls in 0.9 and you get an error message about "getrandom", you can either 
# - follow the instructions in the error message and change your rustflags locally and in the ci workflow or
# - put the following at the bottom of this file: 
# [patch.crates-io]
# getrandom = { git = "https://github.com/benfrankel/getrandom" }
rand = 0.8

?

[trim zealot]

using an arbitrary git repo url for a fork definitely falls under "scary for new users". Endorsing a fork feels fraught as the situation is developing. I don't have any good suggestions that haven't already been explored I think. Documenting the fork's changes would be good.

[tacit verge]

i don't remember if getrandom fails to compile if you don't include the wasm_js feature or cfg. let me try compiling rq EDIT: it fails to compile

[finite depot]

@trim zealot I assume you would document that in the fork's readme, not in the commented Cargo.toml, right?
@foggy relic I assume putting the fork in TheBevyFlock would not be a good move, right?

[tacit verge]

ok this does fail to compile

so if getrandom 0.3 gets pulled into your web build, it'll fail at least

[trim zealot]

As a personal use-case, I probably would avoid the fork in general either way; it can't be official enough to be endorsed and it being unofficial makes it "some random person's" fork (from an uninformed user perspective), but the comment would then be the only thing I read so I'd say the comment has to include it. I had to make these decisions for workshops very recently and decided to stay back on 0.8. Is there a reason we need to support 0.9? Bevy itself is on 0.8 so it seems pretty ok to say we're 0.8 compatible as an ecosystem in general.

[finite depot]

No, we don't need to support it at all. This is just to avoid footguns because @tacit verge and I have both experienced pulling in community crates that accidentally pulled in getrandom 0.3, which surprisingly broke our builds

[trim zealot]

was that more than bevy_seedling?

[finite depot]

Yep, though I would have to bisect to tell you which crate

Point is, I'm a fairly experienced Rust dev and it took me an annoying amount of trial and error to get to a setup where getrandom is happy and my personal rustflags and the CI's rustflags were not nuked

If there's a oneliner to avoid that completely, I'd like to at least advertise it

[tacit verge]

it took me about a day to figure it out

[finite depot]

Note that not only Bevy community crates are at risk, but pulling in any Rust crate that uses rand 0.9 will break web builds

[tacit verge]

if you don't know about rustflags overwriting (which i did not), it's super cryptic

i'm personally fine with commenting out the patch with an explanation above it, i just expect some teams will lose time to this during the jam with that approach

if that's the tradeoff we prefer

[trim zealot]

I imagine we'll end up with "hey I'm getting this weird compile error" either way and want a documented place to point people to fix it

[coarse linden]

i know it's not nearly a proactive suggestion for new users to get steering towards "how do I resolve it", but I will point out that if you don't think a template should steer people to cargo-deny, there is a builtin clippy lint for multiple_crate_versions that could be set to deny or warn in cargo.toml. it would at least surface stuff fast and loud, so something to think about.

(immediate issue is that the bevy deep tree already has a bunch of dupes)

[tacit verge]

yeah i was gonna say

and it should be ok for a binary crate to pull in multiple versions of the same dep, including getrandom if you set up the workaround

is this too much explanation to put inline in Cargo.toml?

# Tell `getrandom v0.3+` to use the `wasm_js` backend on Wasm.
# See: <https://docs.rs/getrandom/0.3.3/getrandom/#webassembly-support>.
#[target.wasm32-unknown-unknown.dependencies]
#getrandom = { version = "0.3", features = ["wasm_js"] }
# In addition to enabling the `wasm_js` feature, you need to add
# `--cfg 'getrandom_backend="wasm_js"'` to your rustflags for both local and
# CI/CD web builds, taking into account that rustflags specified in multiple
# places are NOT combined (<https://github.com/rust-lang/cargo/issues/5376>).
# Alternatively, you can enable this patch to remove the rustflags check:
#[patch.crates-io]
#getrandom = { git = "https://github.com/benfrankel/getrandom" }

[finite depot]

This doesn't tell users when to do this

[tacit verge]

true i missed that

[coarse linden]

this was ~everything I had to worry about cargo-deny tripping over in an empty project with only bevy 0.16, log, rand, tracing, and without even looking at wasm support https://gist.github.com/shanesveller/850392bc5f764ecc1ac21ce1b18db4d1

I fully understand and appreciate why a jam-oriented template would do so but I think a lot of the new_2d content really highlights how explicit wasm support brings in a tremendous amount of incidental complexity that isn't inherent to working with bevy 😕

the getrandom rake-to-step-on is just a recent example

[tacit verge]

# Your web builds will start failing if you add a dependency that pulls in `getrandom` v0.3+.
# To fix this, you should tell `getrandom` to use the `wasm_js` backend on Wasm.
# See: <https://docs.rs/getrandom/0.3.3/getrandom/#webassembly-support>.
#[target.wasm32-unknown-unknown.dependencies]
#getrandom = { version = "0.3", features = ["wasm_js"] }
# In addition to enabling the `wasm_js` feature, you need to include `--cfg 'getrandom_backend="wasm_js"'`
# in your rustflags for both local and CI/CD web builds, taking into account that rustflags specified in
# multiple places are NOT combined (see <https://github.com/rust-lang/cargo/issues/5376>).
# Alternatively, you can opt out of the rustflags check with this patch:
#[patch.crates-io]
#getrandom = { git = "https://github.com/benfrankel/getrandom" }

ok honestly i don't feel like spending more time thinking about getrandom, i'd rather move on with my life etc. so i'm going to make a pr for this

if there's an issue with it, please pr bevy_new_2d

https://github.com/TheBevyFlock/bevy_new_2d/pull/424

[foggy relic]

Thanks ❤️

[finite depot]

Thanks @tacit verge 🙂
Btw do you need any help with the pause menu stuff?

If it's too much in the short time left it's also completely fine to leave it out imo

[tacit verge]

should be good on implementation, just took a little break

the pr is ready and needs review now: https://github.com/TheBevyFlock/bevy_new_2d/pull/425

[finite depot]

done

[tacit verge]

responded now

[finite depot]

approved 🙂

We could also move the Z indices into consts

But that's not blocking

Good idea re: moving the pause stuff into main. Fits nicely!

[finite depot]

@trim zealot I think if we merge this PR later today, we're ready for the video 🙂

Except if you see anything that you would definitely change before

[trim zealot]

sweet

now is probably a bit late to be giving that kind of feedback but I'll shout if I see anything

[finite depot]

Yeah sorry we weren’t done earlier 😅

[trim zealot]

oh that's not really what I meant 😅

[finite depot]

Oh, I see!

[trim zealot]

just that if I wanted to give that sort of feedback it should've been earlier in the process

[finite depot]

Gotcha, that’s very considerate of you 🙂

I also still want to change the readme of the hotpatching crate to explain what a hotpatch is

I think I addressed all of your on-stream feedback there otherwise, right?

[trim zealot]

yeah I think that was being forwarded in real time, so I didn't file anything afterwards or whatnot

also my general feeling is "this is experimental; be warned" on hotpatch, so no worries on it missing stuff

promoting it as generally usable now would probably harm it more than help it. I'll let people know it exists and that they can try it if they've built bevy apps before.

but otherwise I don't plan on saying like "go use this its ready for production!" or whatnot

[finite depot]

Yeah my thoughts exactly

I think I'm quite happy with the API that just allows you to slap a #[hot] on a system and that's it

But the blocker to recommending that to a broad audience is that the setup you need to do on your system is better left to people who have got enough time to tinker with that sort if stuff

[trim zealot]

is the rename going through before the jam or are we going with subsecond_system for now?

[finite depot]

When I asked, I didn’t get much feedback

[trim zealot]

yeah probably just leave it then for now

[finite depot]

Yeah don’t want to confuse people right before the jam

Are you going to be streaming your entry btw? 🙂

[trim zealot]

yeah, starting saturday morning about an hour before the theme goes live

then definitely monday morning as well. Sunday tbd depending on when my d&d group wants to play

[finite depot]

Nice, maybe I'll tune in to compare how far behind we are haha

Scope creep is hard

[trim zealot]

haha, stream makes everything take longer so I'll probably be the one behind

I might do an infinite runner type thing if impending boom wins. tbd

maybe I've just been playing Haste too much this week

[tacit verge]

@finite depot here's the merge pr https://github.com/TheBevyFlock/bevy_new_2d/pull/427

[finite depot]

I'll let it run on my system in a few mins as a sanity check 🙂

[finite depot]

Works just as advertised

The only issue I see now is that the audio adjustment very obviously does not affect running audio

Which is a Bevy issue, yes

But now it looks like a bug in the template

Would it work if we pause the music? I assume not, since it's still "already running"

[tacit verge]

ah, yeah

[tacit verge]

tbh i'm not sure if this is the case. after implementing audio stuff in pyri new jam i think GlobalVolume just shouldn't exist

[finite depot]

Why?

[tacit verge]

it's convenient for "master volume", but as soon as you want separate "music volume" etc., you need to write your own system anyways

which you definitely will want

and then you have 2 different approaches for different types of volume

[finite depot]

oh yeah totally

[tacit verge]

in bevy_seedling, there is a volume node that all audio goes through that you can adjust for "master volume"

and you can set up audio pools that each have their own volume node for "music volume", "sfx volume", etc

[finite depot]

That makes sense

@tacit verge what are your thoughts on how to proceed? I see the following options

• Leave as-is (looks bugged)
• Remove audio settings (Menu is just empty?)
• Replace audio settings with some graphics settings (extra work for us)
• Implement separate volume systems (lots of boilerplate)

Or of course ditch the pause settings, which I would really really want to avoid due to accessibility options

[tacit verge]

volume systems imo

it would fit in src/audio.rs which is pretty empty otherwise

i think it's fine to merge the pause menu first though

it's still an improvement

in pyri new jam i have my audio settings in a Settings resource hooked into bevy_simple_prefs for persistence

we can do an AudioSettings resource here, and run the system when it changes

it shouldn't be too much boilerplate

well actually one little factor is we probably want to adjust audio via AudioSink or PlaybackSettings component

the former for already-running audio, the latter for queued-to-run audio

so when you click volume down from 10% to 0%, the click sfx should play with volume 0%

or the volume adjusting system could run after the bevy system that runs queued audio and we can just use AudioSink

[finite depot]

Then let's merge the pause menu and do that next

[finite depot]

agreed, I think my first settings menu PR that didn't use GlobalVolume also put it there

Yeah here: https://github.com/TheBevyFlock/bevy_new_2d/pull/374/commits/a593d1f271abff4ed64b412cdb94b565e87bcbf4

@tacit verge should I implement the thing I had in that commit or do you want to port your system from pyri_new_jam?

[tacit verge]

i think i'll port my system

it doesn't support different volume per audio instance though

you can adjust the volume in the asset itself anyways, not a perfect solution but good enough to keep the template simpler

[finite depot]

Alright, just let me know if I can help somehow

[finite depot]

yeah that's fine

[tacit verge]

actually i changed my mind, realized we'd have to set the volume for new audio entities when they spawn in addition to setting the volume for existing entities when the volume changes

but GlobalVolume already does the former

this will be easier in bevy_seedling where spawning an entity with the MusicPool component automatically routes it through the music pool entity's VolumeNode

and all entities are automatically routed through the global VolumeNode

in my template i currently just pass &AudioSettings into fn music() -> impl Bundle etc

but i think that's not great for bevy new 2d

[finite depot]

@foggy relic how are we feeling about bevy_seedling? It's not "official" enough yet, is it?

[foggy relic]

Yeah, not official enough for a template intending to be dependency free

[finite depot]

👍

Then I propose we leave volume settings out of the template due to lack of good upstream APIs

And just put something else like resolution in there

Or we remove the settings menu after all

The most important bit to provide is imo the pause functionality itself. Adding menus to it should be easy for users.

So maybe it's fine to leave it out, now that we have pausing?

[finite depot]

Especially since we have a nice credits screen that already shows how to enter menus from the pause screen and then return back to it

[tacit verge]

i think it's fine to have a settings menu with only master volume

[finite depot]

Put what about the already playing music?

[tacit verge]

just need the system to update it when GlobalVolume changes

the issue with using a new resource was we'd have to do that, and set the volume for newly spawned entities too, which is too much for bevy new 2d at that point

[finite depot]

Ah okay, I misunderstood your previous comment then

[finite depot]

got it!

Yeah, I agree

So just run a system that checks whether GlobalVolume changed and then iterates through all sinks and sets them?

[tacit verge]

exactly

[finite depot]

Sounds good

[tacit verge]

https://github.com/TheBevyFlock/bevy_new_2d/pull/428

just tested that this works

i put my system volume real high and went from 10% to 0%, no click sound 👍

i'm not 100% sure the system ordering is correct though i'll think about it rq

it should be fine anywhere ig, it's fine if there's a 1 frame delay for applying changes to global volume

but we mutate GlobalVolume in observers that run on Pointer<Click>

which i assume is determined in PreUpdate

so there should be no 1-frame delay

[finite depot]

I would also believe so

[finite depot]

left very minor comments

btw while we are on it, @foggy relic, do you know whether this behavior is intentional?

let linear_a = Volume::Linear(0.5);
let linear_b = Volume::Linear(1.6);
let linear_c = linear_a - linear_b;
info!("{}", linear_c.linear());
// prints 1.1

When going negative, linear volumes don't clamp at 0, but use their abs value

Certainly caught me by surprise 😄

@tacit verge I approved it in advance because I have to go to bed now and my comments are just very minor 💤

Could you ping Chris when it's merged? 🙂

Thanks again soooo much for implementing the pause functionality I was personally very much looking forward to it

[foggy relic]

I would very much call this a bug

[finite depot]

good to know, I'll do quick issue then before going offline so I can remember doing a PR for it

Done: https://github.com/bevyengine/bevy/issues/19417

[finite depot]

Ah, let's maybe also verify that the release workflow works beforehand

okay that's it, good night 👋

[tacit verge]

ok sounds good, cya

[tacit verge]

@trim zealot the template should be ready to go now

[trim zealot]

Awesome, thanks for the heads up

[tacit verge]

btw @finite depot, feel free to either create a pr for https://github.com/TheBevyFlock/bevy_new_2d/issues/186 or move it to the Bevy Jam 7 milestone

i don't plan on working on it at least until after the jam now, since i'd rather spend the remaining time making sure i'm personally ready

[tacit verge]

opened an issue to checkpoint bevy_new_minimal's metadata files from bevy_new_2d: https://github.com/TheBevyFlock/bevy_new_minimal/issues/21

[trim zealot]

for future consideration, there's not much discussion when PRs get merged, so its difficult to ascertain why something like TickTimers was added. (relevant PR: https://github.com/TheBevyFlock/bevy_new_2d/pull/418 )

[tacit verge]

oh that specifically was added a long time ago

the inclusion in that pr is due to merging lib.rs into main.rs

[trim zealot]

sure, but the original PR doesn't include the reasoning either: https://github.com/TheBevyFlock/bevy_new_2d/pull/110#discussion_r1674409110

[tacit verge]

it seems to be originally from https://github.com/TheBevyFlock/bevy_new_2d/pull/102

at the time discussion was mostly happening in the bevy jam working group and the code was very unstable

[tacit verge]

what's the suggestion here? include more context in pr descriptions?

or in comments?

[trim zealot]

either would be useful yeah

in this case specifically it would help answer questions like why the SystemSet exists or why this (and the input reading) work isn't done in PreUpdate

[tacit verge]

probably should be explained in docs/patterns.md

i can create an issue for this specific case

my opinion on AppSystems is that it's good practice to always put your systems in Update unless you know for sure that you can't, like if you have to run after a Bevy system in PostUpdate to avoid a 1-frame delay

that way you can adjust your system ordering more flexibly (because schedules are a hard boundary)

also that having a high-level system set for game logic just makes things much easier to reason about, and helps avoid 1-frame delays and difficult system ordering bugs, even if it technically introduces more ordering constraints than strictly necessary

https://github.com/TheBevyFlock/bevy_new_2d/issues/429

[finite depot]

I think Chris has a point with input reading specifically. That should be in PreUpdate, or you get a 1 frame delay the second you start using Avian

Mind if I PR that?

[tacit verge]

why is that?

i would expect physics to run after Update

[finite depot]

The fixed schedule happens before Update

[finite depot]

Nopes

[tacit verge]

hm

why can't it run physics in a separate fixed schedule after update?

so if i change velocity in Update, that doesn't take effect until next frame?

[finite depot]

That was on the table, there’s a lot of context

[trim zealot]

(fwiw I'm only noting some missing documentation; not arguing for one way or another by bringing it up)

[finite depot]

Yep. The correct schedule for that is… (brace yourself)

[tacit verge]

my feeling is this is an upstream issue with avian and/or bevy, game logic is "supposed" to go in Update and "just work"

where 1-frame delay doesn't count as just working ofc

[finite depot]

app.add_system(
  RunFixedMainLoop,
  foo.in_set(RunFixedMainLoopSystem::BeforeFixedMainLoop)
)

[tacit verge]

😔

[finite depot]

Then you'd be in the minority

[tacit verge]

i generally avoid fixed update stuff because imo it's still half-baked

[finite depot]

It works really well once you know that magic incantation I posted

[tacit verge]

aren't there still issues with events and other edge cases?

[finite depot]

Pretty much ironed out upstream or externalized in input manager crates

It's technically in a pretty good spot

[tacit verge]

hmm

so should all game logic go there?

as soon as you split game logic between systems you can't order things properly

and any game logic system could suddenly want to mutate velocity or w/e

[finite depot]

When using fixed update loops, Update is pretty much just for visual updates. So setting velocity there would be misusing the schedule.

Which is completely backwards from what we teach users in examples, yes

[tacit verge]

at the very least this is an upstream ergonomics and docs issue

[finite depot]

Oh absolutely

[tacit verge]

i also know that technically most games should be using fixed update for game logic

bevy or not

but bevy's fixed update was broken or a major pain for a long time

[finite depot]

Everything that moves stuff "should" go in fixed update, everything that pushes data that is needed for movement info "should" go in the system before (see incantation), interpolation "should" go in the system set between fixed updates and updates, and the rest can go into Update
By this reasoning, input goes in PreUpdate (which runs before state transitions, so careful there), but also Camera needs to move every frame, so don’t put that in fixed updates

I say "should" because in practice, just using Avian and BEI gets you 90% there automatically and one frame delayed input is fine if you have high enough FPS to not notice

[tacit verge]

i think state transitions should run before PreUpdate btw :p

well actually

if you're doing game logic in fixed update, state transitions should run in there too

at least for states that affect game logic

[finite depot]

Oh yeah also absolutely true

In practice, for ordering, you end up with a system set for ordering things that happen before the fixed update and a set for things after

(Since the stuff inside the fixed update is usually the business of your physics library)

If you don’t use Avian and want to implement stuff yourself, I wrote some lengthy words on the subject in https://bevyengine.org/examples/movement/physics-in-fixed-timestep/

@tacit verge bottom line is: this all works, but requires some knowledge about the scheduling.
Which is why I'm really happy that BEI uses observers triggered in PreUpdate. That just automatically removes a footgun entirely if you e.g. set your velocity in one of those systems

[tacit verge]

yeah observers make sense

[finite depot]

Anyways @trim zealot you’re absolutely right, we should copy-paste our reasoning from Discord into the PR descriptions 🙂

(At the least)

[finite depot]

Note that they still don’t save you from accidentally ignoring inputs if you don’t do input accumulation, if you know what that is

Which reminds me that should add that to Foxtrot. I just kinda assumes Tnua would do input accumulation for me, but come to think of it, that’s probably wrong 👀

[finite depot]

😄

[finite depot]

@gritty flume do you have some tips on how to nicely implement an audio slider in the template?
I understand the ideas behind it (use dB, multiply volumes, etc) but my understanding breaks down the moment I want to visualize it to the users as value between 0 and 500 in steps of ten, as the underlying maths end up in very not-ui-friendly numbers

I came up with something for Foxtrot, but it was a surprising amount of boilerplate for such a common task, so I didn’t upstream that version

[gritty flume]

It's surprisingly "unacademic" if you will, most faders will have a custom curve to achieve the whole range from -inf..0 dB

You can make it linear (in the dB) from your lowest value to max, and then simply drop to zero at the end, eg. -48..0 for levels 1..10 and 0 is just 0 volume

For more continuous sliders you might implement it in 2 stages where some portion of the travel of the slider moves from -inf to a set volume, and the rest linearly moves from that set point to 0 dB

[finite depot]

Sorry, I don't have enough knowledge of the domain to quite follow :/
Could you maybe write just a few lines of pseudocode? I'd greatly appreaciate it

[gritty flume]

let postiion = slider.get_position();
let volume = if position < 0.1 {
    Volume::Linear(lerp(0.0, 0.01, 10.0 * position))
} else {
    Volume::Decibel(lerp(linear_to_db(0.01), 0, (position - 0.1) / 0.9))
};

I don't know if that makes it any clearer

[finite depot]

Yes, that makes it much clearer, thanks a bunch!

[gritty flume]

the values might be off (40 dB might not be a big enough range for the decibel part of the slider) but that's the approach many faders take

const VOLUME_STOP_DB: f32 = -60.0;
const VOLUME_STOP_POS: f32 = 0.01;
let postiion = slider.get_position();
let volume = if position < VOLUME_STOP_POS {
    Volume::Linear(lerp(0.0, db_to_linear(VOLUME_STOP_DB), position / VOLUME_STOP_POS))
  } else {
      Volume::Decibel(lerp(VOLUME_STOP_DB, 0.0, (position - VOLUME_STOP_POS) / (1.0 - V0LUME_STOP_POS))
};

Factored the constants so that it's clearer what you can tweak your fader range

[fierce jewel]

Hey so I was messing around with the template and when making a new project from the template, if I select no on: The template is requesting to run the following command. Do you agree when it asked if I wanted to run cargo update --package on the project. I get an error saying something failed, and this could be somewhat unfriendly as it's unclear if that means that the project creation failed or not. This could trip up some people, and tripped me up at first, would there be any way this could be fixed or made a bit clearer?

[fierce jewel]

Also, I know it's been a bit, but I just wanted to go back to this really quick as I was taking a look at the Window stuff again now that I have some time and energy. This isn't super high priority but thought I'd ask about it since I have some ideas, but I'm unsure what exactly what you're needing here and why the video mode stuff was an issue.

[tacit verge]

how do you display the window's current video mode in the ui?

and what do you show if it's in windowed mode instead of fullscreen?

[tacit verge]

the command exists to generate Cargo.lock so that the initial commit passes CI, which uses --locked for all cargo commands

if you can think of a better solution, or at least some way to make it more ergonomic with cargo-generate, that would be great. i don't know of a better way atm

[fierce jewel]

Is there a way to show something like: "You may be prompted to run a command, if you select no an error may occur, this is expected." or something of the sort so that the user at least knows that it's expected if you hit no?

[tacit verge]

maybe the rhai script can print something

[finite depot]

Why are we even asking the user? Just to be nice?

IIRC we can just execute that command without asking

@trim zealot I'm back on my machine now. If you have some last minute feedback, I'm happy to PR it 🙂

[tacit verge]

it's required in order to run commands

Rhai is meant to be "sandboxed" but we're trying to run an arbitrary command

[fierce jewel]

I guess part of it is I'm not entirely sure why you need Video Mode in particular for a monitor? Is it for getting the bit depth for colors or something?

Also looking into it, at least from what I get from the winit documentation, Video Mode is only available for a window, if it is exclusive Full Screen, because then it's taking up the entire monitor. Otherwise you'd want to get the current Video Mode of the Monitor and use that. However Winit also doesn't provide that information either. All Winit provides on the Monitor is an iterator of Video Modes the Monitor supports, which is what's also exposed through Bevy.

At the very least, for a basic options menu you only really need Monitor, Resolution, and Window Mode (Fullscreen, Borderless Fullscreen, Windowed)

If it's something you need to get back into to answer, it's fine if it takes a bit (especially as I imagine there are some other priorities atm)

[trim zealot]

video is recorded, I'm just rendering and such atm

[trim zealot]

I don't even think the command needs to be run. we removed it from the minimal template

[tacit verge]

yeah i won't have time to look into it until after the jam at least

[fierce jewel]

Looking into a bit, rhai can just print something to the screen, so before you get to the command you should just be able to do something like print("Some text") and try it out.

At least according to https://rhai.rs/book/language/print-debug.html

[tacit verge]

this is because the minimal template doesn't come with CI yet

[trim zealot]

maybe it shouldn't have a lockfile in the 2d template either?

[tacit verge]

well we'd have to remove the --locked args from cargo commands in the workflows if we want to remove the lockfile

[finite depot]

We did that to ensure we deliver something to the users that we know works

[tacit verge]

also we can't copy the template's Cargo.lock for the user's generated project, because it uses the name bevy_new_2d inside

and having a Cargo.lock.template would be a pain to maintain

[tacit verge]

technically we don't get this from the current approach, because the user will get an updated Cargo.lock compared to the template's version

what we do get is making sure their CI builds are consistent if they don't touch Cargo.toml

[fierce jewel]

Absolutely fair. If you do happen to be able provide additional information before then feel free to send it my way ofc. I have some other bevy related stuff to work on (like messing around with letterboxing) in the meantime as well.

[trim zealot]

every other bevy project being created daily would also break if that were the case

since non template bevy projects don't get a lockfile

[finite depot]

Yeah, but that is not really much of a consolation to the user that runs into this 😅

I mean, maybe it's a skill issue on my part, but I've created new Bevy projects before and happened to win the lottery of "some dependencies just really don't want to work on their newest versions today"

[trim zealot]

I mean, "bevy installs are broken globally" doesn't seem like a problem this template needs to solve

[finite depot]

If the cost for fixing it is including a lockfile, why not?

[finite depot]

Though it seems like I was mistaken anyways

If the lockfile updates all its deps, our current approach is misguided

[trim zealot]

because you have to ask the user to run a command that isn't explained when creating the project 🙂

[finite depot]

Yeah it should definitely be either explained or run automatically, fully agreed on that

[trim zealot]

it also fails if the answer to the question is "no", but I forget exactly how it fails. let me check

[tacit verge]

i thought --locked is just a good practice for reproducible CI

[coarse linden]

i'll confirm specific versions as needed, but early this week and again just now, if I do bevy new -t 2d and say no to The template is requesting to run the following command. Do you agree?, I get a correctly named but empty directory

[finite depot]

Oof that's bad

[finite depot]

Yeah that too. I would very much like people to not run into "huh, it works on my machine, weird" if possible

[finite depot]

[trim zealot]

big scary "failed" message plus an empty dir

[tacit verge]

i mean we could always switch to a Cargo.lock.template approach and try to make that nicer to maintain

[finite depot]

Yeah I don't like that at all

[tacit verge]

rhai doesn't do anything weird for mv commands

[finite depot]

Probably fine to just add one now for the jam as we're not touching the template now anyways

We can then still think about how to proceed later 🙂

Thanks for bringing it up, everyone!

[trim zealot]

yeah, not pushing for changes now. just noting that its definitely a failure mode of the template

[finite depot]

@tacit verge should I PR it or you?

[tacit verge]

you can pr it and i can make the issue :p

[finite depot]

I'll change it right away. Seems like a very annoying trap to fall into

[fierce jewel]

Yeah, I guess it's a good thing I ran into it and brought it up then, although I was wrong with what happens if you say no.

[coarse linden]

is it cargo-generate based under the hood? based on the simple steps in the rhai script I would expect to get the contents of the templated dir minus a fresh Cargo lockfile. I wonder if they would consider that a bug?

[fierce jewel]

It's from cargo generate.

TL;DR Cargo Generate allows you to specify rhai scripts that can run at specific times. The latest one is Post

Post hooks are run after template expansion, but before final output is moved to the final destination.

Why not later? Security, and the fact that a failing script still causes no errors in the users destination.

So if the Post hook fails, then it will fail before moving everything to the final destination.

[coarse linden]

huh, WAI i guess

not least-surprising imo

[tacit verge]

issue created: https://github.com/TheBevyFlock/bevy_new_2d/issues/430

[finite depot]

https://github.com/TheBevyFlock/bevy_new_2d/pull/431 don't approve yet

any idea why this just skips everything?

hmm everything seems to be in place

why do I get those weird messages then?

Oh wait, once the things starting with a . are skipped

huh

[coarse linden]

mine also says skipped for nearly every line

[finite depot]

Is this because of the new Bevy CLI? 👀

That would mean that users are getting no CI

[coarse linden]

looks like it's only the files that are templates are reported as not skipped, so maybe that's a strange phrasing for "this didn't need any rendering"?

[finite depot]

same on main

[finite depot]

Oh yeah right, it is actually in the generated files

weird

let me experiment a bit

Oh yeah this means "nothing to substitute" I believe

I could swear this used to not be rendered though

[tacit verge]

maybe related to this? https://github.com/TheBevyFlock/bevy_new_2d/blob/a662f590a96d010961a00361714a93c830265644/cargo-generate.toml#L3

[finite depot]

@rain solar do you know if the CLI updated cargo-generate at some point?

[finite depot]

Let's try

[trim zealot]

https://www.youtube.com/watch?v=ez4oGeM3X2o

[finite depot]

heck yeah!!

[finite depot]

removing that line replaces the "skipped" by "Done", but also:

these friendly Chinese people say to use "exclude", let's see

[finite depot]

Found it: exclude means "plz don't validate this file's liquid tags"

which is nice

still results in the misleading messages though

but the files are there, which is what counts

[rain solar]

yes but a "long time" ago to 0.23

[finite depot]

@tacit verge done: https://github.com/TheBevyFlock/bevy_new_2d/pull/431

plz verify before merging 🙂

bevy new -t 2d --branch lockfile foo

[tacit verge]

hmm so include is "please validate this file's liquid tags" then i guess?

we only use liquid tags in .template files iirc

[tacit verge]

also i assume this enables translating the liquid tags too

which we probably only want to do in .template files just in case we have a stray {xyz} in some other file

[finite depot]

Oh right!

[finite depot]

I reverted to that version

ready again 🙂

[finite depot]

@trim zealot I just watched your new video and got this feeling that you've improved as a creator since the last video you did on the template. Something about your cadence? Or how the script flows? Hard to tell, but there's something there that seems more engaging than before 😄

Maybe it's also due to the production quality, e.g. the little title cards in the corner you started doing

Also, as someone with bad vision, I appreciate how big the font size is

No comments on the actual content of the video, the template is presented excellently from what I saw

I highly appreciate the section on explaining the patterns. Also how you explain things like impl Into<String> that I didn't even consider others might not know.

[trim zealot]

I'm glad you think so. I definitely focus on changes adding up to mean videos "6 months from now" being better than what I produce today and its been 10 months between those two, so there should be a visible improvement there.

[trim zealot]

yeah, this is one of the reasons that introducing new concepts or abstractions into the template is something worth evaluating constantly. The template as it stands today is about 1300 lines of code which is longer than almost any block breaker/asteroids/flappy bird/etc game by a significant amount (500-800 loc). Any deviation from "how other bevy applications work" means more cognitive overhead for new bevy users, and there's a limit to what a new user can handle.

Which ends up being why I'm asking about things like AppSystems::TickTimers, etc. Most new users are going to cargo-cult something or do the simplest thing because of that mental load, not choose the optimal thing for a production game. For example, sticking everything in Update vs using FixedUpdate for someone unfamiliar with game dev; or function plugins vs struct plugins when struct plugins are used in all examples, third party crates, and upstream code.

IMO the shape of the template is definitely a product of the people working on it so I try to only argue for changes when things are pretty far out on that spectrum (introducing a SpawnObserver BundleEffect, for example), but that mental overhead is definitely a thing worth considering.

[finite depot]

Completely fair! I hope the LOC can go down as new Bevy versions release and we no longer need e.g. a custom Widget abstraction

Some other things I'd love to see go due to API improvements upstream:

• The asset preloading stuff
• The state wrangling we have to do to get a pause menu working
• The animation boilerplate
• Maybe even the splash screen

I think we can also talk about maybe removing the settings menu.

Since we now have pausing, adding it back in manually is trivial, especially if users already have the credits menu as a guide

Well, maybe not "trivial"

but easy enough

[trim zealot]

IMO if the asset_tracking abstraction is required it needs to have a corresponding issue in the bevy repo. Its not the template's job to fix problems with upstream bevy by developing new abstractions that are only present in the template.

the closest I can get to why it exists would be needing it for audio reasons maybe

[mortal breach]

(especially an "official template")

[finite depot]

There's one floating around. While I agree in principle, it's more important to me that users get something that does not break in surprising ways. As you correctly point out, this is needed against audio stutters :/

If we used JS APIs upstream for audio on Wasm, we wouldn't even need it

Since that's on the roadmap for bevy_seedling, I'm cautiously optimistic

[finite depot]

Yeah it's a bit sad we need any custom abstractions at all 😅 We did open up about 15 issues while creating the template, and a few of them have already been resolved, so we were able to remove some stuff again fortunately

(And we even uncovered 2 rustc bugs )

Ultimately, the template in my opinion is less about showing off the parts of Bevy that are great and all, and more about providing something to the user that they can use as a solid foundation with a good conscience.
If that requires doing something that is ugly or verbose, that's unfortunately Bevy's reality and we have to consider whether hiding that away is just pushing a footgun onto the user.
I'm not comfortable handing the user something that I know will cause them trouble when uploaded to itch.io in the long run, or will require big refactoring to support common features.

Though obviously, this is something that needs to be weighed on a case-by-case basis. SpawnObserver is a good example of something that imo is not worth adding in complexity.

Hope I'm not coming off as too protective or anything, it's just that we are very much aware of the complexity and would also wish it wasn't there, so the things we added are generally there for a good reason, barring mistakes or things that became outdated

This is btw also why I'm against doing a bevy_new_3d right now. I believe the amount of boilerplate required to do it right if we use no external dependencies is way too high to hand to beginners,

Also, I would not be opposed to having a second template that basically just handed you a 2D camera and a character, for when you really want the absolute minimum required for 2D

[trim zealot]

Right, so then I think this is a template made for experienced Bevy developers who already understand quite a bit about Rust and Bevy. If a scripted 30+ min video can't cover all of the topics in the template, then its also not meant for new Bevy users as they will take multiples of that to understand what's going on.

[finite depot]

I would say intermediate is the target audience. I would not hand it to a totally new user in its current state, no

[trim zealot]

the SystemSet setup is a pretty good example of that. A new user sees everything being added to Update, but the template sets up what is basically its own schedule to add systems to

[finite depot]

Yeah a total beginner does not know what a system set is, nor do they really need to, that is true.

Maybe it would make sense to have a template that is intended for new users so they can easily experiment, and a template that is more production-ready?

Or let the 2d template ask you which version you want interactively

[trim zealot]

I think in the end what templates there are is up to you, the people working on it. I find myself avoiding the bevy_new_2d template for new projects personally.

[finite depot]

I'd say at a certain level of experience it generally makes the most sense to have one's own personal template anyways

[trim zealot]

At the end of the day, one of the reasons the video exists is because there's so much in the template that I feel like an overview done in this way becomes almost necessary, and I will continue to do that as long as its useful.

[finite depot]

Yeah, that makes sense. Thanks again for that 🙂

[mortal breach]

My only point is that bevy_new_2d seems controversial / maybe unworkable as an official -t 2d or whatever in its current state. (But I am not arguing that the things it is doing are bad or wrong. It would just feel odd to do some of them in a project under the bevy org.)

[finite depot]

I'm personally not optimistic that anything beyond "Here's a 2D cam and a character to move with WASD" can become a first party repository due to the desire to not be opinionated, which anything beyond that very quickly is.
But the maintainers wishes right now are to generally keep -t templates in TheBevyFlock, so that should be alright

[mortal breach]

Cool, seems like we're on the same page too.

[finite depot]

To be clear, I'm totally fine with the basic -t 2d template being that very barebones thing

[trim zealot]

the cli itself is trying to get upstreamed now that they have an alpha release, which will implicitly make the templates more front-and-center too

[finite depot]

I chatted with Alice about that, and the idea really is to keep the templates as-is until we really push templates in an official capacity

That might sound misleading

"as-is" means "keep them under TheBevyFlock, don't hold them to the same level of scrutiny as Bevy Org repos"

There definitely will be a maintainer feedback round, don't get me wrong 😄

And I already know that that feedback round will involve chopping off stuff left and right

Bottom line: this chat with you two @trim zealot @mortal breach shows me that there clearly needs to be some way for new users to easily create a minimal 2D template with the CLI that they can experiment with without learning about 50 different Bevy features and their ins and outs

Since most of the outstanding issues in the bevy_new_2d repo are related to further CI optimizations and not features / code itself, I think we are in a good state now to tackle something like that

I see three possible routes:

• Have a single 2d template with an interactive question, asking you for the flavor
  • I kinda like this one the most, as it does not require the CLI users to learn more params and also does not require setting up a new repo
• Have a 2d and a 2d-minimal template
  • My least favorite option, as I think new users will gravitate to the cli command that seems the most "default"
• Have a 2d and a 2d-production template
  • Name can be bikeshed (2d-advanced, 2d-extras, etc.), but I think that is workable too.

[tacit verge]

bevy just needs to fix all of this upstream imo

the entire theme/ folder should be deleted in favor of unstyled widgets provided by bevy

and users shouldn't have to implement spritesheet animation themselves

bevy_new_2d doesn't really do anything special, it's just title screen, credits, settings, and pause menu, with an animated walking duck. the fact that there's so much complexity required to make that work is a symptom of bevy itself not being beginner-friendly

if you drop a new user in a minimal template, they'll probably never have a settings menu for example

so i'm not sure what the ideal beginner-friendly template would even look like right now

[stable sandal]

I'm not sure a settings menu makes sense in a beginner template

[tacit verge]

in current bevy maybe not, but it ought to fit in a beginner template imo (even if it's just a master volume selector to be clear)

[stable sandal]

is this something that is available in templates for other engines? I guess templates exists for unity/godot, we could look at the content of the top rated ones

[tacit verge]

i have no clue actually 😄

[trim zealot]

godot's default flow has you pick a renderer and then just kinda plops you into an editor

so no real template from that perspective afaict

[tacit verge]

ig you have to go out of your way to use a godot template

[trim zealot]

marketplace seems to be where you get them, and they're kinda just demos? here's the official ones: https://godotmarketplace.com/publisher/info_n9b0r5v5/section/145/

was able to find something that looks similar to the current 2d template in terms of menus and such: https://godotengine.org/asset-library/asset/3790

looks like it was created as a jam template too

doesn't seem like there's any way to figure out what's being downloaded/used/etc

[coarse linden]

whether or not they're included at all is a separate question, but my personal POV is that an official template, or one aiming to become so, doesn't need to default-include CI and Itch stuff. I'm probably in the minority about WASM out of the box too.

[trim zealot]

I think if its a Jam focused template the ci/wasm stuff makes sense, but if I wasn't doing a jam I wouldn't be focused on wasm personally

[tacit verge]

yeah i can see that wrt wasm and itch.io. bevy_new_2d is in a sort of awkward spot of not technically being a jam template, but being mostly used for jams

[trim zealot]

I would say that it is a jam template, given that all the work on it happens right before (and because of) the next jam

[tacit verge]

yeah that's fair. it also started as part of the bevy jam 5 working group

[normal shale]

I think in that part the template is similar to the new usage and game examples, it highlights pain points you will quickly run into when starting a project with Bevy

[stable sandal]

for "serious projects"© the way it works is that you have multiple templates that you can compose. for example you pick "basic 2d" + "wasm itch.io", or "basic 3d" + "high quality renderer", ...

[dreamy forge]

I have a modest proposal:

A 3d template with:

• A single plane
• an atmosphere skybox (or using atmospheric scattering)
• a first person controller where you can jump and look around

[finite depot]

Point 3 is not really doable without a physics engine :/

[dreamy forge]

Counterpoint, if it's just a single plane you can hardcode it

you can add a comment in the code to recommened using a physics engine

[finite depot]

Sure, but then we are implementing gravity ourselves for nothing. And if we have no jumping, and just a single plane, I'm questioning what the value of the template is in the first place

[dreamy forge]

fair

I'll try to code this up and maybe then we can see if it's worth bothering with

[austere shale]

My 2c would be that I really appreciate what the template is doing. I'm ultimately gonna roll with the @tacit verge 's template for the jam because I'd use the 3rd party deps anyway, but this is pretty close to what I'd like to get from a jam template - CI setup, menus and the stuff around that that can be fairly easily replaced.
An alt I'd consider would be the minimal app with just the CI. This's coming from someone pretty familiar with bevy so obviously doesn't really apply to newcomers, but I also don't think newcomers should start with a template anyway.

[tacit verge]

ci / ide integration etc. + App::new().add_plugins(DefaultPlugins).run() is the goal of bevy_new_minimal, which is what you get with bevy new if you don't specify a template :)

currently it doesn't include ci / ide integration but it's planned to copy that over from bevy_new_2d soon

i guess this does raise the question of whether bevy_new_2d should consider relatively new bevy users as part of the target audience

if we think it shouldn't (at least for now), we could make that more explicit in the documentation

we have this section at the top of the readme, but it doesn't explicitly mention whether the template is meant for beginners vs intermediate users etc

[finite depot]

Per above, I think we should add a minimal mode that gives you nothing but a 2D cam and a player with movement but without animation. AKA the absolute minimum.

Something like a question at the beginning, asking you if you want the minimal mode or the production mode

[tacit verge]

created an issue about code vs CI: https://github.com/TheBevyFlock/bevy_new_2d/issues/432

[finite depot]

Thanks 🙂

[tacit verge]

ah it's not fully related to your point but an earlier point

but it is related

created an issue about target audience: https://github.com/TheBevyFlock/bevy_new_2d/issues/433

[dreamy forge]

@finite depot

[finite depot]

🎉

[dreamy forge]

the code is very messy and could use some polish, but I still think that a bevy_new_first_person template could be a good idea

[finite depot]

If you can make a case for this being useful to a user without having to rip out most of the implementation, I'm open 🙂
I assume the collision is not Collide and Slide, but just checking the Y translation value?

[dreamy forge]

yes

part of me wanted to implement quake 2 movement

but I didn't

[finite depot]

Then my main question is what kind of user would do what with the template. If there's no collision, application is quite limited. If our suggestion is to use Avian, then we immediately give the user the homework to replace the existing implementation in the template

I really wish Avian was upstreamed

[dreamy forge]

to make the template maybe a bit more usefull I thought about adding a settings menu so you can live change fov / some graphics settings

[finite depot]

Having a standard FPS camera setup as shown in https://bevyengine.org/examples/camera/first-person-view-model/, where the settings control the mouse sensitivity and the world model FOV would certainly be nice 🙂

Those two settings are especially important for accessibility

[dreamy forge]

I know some potential counterpoints to this, but is there actually anything stopping us from adding an external physics engine?

[finite depot]

The goal of the project is to be second-party, i.e. stay opinionated, but also stay vanilla Bevy

[dreamy forge]

yes, but like, would a user care much about that?

[finite depot]

If we had a template that implemented the two camera (or three if you count the UI camera) setup, there's also a bunch of hacks that need to be included to get HDR working. That could also be part of the code.

[finite depot]

Depends on the user. I know quite a few people are quite allergic to dependencies.
This is more of a self-imposed limitation than a user wish though

[dreamy forge]

I feel like it's possible to excuse something as substantive as a game engine, especially if we're able to somewhat seperate out the code that deals with that

[finite depot]

You mean a physics engine, right?

[dreamy forge]

yes

[finite depot]

I think it's worth putting it on the table, yes

[dreamy forge]

bad words

at the end of the day, having a something like a 'bevy_new_3d' makes sense to me, just from a 'well we have a bevy_new_2d so why not a 3d template'

[finite depot]

I don't think any of us has capacity for this until after the jam, but we can certainly discuss creating a bevy_new_3d that is allowed to pull in avian3d after 🙂

[fierce jewel]

Just as a note, part of the reason why bevy_new_2d does not use third party dependencies is because as the template is second-party/officially unofficial but aims to be aligned with Bevy Upstream and it was a concern that if it relied on third-party crates then the maintainers of those crates may experience additional pressure in maintaining it.

(FTR I would argue that certain things might be better moved to a similar status to the templates, which would ease things a bit. But it's not really happened yet)

At least that's what I remember from when this template was first made.

[woven sail]

Hello, is there a way to create a new bevy project with the cli with a more minimal project than the existing template?

I find that im basically deleting or rewriting a lot of stuff when really the most important part is serving to the web (at least for me)

[finite depot]

just remove everything except the .github dir

The minimal template does not have the CI setup yet, unfortunately

[woven sail]

thats what i ended up doing was just wondering there was something better

thank you!

[finite depot]

I'd also keep the Cargo.toml, there a bunch of good defaults in there

[woven sail]

i just deleted all game code pretty much

bye bye ducky 😔

[finite depot]

[austere shale]

@finite depot
is there some setup needed to run subsecond in, um, sub a second? My hot patches take roughly 15 seconds 😅
(note, I'm using the pyri template)

[finite depot]

Linux?

[austere shale]

yep

[finite depot]

• Use nightly
• Install mold and clang through your package manager
• Install cranelift with rustup component add rustc-codegen-cranelift-preview --toolchain nightly
• Put the following magic incantation in your ~/.cargo/config.toml:

[unstable]
codegen-backend = true

[profile]
incremental = true

[profile.dev]
codegen-backend = "cranelift"
debug = "line-tables-only"

[profile.dev.package."*"]
codegen-backend = "llvm"

[profile.test.package."*"]
codegen-backend = "llvm"

[profile.release]
codegen-backend = "llvm"

[profile.web]
codegen-backend = "llvm"

[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = [
  "-Clink-arg=-fuse-ld=mold",
  "-Zshare-generics=y",
  "-Zthreads=8",
]

Let me know what the speedup is 🙂

[woven sail]

does the info! macro work for web?

im trying to figure out how to log to the browser console

(it does work i was just being dumb <3)

[finite depot]

should 🙂

[finite depot]

Also, info_once! is very useful for debugging in a system that runs again and again

[austere shale]

thx, I tried spinning up just the minimal template & adding subsecond to that and that takes about 600 ms with just lld, so I'll try the same with this template & than with mold and whatnot

Wait, nope. With lld it actually takes around 5000ms (in a local .cargo/config.toml), but without it takes 600 ms)

Edit:
I've also tried the full nightly setup from above on minimal and the patch took roughly 1 sec, which is still double when compared to using no profile config whatsoever 😕

[finite depot]

weird 👀

Can you try the setup above but with the lines saying mold commented out?

So you use your default linker

[austere shale]

Tried, that makes it faster (provided I don't set clang either)

(I don't think any of the other zflags actually make a difference and I got a boost from cranelift)

[austere shale]

Tried with Pyri's template with the cargo config aimed at perf but still using the default linker the hot patches take around 1.5 sec. So not quite subsecond, but workable. With mold it takes roughly 2.2 sec. I wonder what I'm doing wrong here...
Are you pinned to a specific nightly?

[tacit verge]

that's faster than it is for me :')

[austere shale]

r u using mold, lld or the default linker?

[tacit verge]

i think i'm using mold

symlinked and -Clink-arg=-fuse-ld=mold

[woven sail]

question before i go down a rabbit hole, does hot reloading with subsecond work on wasm or is it native only?

[austere shale]

native-only
https://github.com/TheBevyFlock/bevy_simple_subsecond_system?tab=readme-ov-file#known-limitations

[steady palm]

re: using third-party crates in this template, what comes to mind for me is the lovely svelte CLI, which allows you to optionally add from a selection of dependencies when creating the project

adding one mutates the project template according to a script like this :https://github.com/sveltejs/cli/blob/main/packages/addons/vitest-addon/index.ts
& their philosophy for which add-ons to maintain in the cli is in the readme

Please file an issue for discussion before sending a PR for a new add-on. Most new add-ons will likely be recommended to be implemented as community add-ons. This repository will only hold a very limited number of add-ons at the maintainers discretion that address widely held needs, are considered best-in-class, and are widely used in the Svelte community.

if this kind of philosophy were applied to the bevy cli, i would maybe anticipate options like bevy_asset_loader, rapier, avian, enhanced input, kira audio, maybe something for tweening, maybe tnua, for 2d maybe bevy_ecs_tiled/ldtk and maybe something for spritesheets

but of course, the idea of N optional features that each mutate the template hopefully in a way that still produces a viable runnable game is a fairly tall order lol

[finite depot]

that's pretty neat, I didn't know about this 🙂

that looks really neat for users!

[elder thicket]

Unfortunately Discord's search functionality isn't great for forum posts, so I can't reasonably figure out if this has been asked before but
What if Bundle Functions took a proper Bundle (MonsterSpawnParamsBundle) (or just a struct) as a parameter instead of the individual fields?
Would that help with any of the current limitations? (no dependency injection, no replacing components)
It'd at least allow for the parameters to be defined in any order afaik, which seems to be a minor plus

[tacit verge]

i don't think it helps with the limitations, but i do like that pattern for container widgets, so you can do something like commands.spawn(widget::column(children![...]));

where fn column(children: impl Bundle) -> impl Bundle

[elder thicket]

I imagine for replacing components, if the parameter is a Bundle, you could maybe somehow do "if Bundle contains ComponentA, use it, otherwise default"?

bypassing the "you have to add an argument to the function to explicitly allow it"?

[tacit verge]

is the idea to accept a specific bundle or any impl Bundle as the argument?

[elder thicket]

probably impl Bundle with a specific Bundle being made to provide info on what it should usually include to the caller

Apologies for not fully thinking this through, I'm still learning ECS, moreover Bevy 😛

[tacit verge]

i can't say for sure that that's not possible :p

[tropic epoch]

Can it be that the wasm itch build can't load pngs when I use DefaultPlugins.set(ImagePlugin {default_sampler: ImageSamplerDescriptor::nearest(),}) ?

there is something about it in the docs:
"As this type is part of the ImageLoaderSettings, it will be serialized to an image asset .meta file which might require a migration in case of a breaking change."

and .meta files can't be loaded in wasm?

[finite depot]

They should already be disabled

[tropic epoch]

they are

for some reason, my own pngs won't load

but only in wasm on itch, bevy run web and cargo run and bevy run all work as intended

[finite depot]

any errors in the console?

[tropic epoch]

I have this error when trying to play my game on itch.io:

 Failed to load asset 'images/1bit-panel.png' with asset loader 'bevy_image::image_loader::ImageLoader': Could not load texture file: Error reading image file images/1bit-panel.png: failed to load an image: Format error decoding Png: Invalid PNG signature., this is an error in `bevy_render`.

It works locally with cargo run, bevy run and bevy run web, but not online on itch

The splash screen loads as expected

The ducky sprite too

[finite depot]

Whack

[tropic epoch]

I totally agree

[finite depot]

I have no clue then @tacit verge you ever ran into this?

[stable sandal]

you didn't upload your pngs to itch, so it's giving an html page to the png request

you can confirm in your browser console by looking at the query

[tropic epoch]

We've cloned the new 2d template via the bevy cli, the images are in the asset folder and are pushed to itch by the release yaml - shouldn't that work out of the box?

And in chrome console, there are no 403 or 404 errors

[stable sandal]

can you check what the network request is replying?

[finite depot]

Then you would get a 403 and not an invalid PNG signature, no?

[stable sandal]

🤔
we need to know the http query response exactly

@tropic epoch can you share your jam itch.io page?

[tropic epoch]

I agree. Downloading the submitted .zip I can confirm that the files arrived safely

[stable sandal]

(Tig0r shared their project privately)
@tropic epoch I see one issue, not on your pngs, for me its crashing on the ogg files loading: you've setup your repo with gitlfs, and the files sent to itch.io are not the actual files but the git lfs pointers

[tropic epoch]

what

[finite depot]

Aaah now everything makes sense 😄

[finite depot]

Activate lfs checkout in the release workflow

[finite depot]

See https://github.com/TheBevyFlock/bevy_new_2d/blob/main/docs/workflows.md#configure-environment-variables

Just set this here to true:

And be aware that itch.io uploads count towards your total LFS quota

[tropic epoch]

Thank you so much

I'll do a final test

It works. Thank you so much @stable sandal @finite depot

[woven sail]

not sure why I started getting this error seemingly out of nowhere when using bevy run web?

ran a cargo clean and it seems to work fine now

[finite depot]

I redirected it to #1278871953721262090 🙂

[woven sail]

thank you

!

[normal shale]

Its a bug in a specific nightly version, try running rustup update :)

[normal shale]

Ah nvm :)

[viral blaze]

Fairly old, but what turned out that was happening is that I had accidentally imported use bevy::reflect::List; at some point. This somehow messes with the types, and instead of LevelHandle automatically being a Handle<Level> it becomes &dyn PartialReflect

[normal shale]

Just came back to this, why do you recommend mold now? I thought it doesn't provide a measurable speed up?

[finite depot]

Not on CI, as its speed up in the realm of single seconds. So mold only matters when your local incremental compilations are already in the realm of seconds 🙂

[normal shale]

Ahh fair, then the time to install it in CI probably cancels out the faster link time. Thanks!
Has anyone already tested the wild linker, how it compares to mold?

[finite depot]

I'm not on my PC right now, but I believe on my machine it was something like 1 sec shaved off a 5 second build or something like that

The biggest difference in speed is using cranelift

That shaves off about 50% of the build time

[finite depot]

Never got it to work unfortunately

Especially not with subsecond

[normal shale]

cranelift is nightly only, right?

[finite depot]

Nightly only if you want the setup to be simple. IIRC you can use it on stable if you manually download it and use cargo clif or something like that

I did it for Windows once, back when you couldn’t download it there with rustup

[normal shale]

I still really want something like bevy init fast-compiles which does this setup automatically. But nightly should be optional for that command, so if the user wants to use stable we have to fall back to slower settings

[finite depot]

Yeah cranelift on stable is IIRC only usable by using a custom CLI or cargo subcommand.
Though technically the Bevy CLI could silently call that in the background? Not sure if that’s a good idea or not, but it’s a possibility

[coarse linden]

there's cargo-wizard that would probably be very interested to get feedback from this crowd, and has overlapping concerns

https://github.com/Kobzol/cargo-wizard

answer questions in a mini-TUI to patch your .cargo/config.toml accordingly

some of its recs contradict what's in bevy_new_2d's templates but I haven't done any homework to figure out which ones I land which way

[normal shale]

Interesting I will take a look at that!

[tropic epoch]

does the #[dependency] macro work on vec's of handles, too?

[finite depot]

Yep 🙂

[finite depot]

Also works on https://github.com/janhohenheim/bevy_shuffle_bag 😉

IME that’s what you uuuusually want instead of a vec of assets anyways

At least, for the kind of stuff that I use a collection of handles for, e.g. a collection of jump sounds

[tropic epoch]

aight, thanks

[finite depot]

This also sped our game up FYI

[tacit verge]

interesting

give performant bevy on web pls

[tacit verge]

btw one change i made from bevy_new_2d during the jam is making the "loading screen" into a variant of enum Menu instead

i think it works either way, but my screen states are "heavy" (screen transition animation, reset the camera, maybe despawn background music, etc.) while menu states are "lightweight" (just hide the previous menu and show the new menu)

and i didn't want a heavy transition into and out of loading

just depends what you're going for so no need to change it in bevy_new_2d

so ultimately i only had three screen states: splash -> title <-> gameplay

which makes me question the abstraction a little bit 😅 but it's probably fine

[tacit verge]

@finite depot regarding -Dwarning in release workflow, technically it will prevent release if you have e.g. dead code or unused imports, stuff like that

release workflow doesn't check lints but it still emits warnings during the compilation process

[finite depot]

Yeah but it doesn’t stop, does it?

[tacit verge]

with -Dwarnings i believe it does

which i personally want, but i can see the argument

[finite depot]

Ah I see

[tacit verge]

i misunderstood the pr initially

btw another option is to add an opt-in "Ignore warnings?" checkbox when you manually trigger the release

[finite depot]

Oh wait, I see

I thought this was about CI

👀

Whoops

[tacit verge]

same lmao

[finite depot]

Hehe

[finite depot]

I kinda like that

It’s unobtrusive

[tacit verge]

(build for xyz? checkboxes are neat too)

although for that, you have to consider what happens to the "release on pushed tag" trigger. does it still release to all platforms like it currently does?

[finite depot]

I would also like to think about uploading to itch on CI

I think I also want that for non-jam stuff

And I believe most people during the jam would love it

[tacit verge]

yeah it was a great experience

push a commit and 4m later it's live

i had to turn off notification spam though

itch.io notifies (and emails) you for each build you upload by default

finally found out how to disable it recently before the jam lol. the setting is pretty hidden

[finite depot]

Oh plz share

I need that as well

[tacit verge]

let me check rq

[finite depot]

Btw how was your jam? 🙂

[tacit verge]

good! i'm very happy with my final submission

wish i could have made it harder to win, but it's a jam so i have to make the player god lol

i made another roguelike deckbuilder hehe

my favorite genre

i saw you worked with jondolf again and made the zombie waves game

i'll probably try it out once i start playing others' games

[finite depot]

I love that genre as well 😄

[finite depot]

Yee I just really really wanted to make a shooter

[finite depot]

Seriously just the genre tag is enough to make me want to play your submission haha

[tacit verge]

this time it's turn-based so i learned how to do that in bevy. it was actually not too bad, i have an enum Phase state for the different phases, and a StepTimer resource. i run a "step xyz phase" system within the proper Phase whenever the step timer finishes, perform a single step of the simulation, and either set a new cooldown for the step timer or change the phase

then UI syncs to the change in the simulation

[tacit verge]

i think it's really cool that you're making 3d games with bevy with a lot of more "advanced" 3d features

from the outside it looks kinda like the state of bevy ui though in terms of DX

like you have to know how to work around all the common issues and build a lot of your own abstractions

maybe it's not so bad with tools like skein etc. though

[finite depot]

I was actually wondering myself how to implement a turn-based thing like Pokemon with Bevy. So a state enum with turns?

[tacit verge]

yes but calling it "phase" makes it more conceptually flexible

because you can have things like a "setup phase"

and player / enemy turns would correspond to either particular phases or sets of phases

action enabling / disabling is also helpful here. you need it to disable actions while the game is paused anyways, so just disable based on phase too

i also had a resource counting how many "rounds" there have been, which increments whenever you return to the initial phase. was useful for certain mechanics

and same for how many "steps" there have been within the current phase

(code: https://github.com/benfrankel/flux_pursuit/blob/main/src/game/phase/mod.rs)

[finite depot]

The DX is actually mostly fine, the biggest issue is that you run into a lot of bugs fast once you combine features since they’re mostly tested in isolation.
For example, first person usually requires 3 cameras (UI, view model, world model), but not a single HDR rendering feature works out of the box with a multicam setup. Also Wasm just does not respect walls at all once you have more than a two lights or so on a big map, so you need to make your map in a way where it doesn’t look buggy that lights go through solid walls

[tacit verge]

we should make inscryption together for the next bevy jam 💅

turn-based 3d roguelike deckbuilder

[finite depot]

And locking + unlocking the cursor is nearly impossible to do reliably, you have to do a ton of tricks

[finite depot]

Thanks for the reminder that I still need to play it 😄

[tacit verge]

oh yeah i highly recommend that and noita

my two favorite games wrt game design

[finite depot]

Level design in 3D bevy is in a great spot tho, TrenchBroom is so well integrated that I doubt I would switch to a Bevy editor for mapping even if it came out tomorrow.

[austere shale]

Play it, it's awesome. After rating jam entries ofc 😁

[fierce jewel]

Nice! Is it similar to using LDtk with 2d stuff (if you have any experience with that)?

[finite depot]

Aye aye
I'm not home until tomorrow, but I'm getting very excited to play all these cool entries from looking at the screenshots and reading comments 😄

[finite depot]

I only ever watched people use LDtk, so I have very limited experience.
In TB, I can mark components to be exposed in the editor along with some 3D model.
Then TB will show it as an object you can drag and drop into the scene. If you click on the object, all fields of exposed components are visible as editable key-value pairs.
For example, I could drag a lamp into the scene with an exposed PointLight on it that will allow you to change the intensity in the editor. You can’t see it in TB itself, but saving the map hot-reloads it in Bevy, so you have a very fast iteration time 🙂
Our level designer for the jam is not a dev, and she was able to create the level without touching a line of code. That was pretty neat!

[fierce jewel]

Neat, so it does sound similar-ish to LDtk, although LDtk might require a bit of work to get setup. I've never tough TB so I have little experience with it.

The integration might be a bit better than with LDtk, but that's more-so just a limitation of the current LDtk implementation than anything else.

I'm mostly asking because LDtk is what I'm mostly familiar with.

[finite depot]

I’d love to try it at some point, it looks like really neat software!

[fierce jewel]

It is! The documentation...could be better but overall it's really nice and fun to use

If you do give LDtk a try feel free to reach out with any questions regarding it. I should probably sit down and write an LDtk book or something

The ONLY things I'm still irritated about is the lack of isometric support (and also hex, but I don't really use hex tiles). If it had that, it would be perfect.

[steady palm]

I used it for the jam and was a bit frustrated by some of the limitations - for example, there is no mechanism in the entire editor for non-square sprites to be used for entities, which is very strange and made it so that I had to use placeholders and wire up the spritesheet layout and stuff in bevy instead

[austere shale]

U sure?

[steady palm]

yeah, you can make the entity non-square but if you use a sprite for the editor image it has to be square

[austere shale]

Gotcha, sorry

[steady palm]

using a sprite for the editor image is nice because bevy_ecs_ldtk then hooks it up for you with the right layout

I'd love to have used it for all my sprites, but as-is I had to do like half and half

[steady palm]

(plus it allows you to better visualize everything in the level)

[fierce jewel]

I mean that is a bit of a limitation, but I'm not quite sure what sprites you'd have issues with personally.

[steady palm]

we used a sprite pack that had many non-square sprites lol

[fierce jewel]

Fair enough, I've just never ran into it myself.

[steady palm]

a simple example is this animated background water shimmer, which ideally we'd be able to visually place in ldtk without adding 160px of empty padding or using 16 tiles for it which must be animated separately

(i just sent one frame of it but yeah)

anyway, aside from that limitation, it was an absolute blessing for iterating on levels and bevy_ecs_ldtk being able to just hot reload it was so good

would use again

[normal shale]

Did we ever try SCCache for CI? If yes, why did we go with rust-cache instead?

[tacit verge]

we did: https://github.com/TheBevyFlock/bevy_new_2d/issues/118

https://github.com/TheBevyFlock/bevy_new_2d/issues/128

i'm not familiar with the details, though

i don't fully understand what exactly sccache does. my understanding is it's good for sharing build artifacts between different projects on the same machine

which is the opposite of what you need for CI, which is the same project on different machines

but it might be more general than that

[normal shale]

Honestly I also don't really understand it.
I'm asking because I finally got the time to share some of our CI findings on the Rust Zulip and someone asked what caching we are using and if we are using SCCache.
I'll try to ask if they are using it and if they have more insights, but maybe rust-cache is just better for our use cases :)

[normal shale]

sccache works quite good with e.g. a s3 backend, and helps with speeding up recompiles of heavy dependencies. fast crates are probably not worth it, as the fetch time will be larger than recomliling from scratch. also sccache doesn't work with incremental compilation, but that should be disabled on CI anyway

[finite depot]

I personally notice no difference when using it locally. I suspect something is acting weird somewhere, so it's not triggering.
I found a global shared target directory to just be the straight up better version in every way of what sccache tries to do

[tacit verge]

i'm gonna cook up a better abstraction to make this free

(not for bevy_new_2d obviously)

[tacit verge]

"pushing automatically on a tag" is a feature that sounds nice in theory, but in practice we should make releasing a more deliberate action

due to the fact that it uses a lot of CI minutes and also deploys to itch.io

plus that will make it easier to have one place for release workflow configuration with e.g. checkboxes for which platforms you want to release to, or -Dwarnings

@ionic condor

too many exported symbols (got 142869, max 65535) is interesting

iirc some people were seeing that in relation to using dioxus-cli for hot reloading on windows

oh after some searching, that might be related to using -Zshare-generics=y on windows, which we are doing in the release workflow rn

interesting that i haven't hit this issue myself then. maybe related to the dependency tree

if that's the issue then it's an easy fix, although i believe it'll make the windows build even slower 🫠

[coarse linden]

last I knew, sccache is transparently bypassed when rustc is doing incremental crate compiles, so, almost all the time when using OOTB defaults and not actively doing release builds. definitely undermines our expectations.

this first caveat is a doozy too https://github.com/mozilla/sccache?tab=readme-ov-file#rust

[trim zealot]

jam-wise I was also stuck in an airport later in the week trying to slam out some jam code in small free time between boarding/etc and spent a decent amount of time fixing clippy warnings that I didn't really need to fix for the jam game to work.

it feels like a lot of the feedback listed above is relevant to "is this a game jam template or not", for example a jam template by default could ignore clippy warnings in actions, only enable the web build by default, etc.

[finite depot]

Yeah maybe the template should ask you whether you want the jam CI or not

[tacit verge]

in my jam template i have separate ci.yaml (ci for the template itself) and ci.yaml.template (ci for the user)

in the latter the Docs and Tests jobs are disabled

i think clippy lints in CI are still desirable even for a jam template?

since you can ignore failing CI if you want

although if the user starts ignoring failing CI, they may miss a more important failure

[finite depot]

Yeah we'll have to think about this when / if we switch to continuous itch deployment on main 🙂

BTW, having played a large part of the submissions so far, I'm very happy to see how many people adopted the main menu!

Having dedicated audio settings for each entry is sooooo nice for me as a player 😄

And a few people even put custom settings in there!

Or used the widget layout to add a level selector!

e.g. here

This is lovely!

Credit to @amber prism ^

Hi @steady palm 👋

[steady palm]

I have a personal bias against requiring an extra click to get through a main menu for jam games (unless there's some art, logo, or extra buttons like level select to warrant it), that's the only reason I didn't use it, but having the pause menu and volume slider out of the box was very welcome!

[steady palm]

hi! :)

[finite depot]

Yeah I also think for most submissions it makes sense to just skip straight into the first level

Fortunately, that's easy to opt-into. Just set the state transition on startup.

But it's worth considering whether we could just remove the main menu entirely

Since, as you note, we have the pause menu already

Or at least also default to just jumping into the first level

[steady palm]

I think strictly speaking the main menu by default is very well justified, especially since in the template it doubles as a loading screen (assets begin loading in splash screen and it skips straight into the game if everything managed to load before the player clicked play)

I just couldn't figure out how to use that with bevy_asset_loader and so tore out that wiring anyway

[tranquil breach]

If you're looking for a point of inspiration, the CLI uses a workflow_dispatch action to build new releases (https://github.com/TheBevyFlock/bevy_cli/blob/main/.github/workflows/build-cli.yml)

It's a little difficult to find, but very manual and won't be done without someone wanting it to

You can setup inputs and checkboxes for workflow_dispatch actions, which is also pretty cool!

[tacit verge]

yeah, i think this would be for the best. we already explain how to do this in the docs since we have both a pushed tag trigger and a workflow dispatch trigger atm

[tacit verge]

https://github.com/TheBevyFlock/bevy_new_2d/pull/438

[tacit verge]

here's a thought: user creates a new project with a really long title, creates an initial commit and pushes, their CI fails on initial push due to formatting

because the long title causes rustfmt to want to wrap some lines in the generated code

we could run rustfmt in the post-generate hook but ^\_(``/)_/^

[tacit verge]

here's what a manual release looks like currently (default values, but i typed in v0.1.0):

[finite depot]

lovely!

I find the ? a bit noisy

But looks good otherwise 🙂

[tacit verge]

https://github.com/TheBevyFlock/bevy_new_2d/pull/440

same!

[finite depot]

😄

[tacit verge]

it felt better when there were only a few checkboxes

this is devious

(2 minutes on apt-get, 3 seconds on cargo test)

anyways new ui

[finite depot]

next jam, only half of all submissions will include Windows builds

[tacit verge]

lowkey makes me wonder if we should be caching build deps

currently we always apt-get update and get the latest versions of build deps

which means we might get a newer version that breaks something

very unlikely ofc

not a big enough deal for me to worry about this though

ah the rustflags env code is wrong, echoing something into GITHUB_ENV doesn't make it available in the current env until the next step lol

so you end up with only -Dwarnings, or w/e

https://github.com/TheBevyFlock/bevy_new_2d/pull/441

[trim zealot]

I removed all native builds from my ci this jam 😆 web is like half the time to build

[tacit verge]

yeah the web build is so fast, even with wasm-opt

[tacit verge]

our buttons all trigger on middle and right click btw 😄

that's the default when you use Trigger<Pointer<Click>>, somewhat awkwardly

we would need to add if trigger.event.button != PointerButton::Primary { return; } to every button's observer

[finite depot]

lol

[normal shale]

How can that be the case, considering it has to also run wasm-bindgen and wasm-opt?
I guess wasm-bindgen loses overhead after rustc optimized for size?

[ionic condor]

maybe you could help this guy with distributing on linux? https://discord.com/channels/691052431525675048/1390427492082258011

[finite depot]

We don't distribute AppImages yet either, so unfortunately not

Still trying to nerdsnipe @hearty cosmos into implementing that hehe

[ionic condor]

Idk, but I think that dude wants "at least some way of distribution", not sure if he's wanna go AppImage way

[finite depot]

Fair enough

@robust hound we just zip our stuff up for distribution and that's working great so far

[robust hound]

@finite depot Thanks, I've been perusing your release.yaml which if I'm reading correctly uses ubuntu-latest as the build platform. Do you know which version of glibc this uses and have you had any issues with users on older linux versions?

[hearty cosmos]

Flatpak Single File Bundles might be the thing to use :) https://docs.flatpak.org/en/latest/single-file-bundles.html

[finite depot]

@tacit verge do you know about this? All I know is that that works on my modern Linux

[normal shale]

Didn't spot glibc yet, but here's a list of everything included in the image:
https://github.com/actions/runner-images/blob/main/images%2Fubuntu%2FUbuntu2404-Readme.md

[tacit verge]

i don't know, same here. but yes, we use github's ubuntu-latest runner for linux releases

[robust hound]

24.04 ships with glibc 2.39

[tranquil breach]

We build the CLI with Ubuntu 22.04 specifically to support older versions of glibc: https://github.com/TheBevyFlock/bevy_cli/blob/ff8d39aba29f6f04aecd7f8ec429d173649646ee/.github/workflows/build-cli.yml#L63-L65

(Specifically for the precompiled version of the CLI)

I remember @normal shale ran into an issue using the precompiled binary on Pop!_OS before we switched from ubuntu-latest to ubuntu-22.04 (see his original comment)

[fierce jewel]

You know, I really wish sharing RustRover Live Templates were easier as I would love to share the Live Templates I've made for Bevy as I do have some I've been working on over time, but because of how they are, it's not really easy to share ^^'

[fierce jewel]

Like I have some nice surround templates, plus also a rather nice Relationship Template I put together.

[finite depot]

@tacit verge https://github.com/TheBevyFlock/bevy_new_2d/pull/445

[tacit verge]

is_multiple_of??

that's in the rust std?

[finite depot]

yep, it's new 🙂

[tacit verge]

oh 1.87

nice, modulo is fine but i suppose that expresses intent better and would be more universally understood

oh and it handles rhs == 0 correctly instead of panicking

[finite depot]

@crude cobalt this fixes your bug report 😉

[crude cobalt]

thanks

[finite depot]

@tacit verge RC time 👀

I think the upgrade should be trivial

BUT

I'd also like to move the UI to feathers while on it

any objections to that?

Alternatively, we could keep the theming by using the upstream headless ui widget and show how to theme them

at the cost of boilerplate

Talin says that the theming API will drastically change

so we shouldn't invest too much time there imo

[tacit verge]

no immediate objections, my understanding is that feathers => editor-styled widgets?

we expect users to retheme the widgets themselves, so the temporary theming in the template itself shouldn't be too important

[finite depot]

yep

[tacit verge]

(ofc in practice, during game jams at least, users will usually allocate their short time towards more important things)

[finite depot]

some far-away future may bring something like feathers that is geared towards games, that can be easily themed using nine patch

[tacit verge]

yeah, that would be a perfect fit for the template imo

[finite depot]

(Talin is thinking about doing that post-feathers post-bsn)

[tacit verge]

if the plan is for it to be easy to swap between feathers and this hypothetical future theme, that would be even better

[finite depot]

I believe so

Also, feathers will probably allow theming the font and color

so that should already go a long way

[tacit verge]

separate prs will make this easier

[finite depot]

good idea

I want to port some stuff to 0.17 tomorrow

[tacit verge]

i should be able to review

[finite depot]

I'll try to do my own crates first so that I already run into issues there and don't run into accidentally breaking the template

If I get through them quickly enough (and I think I should), I'll do the template next

[tacit verge]

at this point i want to keep the boilerplate low for personal reasons too 😄

easier to maintain

[finite depot]

@tacit verge on it now

should we use bevy_seedling while on it?