Bevy, Avian2d, and bevy_egui have all been bumped to the latest
versions.
MSRV is now Rust 1.89.0 because that's the minimum for Bevy (including a
couple of its dependencies).
The webpage has a placeholder string instead of a hard-coded version.
This gets replaced by the Makefile with the help of a pair of `sed`
calls.
And with that, I've upgraded my ad-hoc web bundler with an ad-hoc HTML
templating engine.
- Replaced "bevy_spatial" with "avian2d"
- Upgraded Bevy to 0.17
The bevy_spatial crate is still stuck on Bevy 0.16 and I'd like to move
forward and start playing with some of the new UI stuff. I've replaced
it with Avian physics, although I'm only using the spatial querying
facilities not the rest of the physics engine.
Avian physics has been updated for Bevy 0.17 while bevy_spatial has not.
Now that the program is switched over, I can finally pull in the new
versions of everything.
I figured out why the new flocking behavior is different...
The previous version used 1/4th the view range for boid separation and I
didn't preserve that.
Working demonstration, but I'm not sure shape casting is the action I
want to be doing. I've just found a "shape_intersections" method in the
docs, but I'm saving my progress before making further changes.
One or more of the transitive dependencies needs Rust 1.88 or newer, so
this becomes our minimum version. It may be possible to build with an
older Rust by manually picking dependency versions but I'm not going to
do that.
Ideally, `-Zminimal-versions` would pick out those versions, but lots of
crates don't correctly specify minimum depdendency versions. As a
result, our transitive dependencies resolve to
matching-but-non-functional versions.
The player-controlled boid was for testing the flocking behavior. It has
outlived this purpose and I never even bothered to make it larger like
the others. It's finally going away completely.
The birdoid flocking parameters are now a resource named
`FlockingParameters`. Adjustments can be made using the Egui inspector
widget, although I plan to make a custom UI in the future.
I'm not happy with the flocking behavior so I fiddled with the program
to find these new behavior parameters. It's annoying to constantly
rebuild the program, though, and I'd like for the end-user to be able to
fiddle with it at runtime. To that end, v0.7.0 shall be the UI update.
Semver checks only make sense for things that have a public interface.
While an application technically does, these semver checks are for the
Rust API not the GUI shape or something. It's for checking that a
library upholds it's semver promise.
This is not a library, so these checks don't make sense.
This is actually a build configuration task, but I don't have a tool to
do that (no `./configure.sh` to run!).
To work around this, I'll just have each of the html-installing targets
install their own and remove the other. That way back-to-back builds
don't accidentally contaminate each other. The WASM and JS files are
identical, so they don't need this treatment.
The `web-standalone` target does what the old `web` target did: Produce
the WASM, JS, and an index.html so the output can be served up directly.
The new `web` target renames the "index.html" to "boids.html" so it can
be used as a submodule/subpage in a larger website build.
Variables that a package consumer might want to adjust should be placed
at the top of the file so they are immediately visible. Any constants
shall live below those (just the SRC folder, really).
I had named it makefile_web" in an effort to communicate to the user
that the Make-based build path is only for web builds. It's annoying to
type all that out, though, and it doesn't seem like other projects
follow this convention. I'll just put a usage note at the top. It's not
like the Makefile can be mis-used to make a non-web version. There is no
footgun here.
If I'm actually presenting this online (and I am), I should probably
have a real license attached to it. The AGPL seems good to me. I can't
imagine anyone would seriously have conflict concerns for a Boids
implementation.
The webpage now presents this information, as does the Cargo.toml
manifest.
I might sometimes build different profiles, so this gives me somewhere
to change them. It *does not work* for debug builds because of how cargo
works. So that sucks.
I can't think of a reason anyone would seriously want to change the
target, but I've made that a variable, too. WASM64 exists, but I can't
get a read on it's availability across browsers. The benefit seems to be
accessing >4GB of memory, which is not important for this project. Other
targets are for "desktop" platforms and so shouldn't be using the
makefile.
https://www.gnu.org/software/make/manual/html_node/Multiple-Targets.html
The previous recipe told Make that each file could be produced by
running wasm-bindgen. The more correct expression is that *both* files
will be produced at the same time.
Now Make knows to only invoke the command one time to get both files if
either is out of date. Previously, multi-job builds (`-j2`) could build
the files twice -- one invocation for each out-of-date file.
