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.
I want to at least have the smell of reproducible builds, so I'll make
the image build using the lockfile. Otherwise the build-time dependency
information gets lost.
The config.toml lets me run `cargo run --target wasm32-unknown-unknown`
and host a dev server.
I've adjusted the Cargo.toml to use the kdtree_rayon feature by default,
but disable the Rayon feature for WASM builds (because it doesn't work).
With the 1.0 radius boids (instead of whatever `Circle::default()`
uses), a separation activation of 1/4 the range looks more visually
appealing (imo).
The starting velocities going outwards in a circle means that the sum of
energy in the system is 0. As the boids come back together, they will
slow down to fall into a lattice. This is interesting, but not the
flocking behavior Boids are supposed to have.
I've replaced the `space_brakes` function with this new speed controller
to keep boids moving between two speeds. Anything too slow will speed up
along it's current vector, and anything too fast will slow down.
The "length" is actually the `enumerate()` index, which is one less than
the item count. The previous version was not using the average, and may
have been deviding by 0 for boids with exactly one neighbor.
The keyboard input should apply a force, not modify the velocity. Right
now, there is no Mass component, but in the future there might be. I've
just fixed a broken physics integrator made by bad assumptions, too, so
I'm goig to do this for consistency if nothing else.
The velocity component never got updated. Instead, the system was only
calculating the current frame's deltaV. That instantaneous dV and any
velocity that *did* get assigned (bundle insertion, keyboard control)
would be added to the position.
Now forces are integrated into velocity, and velocity is integrated into
position. You know... like a real integration function.
The module isn't the plugin, so it's going to be called simply
"birdoids" going forward.
I've turned it into a folder and a `mod.rs` so I can slap down a small,
custom physics system.
