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:
- The benefits introduced by the lagfix largely exceed the entity of the problem that was documented for MSU-1 games. We are talking about a proportionally small subset of hacked / patched titles that do not work - and they actually malfunction only if you activate the Rewind function on RA - as opposed to an option that has been measured and verified as an improvement to all compatible software.
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.
- The latest blog entry specifically mentioned the lagfix being implemented on all existing SNES cores as a major breakthrough for version 1.3.5 - and this includes bsnes and bsnes-mercury. That implies a contradiction between what has been publicly stated on the blog and what is actually being downloaded by the end user.
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:
- The benefits introduced by the lagfix largely exceed the entity of the problem that was documented for MSU-1 games. We are talking about a proportionally small subset of hacked / patched titles that do not work - and they actually malfunction only if you activate the Rewind function on RA - as opposed to an option that has been measured and verified as an improvement to all compatible software.
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.
- The latest blog entry specifically mentioned the lagfix being implemented on all existing SNES cores as a major breakthrough for version 1.3.5 - and this includes bsnes and bsnes-mercury. That implies a contradiction between what has been publicly stated on the blog and what is actually being downloaded by the end user.
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.”
Typical users will benefit from fixing the input latency bug which makes many games unplayable. And the msu1 system requires special setup that typical users will not use, so it is better to fix the snes emulation/latency first and then work next on the msu1 system and its interaction with retroarch.
“unplayable” is hyperbole of the highest order. Very few people have complained about the single frame of extraneous latency in the 11 yrs bsnes has been around and in the 5+ years RetroArch has been around. OTOH, MSU1 is a flagship feature of bsnes and one of the main reasons people use it over snes9x.
If you guys value that one frame of extraneous latency over MSU1 support, you’re welcome to enable the option and compile your own copies of the core while we look for a proper solution to the serialization issue(s). In the meantime, snes9x/next doesn’t appear to have any issues with brunnis’ patches, so if latency is your biggest concern, just use it instead.
As long as one of them (Snes9X) has this fix inclided in mainline updates, awesome
What about FCEUmm? It’s mentioned on the 1.3.5 post (now 1.3.6, for some reason). Does the regular FCEUmm include the lag fix now? (By regular, I mean the one provided by the online updater)