No need to be so caustic. :v
Reset button on home consoles is not a circuit breaker; its signal is processed in software. So it's still just a button. Now power switch would be a different issue, but we don't abuse that.
If you wanted to make a hardware abuse argument, you could direct it to e.g. closing the lid on DS games, which is actual hardware abuse. And I'd even be inclined to agree with you there. However, this is a topic about Metal Slug in particular.
EDIT: I've been told that closing the lid is also an input signal processed in software. So that can be scratched off the list as well.
Technically, if you only clip into solid objects, that's not considered out-of-bound. The term if for when you leave the physical boundaries of the level.
Also, Aran;Jaeger/EternisedDragon promised me to post here a list of hacks the underflow may affect routes for.
If deaths save significant amounts of time and add to entertainment, sure, why not. Continues are another deal, and I was very vocal against them for reasons already stated; my position hasn't changed.
Should I make this a poll, btw?
Such a beautiful run! So much new stuff, lots of outside-the-box strategies and rethought approach to old rooms, as well as Sniq's unyielding devotion to pushing that frame optimization envelope on RNG and lag. I also love the attention he put into entertainment choices; those were probably the best I've seen in this game since JXQ's 100% v2. So this is an honest, no-reservation yes vote.
And now it's time for the "where should we put the missile underflow" debate!
It's hard for me to say whether there will be a point when it becomes a liability with classic SM categories. For one, the 100% category is likely free from this forever because the trick setup takes time and none of the 100% routes really require extra ammo for major savings. The low% will not go below 13% unless something major is found, and although I wouldn't want that category to be marred by infinite ammo, it'll likely remain safe for years considering how well-optimized the latest TAS is. RBO is a likely candidate for an underflow, but its use there is so minor it'll barely change anything over the current published TAS. The glitched categories are too glitched to bother. So vanilla SM is certainly fine for the time being.
What I'm worried about the most, however, are SM hack runs. Because if the underflow is institutionalized by accepting this run as the improvement to T&K's any%, it means it will be legit to use in every other SM or SM-engine run on the site. Including all of the prospective hacks submitted subsequently. Not using this glitch, similarly, will be counted against the runner. Although on one hand I feel like the community should move on with the times and do something new, on the other, this glitch does introduce a heavy bias upon route planning and, more so, cheapens a lot of ammo management which is one of the more exciting parts of TASing SM and is always a good venue for a proficient TASer to show their worth. So I'd be more inclined to ban this glitch from the classic (no-major-glitches) categories. To be more precise, about 66/33 in favor of the ban.
That said, I'm glad this run got submitted and I hope it gets every bit of recognition it deserves. Thanks for doing it, Sniq!
Well, that's something like two extra hardware/compatibility layers (GC -> GBA, GBA -> GBC; I don't think there is a direct GC -> GBC pathway in GBP). Although it might seem easier to tap into GC's controls per se, it's also more likely to cause more problems at some point. Doing this on GBC proper is the safer bet.
On one hand, yes, I understand what you're saying perfectly. On the other, it's clear that the concept is evolving into something akin to demoscene. I do like this direction, I have enjoyed this run greatly, and I certainly hope to see more ACE runs like this—as opposed to something that beats the game in three seconds or w/e.
Arguably this is a much better venue for the concept of ACE than the actual speedruns that take advantage of it. An ACE run that aims for speed can be adequately summarized in text by the ACE setup itself, since in the end they all gravitate towards the exact same sequence: a few seconds of normal gameplay, a brief period of incomprehensible crap, done. The concept of time becomes meaningless in the absence of actual gameplay. Clearly time isn't the important thing here. This movie gets it.
Familiarizing yourself in increments is quite sensible.
Begin with slowdown and savestates and learn to adopt the mindset of efficiency—not wasting movement, only doing things that serve your primary goal. Consider doing a few simple speedruns for fun just to get used to the mindset, unless that's already how you've played some games before.
Move on to frame advance and memory watch. At this point you should stop eyeballing things and instead rely mainly on the value readout. Find or look up everything that you might need, try executing complex tricks/glitches, and figure out how to use them optimally.
Then move on to TAStudio and Lua scripting—they help you automate, make more sense of things, and spend less time on the more boring/mundane parts. This isn't strictly necessary, but if you want to compete with the more optimized runs out there or just do something very complex in general, it would be hard to avoid. Learning Lua might be in order, unless there are already good scripts available for your intents.
When you're confident with that and want to break games apart completely, move on to tracing and disassembly. Low-level knowledge, such as the basics of assembly language of whatever the emulated system you'll be working with, will certainly be necessary here, unlike any prior step. Note that this step is only really required if you want to dabble in ACE or find obscure game-breaking glitches for real. In no way this is a prerequisite for quality TASes in general, and only a few dozen runs on the site go in that territory.
SMW in particular is very well documented, and you can use the extensive knowledge accumulated by the authors of its runs. However, it does occur to me that this game in particular has already been broken every which way, so keep that in mind.
Quality run of a good game, if rather hard to follow. Yes vote.
A bit of a tangent, but I actually wonder if any% would have looked better as 2P, because in such a fast-paced platformer with complex moveset and colorful graphics there's just no way to keep up with what all the four characters are doing (and rewatching each stage 2-3 times to make full sense of it isn't my thing). This is in stark contrast with stage skips where basically no actual gameplay is happening for something like 30–40 seconds in a row, counting loading screens. I feel bad saying something similar about yet another keylie run, cause this is at least second or third time I've done this already, lol. Still, I love your work, man, don't be discouraged by my criticism. :p
This is the list of relevant tags currently applicable to the classic categories:
- Forgoes major skip glitch
- Forgoes final boss skip glitch
- Heavy glitch abuse
- Forgoes time-saving glitches
- Foregoes memory corruption
I believe an underflow any% would qualify for all of them except memory corruption; correct me if I'm wrong there. Memory corruption is typically considered a major glitch, and major glitches are intuitively understood as something that bends or even breaks the rules of the game fundamentally. However, in this case, it just provides more ammo than would've been available otherwise; it doesn't grant any new items (unlike GT code), nor gives access to inaccessible areas/enemies (unlike OOB travel, Space/Time Beam, etc.), nor allows game state/event manipulation (ACE, Space/Time Beam).
So in this case the bending occurs but isn't fundamental; in almost any other game nobody would bat an eye at using a glitch like this. It would be a no-brainer for any run category that didn't make it a point to avoid glitches entirely. The only reason it's so important in Super Metroid is that its entertainment value is highly predicated on the route (item collection order, area visit order and the like), and routes in it are highly dependent on the choice of glitches to be used.
Well, actually, yes. The reason is that a run accepted as an improvement to an existing category (as opposed to changing or creating a new category) makes its rule set the de facto standard. In other words, it says, "things used in this run are allowed; forgoing them will be counted against you in the future".
Thus, there are two realistic ways an underflow-based any% would be judged.
1. Treat the underflow glitch as major. In this case the run would be rejected for being slower than the current glitched any%. Things will basically remain as they are for the time being, and a prospective Taco route any% would become the new realtime any% and will most likely obsolete the in-game any% as well.
2. Treat the underflow glitch as non-major. This, also, will lead to a double obsoletion, but will not become a new category. The underflow glitch itself will be there to stay in the any% branch pretty much forever because, much like with the GT code, there is no way to outperform it without breaking the game even harder—which we have already done in the glitched TAS.
In such case runners who work on a non-underflow any% under the same ruleset as in T&K's run will have to deal with the fact that their run will likely never be published because they would have to compete in one category with the underflow any%, which is obviously futile, and I expect this to decrease their already low motivation quite a bit. The only way of sneaking a third any% branch in from that point onwards would be to make it completely glitchless, which will very likely invalidate mockball, arm-pumping, jumping through solid ground, slopekiller, and other techniques whose belonging in a glitchless category is a matter of dispute with no easy answers nor convenient resolutions. The entertainment value of a run that omits all the "impure" techniques would be dubious, which, again, will affect the motivation of prospective runners.
As a bottomline, if your run is accepted (and it most likely will be), a run using Taco's route would be unpublishable. So if you want a run using that route to be published at any point, it would have to be done before an underflow run is submitted.
If you want to take a look at how similar precedents were handled in the past, GBA Castlevanias will have you covered. Spoiler: a glitchier run obsoleted a less-glitchier one pretty much every time. Content policy-wise, nothing has changed since.
Yeah, if you submit an underflow any% run first, you'll be immediately institutionalizing it in the branch. An any% that avoids this glitch will never be accepted over it once the glitched run is there, so keep that in mind.
I say just select 135 random 256×240 TASes and proceed with that. I know AngerFist will make a multi-game TAS of 135-megaman-clone-hack-lookalike eventually, but we don't have to wait for him, do we.
I haven't compared directly because running lsnes gives me rash, but I see you've gained something like 6 full seconds, an extra tank, and quite a bit more ammo compared to T&K's TAS so far. Fantastic. I'm curious as to whether you have an estimate on final time in mind. Something like 38:20 seems like a given, but maybe you're expecting to save even more?
I suppose you won't be taking any more Energy Tanks other than the High Jump one, or will you be skipping the HJB in this route?
That's mostly because of 4:2:0 upscale negating the information loss through adjacent pixel color redundancy (and higher resolutions being a better source to downscale that back to the monitor resolution). If you make two or four adjacent pixels share color to save bandwidth, just quadruple their amount, and each pixel will retain its original color. Simple and elegant.
YT does set a higher bitrate target for larger resolutions as well, but ever since the move to VP9 the benefit for low-res videogames seems to be marginal in that respect. When YouTube starts supporting native 10-bit 4:4:4 color space, upscaling to extreme resolutions (if at all) won't be as much of a necessity.
I happen to know both how to afford such equipment and what has to go through one's mind to actually purchase it. Unfortunately, it also answers the question of how these companies manage to stay in business.
There's a real gem lower on that page:
Barely avoided spilling tea all over my new keyboard. Indeed, that less-than-0.5% bonus received as a gift card must be super enticing for someone about to spend about 100x money on a cable than it is worth. Stay classy, Amazon.
Wow, that bad, huh? Damn, I wish using Grapple in an RBO wasn't so much slower. At this point it feels kind of imperative to use it just to differentiate and provide some bonus entertainment for the category, otherwise Norfair would just be the only major stand-out (well, unless killing Kraid with Plasma is your thing).
Well, thanks for the insights.
It could be that in these cases it simply coincided with the optimal way of doing these segments that isn't specific to the slope mechanics knowledge. That said, this was something that had been bugging me since my experiments with a low% run from way back when—I figured I was losing time on slopes that looked like it could be avoidable with hours of precise position bruteforcing, but I never realized the solution would be so simple and elegant.
Yeah, I had pretty much the same idea upon reading Overfiendvip's explanation. In retrospect, the game has a quite surprising amount of instances where doing something weird changes your hitbox width/position by as much as a whole pixel, or, say, movement speed by a 1/16th of a pixel. How many years has it taken to notice the boomerang ledge grab, for instance? Could well be that we haven't yet discovered all the basic things like that.
Alright. And this effect only occurs when Samus is in a state valid for unmorphing (i.e. completely in a ball state, not in a transitional state) but is prevented from doing so by a low ceiling, right? Was wondering whether it could be used during morph/unmorph transitions, but I guess it can't.
Can you give more details about the setup though? The exact prerequisites and such.
Thanks in any case.