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 ...)
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
i'm not *entirely* sold on this particular enum-based api, but i think
it could work. in the future i'd likely ALSO want something that could
work with triangle data as an offset from a larger buffer, but we can
solve that problem later when it comes up.
mainly i just didn't want to have a bunch of different triangle_2d
function variants exposed. same justification as with the blit enums,
basically.
the difference is important to note since most articles discussing
implementations of barycentric triangle rasterization show a test
for positive w0/w1/w2 to determine if you're inside the triangle or not.
they also usually use a slightly different formula in the `cross`
function if they assume counter-clockwise vertex winding.
since i'll admit i still don't *fully* grasp the math behind the edge
functions and that stuff that is used to calculate the a01/b01/a12/...
values, i wasn't sure how to adjust these for counter-clockwise winding
to keep a positive w0/w1/w2 check. so the simple solution is to use
the `cross` function as it is now, calculate a01/b01/a12/b12/a20/b20
as we are now, and do a negative w0/w1/w2 check and we get to keep
counter-clockwise vertex winding which i prefer. hooray!
to be honest, i'm not sure how this compiled successfully before, since
the value being passed in via Bitmap::triangle_2d_custom is clearly of
type `&mut PixelType` ... ? either way, this is now written consistently
and we get to remove an unnecessary unsafe block
Gered