Sorry for reposting this, but the old post title wasn't specific at all and I posted several times things that should have all been posted together. Anyway, I found an issue with the Livesplit plug-in for rounding times to the nearest framerule. The plug-in rounds the split times to multiples of 21 frames, or 0.35 seconds. Since NES and emulator run slightly faster than 60 FPS (60.09881), 21 frames isn't exactly 0.35 seconds. It's roughly 0.349424 seconds per framerule. I think the plug-in needs to use this exact amount of time rather than just 0.35. Then it will accurately measure split times.
But livesplit only measures like Two numbers After the dot (.35) so .349 would probably round up to .35 or .3. Thats enough to See if you lose or gained a framerule. :P
After 30 framerules (~10.5 seconds) the difference is still below 0.02 seconds. It's negligible.
True, but a given split can contain anywhere from 50 to well over 100 framerules. Full game runs contain several hundreds, if not thousands of them. The small difference will become apparent there. I re-timed my splits from my last run based on multiples of 0.349424. Comparing them to multiples of 0.35, they don't line up at all. If the +/- was rounded to the nearest .35 multiple and the split time was rounded accordingly, the plug-in would be functional.
Its accurate enough, splits are just there so you know patterns and other things related to your pace. No need to overthink it
Maybe I am overthinking it. I just fail to see how the plug-in serves any practical purpose in its current state.
I mean you dont have to use it. Its just for new people who cant split that accurate so that they see if they lost/gained time and how much. :) Good luck!
Getting an accurate time is what the spreadsheet is for. The plugin does a good enough job for you to know what fr youre on, also,it doesnt change the time on wich you stop the timer.
I mean if you acually want to know your full run Time you should use the spreadsheet. If that is what youre on.
Any% (NTSC) runs below 4:57.000 must now fulfill additional requirements in order to be verified.
- The run's full session must be included in the submission description.
- For emulator runs below 4:57.000, some form of input display must be visible for the duration of the run. A hand-cam or input
