Great, I’ll see if I can get it running in the same way.
Just so you know, using the pause-step method you will actually mask any differences between the video drivers. Your test results are great when it comes to evaluating the emulator lag, though. They match up well with my tests as well.
Anyway, unfortunately, you will need to record the action and count frames to really find out if the video driver makes any difference. I’ll see if I can do a test like this within the next week or so.
[QUOTE=Brunnis;42172]Great, I’ll see if I can get it running in the same way.
Just so you know, using the pause-step method you will actually mask any differences between the video drivers. Your test results are great when it comes to evaluating the emulator lag, though. They match up well with my tests as well.
Anyway, unfortunately, you will need to record the action and count frames to really find out if the video driver makes any difference. I’ll see if I can do a test like this within the next week or so.[/QUOTE] Ah, that clears up the confusion.
Also I heard the there’s no frame delay on ios? That it has 3 frame delay. I wonder if thats true.
Feckin A guys. I was checking this thread daily, until I stopped for a while due to a newborn son. Not only does the new commit completely solve the problem, I can finally start planning to enjoy the greatest system of all time with him. Kudos for a simple and easy fix. Mario World plays like butter now.
They grow so fast!
[QUOTE=Brunnis;42169] Yep, this is great news. The fix was just committed to both the regular bsnes and the bsnes-mercury cores. I’m taking a bit of a break from the emulator analysis stuff for the moment, but I’ll probably spend more time on it in the future. To be honest, though, I’m quite pleased with having removed 1 frame of input lag from fceumm, snes9x, snes9x-next, bsnes and bsnes-mercury. :-)[/QUOTE]
You rightfully should be 
With regards to finding more possible targets, are cores that have a frame count of 3 (or worse) with the frame advance method possible suspects?
Would it be useful for people to report them here if they find a core that does not go below a value of 3 when tested with say a suite of games?
Just tested Megaman X2 / X3, US and Japanese, on bsnes / bsnes-mercury, balanced / accuracy, pre/post Brunnis patch:
nothing wrong here.
I passed the capcom logo, title screen, played half way in the level.
Win7 x64 nvidia opengl.
Tested with the buildbot version through core updater, no issue with bsnes/bsnes-mercury on Rockman X2.
The MSU-1 chip is working.
I notice a big slow down with bsnes/bsnes-mercury balanced right on the title screen if GPU hard sync is ON @0. GPU hard sync OFF = no slow down. Brunnis patch makes no difference.
Then playing the game is OK with GPU hard sync @0. That’s strange there is that processing peak there on the title screen, perhaps a pre-loading?
I’m going to assume this is all for games that are actually patched for MSU1 audio and not just MSU1 capable games.
There have been a few committs today fixing a potential issue with the clearing of the frame event flag. For those of you who have seen issues with MSU-1 patched games, please compile bsnes (non-mercury) from source an retry.
I still haven’t been able to reproduce the issue, so no idea if the changes help.
Would be interesting to confirm whether the same occurs in bsnes-mercury.
Yeah it’s probably a serialization + MSU-1 issue that gets actually worse with the input lag hack. I don’t really understand why it happens when music playback starts, maybe the state size changes when music starts? that could explain why it works fine with super road blaster since that one is MSU-1 all the way.
Yep, the state size was one of the first things that came to my mind as well. I’ll try to look some more into the issue as soon as I get some spare time for it. Probably not this week, though.
EDIT: Just a thought… What happens if you disable the lag fix, but leave the frame_event_performed declaration in the CPU as well as the serialization of said flag? That way you’ll just include the extra variable in the serialization, but it would be completely unused. Does Mega Man X with MSU-1 support work or not?
I just confirmed that it’s not the lag fix itself that causes issues with MSU-1 games. Simply adding the frame_event_performed flag to the CPU Status struct (and disabling the other parts of the lag fix code) will make the core crash with Mega Man X with MSU-1.
Turning off the lag fix just seems to hide the problem, at least to a degree (MMX2 and MMX3 crash even without the lag fix). It’s probably the serialization code that needs to be fixed.
Thank you for identifying the actual cause of the error. It would be worth verifying whether the serialization issue is occurring on both Windows and Linux (or other systems). Valgrind may also help identify problems where memory is overwritten, given the normal debugging methods are not helping.
Has memory alignment been ruled out for the struct issue? Are the other members of the struct exceeding their memory allocation?
It’s great work in fixing the input latency bug which was present (and apparently undetected) in the snes emulators for quite a long time.
If the posted stack trace at github is pointing directly to the cause of the bug, then consider testing in non-x86 system. There is alternate SSE2 and memory alignment code in mismatch.c (of Retroarch project, not libetro-bsnes) which may be disabled if the non-x86 system works with Brunnis’ fix; and likewise worth verifying the compiler’s flags for any memory alignment set by default or by build environment.
[QUOTE=bidinou;42111]Apparently there was some additional input lag specific to the (s)nes. There is one more frame of lag specific to opengl (you can work around it by using the dispmanx video driver but then you have no pixel shaders – btw, I’d love to know what good overlays you can use with it I tried a few but the result was not satisfying – and there seems to be one more frame of lag which is not understood for the time being.
Also I read this, is it relevant ? “Also, Lakka has now been modified upstream to apply the rt-kernel patch for more consistent scheduling with 1Khz tick rate, preemptible etc. (frame delay setting can be increased further)”
Finally, there is this frame_delay_setting that can help you get back up to one other frame of lag but you need a very fast CPU and this is super annoying to tweak. (different optimal value per system or even per game)
/me enjoys reading this thread even if he is just a dumb user
Edit : brunnis made a summary here : http://libretro.com/forums/showthread.php?t=5428&page=18 Without frame delay, there is up to 5 frames of delay while he only measures about 2 on a real SNES. I clearly see a huge difference between RetroPie on a Pi and the NES/PCE/… FPGA core on my MiST for instance. But FPGA computers are 1) very expensive 2) support few systems.[/QUOTE] Does the windows version have the dispmanx video driver? Which, has no shaders and has to use the blurry bilinear filter, right? Does that shave 1 frame off 5 frames of delay and thus you get 4 frame delay?
[QUOTE=MrPoe;42584]Does the windows version have the dispmanx video driver?[/quote]no. it’s raspberry pi only.
Which, has no shaders true
and has to use the blurry bilinear filter, right?
no
re: gl shader lag - if your shader is running at 60fps i don’t think the shaders will be causing lag? also i thought someone tested with shaders and said it didn’t cause (additional) lag?
Great that Brunnis findings and work was mentioned in the 1.3.5 release!
Yeah, it is great that his fix was actually recognised on the official Libretro blog. Once again, great work and I’m truly grateful for the improvements and efforts that all contributors are making here to achieve a perfectly responsive experience.
That being said, I have also noticed that Alcaro had disabled the lagfix on both bsnes and bsnes-mercury, as evidenced here and here. As far as I understand, this has to do with the issues recently brought up by Radius with regards to MSU-1 patched games, which seem to break entirely with the Lagfix on and Rewind enabled.
I would humbly request for it to be turned back on, for two reasons mainly:
I feel that it should be better left ON by default, at least on bsnes-mercury, while emphasizing that MSU-1 patched games currently work only with Rewind OFF.
Thanks in advance, looking forward to an update on the matter.
Awesome, I hadn’t seen that yet. 
Thanks!
[QUOTE=Geomancer;42647]That being said, I have also noticed that Alcaro had disabled the lagfix on both bsnes and bsnes-mercury, as evidenced here and [B]here[/B]. As far as I understand, this has to do with regards to MSU-1 patched games, which seem to break entirely with the Lagfix on and Rewind enabled.
I would humbly request for it to be turned back on, for two reasons mainly:
I feel that it should be better left ON by default, at least on bsnes-mercury, while emphasizing that MSU-1 patched games currently work only with Rewind OFF.
Thanks in advance, looking forward to an update on the matter.[/QUOTE] Yep, I was aware of that. I am looking into it. Here’s a comment I just posted on GitHub, in response to Alcaro defending the disabling of the lagfix:
“I agree, Alcaro. I’ve spent the better part of the day looking at this and I’ve found that the issue has nothing to do with the lagfix or MSU-1 games. It appears to be a bug within state_manager.c and/or mismatch.c in RetroArch. I’ve been able to make a workaround by doing a small change in state_manager.c, but I’m not done with my investigation yet. Hopefully I’ll have some more info tomorrow.”