#0.14 Bevy Jam

1 messages · Page 4 of 1

agile dirge
#

gn

bitter sparrow
#

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

slender belfry
# bitter sparrow but it's possible to predict what types of things users will want to add to an e...

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!

bitter sparrow
slender belfry
#

Oh wait

bitter sparrow
#

yeah seems to be diffing from an older commit

slender belfry
#

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

bitter sparrow
#
  1. not sure about the full suite of derives for every type
  2. what's the benefit of e.g. reflect(Hash) and other traits?
#
  1. Name convention for entities: i do PascalCase in my personal code. curious if there's a standard for this in the bevy community, or if there should be
slender belfry
#
  1. Fine with cutting it
  2. No idea honestly
  3. It’s for display purposes, so whatever is nicest to read naturally
bitter sparrow
#

for 2, ive only done reflect(Resource) in the past because it allows the resource to be viewed in inspector

slender belfry
bitter sparrow
#

ic

slender belfry
#

I know Bevy and Avian always reflect everything available, so I was following suit

#

But I don’t know the exact benefits

bitter sparrow
#

me neither. it's possible it's more relevant for libraries that don't know how their types will be used by users

slender belfry
#

Library code is also different from binary code, so we may be fine cutting it

bitter sparrow
#

keeping reflect(Resource) and reflect(Component) is 👍 from me

slender belfry
#

If we trim down the reflects, I might as well remove the serialization

#

Same rationale imo

bitter sparrow
#

everything else in the pr seems straightforward / uncontroversial

bitter sparrow
#

if we're not doing anything with serialization

#

if we do end up needing it we can add it later

slender belfry
bitter sparrow
#

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

slender belfry
#

Btw, I just noticed that in terms of comments, we have far surpassed the other working groups 😄

bitter sparrow
#

you should see the old states thread that wasn't a working group

slender belfry
#

Oh I bet that was controversial

bitter sparrow
#

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

slender belfry
#

I'll merge your PR now since I think it's very similar in spirit to what @agile dirge already did.

bitter sparrow
#

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

slender belfry
#

That's nice 😄 I'll still need to wait for the Blender workflow

#

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

bitter sparrow
#

and polish

#

i want the duck to move faster

slender belfry
bitter sparrow
#

core/booting.rs snuck its way back in in your pr

slender belfry
bitter sparrow
#

feels so nice with the fade

#

should PhysicalTransform impl Component? it currently does not

#

ik we're ripping that out in a sec

slender belfry
#

It does 😄

#

Just manually for the hooks

bitter sparrow
#

ah right

slender belfry
#

I've set it to automerge as soon as you approve since Mini already wrote they'd approve it

bitter sparrow
#

also cargo fmt complained in CI

#

do you have format on save configured?

slender belfry
slender belfry
#

That one formats that line differently, haha

bitter sparrow
#

register_type::<(...)> recursive registration ❤️

bitter sparrow
slender belfry
#

great, gonna yeet fixed timestep now

bitter sparrow
#

cool

#

the upstream fixed timestep example is not merged yet, right?

#

can create an issue to link to the example once it's merged

slender belfry
rigid geyser
#

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

slender belfry
# rigid geyser Especially when we’re “preemptively” adding it in this case when it isn’t really...

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?

bitter sparrow
#

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

slender belfry
slender belfry
#

ui_boilerplate

bitter sparrow
#

it's specifically "util" ui

slender belfry
#

that's at least honest

bitter sparrow
#

cart's suggestion in the pr was ui_tools

slender belfry
#

I'm fine with that

bitter sparrow
#

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

slender belfry
bitter sparrow
#

well currently the template itself has no nesting there

slender belfry
#

Yep, so as it stands it's probably reasonable to rename it

#

simple rename PR

slender belfry
bitter sparrow
#

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

slender belfry
#

fair

#

lemme add that to the PR

bitter sparrow
#

ok

#

will parallel bevy_dev_tools better as well

#

the toolsening 😩

slender belfry
#

There we go

slender belfry
bitter sparrow
#

src/game_tools/spawn_tools/player_tools.rs

slender belfry
slender belfry
#

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

bitter sparrow
#

macos build fix will help. tough to do that on linux

slender belfry
#

Can I leave the splash fade to you? You already have experience with that 🙂

bitter sparrow
#

yes

slender belfry
#

thanks

#

Also no clue how cargo-generate works. @hidden pond, I think you know about this stuff?

bitter sparrow
#

i suspect it will be challenging to reconcile cargo-generate and .github/workflows/release.yaml

#

and ci.yaml

slender belfry
#

Probably? I have no idea

slender belfry
bitter sparrow
#

we may have to have two separate repos, one that's just a template, and one that's generated from the template

#

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

bitter sparrow
#

but it's fine either way, we can delete tags / releases manually as well

slender belfry
#

I think if supporting cargo-generate forces users to use it, I'd rather have it be a regular GitHub template

bitter sparrow
#

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

bitter sparrow
#

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

slender belfry
#

Also convenience when writing a new file. I'm a bit faster writing just the fn.

mortal merlin
slender belfry
#

I've even setup a VSCode shortcut that turns plugin into:

use bevy::prelude::*;

pub(super) fn plugin(app: &mut App) {
    todo!()
}
mortal merlin
#

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?

slender belfry
mortal merlin
#

That makes sense, instead of polluting the global scope. Will start using that 🙂

slender belfry
#

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

inland comet
slender belfry
#

But yeah, sec

inland comet
inland comet
slender belfry
#

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

slender belfry
#

Happy to share 😄

slender belfry
#

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

slender belfry
#
/// 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

bleak grail
slender belfry
#

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

slender belfry
inland comet
#

At work we use wasm-pack but that's even worse. We just haven't bothered changing it

slender belfry
#

Can one do that maybe with a custom cargo command?

bleak grail
slender belfry
#

But yeah, if that doesn't work, it's not the end of the world

inland comet
#

Are you on Windows?

slender belfry
slender belfry
slender belfry
hidden pond
#

Oh that's neat. Like the throbber y'all used lol.

slender belfry
inland comet
#

Hmm, then we just need to find some way to make this work cross-platform

slender belfry
#

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

inland comet
#

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

slender belfry
#

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

dawn crag
slender belfry
#

there we go

dawn crag
#

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.

slender belfry
#

Filed a bug

slender belfry
#

I guess I'll just make the splash screen a regular asset for now

dawn crag
#

Or, splash.png is 30kb, just let it be in the packages.

slender belfry
dawn crag
#

Oh, I guess I'm making a weird assumption that things work okay if the thing is in the assets directory.

inland comet
dawn crag
#

But it's outside of there to prevent it from being included redundantly in bundles, right? But it's 30kb so who cares?

slender belfry
#

...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 :/

slender belfry
#

I'll just add a little powershell and .sh script with the manual incantations, that should do

agile dirge
#

I could make a very simple host with axum and we can add it as a bin

#

but probably too much

slender belfry
#

Yeah I'd like to avoid that if possible

dawn crag
#

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. 🤷‍♂️

agile dirge
#

but then we'd have a

  • Rust based hosting, no additional tools
  • Correct missing file behavior
slender belfry
dawn crag
#

But I'm not seeing any configuration for disabling SPA mode there, so I dunno what's going on.

slender belfry
slender belfry
#

We could then just tell people to do cargo install serve_bevy or whatever

#

that'd be pretty cool 👀

agile dirge
#

sir this is wendys

#

i technically worked with all of those features

#

but it would take some time to make

slender belfry
#

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

agile dirge
#

its probably easier to PR a feature to trunk then

#

they use axum anyways

#

it's there

slender belfry
#

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.

agile dirge
#

"html file procuded", trunk make a new html file?

slender belfry
#

It also inlines stuff for you and init()s your Wasm

pseudo marten
dawn crag
#

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.

slender belfry
#

It's great to have a place now that has these settings collected 😄

dawn crag
#

(And also at the time there was no no-spa mode)

slender belfry
#

Thanks everyone, looks like we can use trunk for the template then 🙂

dawn crag
slender belfry
#

but idk if it worked the same way

dawn crag
agile dirge
#

nope

#

need to do trunk --no-spa serve

slender belfry
agile dirge
#

They didn't update the example Trunk.toml

#

the code is there it seems

slender belfry
agile dirge
#

I was gonna add it myself but it was already in the code 😛

slender belfry
#

Hehe, good find 😄

#

btw @agile dirge are you doing the SFX at some point?

agile dirge
#

Oh right that, I didn't really start so anyone can take it

slender belfry
#

I'm asking because I have no idea how audio is best done

agile dirge
#

me neither 😉

slender belfry
#

hehe

agile dirge
#

actually thats not true

#

i have ran into a decent convention

#

it's the same as spawn api

slender belfry
#

Ah really?

agile dirge
#

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

slender belfry
agile dirge
#

could, but there is an example for that

#

well, there is one for audio for sure too

slender belfry
agile dirge
#

but with audio we can do the asset offloading thing

slender belfry
#

I'll probably no longer touch the code itself and do the devops stuff now

agile dirge
#

k

#

we do need to fix ci for mac

slender belfry
#

Also hope what I did with trunk works on itch, need to debug that once it's merged and deployed

agile dirge
#

I'll appr once i launch it on my side

#

just upgrading trunk

slender belfry
#

thanks for double-checking 🙂

agile dirge
#

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

slender belfry
agile dirge
#

yea

slender belfry
#

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 👀

agile dirge
#

oh, i missed that

#

i've got no clue how those work in trunk

slender belfry
#

checking the dist/index.html, it just added that script inside a script tag

agile dirge
#

Well, we'll know it works when i add sfx 😉

slender belfry
#

hehe

#

I can also quickly go and hit up an actual web dev

#

sec

agile dirge
#

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

slender belfry
#

Now it's the same

agile dirge
#

Looked at both, does generally the same thing

#

aight, ill work on sfx

slender belfry
#

But adding it anyways, maybe it works on other OS

#

@bitter sparrow I addressed your comments

bitter sparrow
#

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

slender belfry
#

No opinion on that, sounds good

bitter sparrow
#

@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

slender belfry
#

lemme try

bitter sparrow
#

oh it's a bit of a mess to add lol

#

let me copy/paste the code you need to use here

slender belfry
#

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

bitter sparrow
#
        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

slender belfry
#

Could you do it?

bitter sparrow
#

yeah that's why embedded_asset was added lol

#

okay sure

slender belfry
#

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

slender belfry
bitter sparrow
#

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

slender belfry
#

Works

bitter sparrow
#

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

slender belfry
#

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

bitter sparrow
#

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

slender belfry
#

let me see if there's anything noticeable

slender belfry
bitter sparrow
slender belfry
bitter sparrow
#

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

slender belfry
slender belfry
bitter sparrow
#

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

bitter sparrow
#

ok that works too

pseudo marten
#

in Firefox

#

It's not only bookmarks like in the video, but also if I manually change the URL in the navigation bar

bitter sparrow
#

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

bitter sparrow
#

would be odd if it blocked clicking bookmarks though

slender belfry
#

I wonder if that will happen on itch.io as well.

#

Merging it now and triggering a release after to investigate

agile dirge
#

@pseudo marten did you update trunk before testing?

#

in relation to no-spa setting

slender belfry
#

I'm using trunk 0.20.2 and can reproduce it

bitter sparrow
#

tbh we can consider this to be a feature. players should be incentivized to finish the game before they switch tabs

agile dirge
#

k

#

i need a kevin macleod song for out template

slender belfry
agile dirge
#

well i need to pick one

#

or few, we can play them at random

slender belfry
#

Then monkeys spinning monkeys

#

love that one 😄

bitter sparrow
#

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

agile dirge
#

thats a good one too

#

ill do monkeys spinning monkeys in credits

#

cause i already added it

bitter sparrow
#

is audio fade in/out possible in bevy_audio

#

or are you doing a hard cut between the songs? :p

agile dirge
#

i'd need to animate the volume myself

#

hard cut oc

bitter sparrow
#

ic

#

i should prob go ahead and add the splash screen fade in/out

slender belfry
#

I'll check later, need to fix the wasm build on release first

bitter sparrow
#

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?

agile dirge
#

#animation-dev, no clue

slender belfry
#

oh come on

agile dirge
#

splash screen is the only thing we can overcomplicate in here

slender belfry
#

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

bitter sparrow
#

trunk yeet /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

slender belfry
#

still think it's worth it for the dev experience

#

But yeah, it's not a secret that trunk is sometimes a bit crap

bitter sparrow
#

local web build is definitely needed

#

think ill stick to bash scripts in my template but obviously that won't cut it here

#
  1. is the worst option
dawn crag
bitter sparrow
#

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?

slender belfry
#

I can compare the size difference

slender belfry
#

Then we could just remove the different profiles

#

win-win

#

(I have low hopes)

#

(but mayyyybe)

bitter sparrow
#

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

pseudo marten
bitter sparrow
#

that sounds like the easiest way forward lol

slender belfry
#

But idk if they're willing to accept a little patch in there for us

#

as a treat

slender belfry
dawn crag
#

And benchmark some stuff. But I'm not gonna / probably doesn't matter.

bitter sparrow
#

yeah that's true

#

if it's like preventing loop unrolling

#

i imagine loop unrolled code would compress reasonably well

slender belfry
dawn crag
#

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)

slender belfry
#

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

bitter sparrow
#

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

slender belfry
#

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?

slender belfry
#

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?

dawn crag
#

seems to be the decision nikl made

slender belfry
bitter sparrow
#

just include it. users can just not use it if they don't want to

slender belfry
#

Aight

bitter sparrow
#

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?

slender belfry
bitter sparrow
#

i approved it before i saw the rest of the PR 😄

#

i can make another PR with my comments np

slender belfry
bitter sparrow
#

github being weird ig

#

only showed me a small part of the pr in the diff

slender belfry
#

Because it's already merged I can at least already trigger the release action

bitter sparrow
#

sure

#

imagine dealing with this during a game jam though 🙄

slender belfry
#

can I get an ultra quick approval on that?

#

So I can run the CI again

#

thx

slender belfry
slender belfry
bitter sparrow
#

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

slender belfry
#

Oh yes

#

Itch works ;D

#

@pseudo marten I believe the bookmark thingy is not present on itch. Must be a trunk serve thing

bitter sparrow
#

ok i will just do a pass on audio in a separate pr imo

#

would rather land the feature first

agile dirge
#

wdym

bitter sparrow
#

don't want to keep it in code review hell

agile dirge
#

ehh, sure but you need to approve

bitter sparrow
#

yeah will approve after my nits resolved

agile dirge
#

why are half of them outdated

bitter sparrow
#

pr updated while i wrote them i guess

agile dirge
#

ah right

#

addressed

bitter sparrow
#

approved

agile dirge
#

the fact that you'd rather make a new PR than propose changes is bothering me

bitter sparrow
#

why?

#

i don't want to hinder more work

agile dirge
#

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

bitter sparrow
#

the prs will continue until morale improves /j

agile dirge
#

Why we need to remove camera resetting:

  • camera doesn't move
  • if camera moves, we need to see it move
  • that needs level content
bitter sparrow
#

player will add level content presumably

agile dirge
#

what

bitter sparrow
#

user i mean

#

sorry

#

this will become the user's codebase, it's not meant to be a self-contained project

agile dirge
#

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

bitter sparrow
#

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

agile dirge
#

that's user's problem

bitter sparrow
#

it's a correctness problem imo

#

if we're in a state that is "allowed" to move the camera around

agile dirge
#

we don't provide camera movement

bitter sparrow
#

then it's correct to reset it when exiting that state

agile dirge
#

no

#

we do not move the camera

#

we do not have to reset it

bitter sparrow
#

^\_(``/)_/^

agile dirge
#

we do not try to guess what the user will do and try to fix it for him

bitter sparrow
#

that's not what i'm saying

#

but w/e

agile dirge
#

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

bitter sparrow
#

nope

#

better to link to bevy_asset_loader and iyes_progress in readme

agile dirge
#

animations are fresh so lets discuss that tomorrow

#

you're doing animation for splash?

bitter sparrow
#

yes

#

custom component not bevy_animation

agile dirge
#

k

#

we have player (duck) and splash left

bitter sparrow
#

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

agile dirge
#

lets maybe at least add a folder for images in general

slender belfry
bitter sparrow
#

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

slender belfry
bitter sparrow
#

so it's not about how smart the user is, it's about not including a correctness bug in the template

agile dirge
#

that's speculation

slender belfry
bitter sparrow
#

ok. i'll just create an issue for it then

slender belfry
bitter sparrow
#

honestly the camera should reset on any Screen state transition

agile dirge
#

i dont agree with that...

bitter sparrow
#

all good 👍

#

not trying to convince

agile dirge
#

not until a PR 😂

bitter sparrow
#

feel free to delete camera reset code now

agile dirge
#

no hurry

bitter sparrow
#

bevy_state makes it hard to implement something like this anyways. lol

agile dirge
#

not really

bitter sparrow
#

"any transition"

#

you'd have to iterate and add a system for every screen no?

agile dirge
#

nope :p

bitter sparrow
#

oh you could react to a transition event in the update schedule

#

but that wouldn't be ordered properly

agile dirge
#

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

bitter sparrow
#

mmm right i asked for those

bitter sparrow
#

yeah. possible with a pile of boilerplate

#

better than nothing

#

consistent with many other parts of the bevy engine currently tho

agile dirge
#

pile of boilerplate

#

consistent

#

YUP

#

wait no

#

there

#

i just wanna move to states as entities as quickly as possible

bitter sparrow
#

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

agile dirge
#

that's what new is usually used for

bitter sparrow
#

yeah the issue is you lose the field names

#

esp in a bigger struct

agile dirge
#

you name the parameters though

bitter sparrow
#

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

inland comet
#

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

bitter sparrow
inland comet
#
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

inland comet
bitter sparrow
#

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

slender belfry
#

We have evolved from finding Bevy bugs through the template to finding Rust bugs ferris_spooky

bitter sparrow
#

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..

slender belfry
agile dirge
#

facing the duck is fair

#

idfk how you wanna wrap

bitter sparrow
#

i'll hardcode it

agile dirge
#

that usually requires doubles

bitter sparrow
#

user will strip it out anyways

#

doubles as in f64?

#

i'll make facing its own pr anyways

agile dirge
#

yeah, facing seems easy enough

#

doubles is too involved imo

bitter sparrow
#

oh.

#

you mean like if the sprite is halfway on the edge?

agile dirge
#

yea

bitter sparrow
#

i was thinking i'd just tp it after it's fully offscreen yknow

agile dirge
#

oh

#

hm

#

yeah that works

bitter sparrow
#

😄

agile dirge
#

but i'd split the movement system at that point

bitter sparrow
#

oh yeah the movement system shouldve been split a few changes ago

#

or from the start

agile dirge
#

it was

#

when fixed update was removed it was merged into a single system

bitter sparrow
#

ah

agile dirge
#

but then the audio change made it a teeny bit too complex

bitter sparrow
#

i'll do a refactor to split the system up in a separate pr as well

agile dirge
#

now's a good time to split it proper

#

sure

bitter sparrow
#

how granular would you be willing to accept

#

MovementIntent component on the entity populated by the first system based on input?

agile dirge
#

ActorController

#

that's what most engines use right?

bitter sparrow
#

Actor { speed: f32 } component

#

idk

agile dirge
#

no, not for speed

#

what you named intent

bitter sparrow
#

oh

#

it would contain the normalized Vec2

agile dirge
#

cause then you can use that to play sound

#

to flip sprite

#

and do movement

bitter sparrow
#

yep

agile dirge
#

👍

bitter sparrow
#

you're saying to call that ActorController tho?

agile dirge
#

normalized Vec2 is Dir2 btw

bitter sparrow
#

that is true

agile dirge
#

I'd like confirmation from someone with commercial engine experience

#

but in UE you have actors and you attach controllers

#

to do movement

bitter sparrow
#

that's fair. i'd accept a name that's an industry standard ofc

agile dirge
#

I'm just not sure if that's the exact object for this

#

but i dont remember others

slender belfry
#

Yeah +1 for the name Controller

#

The Actor part doesn’t matter imo

agile dirge
#

yea that's specific to UE where you work on Actors

slender belfry
#

MovementController?

bitter sparrow
#

if "controller" is the concept then i'd say that that's the correct name

agile dirge
agile dirge
#

actually, dont use Dir2

bitter sparrow
#

splitting the system up will be the next PR

agile dirge
#

cause you can't have 0 there

bitter sparrow
#

Option<Dir2>? or is that bad

#

wait no

#

it should just be Vec2 you're right

agile dirge
#

let's keep it numeric

bitter sparrow
#

should support <1 length

#

like a joystick that's not pressed all the way

agile dirge
#

i think Dir2 uses a single float underneath

#

true

bitter sparrow
#

I found the difference between the 2 projects, it happens when a project has both a lib.rs and a main.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

inland comet
#

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

bitter sparrow
inland comet
#

Or do a hotfix where we replace \ with / inside the macro

bitter sparrow
#

true

agile dirge
#

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

slender belfry
#

"To use this template, please use our rustc fork" /s

agile dirge
#

hey, it's not a 3rd part Bevy dependency so it's fair game

bitter sparrow
#

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

agile dirge
#

this should do exactly that

bitter sparrow
#

yeah that would be better

#

i'll get back to that, currently finishing up movement system refactor

agile dirge
#
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

bitter sparrow
#

yeah i figured heh

agile dirge
#

ecs refactor is living rent free in my head rn

bitter sparrow
#

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

agile dirge
#

kk

bitter sparrow
#

its more code, mostly because some hard-coded constants were split into individual components

#

i probably need to update some of the comments..

agile dirge
#

any specific reason why you used a timer instead of the duration?

#

the effect is quite different

bitter sparrow
#

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

agile dirge
#

mind if i tweak it back to work like original?

bitter sparrow
#

it ought to work like the original yes

agile dirge
#

it's a matter of updating timer when moving and resetting when not moving

#

so play sfx gets super simple

bitter sparrow
#

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

agile dirge
#

collecting input deserves it's own system set imo

bitter sparrow
#

yeah i agree, i have it split up in my template

#

i'll update system sets now

agile dirge
#

lmk when you're done, everything else is mostly alright

bitter sparrow
#

ok

#
enum GameStep {
    RecordInput,
    TickTimers,
    Update,
}

this reasonable?

agile dirge
#

we only have one timer right?

bitter sparrow
#

there's a timer in splash screen for changing the state

agile dirge
#

does it use this sytem set?

bitter sparrow
#

it would if it existed

agile dirge
#

why

bitter sparrow
#

it uses an internal .chain rn

agile dirge
#

chain is fine if it's only 2 systems

bitter sparrow
#

technically true

#

the system set is good for external ordering

#

in splash screen's case it's self-contained

agile dirge
#

yeah

bitter sparrow
#

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

agile dirge
#

i mean, it's your own code, you can change it later 😛

#

personally I'd go for RecordInput and Udpate

bitter sparrow
#

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

agile dirge
#

do as you will

#

i mostly want the old timer behavior :>

bitter sparrow
#

okay :)

agile dirge
#

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 ??

bitter sparrow
#

yeah..

agile dirge
#

wait.. are we going in that exact direction? 🤔

#

cause we play sound on timer finish

bitter sparrow
#

oh

agile dirge
#

the old behavior was more like a cooldown

bitter sparrow
#

right

#

i'll even name it cooldown

agile dirge
#

sure

#

thanks

bitter sparrow
#

why can't i construct an already-finished timer

#

😩

agile dirge
#

hmm

#

a reset that primes timer as finished

bitter sparrow
#

i can construct a timer and then tick it for its full duration but it's annoying

agile dirge
#

would do the same job right?

#

at least we can add an issue for that

bitter sparrow
#

doesn't reset basically start the countup from 0?

agile dirge
#

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

bitter sparrow
#

i'm using finished in this case

#

because if you weren't walking for a while, the countdown is long over

agile dirge
#

but finished doesn't reset it

bitter sparrow
#

i can switch back to using 2 floats :p

agile dirge
#

lets use 2 durations yeah..

bitter sparrow
#

i can .set_elapsed actually

#

it seems like Timer is basically designed to count up, but we want to count down

agile dirge
#

yeah

bitter sparrow
#

and the difference is that in both cases the default state would be 0, but the meaning is different

agile dirge
#

we need a Cooldown primitive

bitter sparrow
#

yep

#

@agile dirge updated the pr

#

yeah those mobility names are leftover from before a rename. fixing that

agile dirge
#

hmm, yeah that should work

bitter sparrow
#

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

agile dirge
#

not sure what that is

bitter sparrow
#

or just take App

#

to localize the system set configs near where the variants are defined

agile dirge
#

same module is pretty close :p

bitter sparrow
#

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

prisma delta
bitter sparrow
bitter sparrow
#

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 🥱

slender belfry
bitter sparrow
#

ok. i'll prob update the splash screen fade pr to use bevy curves before i go to bed

bitter sparrow
#

gizmo.config_mut::<PhysicsGizmos>().0.enabled.toggle() would be so nice

bitter sparrow
# bitter sparrow would also love `fn toggle(&mut self)` defined on `bool`
#

my_bool ^= true; is clever

bitter sparrow
# bitter sparrow would love if rust (and `glam` etc.) provided a `.wrap` to parallel `.clamp`
#

couldn't find a suggestion for wrap anywhere

bitter sparrow
#

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

slender belfry
#

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

agile dirge
#

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

slender belfry
#

Yeah feel free to merge everything that @agile dirge approves, I can always just do a PR later today with minor changes if needed 🙂

agile dirge
#

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

fallen stag
#

i think this is for the best, for now. we are still working on the connection between animation and math curves.

agile dirge
#

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

prisma delta
#

State bound entities?

agile dirge
#

used 😄

prisma delta
#

Clearly it was a good idea then!

agile dirge
#

we have 2 state contributors here, no way we'd skip that

fallen stag
#

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

slender belfry
#

But also not super high priority

agile dirge
#

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

fallen stag
#

can i ask... what is even the point of this group? like, what are you ya'll doing?

slender belfry
agile dirge
slender belfry
#

Geared towards people wanting a starting point for a jam

fallen stag
#

are yall going to update the readme on that?

agile dirge
#

yes

#

probably split into multiple files

slender belfry
agile dirge
#

we have a tracking issue for everything that needs to be noted

slender belfry
#

@fallen stag feel free to participate in any bikeshedding 🙂

fallen stag
#

i don't really have time, just curious

slender belfry
agile dirge
#

As a side note, the template is pretty neat for finding design patterns and bugs in Bevy

hidden pond
#

And hopefully we can get cargo generate support implemented.

slender belfry
slender belfry
hidden pond
#

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.

slender belfry
#

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)

hidden pond
#

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

slender belfry
#

So you’re saying our own CI will still run fine when supporting cargo generate?

hidden pond
#

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).

slender belfry
#

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?

slender belfry
slender belfry
agile dirge
#

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

hidden pond
slender belfry
slender belfry
agile dirge
#

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
prisma delta
hidden pond
slender belfry
hidden pond
#

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.

slender belfry
slender belfry
hidden pond
#

Yes.

#

That's why I want cargo generate support in the first place.

slender belfry
#

Where do you click for that? I wanna try later

hidden pond
#

RustRover user cargo generate to create project templates.

slender belfry
#

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 🙂

hidden pond
#

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.

hidden pond
#

Just depends on how tired I am after work and all that ofc.

slender belfry
slender belfry
hidden pond
#

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. 😛

prisma delta
#

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 🙂

agile dirge
#

@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

agile dirge
#

@hidden pond are you Sapein form GH?

hidden pond
#

Yes

agile dirge
slender belfry
agile dirge
#

doesn't cargo generate require that we add templates into quite important places? {{ template-var }}

slender belfry
agile dirge
#

alright, I didn't read the whole conversation so I didn't know that

#

If so, sure

#

doesn't hurt

prisma delta
hidden pond
#

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.

bitter sparrow
#

we could update the branch only on "releases" of the template

agile dirge
#

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

bitter sparrow
#

semi-official

agile dirge
#

this template will be promoted for the jam

#

and we're supposed to promote other templates

hidden pond
#

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.

slender belfry
#

I think maintaining a branch should be nearly trivial, as there shouldn't be any merge conflicts.

bitter sparrow
#

thoughts on renaming AppStep -> Step system set?

#

i think it's cute, but may be pushing it

#

Step::TickTimers, Step::RecordInput, etc.

bitter sparrow
#

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

agile dirge
#

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

bitter sparrow
#

hm i guess impl Screen { fn bg_color(&self) -> Color { ... } } is an option

agile dirge
#

add marker to root ui and read from a query?