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