i really did not want to use nightly, but i think it is worth it for
portable_simd which is still nightly-only (and i'm guessing will be
for a long while still). i was not particularly enthusiastic about any
of the alternative libraries that exist for stable rust simd, as it
always seemed like something small was missing from what i knew i would
want longer term.
the color type aliases have been a long time coming. it might make
sense to re-work the various color functions into some traits that
these color type aliases implement.
added the color function variants that accept and/or return 4 color
component arrays to aide in code that is doing more complex color
manipulation where it just makes more sense to always be working with
4 color component arrays instead of always converting to/from packed
and unpacked formats
this is based off what i saw some other libraries doing. i'm not sure
what is the "best practice" to be honest, but i definitely like this.
especially the prelude is now much simpler, which is nice.
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.
Gered