"on my machine" sync is fine but seems to be random whether it's OK or requires 7-10 ticks of delay. On the big screen @ Evoke, it felt like the sync was ~80-120ms off.
so i need to investigate the tic80 sources and figure out .. what exactly IS the reason for the delay and is there a way to be "perfect" / consistent?
already it's not actually looking promising:
https://github.com/nesbox/TIC-80/blob/main/src/core/core.h#L31
#define TIC_SOUND_RINGBUF_LEN 12 // in worst case, this induces ~ 12 tick delay i.e. 200 ms
TIC()s run at a fixed 60hz. The sound buffer is consumed at a nominal 60hz, but if there are any stalls, the position in the ringbuffer drifts.
if the host machine runs at a different framerate like 59.97hz as opposed to 60hz, maybe slippage can occur if vsync is enabled.
so an idea is to require --soft --fullscreen --skip at parties.
another idea: calculate actual drift by using time() versus ticks. time() is wallclock, so it should reveal whether TICs are being invoked at the right cadence. With VSYNC, tic80 will get bottlenecked and basically go only as fast as the refresh rate of the display. SDL sound buffer runs independently. So if the projector is 59.97hz, the ring buffer should experience skipping.
i think we should just try --soft, but also i would add a runtime check in case of broken timing. when time() and TIC() jitter too much, call it out in somatic state payload.
"on my machine" sync is fine but seems to be random whether it's OK or requires 7-10 ticks of delay. On the big screen @ Evoke, it felt like the sync was ~80-120ms off.
so i need to investigate the tic80 sources and figure out .. what exactly IS the reason for the delay and is there a way to be "perfect" / consistent?
already it's not actually looking promising:
https://github.com/nesbox/TIC-80/blob/main/src/core/core.h#L31
TIC()s run at a fixed 60hz. The sound buffer is consumed at a nominal 60hz, but if there are any stalls, the position in the ringbuffer drifts.if the host machine runs at a different framerate like 59.97hz as opposed to 60hz, maybe slippage can occur if
vsyncis enabled.so an idea is to require
--soft --fullscreen --skipat parties.another idea: calculate actual drift by using
time()versus ticks.time()is wallclock, so it should reveal whether TICs are being invoked at the right cadence. With VSYNC, tic80 will get bottlenecked and basically go only as fast as the refresh rate of the display. SDL sound buffer runs independently. So if the projector is 59.97hz, the ring buffer should experience skipping.i think we should just try
--soft, but also i would add a runtime check in case of broken timing. whentime()andTIC()jitter too much, call it out in somatic state payload.