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 ...)
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
i unfortunately feel like i should really force myself to use rustfmt
even though i very much dislike it. most rust developers seem to use it
so i should probably get used to it ...
however, case-in-point for me is the amount of times i used either
#[rustfmt::skip] or adding a blank `//` comment to force separate
lines, etc, really proves how terrible basing almost all of your
formatting rules on arbitrary length thresholds really is. code
formatting is far more subjective than that.
i'm going to guess this was added early on automatically by clion
and i just never caught it. they'd been here since the project was
first committed to a git repo. oh well.
we'll be introducing variable display size features next, so these
screen dimension compile-time constants are not going to be useful.
the "low_res" and "wide" features were also tied to the idea of
compile-time constants for display sizing so these need to go too,
and will be brought back via runtime configuration
this is mainly to prevent RgbaBitmap's from being initialized by
default to all black with alpha=0. this can still be manually done if
desired, but the assumption is that most of the time you'd want
alpha=255.
for the most part this doesn't matter one way or the other except when
we get to blending (not yet done for RgbaBitmaps, but coming soon) and
saving RgbaBitmap's to PNG files where it becomes blatantly obvious
when you have a bitmap with all/mostly alpha=0 pixels!
when reading palette files/streams, we set up the colour entries
using helper functions that automatically set an alpha component of 255.
however, we were first initializing the palette with 0 (alpha component
of 0 too).
this meant that if a palette of less than 256 colours was loaded, the
remaining entries (since Palette is always sized for 256 colours), were
black (0,0,0) with alpha components of 0.
this change makes all palette entries have a consistent alpha value
(which is never really used anyway ...) when loaded.
Gered