Input Lag in Hatsune Miku Project Diva 2nd #4020
Comments
|
I thought there might've already been an issue for this? I think someone said toggling some settings improved it. Maybe I'm wrong. How far off is it? Like very noticeable, or just enough to screw up timing? Are you using a controller, Android, Windows...? -[Unknown] |
|
I have this game, and on the latest revision (0.9.1-1463, tested hours ago) using my Core 2, ATI 4670 and Windows 7 x64 SP1 system, it's still pretty much perfect in terms of the timing, when using either my Keyboard or my wired x360 for Windows controller. I'll wait for @thedax to chime in too, since he has this game and regularly boots it up for testing purposes. (jukebox etc) Basically, this game has been one of the crown jewels in terms of compatibility in PPSSPP for a long time, and it is possible to finish (0 - 100%) the game on Hard (tested) without too much trouble (on a controller) if you're a proficient enough player on PPSSPP. Now there are other games that significant input timing issues like Patapon 1 for example (inability to maintain Fever status easily), but not this one, at least from my end. There was also a Low Latency Audio option that was merged into master quite a long time ago that was supposed to help as well for those other games. The user has got to be using Windows (or some desktop OS), since he/she mentions that JPCSP does not have the same issue. EDIT:- Using FXAA introduces some input lag on my end it seems (even with consistent 100% speed), I've been testing this game all this while without FXAA, since default settings don't involve using it. |
|
I'm surprised FXAA would cause a noticable difference to lag, it shouldn't unless your GPU is really, really slow. Placebo effect? Some graphics drivers will automatically triple buffer, which can cause an extra frame of lag if implemented badly. There are hacks around that, which might help too. |
|
@unknownbrackets Its noticeable on the highest difficult where you need to press more buttons @solarmystic I finished the game and i'm only aiming at Perfect on Extreme difficulty @hrydgard FXAA enabled and its still the same, no differences. And i'll upload a video showing the same song on Project Divan 2nd and Extend,maybe that can help to see where the issue is. |
|
Note that some keyboards may have lag or errors when you press multiple buttons at the same time in quick sequence. Probably a usb controller would work better here, but unfortunately on Windows currently they are all polled 60 times a second (so they may not be sampled frequently enough.) This situation may be better or worse on Android, I'm not sure (probably better, assuming things can keep up...?) So changing your input method may affect it. Theoretically, mouse might actually be the most accurate... unless you have an expensive keyboard, in which case it's probably fine. -[Unknown] |
|
I'm using a gamepad, to be exact a Sony PSOne gamepad. |
|
Here u can clearly see that there's something wrong. |
|
sometimes presses are registered twice, most of the time they are just unreasonably desynched. for example, you may try to hit whole notes like this PA-PA-PA-PA, but it ends up coming out like PA-PAPA--PA. tried a wireless keyboard, wired keyboard, wired ps3 controller. all have the same input lag. not going to try any more input methods as all the users here have reported the problem with a variety of different hardware, it's clearly the emulator's issue. putting it bluntly the lag issue makes the game pretty unplayable on all difficulties. project diva games have always been really stingy about timing. the only way to play is to compensate for lag by hitting notes before they match up. |
|
@unknownbrackets Can you investigate more around multihtreading with non buffered rendering? Setting the game to Buffered/CPU/GPU Rendering with multithreading fixes the graphical issues but input lags come back. EDIT:The Non Buffered Rendering + Multithreading Method might not be 100% sure that could fix it, its almost unplayable on it so i can't give you a 100% answer to that. If things wouldn't jump in and out and there wasn't the flickering i could give you a straight answer. |
|
If that helps it just means your device is too slow, I think. Both of those impact performance and not input at all. Multithreading ONLY impacts the GPU right now. It doesn't make input or audio multithreaded. So, if that helps, it helps because of better timing. Same with buffered rendering. If turning that off helps, it just means it's spending less time drawing. -[Unknown] |
|
So, I did some tests. With my PS1 controller and adapter (which is DirectInput), I seem to only get analog changes with a resolution of 0.072052 seconds between changes. That's like 14 fps at best. About the same for buttons and HAT: 0.071762. The sample resolution is definitely better than that. I wonder if it's just my controller, though. -[Unknown] |
|
Could be your adapter, too. |
|
Right, sorry I meant either one. I kinda doubt DirectInput is that bad. And I assume XInput must be better. But I wonder what resolution we can get. It's fairly easy to test. Just log the real_time_now() change whenever the joystick state is altered, and then unthrottle PPSSPP while you mash buttons. Since it's unthrottled, it'll sample more times per second. Actually, I think we may only sample 30 times per second if the game is 30 fps, now that I just say the above... -[Unknown] |
|
Idk what u guys are talking about but i'm happy that there is still some progress here. |
|
@hrydgard so, aside from my poor DirectInput support, it's pretty clear from #3318 that sampling the controllers is currently done at the game's framerate. On Windows, splitting it off to a thread would be an easy way to solve this, where they could poll the controllers 120 times per second, for example. However, on Android, that won't ultimately help. I think controllers are actually processed on a separate thread there, but the on-screen buttons aren't. Ideally, we should check those 60 times per second even when the game runs at 30 fps. And SDL/Blackberry/etc. have the same issue even with controllers. So... we could still exit the loop and not flip I guess? Or add a NativeSomething to process input only? May still thread up the inputs on Windows to be sure. -[Unknown] |
|
Hm. On Android, touch events are immediately sent through to the app through NativeTouch and there is no buffering apart from any that the Android OS does for us. The old touch buttons were updated once per frame but the current ones update instantly, I think. So display framerate should be irrelevant. There are two other issues causing latency on Android though:
|
|
Here's something to try: You'll need to build this branch, and then edit your ini (maybe run and close PPSSPP first just to get the setting in there): ForceLagSync = True This will keep the game clock and real world clock in sync approx every 1ms. Things to understand about this:
Anyway, I don't really have a test case for the latency and I'm not a twitch game person, so this isn't well tested. But in theory it ought to work. -[Unknown] |
|
@unknownbrackets |
|
@unknownbrackets First up, the good:- Instananeous inputs during gameplay. Somehow the game registers them even better than before, even though it was okay for me before this. The bad:- The games don't ever hit full Speed now, they go close to it but not quite there, almost as if the emulators framelimiter is borked. This is not a hardware performance issue since if I unthrottle the framerate, it shoots up to the hundreds. Seems like it's only hitting 95-97% which makes the audio very stuttery. Here's a screenshot of what I mean:-
I guess my ancient Core 2 laptop isn't quite powerful enough to enable this option and still get 100% Speed ingame. I did notice that 1 core of the CPU is being completely maxed out by the program with this option enabled with MT disabled of course. |
|
Yes,I tried patapon 3,also hitting30/30(96-97%). |
|
Again, it's syncing to the cpu every 1ms. If emulating any 1ms chunk of game takes longer than 1ms, this means it will be slower overall. That's why we don't do this normally. Please re-read the bold part of my comment. It could be potentially made more adaptive, at least with some room for error, but this was just an experiment to see the effect on lag. But either way, if your system can't keep up realtime, then it's going to make you lose fps. How we normally do it: This makes it: This incurs a speed penalty, because if anything takes too long in the normal method, it looks like this: See how it's still okay? That's not happening anymore: Now you're lagging behind. But, the upside is your watch on your wrist matches the watch on the game, every millisecond, instead of just 30 or 60 times per second as before. -[Unknown] |
|
@solarmystic Mind if you share the build? |
|
Turn on multithreaded,It's stable on 100%,I think it's not that demanding. |
|
@GamerzHell9137 |
|
@daniel229 Interestingly enough, the FPS issue that usually happens with the Project Diva games when Multithreaded is enabled does not exist when Lag Sync is also enabled. |
|
Tried, the input difference is huge in Extend but in 2nd its almost the same. |
|
How about android? GamerzHell9137 [email protected] wrote:
|
|
@yanthey Quoted from Unknown [ This may not work well on Android. ] |
|
ForceLagSync = True,make the game #6196 staying on 100% ForceLagSync = False |
|
Yes, it will also correct timing in games that flip in weird ways that we don't handle well. You can try it on Android but on some devices I can definitely see it making audio lag worse. -[Unknown] |
|
Bad, this game can't load save data on my android. "Unknown W. Brackets" [email protected] wrote:
|
|
Sorry, save data work fine,, but final fantasy crisis core force close on new build of ppsspp. "Unknown W. Brackets" [email protected] wrote:
|
|
If #6220 / the lagsync branch doesn't help 2nd, I don't know what could be wrong with its input timing. This was the only thing left that I knew about. -[Unknown] |
|
@unknownbrackets Nope, Lagsync doesn't fix 2nd but it helps a bit. Maybe the 2D elements(HUD) are making some kind of issue with the game? The other thing is that in each song the sync may be better or worse, dunno why. Ohh and one more thing, Multithread makes the input worse in both Extend and 2nd. |
|
So, ignoring multithreading which has its own issue, is this still an issue with recent changes? -[Unknown] |
|
@unknownbrackets I still find the Solarmystic's 2nd build better. |
|
@unknownbrackets And one more thing, the master build eats the input too. I've recorded myself and slowed down the footage so see if i'm 100% sure about it cause during gameplay i felt that i did press the button more than i should. In Solarmystic's 2nd build 11 button presses is 11. |
|
No new reports about the game, it plays the same on 0.9.9.1 too.
https://www.youtube.com/watch?v=7f8IRWZNuug&feature=youtu.be |
|
I'm playing the three Patapon games and I get a lag of about 300-400 ms, which makes it impossible to play. I've tried both Android and Windows, bluetooth controllers, wired controllers, and keyboards, with the same result. I have tried changing all options related to sound, input, graphics, etc, with no success. I don't have noticed the lag on other games, but it may be because timing is not so critical... Im on 1.0.1 |
|
Some good news, as of 1.4.2-198, this game no longer appears to have any sync/timing issues. I'm using Mac build, on a machine that previously had lag issues when I last tried (around ppsspp v1 if I remember correctly). Audio latency is set to low in settings. If you've had issues running the Project Diva games in the past, you may want to try again! |
|
@Wowfunhappy its same, there's been no changes. |
|
Well, that's odd, because it definitely improved for me on the same machine—the game was unplayable before. I suppose something else in my system could theoretically have changed though. |
|
Improved? Yes. Like it should be? No. |
|
Just a note, as seen in #11813, the real clock sync setting was buggy before but should work correctly now. Note that as per #10195, if you're using OpenGL of Vulkan, you're likely to have some lag in the screen updating versus what's happening in the game. It might be worth trying this now with the force sync setting enabled and using D3D9 or D3D11. Note that forcing clock sync is slower, and works best on Linux/Mac (Windows will have an additional ~2ms input lag because of how its timing functions work, but they work accurately on Linux/Mac/Android - of course Android doesn't have D3D.) -[Unknown] |
|
@unknownbrackets Other than Force Real Sync and DX9/11, any other option that can improve the input lag on Windows? |
|
Well, the lower quality settings are presumably better. Make sure you're not using locked CPU speed or any audio hacks. In theory, non-buffered rendering might have slightly less lag (I'm not sure.) Just to mention, it's entirely possible that the physical PSP has some input lag (the LCD was slow) and that these games account for it by applying a negative offset to controller input. In some ways, this could explain the earlier comments about multithreading improving the situation. If the game does that (once #10195 is fixed, which most likely? is slower than the PSP would be), the problem could be that we're BETTER than the PSP, and so the offset the game uses goes in the wrong direction and makes it think your presses are too early. That means there might be a "goldilocks zone" for input lag. "My score was lower than expected" is a binary measurement, so it will be difficult to zero in on the +/- of that zone if there's no way to say "I average too late" or "I average too early" compared to playing on a PSP. -[Unknown] |
|
@unknownbrackets Yeah, non buffered makes the input better but in general it feels almost the same. A bit better but yeah, still feels "weird". Don't have a PSP but its funny how Vita and PPSSPP on PC feel different with the input. About input offsets, is it possible to implement something like that in PPSSPP? The newer Diva games have the option on PS3 and PS Vita which compensates for LCD lag. Still idk if that would fix it, PPSSPP always had this feeling of "you press the button but the game reacts later to it". And I remember before Megpoid the Music # had less input lag with higher refresh rate monitors (played on 75 Hz), i guess the game reacts different than Diva because it didn't help Diva with input. I think i talked before about Exclusive Fullscreen mode, that might lessen the input lag because in borderless Windows is forcing its vsync and adds a lot of input lag. |
|
The trouble is that it's game logic applying the offset. Retroarch implemented something for NES games that basically uses savestates every single frame. But NES games had about 4KB of RAM, the PSP has 8000 times as much. For a PSP, saving state every frame is too slow and would CAUSE input lag, not solve it. RAM has only gotten about ~30 times faster maybe since the NES; size gains have outpaced speed gains. It might be possible for someone to create a cwcheat or hack to adjust the input lag offset the game logic uses - assuming it even exists. Basically it would have to change the logic so that the "right time" to press a button and get a score is +input lag ms after it's actually displayed. PPSSPP has to run the game logic to generate graphics, so it only has the ability to move everything together (without the save state thing I mentioned above, which really is a smart idea, but as I said not practical for a PSP game.) -[Unknown] |
|
That sucks, welp i guess we gotta wait for that #10195 fix |
|
Imo input lag offset wouldn't cause people with this issue to get better at the game, I would rather say that the "Input lag" imo should be even less of a problem in rhytm games than any other genre as even without game offsetting it, such games are awfully predictable and any player could offset it himself or starting playing on an emulator even not feel anything wrong with it. I do believe based on ways DrawSyncEatCycles hack noticably affecting some of those games(even fixes #9842) and older issue about patapon 1 fever being hard to keep (#2498 ~ which I believe might still be an issue), that the actual problem is that some key presses are expected to happen at different timing than the rest, I recall we had some thread on forum about Patapon 1(long after the issue about it was closed hence I believe it's still a thing) where I helped someone to track some code in disassembly and from that I recall that fourth beat had different timing than the previous 3 when the fever was up, making it much harder to keep, but since it was weird in same way each time, eventually I couldn't tell if it was really broken or not since I got used to it after a few failures.. PS Vita also has imperfect PSP emulator, definitely not cycle accurate, despite being an "official emulator" it's likely even less compatible than PPSSPP at this point in time and should never be used as an example of how games should work on the real hardware. |
|
Just wanted to let you know that enabling real clock sync on Android as well significantly improves the input lag (Vulkan and OGL). There's still a tiny bit of lag as mentioned, but it's negligible compared to before. Finally the game is playable! Thanks. |
|
I feel like there haven't been many people saying this isn't good for a while, and #10195 already covers "all" Proejct Diva games, which presumably includes Project Diva 2nd. So I'm going to just close this as a duplicate (even though that was opened more recently.) -[Unknown] |
It seems that the most important part of a Rhythm games, the inputs, are delaying in Project Diva 2nd.
It works normal on JPCSP but on PPSSPP it doesn't.
And just want to say that Project Diva Extend doesn't suffer of that problem.
The text was updated successfully, but these errors were encountered: