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.
This makes the output folder "required to exist" and not "required to be
more recent."
The folder's timestamp is updated when files are written into it. The
files inside depend on the folder existing. The result is that the WASM
and JS files are considered very slightly older than the folder that
contains them. The result is that the folder is up-to-date but it's
contents are not, thus re-building them and *again* updating the folder
timestamp. The makefile was stuck constantly rebuilding things that are
actually up-to-date.
Oops, it's not supposed to have a file suffix! It's a bit annoying that
it still produces both a WASM and JS file, just not the right ones (and
no _bg.wasm at all). Especially without any warning that it is doing
something different than normal. Oh well.
Call with `make -f makefile_web` to produce a web root for serving. Use
target "boids_web_root.tar" to bundle the files into a tarball. For...
publishing... or something.
The `wasm-server-runner` program seems to supply it's own index.html and
is doing *something* regarding MIME types -- hosting a dev build of the
Boids program results in the browser complaining about "" (empty string)
being an invalid MIME type.
I want my own index.html during testing, and I can't figure out why the
MIME type info is wrong. I've decided to automate the web-root build
process and serve it up with whatever webserver I have on hand.
