Howdy,

I noticed that the runner RyuHayabusa89 managed to set a new WR for the Any% time, which was surprising because there is no apparent way to save even a single frame's worth of time in that category—it is fully optimized so far as I can tell.

So, I framestepped through Hayabusa's entire Any% run and found that there are dropped frames.

Mods, you can confirm this for yourself using the FCEUX framecounter visible in the bottom left:

• Frame 399 goes right to frame 401, skipping frame 400
• Frame 405 goes right to frame 407, skipping frame 406

There are also the following frames skipped, but these also have a single frame of delay, so likely no advantage is gained from these drops (from what I can tell):

• Frame 401 goes right to frame 403, skipping frame 402
• Frame 407 goes right to frame 409, skipping frame 408
• Frame 410 goes right to frame 412, skipping frame 411
• Frame 419 goes right to frame 421, skipping frame 420

Some of these skips have an additional frame of delay between animation, but some of them do not.

This is not the first time I've seen a run performed on an old version of FCEUX that resulted in an impossibly fast time. We ran into this same issue with The Great Gatsby due to FCEUX being inaccurate and had to ban old versions of FCEUX as a result.

Accounting for the 33ms gained by frames 400 and 406 being skipped entirely would make the run have a time of 10s 049ms but there is more likely than not another frame skip in there that I cannot find.

I believe RyuHayabusa89's time should be updated to be 10s 067ms as those frame drops make it difficult to accurately determine the true time, and there does not appear to be any possible way to go faster than the 10s 067ms time.

I also noticed that Hayabusa's Any% (NOOB) WR has frame drops as well.

Before the reset:

• Frame 1529 is skipped

After the reset:

• Frame 469 is skipped
• Frame 472 is skipped
• Frame 479 is skipped
• Frame 1071 is skipped
• Frame 1077 is skipped

This category is much longer and less optimized, and this run has frame delays that are undoing the frame drops, so I don't know if these drops had a significant overall impact on the time. I only checked up to frame 1200 for this run so there's probably more drops in there.

Thanks for digging in to this! I'm not quite sure what to do about this. My gut reaction is that the runs should be invalidated. Moderating runs with dropped frames in a speedrun that results in a smaller framecount is not tenable. I'd like to hear your opinion Joe :)

Forgive me my english but i use translator :) No problem if my time goes back to 10.067 or is completely deleted, but just got sub 10 on the latest version 2.6.4 of fceux. I can repeat it on Nestopia or Mesen if you like. I'm just curious if the emulator helps me or I'm just brilliant xD xD xD

Crit and Beardy are pros in this department and I will back your call fully 👍🏼

@CritRocket I don't think the Any% WR should be invalidated because so far as I can tell it's a fair 10s 067ms run because RyuHayabusa89 didn't slow down for any frames, which is what is required to get the 10s 067ms time. From what I can tell it would be fair to update it to be 10s 067ms rather than invalidating it.

@RyuHayabusa89 If you're able to get a sub 10s 067ms time using MesenRTA I'd be confident there's no frame drops causing an impossible time. It can be downloaded from here: https://github.com/threecreepio/mesenrta/releases

I am pretty sure it's being caused by FCEUX inaccuracies, though, because I checked JoePulito's Any% run, which is also using FCEUX, and it also has frame skips (which doesn't really matter much for a non-podium time).

Just got 10.000s on MesenRTA 0.0.6, but there are 3-4 dropped frames. Just as much as needed by 10.067. So check the vod and decide whether to delete it. It turns out that each emulator is inaccurate and there is no point in fighting for WR for milliseconds.

Ryu, what do you use to clip your videos? I used to lose frames until I started using Handbrake. I make sure it clips at 60 fps and I never lose frames anymore.

I mostly use OBS and Avidemux. So i analyzed your 10.333 PB as well and I also found frame drops, e.g.

-Frame 179 goes right to frame 181, skipping frame 180

• Frame 195 goes right to frame 197, skipping frame 196

But it looks like you calculated the frames correctly. I don't know where the problem is, maybe I'll fix it in the next few days. So I will delete my records including WR Any% as well as WR Any% Noob and Down The Hole WR Submit. Sorry guys.

I use mesen for emulator, streamlabs/obs to capture the video, and Handbrake to cut the video. Like beard said, perhaps a couple frames were skipped but then a frame delay balanced them out. I don't know. But I would scrutinize it more if it were closer to the wr. Do you record each run by itself so it does not need to be edited after the run, or do you record a bunch of runs in one video and then edit down to a single run?

Of course I record a bunch of runs in one video. After all, I also have to show a piece of the earlier one. So I use Avidemux to count the frames and then edit down to a single run. The framerate is in line with somewes.com, but doesn't take into account any dropped frames. Maybe I can try Handbrake in my spare time. But honestly I'm already discouraged from speedruning anything that needs to calculate milliseconds :D

@RyuHayabusa89 Thanks for taking the time to use MesenRTA.

I framecounted @RyuHayabusa89's 10s 000ms run on MesenRTA and when his player falls down the hole and the screen turns solid black he is exactly 1 frame ahead of the 10s 067ms time set by @CritRocket and me. There is also a dropped frame at the very beginning—frame 83 is skipped without a delay—which accounts for the speed increase.

After falling down the hole there is no possible way to save any time versus the 10s 067ms time because it's a free fall—going faster would require falling faster, and there is no game mechanic that allows an increase in fall speed.

As well, I also framestepped through @RyuHayabusa89's entire Any% run and the first three levels of his 100% run for Underground Adventure, as that is another homebrew title he has been running, and I found no frame skips in either of them. Those have no issues that I can find.

So, given that we have frames being dropped on Drunk Time Traveler runs for @RyuHayabusa89, @Zarc0nis, and @JoePulito using emulators (regardless of there being any advantage form the frame drop) and there being no frames dropped for them while using the same emulators on Underground Adventure, I think the problem is this game. This title may simply be too janky to be accurately emulated without a few frames being dropped, which is significantly affecting the Any% run because of how short it is.

I fully trust that @RyuHayabusa89 is doing legit runs and this is a technical problem outside of his control, so I'm not sure what the solution is here.

My opinion, which includes trusting the integrity of @RyuHayabusa89 as a runner.

1. Beard and Crit optimized Any% on console at 10.067. Assuming Beard believe that Ryu's run is visibly an optimized run, we update the time to 10.067 to tie WR and make some notes about the frame count for posterity.

2. Regarding the Any% NOOB run, @Beardstrength has confirmed skipped frames in both my and Ryu's run, though the subset he reviewed appeared to have counterbalancing frame delays. The option is either to invalidate all emulator runs or keep them. I lean toward keeping them. This game will never have runners again if console is required.

There is an alternate option that almost resolves this completely, though it requires consensus.

3. We remove milliseconds, which makes runs tied if within the same second. Not a perfect solution regarding who has the truly fastest run, but it is optimal in that framecounts are less likely to be contested or contentious, should this game pick up steam with more runners.

I had an idea and took a look at both the Any% Underground Adventure runs for @RyuHayabusa89 and @Zarc0nis which both have visible framecounters. I took the sum of the frames, which gave me:

• 356 frames for Zarc0nis
• 342 frames for RyuHayabusa89

With the games running at 60 frames per second, dividing by 60 will give the time in seconds, which results in:

• 5s 933ms for Zarc0nis
• 5s 700ms for RyuHayabusa89

Both of those times exactly match the submitted times.

So, I did the same thing for Drunk Traveler and got these frame count totals:

• 621 frames for Zarc0nis
• 602 frames for RyuHayabusa89 on FCEUX
• 602 frames for RyuHayabusa89 on MesenRTA

When converting these to seconds, however, the results do not match either calculated time:

• 10s 350ms for Zarc0nis
• 10s 033ms for RyuHayabusa89 on FCEUX
• 10s 033ms for RyuHayabusa89 on MesenRTA

Based on this I can only confidently say that RyuHayabusa89 cannot have gotten a time faster than 10s 033ms and I cannot figure out what is causing both the runs for RyuHayabusa89 and Zarc0nis to be inaccurate versus the time given by Somewes.com or Avidmux or whatever tool is used to count the frames.

Honestly, this is very confusing, and I believe this game is the problem. There must be something in its codebase that is causing issues with emulators.

Regarding the suggestions by @Zarc0nis:

I have no dog in this race because I was not planning on running the Any% (NOOB) category, and from I can tell the Any% category is fully optimized with no time save remaining—Ryu's 10s 033ms time I found above notwithstanding—so I'd have no reason to do any more attempts.

Having said that it looks like removing milliseconds is the only tenable solution, which will unfortunately remove competition/challenge from the categories. If we keep milliseconds we have the problems I found above with the calculated times not making any sense.

Without us figuring out what is causing the discrepancy in the emulator-powered run times I don't know what else can be done.

Thanks @Beardstrength. With future runners of either category in mind, and the contention of the framecounts with the abovementioned submissions, let alone however many we may see in the future, I reiterate my suggestion that we revert from counting milliseconds to just counting seconds. It reconciles all current submissions and the only questions would really come up with runs that barely break a second barrier, and that would only be a concern at the podium level really. In short, 99% of current runs and future submissions are resolved.

@Beardstrength you said earlier: "With the games running at 60 frames per second, dividing by 60 will give the time in seconds". But that's not true in emulators. I remember JKloser in Urban Champion said something like that:

https://www.speedrun.com/urban_champion/run/y8q7x7dy

Your calculations are wrong: 602frames/60.1 ---> 10.016 not 10.033 So somewes and Avidemux calculated correctly. But of course that doesn't change the fact that the emulators lose frames in this game.

Thanks for your time @Beardstrength, @Zarc0nis. I agree with your suggestions and now it's all in the @CritRocket hands :)

Sounds like removing milliseconds is the easiest solution to me. Since this game isn't super competitive, I think that this is a fine solution.

Agree...so goodbye my fake WRs 😀✌