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)
this is an unfortunately large commit. probably should've been broken
up into multiple smaller ones.
i decided to revert some earlier preparatory work i had done to organize
graphics functionality into two main streams: "indexed" and "rgb". this
was going to result in two completely different Bitmap structs which
were going to be largely similar and as i thought about it more, i
realized my earlier thinking that i wouldn't be able to generify the
Bitmap struct based on pixel-depth was actually not correct.
so, this commit re-works things significantly in a way which i think
is better but probably still not perfect. basically, we have one
Bitmap struct which provides a lot of generic functionality, but also
specialized implementations based on pixel-depth and this is now what is
separated out into graphics::bitmap::indexed and graphics::bitmap::rgb.
but the rest of the graphics functionality is not separated out by
module like this any longer.
note that i've still kept the GeneralBitmap trait and implementations.
i was originally thinking i could get rid of this since i'd now made
Bitmap generic over pixel-depth, but doing so would require me to
rename the common/general blit methods to avoid a name collision with
the specialized implementations (since they would both exist on the
same types now). and i did not like that. i dunno, maybe i will change
my mind later.
these are obviously useful to new 32-bit graphics functionality, but
they are also useful to indexed colour functionality such as palettes
and blendmaps.
though i am not sure how good an idea my approach was with a bunch of
intermediate preludes. i was thinking it might be nice to be able to
only pick out the preludes that you wanted (if not all), but ... would
i ever really need to do that? somehow i am thinking, no, but i will
give it some more thought
Gered