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.
rename the old "apply" to "apply_to_device". meh. naming is hard.
i expect that most of the time i'd want to use the "apply" method i'm
adding here that handles device locking internally, so that is why i've
chosen to let it be called "apply" and to rename the other one.
for queuing audio "commands" which is a much nicer way to interact
with the audio system in general in a more complex application, as this
lets you play audio in more of a "fire and forget" kind of way.
Rc<AudioBuffer> play methods provided as an alternative because
otherwise you end up with a somewhat gross double-copy of the audio
buffer being played. but i didn't want to necessarily force use of
Rc<AudioBuffer> just yet ... thus both versions of these methods are
provided.
Gered