of course, here we immediately must question whether this is abuse
of operator overloading or not. since you cannot otherwise multiply
these types together, i think this is fine. plus we are not providing
any other math operations via operator overloading, so this feels like
a very explicit thing to do
two primary goals with this change:
1. test triangle dimensions of varying widths, in preparation for
upcoming simd per_pixel_triangle_2d changes. we want to ensure that
scenarios where `width < 4` and `width % 4 != 0` continue to work
fine after simd changes are done
2. test triangle rendering at various rotations, because i remember
while testing fill rule changes, sometimes issues would only be
visible at certain rotations. so this is mostly just useful for
blended rendering methods, but still, is probably generally useful
too ...
i did not expect this to be problematic so soon, based on what i'd
read in various places about the stability of nightly (especially so
for the most common platforms like x86_64, etc)
as i write this commit message, all nightly versions past this date
fail to build ggdt, failing with an "illegal instruction" error.
sigh. this makes me question whether trying to use simd right now is
actually worth it ...
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
Gered