#0.14 Bevy Jam
1 messages · Page 4 of 1
good night
thanks for all the reviews
so the flattening is merged so this is a moot point, but
imo the benefit of the previous directory structure is that it provided logical places for the user to extend the template with their own code
it looks silly to have nested folders / modules in a template with barely any code in it, and it's true that the template itself may never need the structure for its own code
but it's possible to predict what types of things users will want to add to an extent, and provide a structure that already enables that with limited-to-no refactoring required
for example, it's likely that the user will want to create their own utils. now they'll either be mixed in with the ui utils, or they'll have to refactor util/ themselves
whether this point was lost or we've decided it's out of scope, i'm not sure
you should prob do it yourself and i'll review
Completely agree with your assessment. It just makes the template look a bit more scary by implying complexity that is not there. But the upside is that a user won’t have to go move stuff around to reorganize because things are already organized. Dunno what’s best in this case. Personally, I prefer the more nested approach, but the general vibe for others was different. But then again, they didn’t try actually working with it (i.e. making a game), so they couldn’t see the benefit in action that way.
Dunno what the best call is here. For util specifically, I feel like it’s inevitable that a user will want to extend it. Who does not have util‽ So I'd keep the nested mod. This is not a strong opinion tho.
Do you have strong feelings about that case, @rigid geyser? I think we merged pretty much all other changes in separate PRs.
Looks pretty good to me 🙂
Set it to ready now. Huh, no merge conflicts. Cool!
how is that possible o.o
Oh wait
yeah seems to be diffing from an older commit
My GitHub mobile UI just didn’t show them
Oh well, I’ll fix them in a few hours
But you can already review it
- not sure about the full suite of derives for every type
- what's the benefit of e.g.
reflect(Hash)and other traits?
Nameconvention for entities: i doPascalCasein my personal code. curious if there's a standard for this in the bevy community, or if there should be
- Fine with cutting it
- No idea honestly
- It’s for display purposes, so whatever is nicest to read naturally
for 2, ive only done reflect(Resource) in the past because it allows the resource to be viewed in inspector
And you need to reflect Component for the Blender workflow
ic
I know Bevy and Avian always reflect everything available, so I was following suit
But I don’t know the exact benefits
me neither. it's possible it's more relevant for libraries that don't know how their types will be used by users
Library code is also different from binary code, so we may be fine cutting it
Yeah exactly
keeping reflect(Resource) and reflect(Component) is 👍 from me
If we trim down the reflects, I might as well remove the serialization
Same rationale imo
everything else in the pr seems straightforward / uncontroversial
yeah fair
if we're not doing anything with serialization
if we do end up needing it we can add it later
More about whether we think most users will do something with serialization. I don’t think so, but I’m biased since I'm using the Blender workflow mostly and that one does its serialization over Reflect, so you don’t need the serde traits
right
just have to draw a line somewhere i suppose
inspector requiring reflect(Resource) is common, blender requiring reflect(Component) is common
should i merge the simplify UI pr or wait for mini's review?
ig i'll wait since i don't think anyone else is trying to work on those files rn. feel free to merge it for me if that changes
Btw, I just noticed that in terms of comments, we have far surpassed the other working groups 😄
you should see the old states thread that wasn't a working group
Oh I bet that was controversial
so controversial that i ended up making my own crate 😄
hm it was only 1363 messages actually, felt like more. still crazy for a random thread in a text channel
this is basically the bevy jam warmup
I'll merge your PR now since I think it's very similar in spirit to what @agile dirge already did.
enough 3rd-party crates have been updated to 0.14 at this point that i can start updating my personal template :)
only missing bevy_editor_pls but ive commented it out for now
That's nice 😄 I'll still need to wait for the Blender workflow
@bitter sparrow https://github.com/TheBevyFlock/bevy-template/pull/78 ready now
After that's merged I'll remove the fixed timestep
And then I think the only thing missing in the code is sound effects
Rest is documentation and CI stuff
You know what, now that's an uncontroversial opinion
core/booting.rs snuck its way back in in your pr
Fading splash screen as well
Oh thx
oh yes absolutely. i have this in my template and it makes such a big difference
feels so nice with the fade
should PhysicalTransform impl Component? it currently does not
ik we're ripping that out in a sec
Fixed
It does 😄
Just manually for the hooks
ah right
I've set it to automerge as soon as you approve since Mini already wrote they'd approve it
left some comments
also cargo fmt complained in CI
do you have format on save configured?
Addressed all
Yes, but with rustfmt nightly 😄
That one formats that line differently, haha
register_type::<(...)> recursive registration ❤️
approved
great, gonna yeet fixed timestep now
cool
the upstream fixed timestep example is not merged yet, right?
can create an issue to link to the example once it's merged
copy-pasted from my doc comment in the code
Objective
This example shows how to properly handle player input, advance a physics simulation in a fixed timestep, and display the results.
The classic ...
I generally think a “grab bag” util module is a bad idea as the scope isn’t well defined. Better to organize modules using actual relevant context
Especially when we’re “preemptively” adding it in this case when it isn’t really needed. Not a pattern we should be encouraging people to use right out of the gate imo
@bitter sparrow https://github.com/TheBevyFlock/bevy-template/pull/89 ready
one comment, otherwise good
Fair enough, I agree in general. I guess my main issue is that I feel like users will want/need/create a util module very quickly when working on a game since Bevy has certain places that currently simply require generic/grab bag util. For example, people following @shadow light's popular best practices will instantly add the get_single and get_single_mut macros there. Then again, if the util module was just renamed to ui, they would at least be encouraged to add a new module for that to not bloat the one we got.
@bitter sparrow how do you feel about renaming util to ui?
my concern with that is i don't think all ui should go in there. for example, a health bar would be better in game/health.rs
Good point you raised there, thanks
Yeah that's true
ui_boilerplate
it's specifically "util" ui
that's at least honest
cart's suggestion in the pr was ui_tools
I'm fine with that
i went with util/ that "just happens" to only contain ui-related stuff
i think util/{ui stuff mixed with non-ui stuff} is a better outcome than util/ and ui_tools/ as separate top-level folders
in the case that a user adds their own utils
I agree, but I want to reduce some nesting to remove perceived complexity
well currently the template itself has no nesting there
But I'm very open to rename it back if we need non-ui util
well ok. ill approve and find a way to shoehorn that in asap
btw unrelated
dev.rs -> dev_tools.rs
we call it "development tools" everywhere in comments
There we go
game_tools and screen_tools when 👀
src/game_tools/spawn_tools/player_tools.rs
symlink to src_tools for better dev experience 
Set it to auto-merge on your approval
Since I don't feel qualified to add the audio stuff, I'll instead check the macOS builds later
And maybe the local Wasm stuff
macos build fix will help. tough to do that on linux
Can I leave the splash fade to you? You already have experience with that 🙂
yes
thanks
Also no clue how cargo-generate works. @hidden pond, I think you know about this stuff?
i suspect it will be challenging to reconcile cargo-generate and .github/workflows/release.yaml
and ci.yaml
Probably? I have no idea
I'll later probably release a bunch of patch versions to test the builds generated by the release workflow, don't mind me
we may have to have two separate repos, one that's just a template, and one that's generated from the template
came across this: https://github.com/SrTemplates/Bevy
this is not valid .yml pre-generate
i wonder if there's a way to make a repo that's automatically generated from a template repo
you can manually trigger the release workflow on github without pushing a tag btw
but it's fine either way, we can delete tags / releases manually as well
I think if supporting cargo-generate forces users to use it, I'd rather have it be a regular GitHub template
btw just realized if you do DefaultPlugins.set(ImagePlugin::default_nearest()) in a pixel art game
the splash screen will get screwed up by that and look really bad
can manually specify to use ImageSampler::linear() for the splash screen image in case a user overrides that
also just noticed that somewhere our title screen lost its background color, now it uses the grey clear color
in my template:
[main 865eb7d] Migrate to fns as plugins
27 files changed, 272 insertions(+), 391 deletions(-)
all those pub struct XyzPlugin; impl Plugin for XyzPlugin { fn build() { ... } } lines add up
the bigger benefit is the -1 levels of indentation
Woah that’s a lot
Also convenience when writing a new file. I'm a bit faster writing just the fn.
I do that by habit (plugin strct, impl, fn build...) but a while ago Bevy added support for using any function taking &mut App as the only arg (iirc).
That's what we are discussing 😄
The template uses exactly that style:
use bevy::prelude::*;
mod foo;
mod bar;
pub(super) fn plugin(app: &mut App) {
app.add_plugins((foo::plugin, bar::plugin));
}
I've even setup a VSCode shortcut that turns plugin into:
use bevy::prelude::*;
pub(super) fn plugin(app: &mut App) {
todo!()
}
Ah I didn't read enough context 😅
You default to pub(super) since you're most likely to build smaller plugins only relevant to the nearby scope?
Yeah, every module is its own plugin, so you only need to be visible to your parent module so that it can add you
That makes sense, instead of polluting the global scope. Will start using that 🙂
Has anyone here used embedded_asset in combination with trunk? I'm getting a Failed to find src_prefix "src" in "src\\my\\path\\file.rs" and I'm at a bit of a loss
Can you share it and how you added it? I have considered doing that exact thing but haven't had time to actually do it yet
I could even add it to the template 
But yeah, sec
Might be too opinionated, I sometimes get lost when these templates have too much stuff
Do you have a small example for this? I have used trunk a bunch but I don't think I have ever seen this error
So, before I copy-paste it, know this: rust-analyzer comes with a bunch of default autocompletes that are completely overwritten when you try to add a new one. So, I have to include the default ones in my setup as well.
"rust-analyzer.completion.snippets.custom": {
"plugin": {
"prefix": "plugin",
"body": [
"pub(super) fn plugin(app: &mut App) {",
"",
"}"
],
"requires": "bevy::prelude::*",
"description": "Create a new Bevy plugin",
"scope": "item"
},
"Arc::new": {
"postfix": "arc",
"body": "Arc::new(${receiver})",
"requires": "std::sync::Arc",
"description": "Put the expression into an `Arc`",
"scope": "expr"
},
"Rc::new": {
"postfix": "rc",
"body": "Rc::new(${receiver})",
"requires": "std::rc::Rc",
"description": "Put the expression into an `Rc`",
"scope": "expr"
},
"Box::pin": {
"postfix": "pinbox",
"body": "Box::pin(${receiver})",
"requires": "std::boxed::Box",
"description": "Put the expression into a pinned `Box`",
"scope": "expr"
},
"Ok": {
"postfix": "ok",
"body": "Ok(${receiver})",
"description": "Wrap the expression in a `Result::Ok`",
"scope": "expr"
},
"Err": {
"postfix": "err",
"body": "Err(${receiver})",
"description": "Wrap the expression in a `Result::Err`",
"scope": "expr"
},
"Some": {
"postfix": "some",
"body": "Some(${receiver})",
"description": "Wrap the expression in an `Option::Some`",
"scope": "expr"
}
},
there, only the first entry is actually relevant
Thanks, yoinked it
Happy to share 😄
I'd be really glad if you could take a look at my branch
sec
It's fairly minimal. In src/screen/splash/mod.rs we have an embedded asset. Run trunk with trunk serve, I've setup the right config already
(the right config to my knowledge)
And here is the Bevy code that is panicking: https://github.com/bevyengine/bevy/blob/main/crates/bevy_asset/src/io/embedded/mod.rs#L141
/// For most "standard crate structures" the default works just fine. But for some niche cases (such as cargo examples),
/// the `src` path will not be present. You can override this behavior by adding it as the second argument to [`embedded_asset`]:
Is trunk a niche case? Note that building the Wasm stuff without trunk worked with the embedded asset
trunk is generally a bad fit for Bevy in my opinion
Do you have another recommendation for easy local web deployment?
I'm all ears. I just don't want to force users to run the whole Wasm building command pipeline by hand, and a shell script won't work for Windows users
https://github.com/bevyengine/bevy/tree/main/examples#build--run-2 after "Then serve examples/wasm directory to browser. i.e."
Yeah that is exactly what I'm trying to avoid 😅
At work we use wasm-pack but that's even worse. We just haven't bothered changing it
I mean the part before basic-http-server, that's fine obviously
Can one do that maybe with a custom cargo command?
people will have to learn how to use that, I don't think hiding it behind something that makes assets a pain to use is a good idea
I'm not sure if they have to. If there's an easy fix for the embedded asset, trunk serve is as easy as it gets
But yeah, if that doesn't work, it's not the end of the world
I just tried running your branch, and I didn't get this error. It seems to run fine?
Are you on Windows?
yep
And you see the Bevy splash screen in the browser?
For reference, this is how it should look: https://the-bevy-flock.itch.io/bevy-template
(that one uses a manual wasm build without trunk)
Oh that's neat. Like the throbber y'all used lol.
Just tested it on Linux and that works 👀
Hmm, then we just need to find some way to make this work cross-platform
Interestingly, when I replace this:
embedded_asset!(app, "splash.png");
with
embedded_asset!(app, "", "splash.png");
I get "Path not found: bevy_template/screen/splash/splash.png", but no crash anymore.
I'll test the manual build again on Windows to check if this is a Bevy bug
It feels like a bug yeah, loading an asset from the root asset directory should work on all platforms
I looked a bit at the _embedded_asset_path code, and I don't understand how it's platform dependent. I think we'll need to insert some debug logging on a Windows machine to see what's going on
Specifically this PR should have taken care of that
Incidentally, that PR also introduces the panic we're hitting
Update: yeah, I'm getting the same panic on a manual build. Let's see what happens on the relevant Bevy examples
Update 2: Official examples work, but the docs do say that example path resolution is different from regular resolution. @bleak grail, it really looks like a Bevy bug and not a trunk thing. Maybe we'll have to disable embedded assets for now :/
Gonna start working on a minimal reproduction now and file a bug
I have written some stuff about trying to use trunk with bevy here: https://github.com/bevy-cheatbook/bevy-cheatbook/issues/253
I recently didn't completely hate wgpu's setup when I looked at it. Might be worth looking at but I dunno how well it fits in here. https://github.com/gfx-rs/wgpu/blob/trunk/xtask/src/run_wasm.rs
there we go
Thanks for the links!
Would another workaround be to place the splash screen in the assets dir, but manually exclude it from packages somehow? Don't love that either.
I use load_internal_binary_asset in my stuff which I assume would have the same issue? It's a library though and it's easy to configure the asset to be excluded from the crate, so I just put it it in the assets dir.
Filed a bug
Ouff, it would be quite unfortunate to ship the semi-official template with such a workaround :/
I guess I'll just make the splash screen a regular asset for now
Or, splash.png is 30kb, just let it be in the packages.
Hmm? What do you mean by that?
Oh, I guess I'm making a weird assumption that things work okay if the thing is in the assets directory.
I'll take a stab at fixing this I think, that seems simpler than doing workarounds
But it's outside of there to prevent it from being included redundantly in bundles, right? But it's 30kb so who cares?
thanks 😄
nope, doesn't work either then
...I think
let me double-check
Oh, I think it works 😄
at least in the minimal example

Meh, still getting the same error on the template
Dunno why that workaround works on the minimal example and not the template :/
I read through the issue description and those are some pretty good reasons not to advertise using trunk, thanks.
I'll just add a little powershell and .sh script with the manual incantations, that should do
I could make a very simple host with axum and we can add it as a bin
but probably too much
Yeah I'd like to avoid that if possible
Maybe those issues are a little less painful these days. I know @pseudo marten 's template uses it, and I remember some sort of janky workaround was used for... something previously and it seems like they don't need to do that anymore. 🤷♂️
but then we'd have a
- Rust based hosting, no additional tools
- Correct missing file behavior
I'm mostly concerned about what happens when a trunk build goes to itch
But I'm not seeing any configuration for disabling SPA mode there, so I dunno what's going on.
Since regular builds won't work anymore (unless you duplicate the index.htmll)
If you manage to write a little thing that
- builds Wasm targets and passes flags along to
cargo - runs wasm-bindgen
- copies the assets
- starts a local server
- opens the browser
I think you should publish it as a cargo binary
We could then just tell people to do cargo install serve_bevy or whatever
that'd be pretty cool 👀
sir this is wendys
i technically worked with all of those features
but it would take some time to make
Then I don't think there's much reason to add a host to the template. The main pain is the extremely ugly call to
cargo build --target wasm32-unknown-unknown --no-default-features
wasm-bindgen --out-name $BINARY_NAME --out-dir wasm/ --target web .\target\wasm32-unknown-unknown\debug\$BINARY_NAME.wasm
cd wasm
http-server
The http-server itself is great, no issues there. The main thing I like about trunk is that it condenses everything into a single trunk serve
and the file-watcher, but that's secondary
its probably easier to PR a feature to trunk then
they use axum anyways
it's there
Oh that's cool, that's the first issue solved then
Do you know about this part?
The html file produced uses absolute paths to reference js/wasm files. This assumes the project is being placed on its own server at the web root. That might be true in a lot of cases, but it creates a great deal of confusion when deploying to itch. On itch, your project is in a subdirectory and the CDN serves missing files as 403 errors.
"html file procuded", trunk make a new html file?
Yeah, the html file you input has these special trunk-data tags that are used by trunk to generate the actual file at the end
It also inlines stuff for you and init()s your Wasm
I checked out the issue and left a comment with some updates. Trunk is anything but perfect, but I think it is more convenient than some shell scripts.
Thanks!
That's great, thanks. I wrote the issue not because trunk=bad, but because trunk requires configuring and nobody was telling bevy users how to do it, and I didn't know.
It's great to have a place now that has these settings collected 😄
(And also at the time there was no no-spa mode)
Thanks everyone, looks like we can use trunk for the template then 🙂
iirc the relative path thing is recent too, right? Didn't that require manually editing the generated html before?
At least the param existed in the Trunk.toml since 2020
but idk if it worked the same way
ah, found it: https://github.com/NiklasEi/bevy_game_template/issues/99, my memory was correctish
🤷♂️ re: spa-mode, is that configurable in Trunk.toml, or something users need to do, e.g. trunk --no-spa serve?
Just added an issue for that https://github.com/trunk-rs/trunk/issues/819
@pseudo marten could you take a look at https://github.com/TheBevyFlock/bevy-template/pull/95 ?
Ah, good to know!
I was gonna add it myself but it was already in the code 😛
Oh right that, I didn't really start so anyone can take it
I'm asking because I have no idea how audio is best done
me neither 😉
hehe
actually thats not true
i have ran into a decent convention
it's the same as spawn api
Ah really?
but can be much simpler since sound doesn't have much config
yeah
you only need an enum with sfx variants
and you make it an event
(I also thought it might be neat to show animations https://github.com/TheBevyFlock/bevy-template/issues/94, but that's not as important imo)
true
but with audio we can do the asset offloading thing
Good idea
I'll probably no longer touch the code itself and do the devops stuff now
Yeah I'll takle that in few minutes. Should be easy (famous last words).
Also hope what I did with trunk works on itch, need to debug that once it's merged and deployed
thanks for double-checking 🙂
I did that on cart's PR and it didn't work
i trust no one now XD
also, one question about removal of restart audio .js
wait what, I removed it?
yea
oh, it's no longer imported, right
But it's still <link data-trunk rel="inline"'d
that should be the same, right?
I'm not a web dev 👀
checking the dist/index.html, it just added that script inside a script tag
Well, we'll know it works when i add sfx 😉
do we wanna auto open tab?
there is open = true
one comment about gitignore
besides that, it works
I'm leaving that to your discretion, appr
My local coding wizard tells me to add this magic incantation: https://github.com/TheBevyFlock/bevy-template/pull/95/commits/23667543afa938f5eb36f2b56872dec82502245c
Now it's the same
I'd like that, but it does nothing on my machine :<
But adding it anyways, maybe it works on other OS
@bitter sparrow I addressed your comments
Also, I left you a tiny suggestion on https://github.com/TheBevyFlock/bevy-template/pull/93
i'll add a comment. i think i prefer comments in the template to be in the style of "i might have written this comment in my own game's code"
so like first-person or "we" perspective
since this is gonna become the user's code
No opinion on that, sounds good
@slender belfry would load_internal_binary_asset! work instead of embedded_asset!?
that's what i used for my splash screen before embedded asset was introduced
lemme try
oh it's a bit of a mess to add lol
let me copy/paste the code you need to use here
please do 🙂
Or add it directly into the PR
I think maintainers can just push onto it
I'll just revert it if it does not work
load_internal_binary_asset!(
app,
SPLASH_IMAGE_HANDLE,
"splash.png",
|bytes, _path: String| {
Image::from_buffer(
bytes,
ImageType::Extension("png"),
default(),
true,
ImageSampler::linear(),
RenderAssetUsages::RENDER_WORLD | RenderAssetUsages::MAIN_WORLD,
)
.unwrap()
}
);
const SPLASH_IMAGE_HANDLE: Handle<Image> =
Handle::weak_from_u128(145948501136218819748366695396142082634);
you have to change the code in several places
oh god what is that
Could you do it?
Not out of lazyness, but because I have no way of knowing if I did it right 😄
Because I might hit exactly the bug in question
Honestly, if that fixed the issue, I'd prefer the user to just have a regular asset over having to see this
But still good to know so we can add that info to https://github.com/bevyengine/bevy/issues/14246
done
it might not compile because i did it in github editor
or the path to splash.png might be wrong
try cargo run first prob
i mean load_internal_binary_asset! isn't great but it used to be the only way to do this
so imo not crazy to have it in the template... with a comment linking to the embedded_asset! bug
that's assuming this fixes the issue
Works
clippy ci complaining, easy fixes
splash/splash.png should be the path i believe. and can remove asset_server argument because the handle is a const
on it
added a comment and fixed the issues
Meh, I'd really prefer a regular asset over this.
Let me see how big the splash is after pngcrush
15 KiB
I think that's pretty alright
the question is how many frames it takes to load it
probably like 1 or 2 :p
if there are many other assets that start loading at the same time, it may take longer though? not sure
let me see if there's anything noticeable
Then we did something wrong imo
itll be the same size in the binary or as a separate file either way
At least for me, it's impercievable among the noise we have because of the spinner on web and the flicker on native
embedded asset guarantees the loading phase will be instant
well either way there should be a comment explaining that it ought to be an embedded_asset! and linking to the bug
Makes sense, but I don't think the benefits outweigh the costs in complexity here. I'd do it for a personal project though.
Agreed
Pushed a commit reverting to asset_server.load() with a comment
ok
approved and will rebase the explicit linear pr after merge
which includes a comment now
funnily enough, internally, bevy only uses load_internal_binary_asset! instead of embedded_asset!
no dogfooding
no need
ok that works too
I have some very strange behaviour where most navigations out of the game don't work.
in Firefox
It's not only bookmarks like in the video, but also if I manually change the URL in the navigation bar
maybe related to prevent_default_event_handling: true in WindowPlugin?
that's meant to prevent like Ctrl+R from doing something web browser-y while you're in the game
Cool cow 🐮
would be odd if it blocked clicking bookmarks though
Can reproduce in my Firefox
I wonder if that will happen on itch.io as well.
Merging it now and triggering a release after to investigate
I'm using trunk 0.20.2 and can reproduce it
tbh we can consider this to be a feature. players should be incentivized to finish the game before they switch tabs
Literally all are gold
oh that song
wait no
do fluffing a duck
sounds like video game music and it's duck themed
like i swear this is the song that plays in Cut the Rope
thats a good one too
ill do monkeys spinning monkeys in credits
cause i already added it
is audio fade in/out possible in bevy_audio
or are you doing a hard cut between the songs? :p
Exciting!
I'll check later, need to fix the wasm build on release first
im doing something bespoke for splash screen fade in/out
is bevy animation good enough at this point that i should be using it for this?
#animation-dev, no clue
splash screen is the only thing we can overcomplicate in here
Okay, very very cool
No way to tell trunk about our wasm-release profile
need to use release instead
What do I do about these?
# Optimize with size in mind (also try "s", sometimes it is better).
# This doesn't increase compilation times compared to -O3, great improvements.
opt-level = "z"
# Strip all debugging information from the binary to reduce file size.
strip = "debuginfo"
Either
- I leave them out of both native release and wasm release,
- I include them in both, or
- I make wasm the default
[release]and then override these options in[release-native]
I don't like any of these options
trunk
/hj
hm
using trunk does kind of lock us into using it for both local and CI releases huh
i wouldve suggested using wasm-release for CI and allowing local trunk builds to be bigger
yep, unfortunately
still think it's worth it for the dev experience
But yeah, it's not a secret that trunk is sometimes a bit crap
local web build is definitely needed
think ill stick to bash scripts in my template but obviously that won't cut it here
- is the worst option
ooh, wasn't aware of that one
honestly
i want to say keep wasm-release profile
and put a comment in Cargo.toml linking to the trunk issue
could a user just cargo build --profile wasm-release ... themselves and then copy/paste the binary?
I can compare the size difference
Don't think so?
With a bit of luck, it might not make a difference
Then we could just remove the different profiles
win-win
(I have low hopes)
(but mayyyybe)
the bevy examples README (which for some reason includes this information) seems to suggest it makes a significant difference
8.5M -> 6.1M for adding opt-level = "z" on top of wasm-opt
Maybe we could "just" fix that? ^^
that sounds like the easiest way forward lol
Per the discussion, it sounds like the author wants to bundle a fix with a revamped config: https://github.com/trunk-rs/trunk/issues/780
But idk if they're willing to accept a little patch in there for us
as a treat
On it rn, will report back
I still wanna know what those numbers are when compression is involved
And benchmark some stuff. But I'm not gonna / probably doesn't matter.
yeah that's true
if it's like preventing loop unrolling
i imagine loop unrolled code would compress reasonably well
Okay, I got some numbers
wasm seems to compress well in general. One of my games (not using opt-level="z" or wasm-opt is 4.17 MB when served gzipped by itch's CDN. (18.75mb uncompressed)
Compiling the template on main, with this config:
codegen-units = 1
lto = "thin"
uncompressed: 28MiB
wasm-opt: 15MiB
And with this:
codegen-units = 1
lto = "thin"
opt-level = "z"
strip = "debuginfo"
uncompressed: 40MiB
wasm-opt: 27MiB
wasm-opt ran with -Os here
Thanks @night saddle for lending us your fast hardware
tested with .zip as well?
binary, binary + wasm-opt, binary + zip, binary + wasm-opt + zip
seems to be a big difference without file compression in the mix at least
nope
sec
First config, with wasm-opt and gzip: 7.9 MiB
Second config, with wasm-opt and gzip: 4.9 MiB
Heck
We really do need that opt-level eh
Who wants to patch trunk?
Or implement this
Alright, let's be pragmatic. These are jam games that need to run on Wasm primarily. I'll set the wasm-release profile to the default. Native will be optimized for size, not speed. People running Windows XP and using floppy disks can rejoice?
seems to be the decision nikl made
no native-release profile?
I could do that, it just seems supremely weird
just include it. users can just not use it if they don't want to
Aight
removing it means they'd have to figure out how to set it back up (and know that it's not set up)
github lagging for anyone else?
nope
i approved it before i saw the rest of the PR 😄
i can make another PR with my comments np
hehe whoops
Because it's already merged I can at least already trigger the release action
Yeah, the Wasm stuff better work well by then, otherwise trunk will definitely be 
Yeah your comments make sense
actually i'm seeing that they don't really make sense 😄
since [profile.release] is special and holds all of the default release profile values
we need to inherit from that in release-native
awkward but your approach was correct

Oh yes
Itch works ;D
@pseudo marten I believe the bookmark thingy is not present on itch. Must be a trunk serve thing
ok i will just do a pass on audio in a separate pr imo
would rather land the feature first
wdym
don't want to keep it in code review hell
ehh, sure but you need to approve
yeah will approve after my nits resolved
why are half of them outdated
pr updated while i wrote them i guess
approved
the fact that you'd rather make a new PR than propose changes is bothering me
um, ok
i dont think this was blocking anything but sure
new PR sounds like you plan to change a lot, is what's bothering me
the prs will continue until morale improves /j
Why we need to remove camera resetting:
- camera doesn't move
- if camera moves, we need to see it move
- that needs level content
player will add level content presumably
what
user i mean
sorry
this will become the user's codebase, it's not meant to be a self-contained project
well, user can also add camera movement
it's not self-contained but what we include should make sense
like, we could provide client/server project architecture even without networking xd
the thing is, forgetting to reset camera will lead to a bug that may not be caught
you'd have to leave the playing state then go back into it to see the issue
that's user's problem
it's a correctness problem imo
if we're in a state that is "allowed" to move the camera around
we don't provide camera movement
then it's correct to reset it when exiting that state
^\_(``/)_/^
we do not try to guess what the user will do and try to fix it for him
if we add moving camera then we will reset it
but it's currently static and it makes no sense to reset it
are we doing a state for asset loading
or rather, asset loading during splash
animations are fresh so lets discuss that tomorrow
you're doing animation for splash?
k
can you finish this?
https://github.com/TheBevyFlock/bevy-template/issues/22
we have player (duck) and splash left
i mean. i guess
splash shouldn't be in assets/ but it's a workaround for an upstream bug
so i don't really want to structure around that
so not clear how to structure with just ducky.png currently
lets maybe at least add a folder for images in general
Yeah I think the user is probably smart enough to figure that out for themselves.
my argument is that in a state that is expected to be allowed to move the camera, it is a correctness bug to not reset the camera when the state exits
I see the point, I just want to keep things like that out of the template for now after the feedback we got
so it's not about how smart the user is, it's about not including a correctness bug in the template
that's speculation
Yeah I think just having
- Assets
- Images
- Audio
is already enough structuring
ok. i'll just create an issue for it then
Fair enough
Yeah that's a good idea.
honestly the camera should reset on any Screen state transition
i dont agree with that...
not until a PR 😂
feel free to delete camera reset code now
no hurry
bevy_state makes it hard to implement something like this anyways. lol
not really
nope :p
oh you could react to a transition event in the update schedule
but that wouldn't be ordered properly
it's slightly different from OnTransition but i made sure you can hook into any transition for S
in the correct order
there are SystemSets for everything
mmm right i asked for those
yeah. possible with a pile of boilerplate
better than nothing
consistent with many other parts of the bevy engine currently tho
pile of boilerplate
consistent
YUP
wait no
there
i just wanna move to states as entities as quickly as possible
i did it in pyri_state and the api sucks cause i'll have to manually impl QueryData to make it nicer
and i havent done that yet
i want the same type to be usable as both SystemParam and QueryData. would be neat
i mean i believe it is possible in bevy currently, just i'd like to actually implement that
here's a prime case where language-level default values for fields would be great:
struct UiImageFadeInOut {
/// Total duration in seconds.
total_duration: f32,
/// Fade duration in seconds.
fade_duration: f32,
/// Current progress in seconds, between 0 and [`Self::total_duration`].
t: f32 = 0.0,
}
i want total_duration and fade_duration to be customized with no sane defaults, but t should default to 0.0
and fn new(total_duration, fade_duration) is a worse API
there's an rfc for this iirc
that's what new is usually used for
you name the parameters though
yes and an IDE will display the param names for you that's true
but without an IDE the code becomes bad, and you still have the boilerplate of writing the new when it's just a POD struct
fading out of the splash screen and then fading in to the title screen is nice too. but i don't think i'll implement that
can be done by putting an overlay over the entire screen and animating its alpha
rn the title screen snaps in harshly
lol, I investigated the embedded_asset! issue, and apparently the file! macro gives src/main.rs on native windows but src\main.rs on the wasm target on windows. That has to be a Rust bug
that seems like a big deal. file! is used to create unique identifiers for some things too
let path: &Path = file!().as_ref();
let components = path.components().into_iter().collect::<Vec<_>>();
panic!("path: {} components: {:?}", path.display(), components);
Windows native:
path: src\screen\splash.rs components: [Normal("src"), Normal("screen"), Normal("splash.rs")]
Windows wasm:
path: src\screen\splash.rs components: [Normal("src\\screen\\splash.rs")]
So the problem is that the path is somehow a windows path, but wasm is seen as a unix platform so Path::new does not accept windows strings
And it's obscure enough (taking file! and making it into Path on a windows machine for wasm) that it makes sense that it hasn't been noticed
mention this here? https://github.com/bevyengine/bevy/issues/14246
Yeah will do, I tried searching the rustc issues for an existing issue first but I haven't found anything. core::file isn't the easiest thing to search for xD
no yeah i tried searching for file too. lol
if you create a new issue on rustc, worst case it's a dupe and a maintainer links you to the original issue i suppose
Cudos for finding that out, sounds supremely cursed
We have evolved from finding Bevy bugs through the template to finding Rust bugs 
next we will find OS bugs
making a game in bevy is against the natural order of things it appears
btw, thoughts on adding facing to the duck sprite as a "polish" feature?
can keep the implementation specific and within movement.rs, probably
and wrap around the edges of the screen..
If you manage to do that, that sounds great
i'll hardcode it
that usually requires doubles
user will strip it out anyways
doubles as in f64?
i'll make facing its own pr anyways
yea
i was thinking i'd just tp it after it's fully offscreen yknow
😄
but i'd split the movement system at that point
oh yeah the movement system shouldve been split a few changes ago
or from the start
ah
but then the audio change made it a teeny bit too complex
i'll do a refactor to split the system up in a separate pr as well
how granular would you be willing to accept
MovementIntent component on the entity populated by the first system based on input?
yep
👍
you're saying to call that ActorController tho?
normalized Vec2 is Dir2 btw
that is true
I'd like confirmation from someone with commercial engine experience
but in UE you have actors and you attach controllers
to do movement
that's fair. i'd accept a name that's an industry standard ofc
yea that's specific to UE where you work on Actors
MovementController?
if "controller" is the concept then i'd say that that's the correct name
that's fine too, it fits our case and people can generalize it to Controller or add more controller types
actually, dont use Dir2
splitting the system up will be the next PR
cause you can't have 0 there
let's keep it numeric
I found the difference between the 2 projects, it happens when a project has both a
lib.rsand amain.rs.
from @inland comet
i mean we could switch from src/main.rs to src/bin/run.rs, which is what i have in my template
to see if that would resolve the windows wasm issue
if that works it's even more cursed tho
The difference might be between lib vs no lib, I haven't tested that
Yeah, that doesn't work. With a lib.rs you get windows paths, without it you get unix paths
i see. so we have to choose between lib.rs and embedded_asset! if we want windows wasm builds :)
Or do a hotfix where we replace \ with / inside the macro
true
Posted in wrong chat oops
I think we should use curves for the fade-in
I looked at the API, it's a bit cleaner than throwing math formulas
"To use this template, please use our rustc fork" /s
hey, it's not a 3rd part Bevy dependency so it's fair game
i can look at the curves api, but
can we make a piecewise curve?
i mean if not i can just .min(1.0) the curve output and it'll be fine
A spline interpolated linearly between the nearest 2 points.
this should do exactly that
yeah that would be better
i'll get back to that, currently finishing up movement system refactor
let curve = CubicSegment::new_bezier((0.25, 0.1), (0.25, 1.0));
let t = 0.0; // t in range 0.0..=1.0
let alpha = curve.ease(t);
this should do the same as your code
I'm disappointed that t is no longer 0..1, guess ignore my command about that
command, christ
i meant comment
yeah i figured heh
ecs refactor is living rent free in my head rn
i'm gonna put up the movement refactor pr now. will want nits (naming, comments). also the system sets will need an update, i'll do that in a sec
kk
its more code, mostly because some hard-coded constants were split into individual components
i probably need to update some of the comments..
any specific reason why you used a timer instead of the duration?
the effect is quite different
no specific reason
i was gonna have two values
interval and remaining, which counts down from interval
and figured.. that's basically just Timer
yeah i see the behavioral issue
mind if i tweak it back to work like original?
it ought to work like the original yes
it's a matter of updating timer when moving and resetting when not moving
so play sfx gets super simple
will just have to ensure that tick_step_sfx runs after record_movement_controller
well. 1-frame delay isn't a big deal either. but yeah
collecting input deserves it's own system set imo
lmk when you're done, everything else is mostly alright
we only have one timer right?
there's a timer in splash screen for changing the state
does it use this sytem set?
it would if it existed
why
it uses an internal .chain rn
chain is fine if it's only 2 systems
technically true
the system set is good for external ordering
in splash screen's case it's self-contained
yeah
imo as a matter of principle, sticking to using the system sets is good, because you never know when things will become intertwined
but not a big deal to me
i mean, it's your own code, you can change it later 😛
personally I'd go for RecordInput and Udpate
yes, removing system sets is easier than identifying that there's now an ordering issue + which set should each system now go in though
alright
okay :)
one of the things that pisses my off in modern games
is that step sfx is on some weird clock
and if you stop right after hearing it
and then you start walking again
you don't make a sound, like ??
yeah..
oh
the old behavior was more like a cooldown
i can construct a timer and then tick it for its full duration but it's annoying
doesn't reset basically start the countup from 0?
it's like monopoly
go to start and collect money or not lol
yeah, but just_finished is a flag right?
oh wait, that would cause more problems
ugh
i'm using finished in this case
because if you weren't walking for a while, the countdown is long over
but finished doesn't reset it
i can switch back to using 2 floats :p
lets use 2 durations yeah..
i can .set_elapsed actually
it seems like Timer is basically designed to count up, but we want to count down
yeah
and the difference is that in both cases the default state would be 0, but the meaning is different
we need a Cooldown primitive
yep
@agile dirge updated the pr
yeah those mobility names are leftover from before a rename. fixing that
hmm, yeah that should work
this is probably overengineering. but i wonder if this would be a nice pattern:
enum AppStep { ... }
impl AppStep {
fn configure(app: &mut App) {}
}
not actually gonna do this just a thought
not sure what that is
or just take App
to localize the system set configs near where the variants are defined
same module is pretty close :p
not wrong
i wish there was a way to impl Plugin without taking &self
app.add_plugin::<AppStep>() or w/e :p
then states and events could use that api too
and resources
at that point just support app.add::<(MyEvent, MyResource, MyPlugin)>()
eh i'll make an upstream feature request issue, may as well
It's like plugin dependencies but bad 😦
would love if rust (and glam etc.) provided a .wrap to parallel .clamp
like a.wrap(b, c) would keep a within the range b..=c by wrapping instead of clamping
idk how many times ive written this by hand
(a - b).rem_euclid(c - b) + b 🥱
I’ll check it out later, just got up 🙂
ok. i'll prob update the splash screen fade pr to use bevy curves before i go to bed
would also love fn toggle(&mut self) defined on bool
gizmo.config_mut::<PhysicsGizmos>().0.enabled.toggle() would be so nice
This is a fairly small issue I have with booleans - often I want to toggle some boolean (if it’s true, set to false, if it’s false, set to true), but it happens that the boolean is fairly nested. So I have to type something like: a_very_long_struct.my_field.my_nested_field.data.state[idx].blah = !a_very_long_struct.my_field.my_nested_field.data...
my_bool ^= true; is clever
Similar to how x.clamp(min, max) will put x into the range min..=max by clamping it within bounds, there should be an x.wrap(min, max) to put x into the range min..=max by wrapping it within bounds: x.wrap(min, max) == (x - min).rem_euclid(max - min) + min This operation comes up a lot, and currently requires an inlined implementation each tim...
couldn't find a suggestion for wrap anywhere
mm i think the currenty bevy curve tooling is wrong to use here actually
LinearSpline would spend an equal duration in each linear segment
but i just want alpha as a function of t, not a parametic 2d curve as a function of t
i may be missing something in bevy_math, but not gonna figure that out today regardless
Turns out I’m a bit busier today than I thought, but I will make sure to review all of your stuff at some point today @bitter sparrow
I asked in #math-dev about the curves, I'm sure they have some idea in mind for how we should use them
The other PR got approved and automerged
Yeah feel free to merge everything that @agile dirge approves, I can always just do a PR later today with minor changes if needed 🙂
Okay, we've had a lenghty talk, we will stay away from Curves for now, the RFC is promising but the API is still being implemented, so we'd need to add quite a bit of our own code
i think this is for the best, for now. we are still working on the connection between animation and math curves.
On that note, are there any features we'd like to showcase?
Like, new APIs
template isn't exactly the place to showcase, but maybe some features just fit and we skipped them
State bound entities?
used 😄
Clearly it was a good idea then!
we have 2 state contributors here, no way we'd skip that
idk what the scope is for this but maybe you should look at slapping a higher level facade over animation graphs?
It's lower level than what most people are probably going to expect
I have an open issue for that, would be a neat way to guide users imo
But also not super high priority
We're almost ready for another wave of feedback and unless something big comes up, it's mostly README updates
so I think we have time to work on animation more
can i ask... what is even the point of this group? like, what are you ya'll doing?
Agreed. I’d like to write a few words in the readme before gathering feedback though
Have some template for users that is decidedly not just bare bones and only uses Bevy without third party crates
Geared towards people wanting a starting point for a jam
are yall going to update the readme on that?
Yep, that is just the readme of the old CI template
we have a tracking issue for everything that needs to be noted
@fallen stag feel free to participate in any bikeshedding 🙂
i don't really have time, just curious
I meant more like "If you happen to see anything that you think is weird or dislike, let us know"
As a side note, the template is pretty neat for finding design patterns and bugs in Bevy
And rustc, apparently 😄
And hopefully we can get cargo generate support implemented.
I'm still uncertain how to do that without breaking everything else. Suggestions are very welcome
Still flabbergasted that @inland comet managed to track that issue down to file! 👀
Cargo generate doesn't break/choke if the input isn't a template. So we can just, literally, run cargo generate path/to/project and provide the values for the default and if there are no template markers, it will work either way.
or just check Cargo.toml or w/e to see if the template information is still there, and if it is, replace it or use cargo-generate. Neither are great, but both would work.
Ah, that's fair.
In that case, wouldn’t we already have cargo generate support?
Or does it need some kind of metadata file?
(I’ve never used cargo generate)
It works with cargo generate, you just don't get anything with it.
So for example, if you use cargo generate and use the project name shaboingus on the template as it is, you just get the default project without replacing the name and stuff.
Obviously if we use cargo generate and use either method and someone uses the github template feature then it would build on CI as the bevy-template...but that happens regardless
So you’re saying our own CI will still run fine when supporting cargo generate?
So long as we add a step to give it a valid name. Which can be done through something like sed or through using cargo generate directly.
The only downside, would be the project doesn't build locally...but it would be pretty obvious when it fails to build with an invalid name error (or w/e cargo reports).
BTW I was thinking about collecting my thoughts on this whole process in a postmortem about setting up a project without third-party crates, what the core engine still needs and about the need to have more commonly known design patterns in Bevy.
@prisma delta do you think writing about that has some merit, or do you think that this is common knowledge enough that there is little to add?
That would also be the case for when people click on "Use this Template" on GitHub, right?
you're not gonna believe it
https://github.com/MiniaczQ/bevy-design-patterns
How did I not know about that 😄
I stopped updating it because most patterns are about states and we just implemented the solutions in core
but we did get a few from the template so i should update it
especially with hooks, a 1-2 installer patterns
few spawn patterns with observers and commands
probably some barrier pattern until I get something that can be upstreamed
Yes, but again it would point out pretty quickly what the issue is IMHO.
My intuition is that this sounds quite annoying, but I want to give you the benefit of the doubt until I see it for myself. Very possible that I'm wrong here 🙂
Does the subplugin pattern also count?
i think that's more of a preference
it doesn't really solve an issue
unless you count 1 indentation as an issue
For a stricter definition, I'd say a design pattern consists of:
- A problem or complexity
- A solution that's strictly based on Bevy API
I'd like to read a Discussions post about this 🙂
worst comes to worst we can just include a cargo generate enabled branch, as I believe that it can use specific branches as well.
That sounds pretty cool 👀
Leaning entirely into cargo generate would also provide us some nice-ish features as well. Such as including/excluding things based on the choice of the person using it. But obviously the deeper integration into cargo generate we do, the harder it would be to use outside of cargo generate.
For example we could ask users to select a license to use and automatically provide that, or change the template based on if the user wants a binary or library template and the like. Although, again, that would make us require cargo generate, and probably should belong in a separate branch (if not a separate template all together)
But just using a minimal amount of cargo generate would mean that RustRover users (or anyone that uses cargo generate otherwise) would just be able to start a bevy project (especially for a game jam) but just...selecting the template and it would replace what's necessary and allow people to hit the ground running locally without having to go through the github web interface.
A separate branch sounds fairly easy to maintain, I don’t imagine there would be merge conflicts
Wait, RustRover supports cargo generate?
Where do you click for that? I wanna try later
RustRover user cargo generate to create project templates.
That’s pretty neat
Do you think you have time to setup a branch later? Sounds like you already know quite a lot about the topic 🙂
File > New > Project
In the options select rust, and where it says Project Template, if you click the + it asks for a name and a template URL and it explains that it uses cargo generate on the template to generate the new project. Afterwards, you can just click template and select Create.
I can definitely try.
Just depends on how tired I am after work and all that ofc.
Cool! Thanks for the explanation. Maybe we could add that to the readme
Sure, no rush 🙂
Yeah. For minimal cargo-generate integration all we need to add in {{ crate_name }} to Cargo.toml instead of the template name.
I have a minimal template that I use if you want to take a look: https://github.com/Sapein/bevy-basic-template/tree/master
I use cargo-generate in approximately two places: main.rs and Cargo.toml. And that's just to set the window name and crate name.
So if you want to try it out, you can use that.
But yes, the entire reason I want to use cargo-generate is because it makes things a bit nice for RustRover. So if I want to start a new bevy project I can just create a new project pretty easily and have some boilerplate already done for me. 😛
Once the editor is in place I want to lean really hard on cargo-generate and plumb it up to our GUI
But before then I think it's confusing / detracting for new users since it's a different tool
And those are the core audience for templates / project starters 🙂
@bitter sparrow splash screen approved
We could use the ease function if we divided the splash screen into stages, but that's just as much complexity
not worth it
and ease currently is uncached raw newton rhapson so...
@bitter sparrow I updated the camera correctness issue, I have a proposition that we both may agree on
@hidden pond are you Sapein form GH?
Yes
For me this means we shouldn't promote cargo generate in the template
Why not as an additional option?
doesn't cargo generate require that we add templates into quite important places? {{ template-var }}
That can be in a branch per @hidden pond
alright, I didn't read the whole conversation so I didn't know that
If so, sure
doesn't hurt
Yep, if y'all can easily maintain a branch that seems like a nice compromise
I mean Cargo Generate can use branches, commits, tags, etc for templates. Additionally, we're not an official template. While we should consider the concerns from bevy, I don't necessarily think we should hold them as controlling or as requirements for us. Especially when that is relatively tied into bevy itself. If this was an official template, I would be more willing to agree.
we could update the branch only on "releases" of the template
Iirc we are official, we just use a different GH group because template isn't maintained at all times and certainly isn't a focus besides jams
semi-official
this template will be promoted for the jam
and we're supposed to promote other templates
We're still not really official. At best we're 'second party' to borrow game publishing terminology.
But, in any case, I don't mind maintaining the branch solution -- although it does mean that people who use RustRover has a worse experience over all (as I'm unsure if RustRover itself supports using branches, but I'll have to figure it out IG) but you can just fall back to Cargo Generate at least.
I think maintaining a branch should be nearly trivial, as there shouldn't be any merge conflicts.
thoughts on renaming AppStep -> Step system set?
i think it's cute, but may be pushing it
Step::TickTimers, Step::RecordInput, etc.
btw here's how extended screen fade support would look in action: https://pyrious.itch.io/bevy-jam-template
it does rely on successive screens using the same BG color to look nice though
i think you'd have to blend between different BG colors during the transition animation to get that to look nice
read the issue, you could try to blend the BG colors instead of going all black like i originally proposed
also, I'd straight up remove the exit button for web if it's going to be there grayed out
it doesn't cause layout issues for us
yeah no i agree
yeah. would require each screen to specify its BG color somehow
hm i guess impl Screen { fn bg_color(&self) -> Color { ... } } is an option
add marker to root ui and read from a query?