Replies: 3 comments 6 replies
-
|
Thinking of it as tolerating late inputs such that you roll back the game state to revert a miss to a hit, I believe is making the problem more complicated than it needs to be. If the sync option were to instead delay the launch of the widget itself by a certain amount of time, then no rollback would be necessary for the game to function as normal. The only thing you would have to compensate for in that case is making sure the game logic acts on the widget in the original position rather than the offset one. For example, imagine an invisible widget launching at time 0, and the real widget launching at 100 ms after that. In that case, once the invisible widget touches a piston, you know the player must press a button 100 ms later, even if the piston has disappeared in the time between. Granted, this principle would only work for making widgets launch later rather than earlier, but input lag does generally cause late inputs rather than early ones. Alternately, I don't think it would be too impossible to generate a playalong chart for any given map. Any "spawn pistons" instruction is really just a set of "instant spawn" instructions, acting on one column at a time and offset by a known interval. So, for any given map, it can be known ahead of time where the pistons and rods will be on any given beat, and thus possible to know the playalong chart, along with what will happen to the piston should the player be early or late. And from there the widget offset problem can be solved in both the positive and negative directions. |
Beta Was this translation helpful? Give feedback.
-
|
Delaying a rod seems like a solution at first, but we have scenarios where the game state may change and then make it impossible for you to input. For example, if the entire row is despawned before you are supposed to input (with an offset). It unfortunately causes more problems than it solves. Generating a playalong map works for non-endless modes. We need a solution that works regardless of whatever we throw at it. |
Beta Was this translation helpful? Give feedback.
-
|
Since I have received two reports related to audio delay, a first step at a solution could be to move as much audio to be played back earlier, assuming the issue is that the audio is too late, and the display/visuals are synced well enough. The audio I could move back are music (as evident with the Music Offset setting) and most sound effects scheduled with events. I cannot move audio that is played as a result of inputs for obvious reasons (can't predict the future). I could, however, add options to mute those sounds entirely so that there's no audio feedback in case it is distracting. Display lag is a trickier problem because offsetting audio in the opposite direction just makes everything worse: the game world is still being simulated as the master point of reference (i.e. inputs are immediately translated into the game world), but now there would be lag with both the display and the audio. It gives the false impression that everything is synced, but you would still have to input earlier. I'm going to try my hand at doing music+SFX audio syncing today and see where that takes me. Display syncing will have to be more thought out first before I attempt it. |
Beta Was this translation helpful? Give feedback.
-
|
Should mention the sounds affected by these changes: Will be offset:
Considered a sound from an "input":
Any other sounds won't be affected by these offsets. Note that these offsets shouldn't apply in the editor, unless it's in Playtest mode. Right now, the music offset setting doesn't affect playtest mode. Additionally, the editor metronome in Playtest mode should also be offset or just disabled. |
Beta Was this translation helpful? Give feedback.
-
|
I have an early test build with my input calibration experiment, @Gotchfutchian @SomeGuyNamedDavid I kindly ask you to give the test version a shot (from issue #6). You will find that the Calibration settings menu (Settings > Input > Calibration) now reports an Audio Offset slider and a Calibration Test button. You can either adjust the Audio Offset slider yourself or try the Calibration Test (similar to RHRE's Playalong calibration) to get a feel for latency. The Audio Offset amount attempts to move certain audio early or late. The audio it affects is in the comment I posted above this one. There's also a setting in Audio to "disable player input sounds". Since I cannot move the sounds the player creates (piston extension, etc), you may want to just turn them off since they may be desynced from the game and thus be distracting. Please let me know how it works so far. I don't believe this solution is a silver bullet but I hope it helps. Thanks for your cooperation. |
Beta Was this translation helpful? Give feedback.
-
|
Um, what exactly are we offsetting here? Visuals? Audio? Input judgement window? |
Beta Was this translation helpful? Give feedback.
-
|
Man been a while since i was on this repo, Anyway, I personally wanted a way to calibreat similar to ADOFAI, see how long it takes for audio to be sent to the speakers, then on starting the audio track, delay gameplay by the latency. This led me to open Issue #6 which didnt explain my issue well enough. The main issue is the response audio, or the audio that plays on input. Because that would be affected by delay it would be offsync by default and be annoying to listen to, and create noise. I think the optimal solution is to also just copy ADOFAI again and when the latency is high enough, have the hit sounds always play in sync instead of on input. @chrislo27 , if you have any issues with this implementation let me know, and of course sorry for suddenly abandoning it all. |
Beta Was this translation helpful? Give feedback.
-
|
Also adding (cant edit replys on mobile), the input window should also be moved according to the audio delay. |
Beta Was this translation helpful? Give feedback.
-
|
If it's been a while, then I would suggest checking the already existing audio offset and calibration options to see if they help with your problem. I also need to mention that the development cycle for this game has ended as of the v1.2.0 release; I do not intend on another feature release. Major engine changes are far too late at this stage in development. Please keep that in mind. Audio calibration was added in v1.0.2 (released Sept 7, 2021) and we moved to a new audio backend (OpenAL) which improves compatibility and latency in v1.2.0 (released yesterday, Feb 1, 2022). You can finetune the OpenAL backend in Settings > Audio > Advanced Audio Settings and tweak the Buffer Count option to be as low as possible without distorting or garbling the audio. In Settings > Audio > Calibration you can disable player input sounds, which avoids the problem you mentioned of delayed input sounds.
This is sort of problematic because you can kill your own inputs (destroying a rod). This is why I opted to add a setting to disable player input sounds, based on from feedback from others I talked to, since I didn't get any feedback at the time this discussion was still active.
I'm not sure I exactly understand why this is needed. If you had, say 200ms of audio latency, and you offset the game by -200ms to compensate, then you would hear everything (music + gameplay sounds) 200ms early, and input at the correct time. If you have an example that would help me understand, I would appreciate it. |
Beta Was this translation helpful? Give feedback.
-
This is a discussion on the feature idea of input calibration. It is not guaranteed to be elevated to an Issue.
In Rhythm Heaven Remix Editor (RHRE), inputs can be offset to compensate for lag in some form. This is trivial because all inputs in Playalong Mode are already known ahead of time.
In Polyrhythm Mania, the inputs are not known ahead of time due to the extremely dynamic nature of the game. Additionally, there are physical penalties for earliness/lateness: the rod could be blocked by the early extension of a piston, and the rod could fall off the row and stop and explode if you are too late. Also, the inputs in other side modes like Dunk have to obey the same rules.
It is not as trivial as just offsetting the timings on inputs like in RHRE. That is only possible when the game has a kind of input chart (Playalong for RHRE, the note chart for Stepmania, etc). Therefore, for this feature to be seriously considered for implementation, the problems with (effectively) predicting the future and rolling back the past have to be solved.
Beta Was this translation helpful? Give feedback.
All reactions