Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
Only looked into the possible improvements briefly.
gifvex's suggestion to use L5 Rattata and delaying turning the animation off does save time, ~1-2 seconds. It changes two levelup timings, but not for the worse. It does require a full rewrite of the TAS though because Squirtle's DVs are not sufficient for that route change. I don't plan to incorporate it in this submission.
The problem with using Stomp with animations on is that it is actually only used sporadically, and enabling and disabling animations costs time, and the remaining moves, especially Blizzard and Horn Drill, are much slower with animations on, so I don't see a way how this can be used to save time. I didn't measure it but since Stomp uses the fast shake animation (since it has a flinch side effect), I'm not even convinced it is faster with animations on to begin with.
For the jingle skip CasualPokePlayer is right, it doesn't work when the item is two steps away, the music starts too quickly.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
Well, it turns out my previous calculations were entirely wrong, and using Squirtle all the way to Tauros is actually significantly faster. Thanks gifvex for pointing this out.
So while this finally achieves 1:26 IGT, it unfortunately also makes the route a bit less interesting, but I guess reality is under no obligation to conform to our expectations.
I created a new submission for the updated route, since it seemed significantly different, but I'll leave both open for the time being given the voting that has already taken place on this submission, in case the judges see it differently and would like to have these merged instead.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
gifvex wrote:
Did you check using Squirtle all the way to Tauros? Looking at your full-game Squirtle movie, it's very close with Clefable through the end of tower, after having done extra prep expecting to continue using Squirtle.
I did not do a full run, but some calculations and came to the conclusion that it won't be faster with enough confidence. The additional prep that the Squirtle route does, mainly collecting and teaching Ice Beam, is largely offset by the help it provides during the Tower fights, as Squirtle is very low on PP at that point.
That said, I now see that I didn't consider some of the potential additional time saves (e.g. using Paras over Sandshrew, fewer E4 deposits) and it might be closer than I gave it credit for, I guess I also didn't look too closely when Clefable sounded like the more interesting route. I'll need to do some more analysis.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
Yeah, it is very close, but you are still outsped 136 to 137. Technically you have enough Stat Exp for a speed tie from Machamp, but since the effective stats are only re-calculated on level-up, you don't get the extra point of speed you need.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
TiKevin83 wrote:
I would want to test double growl gen 1 miss on the moon rocket as in the Yellow Rival 1 battle, I'm pretty sure it's slightly faster in theory but it's only a handful of frames which might be hard to keep saved searching for gen 1 misses.
I didn't test it initially, using non-damaging moves was a blind spot for me, good call. I did a quick test, and it turns out it is actually 25 frames slower than Mega Punch. Some but definitely not all of this can be extra delay, it just doesn't seem to be faster in the first place. Haven't investigated more into why, my first suspicion is that the failed text is much shorter than for the trypical enemy moves, so it loses the advantage compared to the "But it failed!" text for Growl misses.
TiKevin83 wrote:
I'm curious about the use of the Red cart and Paras over Blue and Sandshrew, due to Paras' longer cry at both the catch and the E4 deposit. I'll have to re-weigh that against the shorter name and the extra route 4 steps.
I did test this one, and catching Paras is ~100 frames faster (excluding the Elite 4 cry). Again I didn't fully investigate why, other variables to consider are that the battle start transition animation is different and potentially shorter in caves than it is in the overworld.
Re Red vs. Blue, Red saves ~7 frames due to Charmander's cry being shorter on the title screen, and I didn't need any version exclusives (not that 7 frames matter in the grand scheme of things, they can be easily lost or gained during the manips).
TiKevin83 wrote:
I'm curious if you checked the 4x Night Shade strat with pound, I'd need to test it again here since Clefable's cry is so much shorter but redbar is so useful in red I wouldn't be surprised if it's worth it just for the rest of tower.
Will try to test console verification soon :)
This one I also tested, and it's close-ish, but ended up 1-2s slower. That said, I also tested it in the Squirtle route where it was actually faster, so it's not clear cut, and my test might have been flawed.
entrpntr wrote:
Out of curiosity, did you attempt a full-game Nidoran TAS? I wouldn't be entirely surprised if there were 52 seconds to save on the published TAS from fully bruteforcing the luck manipulation, but from the writeup it seems like it would have run counter to your objectives with this TAS. (Edit: TiKevin83 says he'd estimate 15-20 seconds from bruteforcing, and he'd know better than me.)
I didn't do a Nidoran route for Red/Blue, but I did do one for Yellow, and the timesave was ~9s, which largely is attributed to manipulation. Of course my brute-forcing isn't perfect either and the quality of the manips might be different between the two.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
Console verification of the run was successful, TiKevin83 produced both a high-quality encode and a live-streamed version on console.
Will a new BizHawk release be a requirement before this new run can be accepted?
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
I can see how this is more useful in RTA, since you're also skipping a whole bunch of spinners, and pause buffering past them costs extra time.
----
The new version of the movie is finished. It syncs on BizHawk versions after this commit, and will hopefully make it into a BizHawk release soon.
Console verification of this run should be possible, but due to inaccuracies of the RTC in the cart, it may not work on all Crystal carts. This run was tuned to TiKevin83's Crystal cart which we used for testing and determined the RTC speed of, it will work on his cart and may or may not work on others. I'll post an update once we have done the console verification.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
entrpntr wrote:
One idea I don't see mentioned is catching an Abra, which I'm almost certain is faster. You get to save 1 trip from Goldenrod <-> Route 36 (teleport to Violet after Squirtbottle most likely), and you can enter the center next to Rock Tunnel to teleport there later on for the EXPN Card quest. I don't know which Kanto route is faster; you can go through Rock Tunnel instead of Route 9, which puts you right next to the center, but you fight a different trainer going that route (Hiker Jim's Machamp instead of Camper Dean's Golduck).
I finally got around to testing this, and to my surprise it doesn't save nearly as much time. Teleporting to Violet after Squirtbottle is ~9.7s faster than biking from Goldenrod, and teleporting to Route 10 to revisit the Power Plant only saves ~4.3s compared to biking from Cerulean (and that is not even counting the need to visit the Center first). These time saves are not even close to justifying spending ~30s catching an Abra. I would have expected it to be way closer, but I guess it's easy to underestimate the time the teleport itself takes up, plus catching Pokémon in Gen II is very slow.
entrpntr wrote:
One other minor note, that your botting setup may take care of anyway, is that switching AI is bugged (due to CheckTypeMatchup), and code flow depends on the type of the move the AI selected (rather than the player's type). In some cases, this can cause the amount of lag to vary by up to 6-7 frames after the player selects a move (FindEnemyMonsThatResistPlayer and FindAliveEnemyMonsWithASuperEffectiveMove are computation-intensive routines that may or may not be triggered). I'm not actually sure which battles are relevant in the route, but at least being aware of this may help avoid losing frames in a handful of places.
Interesting. If I understand correctly this should not matter much, I usually force the AI to use a specific move which I have tested to be the fastest in its move set. Whether or not it triggers this bug shouldn't matter as long as it's still faster overall, since the move animation in the previous turn may be a larger factor than the 6-7 lag frames. For the last turn where the enemy move mostly doesn't matter (except priority moves), the brute force should catch it for me, as it will just use the outcomes which took the least amount of time, independent of why they were faster or slower.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
Quick update: The console verification setup is working, TiKevin83 has just successfully synced a full run on console.
I'll need to redo the whole TAS though on the updated version of BizHawk to make it console-verifiable, which I'll do in the next week, also incorporating the optimizations mentioned in this thread. So please hold off on judging this submission, a new movie is on the way.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
FractalFusion wrote:
Are you referring to TASVideos statistics? Because if you are, then I could care less about whether its statistics are skewed. What I liked most about your submissions were the rerecord counts running in the hundreds of millions, if only to clearly demonstrate how much more optimized your TASes are over just about everything else.
The main problem, and the reason why I don't do it, is that the higher re-record count does not necessarily correlate to a better optimized run. There are huge diminishing returns on it. To illustrate my point, the draft run I did without much optimization took about 100x less time to create, but only was ~1600 frames slower than the submitted run, and the majority of the improvement did not come from better RNG but routing improvements (using different moves, movement optimizations I missed, using an additional Escape Rope I forgot etc.). So a run with an astronomical rerecord count can easily be beaten with just a slightly better route. Manual rerecords are worth way more since the human behind them makes directed decisions, whereas 99.99% of automated rerecords are completely unnecessary and just a machine stupidly following instructions. I don't want to discourage anyone from trying to beat this run by intimidating them with an inflated number, because it's not all that important in the end.
FractalFusion wrote:
OK. I wasn't sure whether the 2x boosted EV/Stat Exp. from Pokerus would have made a difference at any point since Cyndaquil is mostly at low levels (boosted EV is unlikely to change the stat at low levels) and when you get Raikou at LV40, you OHKO the vast majority of Pokemon from then on without using criticals. Though now that we're talking about Pokerus, I'm wondering whether the 2x boosted EV make a difference in other games. The only thing I know for sure is that Pokerus doesn't matter for the current route in Pokemon Diamond/Pearl glitched.
I maybe was a bit too dismissive when creating this run, it is a purely beneficial mechanic. The main issue is that you can only get it after Goldenrod, so it doesn't apply to Cyndaquil where it would be most useful, and Raikou has barely any chance to benefit from it either due to the OHKOs. It definitely wouldn't save a turn (the net effect is only about 2-5 points of damage), but it may have saved a crit or two I missed. I had it in the back of my head when routing, but never seriously considered it because the situation never arose.
----
Coming back to the console verification discussion, I took a look at the gambatte-speedrun version as suggested by Alyosha. The whole situation is a bit messy, since BizHawk's gambatte version is stuck in 2012, and missed a lot of upstream changes from sinamas' original version, so they are quite different.
I took a stab at updating BizHawk's Gambatte version (fork) somewhat successfully (in that no hardware tests I tried showed regressions and the console-verified Blue and Yellow run still synced) with changes from sinamas and gambatte-speedrun. This makes it closer to other versions again and hopefully easier to integrate future changes as well.
I should also be able to port gifvex's cycle-based RTC code, but I don't have the means to do any console verification myself at the moment, so I wouldn't know whether it actually improved the situation, I can only check that I don't make it worse. So in order for this to work, I'd have to have somebody help me do some hardware tests on the builds to make sure it's working correctly (TiKevin83, can you help me with this?), and it would also be great to hear from the BizHawk people (Alyosha?) whether such a pull request would even be accepted.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
FractalFusion wrote:
How many rerecords do you estimate it took to bot this?
I stopped trying to track this after it has been pointed out that these numbers are wholly incomparable to anything else and just skew the statistics. Not counting any of the investigation and test runs, it has taken about 2-3 days of wall clock time, with 8 simultaneous Gambatte instances continuously running, saving and loading savestates. It's probably more than any of my previous submissions due to optimizations I made (e.g. the multithreading support), but I can't attach any meaningful number to it.
FractalFusion wrote:
Did Pokerus ever factor into your route? I don't see a mention of it anywhere.
No. Pokérus doesn't do anything useful in Gen II. I never added any explicit checks against it either though, and I'm not sure it would even waste time in this run considering I never visit a Pokémon Center.
The same is true for shinies btw, I didn't add any specific protections against finding them, but they would naturally be sorted out as being slower.
FractalFusion wrote:
Did you consider poison deathwarping? There is one spot I can think of, and that is in the Goldenrod Radio Tower after beating the impostor manager. That would also allow you to fight a grunt with one Pokemon (around 1:18:58 in the video) instead of the scientist with three.
I only considered deathwarping at the beginning, and deemed it not worth since I want to catch Poliwag with one of the Pokéballs I get. I see the the instance where you want to use it, and I haven't tested it, but I imagine it will be fairly slow because of all the setup that's required. You'd need to (1) visit the Pokécenter you want to warp back to, (2) get poisoned, which will cost at least an extra turn in a previous fight since you OHKO everything, and that is assuming you can find a trainer you have to fight anyway which is in the right spot given the amount of steps you need to take, and (3) get rid of all the other 3 Pokémon in your party (and later get them back for the HMs; or have them faint as well). My rough estimations make it seem unlikely that this saves time compared to chowing through two additional Pokémon (~26s) and going back down the Radio Tower (also ~26s). It's possible that it's faster if the stars align (dumping the other Pokémons in the Radio Tower PC when entering, and picking them back up before leaving (~18s each), finding a trainer the exact right distance away which can poison you (~6sec), etc.), but I'd need to check in way more detail.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
TiKevin83 wrote:
It may be faster to use the PC at 29:00 from the side (4 steps) vs the current egg deposit PC (6 steps and a turn frame)
I straight up didn't know you could interact with the PCs from the side. Yes, this is for sure faster.
TiKevin83 wrote:
It may be faster to nickname poliwag (20 name appearances/120 frames vs the time to nickname)
Yep, renaming only costs ~60 frames. I guess I just grossly underestimated the amount of times it comes up and never bothered to check.
TiKevin83 wrote:
It may actually be faster period to use the Girl. Exarion and wsop referred to luckytyphlosion's prior comments about Girl sprite lag being a second faster than the boy's. But this has not been confirmed.
I did some testing for any sprite lag differences when investigating this because I thought something like this could be the case, but I couldn't find any conclusive evidence. Girl was faster some of the time, Boy was faster other times. Just because I couldn't find any bias in my tests doesn't mean it doesn't exist of course, just that it's hard to control for all the other variables, and any effect is likely very subtle.
TiKevin83 wrote:
The RTA community also generally believed that it was faster to be seen by Alfred, but had not ever properly timed this, so if it's been confirmed that it's faster to talk to him that makes sense.
I have re-tested it just to double-check. Talking to Alfred is confirmed 4-5 frames faster than getting seen.
TiKevin83 wrote:
Instead of teach surf to poli(down 1), teach strength to raikou(up 1), use surf from menu(down 1). what you can do is teach strength to raikou first, then teach surf to poli, saving an input. It may also save an input later on teaching Iron Tail.
It's not actually faster right away, it came out a frame slower in my testing (I think since you introduce 3 neutral frames in order to be able to repress Down/A when moving the cursor, the extra item menu scroll costs more than the Party menu scrolls). However, I believe you are right that it will speed up learning Iron Tail and is therefore faster overall.
I'll include these if I end up redoing this.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
It would be interesting to hear about the different strategies that were considered. Since I made this basically in a bubble, I only used and tested the strategies I could come up with, and I can tell you whether I actually tested it and determined it being slower or just not thought about it at all. E.g. Totodile vs. Cyndaquil I extensively tested, I created semi-optimized runs until Ecruteak for both of them. Raikou vs. Entei I didn't create full runs for, but convinced myself that Raikou will be faster by mapping out all the fights in a spreadsheet, and doing back-of-the-envelope calculations on how much Entei could save in battles vs. how much Entei will lose due to needing to refresh PPs more often.
Also note that resyncing will be a complete recreation of this TAS, since the same inputs will not result in the same RNG outcomes. Given a week of time or so for number crunching, it should be possible to create a new version which looks just like this one on a different Gambatte version.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
Alyosha wrote:
GBHawks RTC is already cycle based, just do you know, if that helps at all.
Interesting. To be honest, I know you have been making great progress on it, but haven't looked at GBHawk much yet. The main reason is that gambatte is a stand-alone library, while GBHawk is tightly integrated into BizHawk. The way I create TASes, I use libgambatte as a C++ library directly, which allows for way more flexibility in how you run the emulation (e.g. breaking and savestating at arbitrary cycles, running multiple instances at once, programmatic access to all the internals, etc.). It wouldn't be impossible with GBHawk, but a whole lot more cumbersome to get the instrumentation I need, since I have to deal with .NET/Mono, and cut away the irrelevant parts of the rest of BizHawk.
I also have some reservations regarding emulation speed (though to be fair I haven't run real comparisons yet). Since I rely on heavy brute-forcing, execution speed is key, and from what I can tell the way you implemented GBHawk is that it emulates very eagerly (e.g. updating the RTC every cycle), while gambatte follows a lazy evaluation approach (e.g. updating the RTC only when somebody wants to read it). While the eager evaluation certainly has its advantages in accuracy and ease of understanding, emulation speed is likely not one of them. To be clear, for normal emulator usage this is likely plenty fast enough either way, but when your TAS quality is a function of how many CPU hours you have poured into crunching all possible states, it makes a difference.
That being said, I'd be interested to hear what the future plans of GBHawk vs. Gambatte in BizHawk are. I'd be sad to see Gambatte support go away, but I can see how it may be desirable from the perspective of BizHawk as a software project.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
To lend some credibility to the whole timing discussion, I took TiKevin83's Yellow glitchless run and converted it to using equal frame lengths. The result is exactly as long as TiKevin83 claims, and plays back perfectly on BizHawk 2.3.
Just to be super clear, this is not an improvement to TiKevin83's run, this is TiKevin83's run, the CPU executes exactly the same operations in the same order, it's just BizHawk that changes when a frame starts and ends, ending up with a lower count.
I'd love to also present such a version for this submission, but it's literally impossible due to BizHawk's limitations of only allowing one input per frame. My magic conversion tool tells me that on frame 32344 (EFL timing) this submission would require multiple inputs (a neutral and an A input), which is not representable in BizHawk's input format. A real console has no problems with this of course. I guess you could try to convert it to lsnes which doesn't have this restriction, but it's probably not worth the effort.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
Well done! The level of thought that went into optimizing away every last frame, e.g. for lag caused by sprite decompression, or which battle intro animation you get, is impressive and requires extensive knowledge about how the game works under the hood.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
Thanks for catching that, I didn't realize I missed the last down input by 1 frame. It doesn't affect horizontal movement at all since you're moving too slow for the 15/16 decrease to matter, but it saves two frames of input length.
Here's an updated version: http://tasvideos.org/userfiles/info/46534819693480766
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
When creating my TAS back in 2014, I was lucky the game was just broken enough to complete this objective in a reasonable time while still being somewhat varied and showing multiple facets of the game.
Of course, the rules had always been somewhat arbitrary to begin with, disallowing certain glitches to make aiming for the fastest time still look interesting in the end, and this run clearly demonstrates that arbitrariness.
I'm very interested to see what happens with this submission. It's clearly an improvement time-wise to the current run, which uses very outdated techniques at this point. But at the same time, it lost all its variety and may not be able to justify its arbitrary ruleset anymore due to being highly repetitive despite the restrictions.
In the submission text of my 2014 TAS, I made a point about whether this is even a sound category still with how broken this game is, and at that point luckily it still was, but since the discovery of LWA it was clearly not anymore, and it was not easily fixable without getting even more arbitrary in the ruleset to a point where you can not really call it a speed-focused TAS anymore but rather a glitch exhibition.
Anyway, thanks for making this, to put the finger on this problem. In my opinion, it should probably obsolete my current run, given that it's hard to justify its existence anymore unless you want to re-brand it as some kind of entertainment-focused glitch showcase run, but beyond that it's hard to recommend where to go with this category from here.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
Alyosha wrote:
Edit: I noticed you used the difficulty switches to manipulate the geeese, but this isn’t allowed RTA, do you know what the best time is without switching ?
I don't know exactly. If I recall correctly, the best way I found without using the difficulty switches is slowing down right at the start to delay the first goose spawn, and then you only need to dodge two geese throughout the run. So that would likely be around 32.52 or 32.54, but I haven't done a full run to confirm.
Omnigamer wrote:
I'm glad you found a way to manipulate the geese with current emulators. I briefly investigated the game some months ago, but noticed in this disassembly that it polls for input multiple times per frame. Through some testing I think I found that you could actually have motion without spawning any geese at all, so long as you weren't holding the button at a certain point in the frame. But that kind of manipulation isn't possible in current emulators, so I'm glad there's something else that works for the same purpose.
You can have motion without spawning any geese, you just can't have fast motion. The geese spawn if you're moving too fast (code). If you never press B, you can complete the game and never spawn any geese.
That said, I have complained before about the fact that most emulators only support one input per frame, unlike actual consoles. It's an arbitrary restriction that actually limits what you can do in some cases, but it seems few people care about this shortcoming. All hail lsnes I guess, for being one of the few emulators with a somewhat reasonable input format that allows for things like this.
Omnigamer wrote:
Any thoughts on trying the other game modes? With this much understanding it's just more of the same, but I'm curious what the maxouts are for the other modes as well.
I don't have any plans to try out the other game modes, as you said they'll not be much different from this one. And the result will probably be 0.99 x (RTA time) similar to this. But if you're curious, I won't stop you :)
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
feos wrote:
Alyosha wrote:
Neat, I'll give it a yes.
If you are interested MrWint, you might want to try to get 32.67 in Barnstorming. It's another legendary Todd Rogers time but this one is probably possible, although no one else has reproduced it yet. Should be kind of straight forward from a bot perspective though.
Yes please!
Interesting, I was not aware of this particular controversy at all. Sounds like a fun project to investigate though, I'll probably take a look at it and see what I can find. It seems there are even more outlandish times claimed for that game, at least some of them seem highly unlikely.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
feos wrote:
The rules don't ban that, and you can edit your submission right away.
I looked at my options for editing the submission but didn't see the option to add authors. Maybe I'm just blind though. Can somebody with the right permissions do that?
Omnigamer wrote:
Thanks for the offer MrWint. I understand feos's points, though. It's not a big deal one way or another, so it's probably best left up to a decision of the publishers/editors. Do what's consistent to the rules and goals of the site.
By all means, it was my fault not thinking about this option, I'm sorry I even put you in the position where you need to ask. I completely agree with you, and my goal is by not to take anything away from what you have done for and achieved in this game.
Dwedit wrote:
Is this basically Omnigamer's TAS but with the players switched, and one frame removed?
Sort of, it's a bit more nuanced with the different possible frame offsets, and all the inputs are mine, but it achieves the same thing, so if you boil it down that's basically it.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
I'm all for adding Omnigamer as a co-author to this submission. My research has been significantly helped by Omnigamer's original research, and I agree that it is mostly confirming Omnigamers results and doesn't actually add anything to the run itself, it's a frame saved due to cheeky frame optimization before the start. I was considering not submitting this at all, to avoid the obsoletion, and instead add it as a footnote somewhere.
So if there's nothing in the site's rules against that, I'd propose to add Omnigamer to this submission's author list (not sure if I can do that myself after the fact).
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
Omnigamer wrote:
For clarity, could you list the frame that input ends for the "fewest inputs" goal between my submission and this one? I think it might be a little misleading to some folks when you mention a 20-frame improvement, but the actual difference in when the last input was entered is only 0-2 frames.
Sure. It's a bit difficult to talk about absolute numbers, because of the emulation differences.
The last input frame for the "least input frames" player is 337, whereas in your run it was 338 (when transferred to BizHawk 2.2.2), so the difference is exactly 1 frame. The same goes for the overall input length (i.e. the last input from the "fastest in-game time" player), exactly one frame.
What is 20 frames faster (actually 21, because of the top/bottom switch) is when the "least input frames" player finally reaches the finish line, long after the input file has ended. I tried to make this distinction clear in the submission text, but I agree it's hard to understand just from watching the runs.
Experienced Forum User, Published Author, Skilled player
(1041)
Joined: 7/24/2013
Posts: 175
HappyLee wrote:
Same thing also applies to SMB any% 1-1 and 4-2, where you're just 1 frame away from saving a framerule but probably just not possible.
Interesting, I didn't actually know 4-2 was that close. Your published warped TAS is 13 frames off, and in my testing I could save a couple of frames, but not 12 (the limiting factor mostly being enemies in the way). I might have missed something there, care to point me to an example where it is that close? I'd like to check that out. It's most likely nothing, but maybe we can have our collab TAS after all ;)
