Closed S1n1st3rn3ss closed 7 months ago
The only way to fix this is to store previous state and check if it changed.
Is that an issue though? You wouldn't use that data outside of gameplay anyway, right?
You wouldn't use that data outside of gameplay anyway
If an overlay stays on the screen permanently (most simpler overlays do), it will show incorrect data when moving from gameplay to song select, forcing overlay creators to wipe that data themselves, can be slightly annoying
forcing overlay creators to wipe that data themselves, can be slightly annoying
Yep i agree, i thinks it's much simpler to wipe it on rosu-memory side. Storing previous state cost and checking it every read cost us almost nothing. But then there's another problem - port counters properly to avoid unnecessary work that (e.g. as stated earlier wiping data when changing to SongSelect
from Playing
state) rosu-memory already does/will be doing in the future. I think we should document those small beneficial differences pretty clear so counter creators could tweak their code?
I think we should document those small beneficial differences pretty clear so counter creators could tweak their code?
I could get to that at some point, yeah
fixed in 8c8dac736a3f7571cbd36482c30c51164ee290a6
Gameplay data (300/100/50/0, combo, etc) doesn't get reset upon entering song select screen, only when starting a new beatmap