At 24 seconds your mario(s) are desynced already when he jumps after the pipe - different variables in the Pellson top readout. mario is a pixel ahead in your right screen. Then in the turnaround room again different variables and speeds.

Could be your controller inputs registered earlier or later depending on several things on the computer.

We know different emulators have different "input lag" time. So pressing a button on your controller might register in 1 millisecond (as an example) on emu1 but in 1.7 milliseconds on emu2... and if that's the difference of a full frame, it will make a difference.

There are plenty of runners for this game (more than 1000 for the main category) and most of them don't interact with the "community" so don't feel any pressure to do that. But there is a fairly active Mario discord that is friendly and willing to answer questions from new runners. Just keep learning the levels until you can finish the game, and submit a time - even if it's slow. As @roopert83 stated - read the listed rules first. The summary of the rules is that there are a number of "whitelisted" legal emulators and consoles. Among them is the NES classic which you mentioned. Completely legal. Be sure to video capture your entire screen and game sound and you should be good.

Most of all - enjoy the journey. I know I speak for several runners when I say I miss learning the game.

Good luck.

One problem with counting run time is it would be harder to use hammers - since knowing the actual "delay" used would be much more unclear. That leads you to frame count but that adds a range of error, especially when 30fps or 24fps, which would multiply over 11 runs. You could eliminate the blank space. Which would work. But also has an an element of error, especially when multiplied 11 times. Granted we're only talking about a small error.

Either of those methods works, it just adds a lot of complexity, and subtracts accuracy (at least a little)

I get the concern, but I see negatives along with the possible solutions to the proposed problem

By far the simplest thing is just to consider restart efficiency as part of the category, as @Tecate said.

Just my thoughts.

Just do your best to record audio the most you can. If you have to mute mic that happens. By that I'm assuming you are only recording smb audio through your mic.

You need audio for the run to be valid. Every deviation and irregularity just makes the run more suspicious and we might require additional things from the runner before verifying - like full session, splits file, etc... And if there's not enough information provided from a run that has oddities then it may be rejected.

I'd keep the full session recording and splits file from that pb until it's verified just in case.

For smb1, there IS an 8-4, and a "beat 1-1 as fire mario" category.

The other individual levels are not (anymore) a category because

(1) there are 32 levels (2) There are already 41 category extensions, and 5 "main categories", adding 31 categories to that would make 77 categories (3) 8-4 IL and "beat 1-1 as fire mario" already get lots of submissions, and they're particularly time intensive to verify since they need to be accurate to the millisecond (4) Most of the levels can't even be improved other than fast accel at the beginning and fpg at the end, so you'd end up having a 10-way tie for first, and a HUGE amount of ties for completing the level in the standard time

As of now, your only submission for mario is an 8-4 IL run... so you still have 40 other categories to submit before you run out :) I'd start with those.

It's a neat concept :)

I know @AndrewG has done this, as well as what he called "juggling%" - which was beating the game while... juggling - which is also not a category on the extension boards.

I've also seen someone beat the game using a DDR pad, but they never submitted the run.

Unfortunately, category extensions isn't accepting new categories, but it's a legal any% run

If an emulator lagged and actually delayed the game play then yes it would be included in the time as a delay - same with 6-4 bowser lag or bbg lag frame - and same general principle as 60fps (as is the case on switch) vs console fps

You'd use hammer patterns and then add in any relevant lag.

That being said I'm not aware of emulators regularly causing lag in that way. My impression is that when they stutter that's rendering delays but doesn't actually affect the speed of the game, just how it's shown on your screen. But if it did actually delay the game then yes, the final time would also be delayed.

You should be able to tell if it's causing real delays or not based on livesplit. If you're splitting slightly late after seeing lag then I suppose it's possible your computer emulator combination is slowing game play somehow. But if livesplit is splitting in framerule units as it should then you shouldn't have anything to worry about.

This is a thread that's been posted and asked numerous times - you can see the responses and discussion in several old and locked threads, including

454 human probability (locked) - https://www.speedrun.com/smb1/thread/mu9qx Is the legendary time of 4:54 possible? (locked) - https://www.speedrun.com/smb1/thread/e8srz

@NateCC14 - it would be too difficult and laborious to runners and verifiers to prove what version you were using unfortunately. I agree it's a shame, but there's really no way around it.

Made a video of the feature, which is TOTALLY UNDETECTABLE - if it's enabled, you can't tell it's enabled. What run ahead does is make it so when you do an input, the next period in frames or time is removed... to "emulate" a reduction in input lag. On original hardware and CRT, when you press "B", mario literally jumps within an indiscernably small amount of time. On emulator, it takes a "lag" period. Input Lag. Mesen artificially removes that. However, if we turn up the "run ahead" to the maximum allowable value, you can easily see what it actually does. Watch when I JUMP. Mario literally goes from the ground, to several frames above the ground instantly. Watch what happens when mario shoots a fireball. The fireball appears several "frames" ahead of where it would ordinarily begin.

That's not even a hard decision. Of COURSE this wouldn't be allowed.

It's unfortunate, because Mesen is a good emulator... but when they make a feature that totally changes the order of frames, SKIPPING TIME, and you can't even tell if it's being used? Yeah, that's not allowed.

Heads up - Mesen will likely be disallowed soon - I would avoid using it. It has a new feature which gives an unfair advantage over original hardware, and is not shown when being used.

^ what @eddiecatgaming said

• small screwdriver (to open it up)
• Q tips
• rubbing alcohol

Unless the rubber itself is cracked or damaged, you can usually make it quite a bit better, and it's fairly easy to do

Based on a little research I did

" Run Ahead: Run ahead allows the reduction of input lag by the number of frames specified. CPU requirements increase proportionally with the number of run ahead frames specified. [...] Note for speedrunners: Using features such as run ahead to reduce lag typically counts as cheating for the purposes of speed running. " https://www.mesen.ca/docs/configuration/emulation.html

and

"With run-ahead, it is possible with an optimized setup for software emulation to have less latency than the original hardware!"

@SammmyilSpider

1. You can actually clip into or through most block "seams" in the game under the correct circumstances, including pipes.

2. Friendly heads up - you may or may not be intending to run this game and submit times, but RetroArch is not an allowed emulator, so if you do submit a time, you can't use that emulator :)

What's more important than how you record the run is what emulator or console you played the run on - in your case Nestopia. However, once your time gets lower (5:00 to sub-5:00 range) you may need to provide additional documentation as requested, such as

1. Entire attempt session(s), rather than just the run itself
2. Your splits file
3. An input file from your emulator

I looked at @eddiecatgaming math and got the exact same time he did - I think the discrepancy between what you're getting and what we're both getting - is based on video frame rate. What we did was download the video in the highest quality available (720p) and pop it into VLC. then go to properties (CTRL+J) and that gives a framerate of 30.023894

After talking to threecreepio, he got a framerate using some other tool of 30.002 - entering those two different variables gives you different times by a frame on https://somewes.com/frame-count/

What we have done on every run so far, other than categories that require some special timing method is:

1. Download the highest quality version of a video available
2. Pop it into VLC to grab video framerate
3. Pop it into Virtualdub to gather start and finish times
4. Enter the variables on https://somewes.com/frame-count/
5. If the video was 30fps, and the start or stop was off by a single frame (as seen by mario's hand positioning) add or subtract a single frame (this was not necessary on this run)
6. Put the "console time" (with modification if necessary) as official time on src

For reference, the run in question is https://www.speedrun.com/smbce/run/yj3vdvgz

If you download pellssons practice rom you can warp to any of the 32 levels

The first paragraph in the rules for "10 Walljumps" is

"Must be actual walljumps. Jumping inside a wall and hitting the block directly above you does not count as a walljump. Cramming yourself between a wall and the edge of the screen and jumping from there also does not count as a walljump."

If that answers your question

If you mean clipping inside the center column of bricks and then jumping, the answer would also be no.

The timing for a run starts with the "400" appearing when Mario enters 1-1.... So regardless of whether or not it would be legal to play as Luigi, it would be a several second time loss... As you'd have to die to even begin play with Luigi. And even then it's not currently legal that I know of.

@KilleDragon that will lose at least a framerule in every instance - since you will not be at the top of the flag and "ejected" backwards. Same reason why runners always grab the top of the flag in general, since Mario accelerates faster backwards than forwards, when mario is above the block, he moves away from the block backwards for a few pixels, which saves a large fraction of a framerule by itself.