In line 167 of kshootmania/src/MusicGame/GameMain.cpp, current implementation of the offset adjustment is:
(offset + effectiveGlobalOffset) / 1000 / speedRatio
My implementation is:
(offset / speedRatio + effectiveGlobalOffset) / 1000
This will have the same effect as simply divising offset in the chart data by the speed ratio.
I built a patched version based on alpha5 and no timing issue was found. Also, in v1 i tried to change the music files and the offset and bpm in chart data manually, and this worked fine for me too.
I would like to ask the meaning of globalOffset and visualOffset, and what would the difference be between these 2 implementations.
Thanks.
About the implementation of BGM offset adjustment according to playback speed
カテゴリ: 質問
(スレッド番号: No. 103)
1 : ZAO
2 : masaka(管理人)
Originally, globalOffset was intended to behave the same as shifting the offset value in all chart data by a specified amount. visualOffset, on the other hand, shifts globalOffset while also shifting the judgment timing (inputDelay) in the opposite direction by the same amount, effectively resulting in a visual-only offset adjustment.
Based on this intended behavior, the current v2 implementation, where playback speed scaling is applied to globalOffset, is consistent with the original design. However, as you pointed out, in practice it is mainly used for judgment timing adjustment, so it may be preferable for it not to be affected by playback speed changes.
Also, since visualOffset needs to shift globalOffset by the same amount as timingAdjust, which is not scaled by playback speed, it looks like at least visualOffset needs to be fixed....
I will take some time to review whether playback speed scaling should be applied to globalOffset itself, or whether only the visualOffset portion should be scaled when applying it inversely to globalOffset, and determine what fix would be appropriate.
Thanks for bringing this up!
Based on this intended behavior, the current v2 implementation, where playback speed scaling is applied to globalOffset, is consistent with the original design. However, as you pointed out, in practice it is mainly used for judgment timing adjustment, so it may be preferable for it not to be affected by playback speed changes.
Also, since visualOffset needs to shift globalOffset by the same amount as timingAdjust, which is not scaled by playback speed, it looks like at least visualOffset needs to be fixed....
I will take some time to review whether playback speed scaling should be applied to globalOffset itself, or whether only the visualOffset portion should be scaled when applying it inversely to globalOffset, and determine what fix would be appropriate.
Thanks for bringing this up!
3 : ZAO
Based on this, maybe separating the offset setting of sound and visual like several other games would be a good idea?
4 : masaka(管理人)
Yes, I agree with you.
In v2, I’m planning to revamp the options screen and make visualOffset adjustable in-game. Right now (in both v1 and v2), it can only be changed by editing config.ini (the "visual_offset=..." line).
As for globalOffset, it’s kept only for compatibility with the timing adjustment behavior in older versions, and it’s basically intended to stay at 0 for normal use. So I’m planning to keep globalOffset editable only via config.ini.
In v2, I’m planning to revamp the options screen and make visualOffset adjustable in-game. Right now (in both v1 and v2), it can only be changed by editing config.ini (the "visual_offset=..." line).
As for globalOffset, it’s kept only for compatibility with the timing adjustment behavior in older versions, and it’s basically intended to stay at 0 for normal use. So I’m planning to keep globalOffset editable only via config.ini.