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).
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.
Gered