search

mmitch / gbsplay

gameboy sound player
https://mmitch.github.io/gbsplay/
Other
98 stars 19 forks source link

cycles should be unsigned, that remove huge delays when overflow happens, which is quite often. #82

Closed untoxa closed 2 years ago

untoxa commented 2 years ago

plugout_io_fn prototype should be something like: typedef int (*plugout_io_fn )(unsigned long cycles, uint32_t addr, uint8_t val);

also previous value: static unsigned long cycles_prev = 0;

also gbhw.sum_cycles

or even better make it all 64bit.

ranma commented 2 years ago

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 :)

untoxa commented 2 years ago

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.

untoxa commented 2 years ago

ps: yes, i'm compiling for windows.

mrehkopf commented 2 years ago

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.

untoxa commented 2 years ago

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

ranma commented 2 years ago

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 :)

mrehkopf commented 2 years ago

"Toxa" @.***> schrieb am 12.02.2022 11:07:36:

8 minutes is a pretty small amount. also cycle count may not reset between songs.

why not just simply test?

gbsplay.exe -o iodumper CGB-B3AE-USA.gbs >aaa.txt

00000014 ff14=06 00011274 ff13=f5 00000014 ff14=06

0035930c ff1c=40 ^^^^^^ almost 1 second of pause in the middle of the song.

0000006c ff1d=6e 00000014 ff1a=80 00000030 ff1e=82 I ran a mingw32 build with the shantae.gbs for about 15 minutes and did not notice any pause during playback. Could it be your audio hardware/drivers? I do see a delta of around 0x3c3678 ticks in the iodumper log but it seems to be the wrapper code that terminates playback at the end of the subsong (after silence detection). Definitely looks different from your dump:

00011264 ff13=04
00000014 ff14=07
003c3678 ff10=80
00000000 ff11=bf
00000000 ff12=00
00000000 ff13=00
...
00000000 ff3d=dd
00000000 ff3e=da
00000000 ff3f=48
ea2998b4 ff06=00
00000000 ff07=f8
00000000 ffff=05
subsong 1
00000248 ff26=f1
00000014 ff10=00
0000009c ff12=00

ea2998b4 looks wild but it's probably from restarting the cpu/cycle count for the next subsong.

untoxa commented 2 years ago

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.