since i cannot think of any way to verify these tests in a automated
way, these are all set up currently as "ignored" tests which need to be
manually run (either directly via the IDE, e.g. CLion as I use, or via
the an ALTERNATIVE test runner via the CLI (such as nextest). these
cannot be run all together via `cargo test` (even if running with only
a single thread). `cargo test` can only be used to run them successfully
one test per invocation.
this has very limited use, outside of some tests i am writing right now,
but maybe it will be useful down the road.
(i suppose mostly, i just wanted to try this out for myself ...)
mostly working, but the imgui ui part is only a placeholder.
also this example project is kind of overly complicated, but i really
wanted this to be something that somewhat resembles a real tool that
i'd want to build.
this has no immediate use, but i think it will be useful in the future
for writing generic constraints requiring 32-bit color support while
not forcing use of any specific SystemResources implementation
since the TextInput event cannot implement Copy, necessitating the
removal of the Copy trait from KeyboardEvent, it feels wrong to me to
have the other event enums implement Copy, because it is inconsistent.
so while this is less convenient potentially, it feels consistent.
probably not a big deal in the future one way or the other.
keeping the original single triangle_2d function taking the enum, but
also allowing separate functions to be called without the need for an
enum, which might be useful.
plus this also feels a bit better organized and easier to read when you
just need to look at one or two different triangle drawing
implementations.
in truth, there's a lot of per-pixel color munging going on in these
triangle renderers. maybe too much? we're doing a lot of operations that
are constantly deconstructing argb32 colors and then reconstructing, and
then deconstructing+reconstructing again. and some of the time we were
doing this as floats, via the "normalized" conversion functions. this
seemed to be adding a bit of "color jitter" that could be visible
at run-time when triangles were being animated somehow (e.g. resized).
also, the whole "inverse area" thing, while probably a bit of a
micro-optimization at best, was causing its own little bit of visible
"color jitter" sometimes, probably due to an increased level of
floating-point inaccuracy when representing the area as a fraction
like that.
improve in the readability sense, not performance i don't think, since
this style of iterator looping is what the slice fill method does
anyway i'm pretty sure
Gered