this is to not force _some_ sdl2 type usage onto applications, thus
forcing them to also include sdl2 as a dependency themselves.
that being said, this is still pretty gross feeling to me and i wish
there was a better solution.
i've not added all possible sdl2 event equivalents. only the ones that
i am currently interested in and use. i'll add more as is needed. likely
the joystick / controller events will be added in the very near future.
0.35.2 is the latest version available via cargo right now, and that
version has some issues building for me that have been resolved in
subsequent commit(s). for some reason the maintainers have not pushed
a new version of sdl2 to cargo for quite some time despite numerous
fixes and updates being available ...? bah!
also the current sdl2 `features` set will probably only work for linux
builds. i will try to work out windows + mac build issues shortly
due to encountering some compile errors on a fresh system which pulled
down the newest minor versions of both. these two libraries do not seem
to follow "good" semantic versioning ... ? ugh. will try to work out
the compiler issues with the latest versions of these later ...
since the keys for the previously used hashmap all corresponded with
an index, this can obviously just be a vector where the element index
corresponds to the lzw code. simple.
i think i prefer this style. it's not _technically_ as safe as it was
before, but i prefer the explicitness of it (and it results in a little
bit less nesting in system functions which is nice).
i don't much like the need for an explicit `unwrap()` call however
but that's the tradeoff!
i originally added LzwDataBuffer under a misunderstanding that i was
going to need to track values in these buffers that were not just
limited to 8-bits in size. this is not actually the case, so we can
do this change to simplify things.
maybe marginally better/simpler, but also some minor cleanups and a
semi-hackfix for minor destination blit corners being cutoff slightly
for some rotation angles
but there are still performance improvements we can make. but at least
now we're not doing some silly double-pixel draw as a band-aid over
missing/gap pixels. and we no longer sometimes have missing scanlines
due to floating-point rounding issues.
mainly switching #[derive(Debug)] to manual std::fmt::Debug impls to
remove debug strings that would otherwise contain long strings of
byte arrays which most of the time isn't so useful to see in any kind
of debug logging
this might still need to be tweaked still as benchmarks are showing
some performance loses (though, also, some minor performance gains?)
so i guess the lambda functions may not always be inlined, or if they
are, the optimizer isn't able to do the same level of optimizations as
it was before? unsure as of yet, so need to investigate further.
however, none of the performance regressions were huge, so i think this
is acceptable to me for now.
libretrogd was never intended to push performance boundaries anyway :-)
Gered