Oh cool beans. Thanks.

Also, just an fyi @Cephla: I framecounted your 1m 11s 967ms run to check if I was timing correctly, and using https://somewes.com/frame-count/ it's giving me 1m 11s 933ms so your run was 34ms faster than the SRC time.

Hello,

I noticed that my submitted run was changed from 1m 10s 950ms to 1m 11s 000ms by @Cephla the moderator.

From my understanding of the timing the starting frame for my run was 780 and the ending frame 5037, which is 4257 total frames, coming out to 70.95 seconds.

I double checked my timing on https://somewes.com/frame-count/ and I'm getting 1m 10s 950ms each time.

Am I using the wrong starting/ending frames?

Just trying to make sure I'm timing my runs accurately.

Thanks.

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.

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.

@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.

@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).

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.

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.

That does sound good regarding the RNG. If it's persistently random even without a hard reset then I see no reason to enforce a reset if the player dies and goes back to the main title menu.

I do agree that having to watch the intro over and over really sucks, but without including the reset how would we know a save state wasn't used?

In theory a player could load a save state right before a death, die, have the game go back to the menu, start a new run, and have the RNG be impacted, such as the positioning of the bats and slorbs and the direction they are moving.

I don't know if it would be possible to lock in the RNG that way, but I also don't know that it's not possible. It's only certainly impossible if the reset is included.

At the very least I think we should do some tests to confirm, to the best of our abilities, that RNG will not be locked in without a reset. My concern is that RNG is decided on initial boot which would lock in the RNG after a death, which would allow a player to keep playing until they find favorable RNG after a death.

I think there should be separate categories for NOOB and OOB rather than combining them into one. The routes are different enough to justify separate categories, in my opinion, and personally I'd prefer to not be doing OOB tricks.

Having separate categories will also help future-proof should there be any other OOB exploits discovered in the later stages.

Fyi I've been tinkering with Low% and I'm confident that it's not possible.

I did manage to get through Train with only 2 coins and 1 drink but there was nothing I could do to void them. There's also the 3 coins in the City at the Hydrant Boost which would be unavoidable.

We could maybe have a category for minimal pickups rather than zero pickups, if there's any interest. From what I can see the game should be beatable with around 5-7 coins and 1-3 drinks. Could be a fun category.

If kuma wants to make an official, proper one we could always just move over to that.

I went ahead and made a Discord server: https://discord.gg/9puD9sMJ

This certainly doesn't need to be an official one or anything, but for now we'll have a place for us to post our different strats for each other to learn from.

If it were just that initial loading of the title screen then, yeah, there would be no fairness issue, but it could still affect RNG in ways we don't expect.

It's best to avoid save states entirely with games that have RNG.

Bit late here, but I can see three potential problems with allowing save states:

The first would be compatibility. Save states used on a desktop emulator are no the same as EverDrive N8 save states. In the interest of fairness multiple types of save states would need to somehow be made with identical timing.

The second issue is verifying on what exact frame the save state begins. A player could adjust the save state to be a few frames ahead which would give them an advantage. How would we check for this?

The third is RNG. The crabs at the end of the game are RNG and the use of save states may lock in the crab RNG such that it isn't different every time the way it is meant to be.

I agree with zarc0nis and kuma: we should start all runs with a reset. No save states.

If somebody is willing to test other versions to confirm they do not provide an advantage that sounds great.

But without confirming they don't I believe it's best to assume they do given we've confirmed that one out-dated version does not lag correctly. There isn't a compelling reason to be using an out-dated emulator and with a game this optimized these slight inaccuracies can easily make the difference between 2nd place and a new WR.

If 2.5.0 does not provide an advantage then it would be safe to say all versions that come afterward are also viable emulators for accurate/legit runs.

Please see my thread regarding this: https://www.speedrun.com/the_great_gatsby/thread/l0cid/1#mhb53

The time muten_pizza achieved is not legitimate due to an inaccurate emulator.

After investigation it is imperative that the emualtor FCEUX version 2.2.3 be banned, and quite realistically all versions of FCEUX other than the latest as well, which is the 2.6.2 version.

The time submitted by muten_pizza had an exceptionally fast Stage 1 framecounted to 54.067 which is faster than all three of the Stage 1 times that are currently podium.

We looked into it and after having muten_pizza switch to mesenRTA and perform the identical route the timesave was immediately lost and he was achieving the expected times that the rest of us also get. The version of FCEUX that was being used, for whatever reason, is not accurate enough to lag correctly and will give the player an unfair advantage.

For the reason outlined above I and zarc0nis both strongly believe we should only allow FCEUX version 2.6.2 to be used.

zarc's a good Dodge Ball mod so I'll throw my hat in in support of that, and should the game continue to explode in popularity—I doubt it, honestly—I'm happy to help out with mod shenanigans as well.

And I will say that, for the most part, if I see the split timer at the end of the run reads one way but the submission is a lower time in milliseconds that I assume you all have done the frame count yourselves. I am more than happy to trust you all with your own frame counts

I appreciate the trust, and we're all homies and wouldn't try to cheat, but we're all human first and we make mistakes. I've accidentally submitted bad runs to Dodge Ball that needed to be rejected because of mistakes, and I've mistimed things before.

For example: That happened to Deadguy. He had a 4:10.920 run but accidentally submitted a 4:10.092 which was accepted. Deadguy would never try to cheat but mods should still doublecheck the numbers.

It's extremely important for mods to framecount every single submission to ensure the claimed timing is in fact accurate.