First pass at trying to get the sound to play in the console. #11
I think this approach is fine for now, basically we keep a "predicted state" and tick the synths locally every time we render a game frame. It's kinda wasteful, but I'm not sure of another approach to use... Perhaps we can use channels and have the main thread "request" the sending back of audio every X samples or something, but I'm not sure how much better that will be.
Performance for this also seems pretty good, as the audio_test example runs at ~1% CPU or less.
The basic logic for this is:
Any time we save a state to memory for rollback, we also save along that predicted audio state.
When loading a state, we send the predicted audio state down to the audio thread and let it continue playing.
Whenever we call game_loop update, we also "advance" the locally predicted audio state along with it.
The saved data is the SoundEngineData struct, which might be kinda overkill but we can see how it performs for now.
Had to a bit of refactoring on how audio was being generated, as the previous method was producing too much crackling and too latency sensitive. This should be decent enough for a first pass.
TODO:
[X] Add sound engine to console
[X] Add raw Apis to Api list
[X] Add AudioContext and related functions
[X] Update gamercade_rs helper functions
[x] Update website with related functions and documentation
There's a minor popping issue when the audio callback & rollback are slightly out of sync. I've left a comment in the audio callback about this, maybe we can get it fixed later.
First pass at trying to get the sound to play in the console. #11
I think this approach is fine for now, basically we keep a "predicted state" and tick the synths locally every time we render a game frame. It's kinda wasteful, but I'm not sure of another approach to use... Perhaps we can use channels and have the main thread "request" the sending back of audio every X samples or something, but I'm not sure how much better that will be.
Performance for this also seems pretty good, as the
audio_test
example runs at ~1% CPU or less.The basic logic for this is:
SoundEngineData
struct, which might be kinda overkill but we can see how it performs for now.Had to a bit of refactoring on how audio was being generated, as the previous method was producing too much crackling and too latency sensitive. This should be decent enough for a first pass.
TODO: