cycles should be unsigned, that remove huge delays when overflow happens, which is quite often. about gbsplay HOT 8 CLOSED

that remove huge delays when overflow happens

There shouldn't be any delays from cycle counter overflow, if there are it's a bug in the affected plugout.

or even better make it all 64bit.

long is already 64bit (on Linux) unless you are still on a 32bit arch (or on Windows).
However I'd argue it's better to make it 32bit throughout so we can weed out overflow handling bugs :)

from gbsplay.

obviously there is. use iodumper and examine the first column, there will be values in the middle of the song that don't fit any reasonable multiple of vblank period. like 93 frames. if you follow my suggestion - they all gone.

from gbsplay.

ps: yes, i'm compiling for windows.

from gbsplay.

Trying to reproduce this on mingw64, is there a specific song to try it on? I've been running
./gbsplay.exe -t0 -o iodumper /m/consolemusic/gbs/sml1.gbs 1 |grep '^[^0]'
for a couple of minutes now to check for overflows but nothing has come up so far.

from gbsplay.

mingw32. alternative solution is using uint64_t for the cycle counter.

from gbsplay.

2^31 / 4194304 / 60 => Signed overflow expected after 8.53333 Minutes
2^63 / 4194304 / 60 / 60 / 24 / 365 => Signed overflow expected after 69730.57 Years :)

from gbsplay.

from gbsplay.

maybe there is some sense in tidying up those cycle counts (and output only audio registers). i was making conversion tools for my SFX engine: https://github.com/untoxa/VGM2GBSFX and it is rather hard to make it all work without some crazy heuristics or manual editing. that is my point and suggestion.

from gbsplay.