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
this also includes a semi-important change where the existing
BitmaskCharacter draw implementation will now not draw anything if
FontRenderOpts::None is passed in, instead of just substituting color 0.
this probably makes more sense this way anyway
at this point i am 99% certain that the previous issues i was having
with making GeneralBlitMethod generic over the bitmap PixelType was
because i was trying to specify a constant PixelType value in generic
code (CustomMouseCursor).
whether this was actually the problem or not i think is besides the
point however because while thinking about this i suddenly realized this
was incorrect anyway!
making CustomMouseCursor generic via GeneralBitmap means that specifying
constant colours was not going to produce expected results (e.g. '255'
has a very different meaning for indexed colour rendering versus for
32-bit RGBA colour format).
so, CustomMouseCursor now figures out the correct transparent colour
to use from the DefaultMouseCursorBitmaps implementation.
this allows us to make GeneralBlitMethod be generic over a bitmap's
PixelType again and i'm sure we won't have that previous issue again as
long as we don't try to specify constant colour values in our generic
rendering code ... which we should never be doing anyway!
this contains an unfortunate hacky change to the BasicBlitMethod enum
which used to be generic over a PixelType (same as BasicImage is
currently). i really do not like this, but i could not find any
solution to the problem.
admittedly it's not the worst hack solution in the world, but it does
technically allow calling code to pass colour values that are outside
the supported range which may lead to odd results at runtime.
this is to not have the main Mouse struct be tied to our indexed-colour
Bitmap graphics implementation (i'm not currently ready to try to
generify this either ...)
since i realized there is an SDL hint that can be used to toggle this
the reason why the rust-sdl "Canvas" struct (which abstracts an
"SDL_Renderer") is not being created in System directly (which would
allow vsync to be toggled on/off via System directly without the use of
a hint) is because not all future SystemResource implementations will
need it (e.g. a future OpenGL implementation definitely won't).
System now uses a generic SystemResources structure to provide video,
audio and input devices
the DosLike implementation of SystemResources provides the same
functionality that this library has had to date.
this change is to prepare for future addition of things like 32-bit
Bitmap support and other possible audio device implementations, etc.
the idea is a custom SystemResources implementation can be substituted
in to configure everything with the desired functionality.
i didn't really think i was gaining anything from the separate error
types because in basically every case these were being used to just
capture and return an underlying SDL error
note that i'm intentionally not using rustfmt. i've tried to like that
tool, but in the end i just really don't like it. too many edge cases
and subjectivity and not enough customization. which is probably the
intent. which makes me hate it that much more. fuck you, rustfmt.
- the new InputDevices struct is added to simplify input device
updating and event processing of input events for all input devices
now available, as well as future proofing for new ones (e.g. gamepad).
this also helps us out with implementing better ways of doing custom
application main loop SystemEvent handling ...
- System::do_events_with has been removed. if custom event handling
is needed by applications, they should now implement this themselves,
as demonstrated by the example in the doc comment for
System::do_events.
-
we just use a catch-all "Unimplemented" enum for the sdl2 event types we
have not mapped / don't care about yet.
this change is mainly just so that we don't need to use TryFrom anymore
as this simplifies making our own SystemEvent iterator
as well, it felt wrong to return an error (even if silently ignored)
whenever an unmapped sdl2 event was raised (since that could happen
fairly often)
work in progress stuff that will be tweaked as i convert things over to
use this and, i assume, inevitably encounter problems and/or discover
some better ways to do it
they all still depend on sdl2 through the libretrogd dependency, but
the benefit is that future sdl2 version updates are much easier to
accomplish for most apps, since only libretrogd needs to be updated
(in theory).
Gered