I'm a bit confused as to why you didnt post about your improvements in the other movie thread, unless this improvement was a more recent find.
Presumably because that would've caused the other movie's publication to be cancelled, as happened to the movie before that, under the well-intentioned but clearly broken policy defended in that thread.
I understand the logic behind the policy, but we have right here in the flesh a clear example of it having the exact opposite of the desired effect. Rather than ensuring that the movie we have published is the latest & greatest, it has instead had a chilling effect on innovation, causing new tech to be withheld from the community for over a month.
I really think this makes it clear that it's time to revisit this policy. I don't know what the perfect policy is, but this outcome is a lot worse than an extra publication having been created for a worthy but quickly-obsoleted run.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Since we keep obsolete publication pages around, and frequently refer to them as valuable history, it seems really weird that the previous run won't get one just because publication was slow. I understand that this is how site policy currently is, but I think it's worth considering a policy change that allows for creating a publication page that is already marked obsolete at the time of creation.
This would create a more accurate record of the history of the run for future historians, and would also give the obsoleted runner the credit & respect they deserve for their efforts.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Sorry DrD2k9, I maybe overreacted there. I appreciate you taking the time to respond in depth. I think part of why I felt like your original reply was talking past me is that I didn't (and I think still don't) understand the input model here correctly.
You refer in your latest post to "goofing off", but that's not what I was suggesting — I was talking about optimizing speed by typing longer commands (at no cost) that result in less text output.
I'm pretty confused now, though, about how to reconcile c-square's claim that this is impossible ("there is no frame rule on the start of scrolling (i.e. hitting enter on key input #1 starts scrolling faster than hitting it on key input #2)) with your claim that "having more inputs within the frame shouldn't lose any time before the impact of the 1st input is seen."
A warb degombs the brangy. Your gitch zanks and leils the warb.
That.. was a rather long-winded and condescending way of, I think, saying "yes" to my question?
I know what a frame rule is, and I know that this isn't literally exactly the same as, say, the SMB1 21-frame rule, which is why I used the word "essentially" in my post. And it is really essentially the same principle – if you consider the DOS key polling time analogous to NES input frames, and HHGG frames analogous to the level end routine, the logic is exactly the same. HHGG won't process your inputs until 11 key polling intervals have passed, so, in the same way, you can "waste time" without actually wasting time.
It seems like this could probably be profitably applied – 11 characters is a lot, so I bet there are some longer commands that would fit within the rule window while reducing text output.
A warb degombs the brangy. Your gitch zanks and leils the warb.
I'm not quite sure what you mean by "display resources"
I probably just don't know enough about how DOS works to be asking a reasonable question; I was kinda thinking in terms of unix terminal emulation layers. I have no idea what systems DOS has between a program attempting to output characters and those characters appearing on the screen, but it seemed possible that some of them might be emulation settings rather than core to the OS.
How long it takes for the game to register the keystroke depends on the game. In this game, each key takes 1.3 ms to register, meaning approximately 11 characters can be registered per frame.
Does this mean that there is essentially a frame rule? If a frame starts and you press "n<enter>", presumably the game can't start producing output until the next frame, right? So you could have typed 9 more characters with no time loss?
A warb degombs the brangy. Your gitch zanks and leils the warb.
I am extremely entertained by this on many levels. Seeing the minutiae of the parser explored to this level is very interesting to me, and even watching the fast encode was neat in that it gave me a sense of the fundamental size of a solution to the game.
One question I have is, what factors determine the speed of text output? Does it matter what CPU or display resources are available to the DOS VM? Given that tradeoffs are being made with input size, it would be nice to know the actual values too – how much time per input keystroke, and how much time per output character (or is it per output line?).
A warb degombs the brangy. Your gitch zanks and leils the warb.
And this [a preference for submissions being optimized for easy of future improvement] also really shouldn't be anything new, but rather should be the usual practice, and if it hasn't been mentioned elsewhere or earlier, then I guess it's about time to mention it.
I can see where you're coming from, and it's a noble thought, but unfortunately this is just wrong.
While it's nice to think of TASing as a community effort to push a game to its limits, and it often functions that way, an individual run is a work of art made by an individual or team, and they should be encouraged to express themselves however they see fit.
Establishing some kind of community expectation that files be "optimal" in some way that doesn't actually save time would put an unacceptable burden on authors and deprive of us of entertaining runs.
If you want to improve a run but the entertainment choices made by the author make it harder to understand what is important for speed and what's not, you'll just have to post about it in the thread, or send them a PM, or figure it out yourself. Sorry!
A warb degombs the brangy. Your gitch zanks and leils the warb.
I just want to say that "ease of future improveability" has never been and should never be a criterion used to judge submissions here. It neither relates to the speed nor the entertainment of the run, which are the criteria we use.
It really feels like people are bringing it up because they are looking for "objective" reasons to denigrate something they don't like. If you find speed-to-the-flagpole more entertaining, that's fine. You're allowed to. But don't try to make it seem like it's "objectively correct" because of some new metric you brought in from left field, that has literally never before been a consideration in any judging process on this website.
A warb degombs the brangy. Your gitch zanks and leils the warb.
I think there are some people here who have misunderstood HappyLee's intentions with the cancellation, though some others seem to get it. To clarify (and HappyLee, of course please tell me if I'm wrong), HappyLee wrote:
"Setting to cancelled for one day because too many voters voted "no" or "meh" for unknown reasons."
To me, this clearly means that HappyLee believes this page is currently receiving a large amount of attention from people who are not voting in good faith, whether because they have been linked here from an external source, or are users who got caught up in the drama but haven't actually watched the video. Since cancelled submissions can't be voted on, HappyLee is using this feature to temporarily block voting, for one day, until hopefully those voters have calmed down or moved on.
Now, I have no idea if HappyLee's interpretation of those votes is correct, and I have no idea how the site staff feels about cancellation being used this way. I'm just here to shed light on what's going on for folks who maybe think he's taking his ball and going home or something. I'm quite sure that's not the case, and I am confident this run will be published as the clear improvement it is.
----
On a more personal note, I'd also like to ask everyone to take a step back and treat each other with a bit more respect. HappyLee is inarguably one of the most accomplished and dedicated TASers of all time, and has put a really massive amount of effort into TASing SMB1 in the way he finds satisfying, and we've all benefitted. It's no surprise that the sudden encroachment of a totally new kind of TASing that threatened to beat out his own submission had an emotional impact. It would've hit you pretty hard, too, to imagine your decade-long project being undercut from out of nowhere with a method you don't like.
It's unfortunate that things happened how they did, but I think HappyLee has done a great job in walking back from some of his more incendiary initial comments, and he and MrWint reached an amicable resolution. I think we all owe it to both of them not to put any more fuel on this fire, and just let the run stand on its own.
A warb degombs the brangy. Your gitch zanks and leils the warb.
I can't imagine a more perfect resolution to the fascinating-but-tense situation around the previous run than "find another amazing improvement."
TAS of the fuckin' century.
A warb degombs the brangy. Your gitch zanks and leils the warb.
This was weird and confusing and I voted yes.
Some of the English in the description is hard to understand, which is no problem for publication, but I wonder if maybe you could post in your native language, in case someone else can translate more clearly? It would be cool to understand what's going on more deeply.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Hi I just want to say, as someone who was already an enormous fan of both HappyLee and MrWint, this thread has been incredibly fascinating, and an emotional rollercoaster. I'm overjoyed to see that you've reached a solid understanding, despite the general nature of internet discourse and a bit of a language barrier.
It's really exciting to hear you two start to talk shop about the almosts and the might-have-beens – if this results in a true collaboration to discover exactly one more frame rule, I might just die.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Extremely yes vote for the shorter, glitchier version!
I don't totally understand why the first one is being submitted, as it seems like it's more a proof of concept than an attempt to get the fastest time, right? They both change difficulty switches mid-run, so it seems like we should just publish the faster one.
I mean don't get me wrong it's awesome that you've done the research and presented that proof of concept! But unless I'm misunderstanding, only the shortest one should be published. It's also drastically more entertaining.
A warb degombs the brangy. Your gitch zanks and leils the warb.
One possibility would be to add the tags "works for all SRAM", "works for likely SRAM", and "requires unlikely SRAM" for runs which are totally SRAM-agnostic, mirror RTA routes that require specific SRAM, and custom build their own SRAM, respectively.
If two runs that make different choices are both interesting, they could be separate branches, but in most cases I would see this just being informational. SMW might be a good case for two branches, accepting this run as an obsoletion of the current run on the "requires unlikely SRAM" branch, and opening up space for a new "works for any SRAM" run (or I guess, giving that record back to whatever the last any% publication was before SRAM-specific glitches were added).
A warb degombs the brangy. Your gitch zanks and leils the warb.
I'm fine with this judgment. I've maybe even changed my opinion from "should've been a new branch" to "should've been rejected".. but not for any of the reasons in the judgment post.
I think everyone who wants to see this movie is already aware of this thread, and has gotten to see it. The rest of the world doesn't need to try to figure out why they should care about two nearly identical runs.
I do wish there was a place for things like this in the Vault, for those that do care. This is a legitimate record for a very niche category, one we've decided isn't different enough from the main one to warrant Moons publication. I wish the Vault rules could be modified to accommodate things like this, so that if someone in the future wants to know how fast the PAL version is, they have a sensible place to look.
Until that change, Gruefood Delight will be fine for now.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Dang, what a thread. Thank you MrWint for the excellent effortpost!
I fully agree that PAL should be a first-class citizen, given MrWint's analysis. I also fully agree with feos that obsoleting the NTSC run is completely absurd and would be massively damaging to the site's quality. That run has so much love and history behind it, replacing it with something artificially faster should just not be a consideration.
I know there have been some examples mentioned of good runs obsoleted by clearly worse ones due to version glitches, and that's always a tricky thing. We have quality/entertainment rules in place partly so that it's not so easy to do – you have to at least make a run of publishable quality with the new glitch. At the same time, there's always a desire to have an up-to-date route hosted on the site.
For most runs, that tension eventually results in a new run being accepted and obsoleting the old one. But SMB1 is solidly in the category of special games for which we allow more than the usual number of branches due to popularity, so luckily, in this case, we don't have to choose. We can have both.
I strongly support publishing this run to Moons as a separate branch. I have a slight preference for the NTSC run keeping the unmodified "any%" tag and this one getting "any%, PAL", but I'd also be ok with just having them side by side as "any%, NTSC" and "any%, PAL".
A warb degombs the brangy. Your gitch zanks and leils the warb.
HappyLee, it's been incredible watching your work (and English!) improve over the last 10 years. You've taken our art form to the pinnacle of technical mastery, and done it with humor and grace.
There's no doubt in my mind that you work primarily for your own satisfaction – I don't think anyone could sustain that level of effort and time investment otherwise – but I want you to know that your work is meaningful to others, too. It's not just entertaining, it's showing us something new about how to see the world.
Thank you for this final run, and all the others, and I hope from the bottom of my heart that your real-life endeavors are as beautiful and surprising as your TASes.
A warb degombs the brangy. Your gitch zanks and leils the warb.
