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.
this probably doesn't really matter, as i understand it rust inlines
a hell of a lot of stuff, especially for method calls from within
the same crate ...
this is just a temporary alternative to the currently unstable
stream_len method, because i don't currently want to depend on unstable
rust versions if i don't need to.
this is to provide an easy way for game states to react to the specific
scenario where they were previously paused and then are re-awakened and
may want to perform (re-)initialization like they may have done in a
previous 'Pending' state (which is only set when states are first
created)
this removes some "dead" frames when pushing/popping states during the
transition between them where there would be at least 1 tick where
no update/render would be called because the top state would be still
in a "dead" or "pending" state
this is intended to allow a game loop to determine if the state
manager is actually doing anything or not, allowing the game loop to
exit out when it determines if there are no states and no more pending
states.
most apps would almost certainly want to add an Entities instance
to whatever context they were going to be passing in to these functions,
but removing the explicit dependency directly to ComponentSystems itself
removes some ownership issues.
Gered