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 ...
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!
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