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.
temporary measure until i feel like making the existing loading process
for all of these able to handle variable pixel bit-depth destinations.
not super high on my priority list so this may not happen for a while.
i did not read the doc comments for pointer methods and mistakenly
thought i needed to calculate raw byte offsets here, but actually it
works in units of size T (where T in our case is either u8 or u32)
Gered