On the original SNES controller (and NES I think) multidirectional input isn't possible without a modded/opened controller. Opening a controller is still original hardware, though.
On a GBA/SP, it's possible, but hard and hurts the fingers and thus can't be done with the precision and finesse as a TAS.
Don't several of the RPG runs here not sync on real hardware because of something to do with the game state or something?
On the original SNES controller (and NES I think) multidirectional input isn't possible without a modded/opened controller.
False. Many snes (and maybe other consoles) controllers can receive both left and right as input on the same frame by pressing down really hard on both sides of the d-pad. this is done without breaking or opening the controller.
On the original SNES controller (and NES I think) multidirectional input isn't possible without a modded/opened controller.
False. Many snes (and maybe other consoles) controllers can receive both left and right as input on the same frame by pressing down really hard on both sides of the d-pad. this is done without breaking or opening the controller.
Was it only certain controllers? I had a later SNES controller (one with colored R/B/Y/G buttons instead of the solid purple) and, try as I might, I couldn't do U+D. (L+R is really hard even on a GBA SP, where I find I have an "easier" time doing it. The original GBA hurts to do it on even more.)
I guess it's possible I wasn't pushing hard enough. But it worked once I opened the controller, if I recall right. Regardless, you are indeed going to damage the D-Pad irreversibly if you try it unopened too many times for too long. There's too much force going on and it's being pressed in ways it shouldn't.
Also, even if it did require opening the controller, that's still original hardware with the original controller... just looking a bit different. :)
I have a rbyg snes controller, r+l does not work on that. It works on some purple button controllers and not others. I have done it many times on mine and still no apparent damage, and still just as hard to do.
that's still original hardware with the original controller... just looking a bit different. :)
So is crooked cart. To my knowledge that isn't allowed here.
I have a rbyg snes controller, r+l does not work on that. It works on some purple button controllers and not others. I have done it many times on mine and still no apparent damage, and still just as hard to do.
that's still original hardware with the original controller... just looking a bit different. :)
So is crooked cart. To my knowledge that isn't allowed here.
I know doing U+D/L+R on a GBA (SP too, probably) will cause damage to it overtime simply because there's too much pressure and it isn't supposed to do that.
Isn't it too hard to emulate a crooked cart because entirely random memory addresses get altered, not specific ones?
Even CEN64 won't emulate crooked cartridge.
It short circuits the abstractions that let us reason about how an N64 works on a higher level than transistors and electronics.
If it were actually possible to TAS with it, only then would it be worth debating as to whether it would be allowed or not.
I'll weigh in even though this seems to be settled. Warp is mostly correct. What we tell people when we explain this site is that we are using computers to simulate a perfect player, one unrestricted by reaction times and reflexes. We're not just putting in arbitrary input. If a robot using the real equipment can't do it, it is not a tool-assisted speedrun.
(Where he goes off the rails is complaining about the reset button. A perfect player could easily press that button. I know of a Pokemon human speedrun that involves cutting off the power and corrupting the save file. It lets you get into a glitched menu that lets you pick an option that will take you to the final room of the game. If it can be done in a real speedrun, it can be done in a tool assisted speedrun. It's only the other way around that might be impossible.)
Anyways, the question for the SNES run is whether or not our imaginary perfect player could execute these inputs. He's allowed to use multiple controllers, as has been established forever. Maybe he has perfect muscle control and can play with his toes and other body parts. He's allowed to use any controller that was authorized for the system, because a human speedrunner can use any controller.
As far as I know, there are no standard SNES controllers that directly implement those extra buttons. It would be pointless if they did, since those buttons wouldn't do anything. So our possibilities are the mouse or the multitap.
Well, the mouse is out, because you didn't confirm that it is possible to send the exact data using the mouse. To confirm that, you'd need to use a mouse as input. It is extremely likely this is impossible, as a mouse has restrictions on the kind of input it can send. Plus, as you said, one of the extra pins is always on, so you can't shut it off.
The multitap is far more promising. Could the player pull it off with 8 controllers plugged in? The much more fun arbitrary code execution branch does that, so I would think it was possible. But we should confirm. Can you do it by simulating 8 full controllers?
My understanding of this is that the answer is yes. In that case, I approve of the run. If not, I don't. Because, if not, we've been lying to people about what a TAS is.
Hence I'm okay with the SMW game end glitch, but only because I believe it is theoretically possible. But I would prefer it to be confirmed with software simulating two multitaps, like is used for the SMW "executes arbitary code" run. IN the AGDQ, it was explicitly stated that this would be possible if you had eight standard controllers and two multitaps. So it should be possible here.
(Where he goes off the rails is complaining about the reset button. A perfect player could easily press that button. I know of a Pokemon human speedrun that involves cutting off the power and corrupting the save file. It lets you get into a glitched menu that lets you pick an option that will take you to the final room of the game. If it can be done in a real speedrun, it can be done in a tool assisted speedrun. It's only the other way around that might be impossible.)
For what it's worth, I'm personally not completely happy with save files being corrupted via resetting in real-time runs either. It just doesn't feel like speedrunning anymore. It feels more like "how can we break the game by abusing the power/reset button". That's not playing the game and thus, in my books, isn't speedrunning it either. Sure, kudos to the people who have the skill to do it, but it's a different category altogether.
"If you can do it in a real console, it's legit" is not a very good argument. You can modify the real console, but that doesn't make a speedrun of it legit. And once we get to removing and changing game cartridges while the game is running, we are going way south with the whole idea of completing games by playing them.
But that's just my opinion.
I don't open blatant clickbait videos. Could you explain what this is about?
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
It's apparently about some guys who cracked open a controller and physically pressed the chip on the circuit board to achieve interesting effects in Goldeneye. In the end, the community unanimously agreed that the "glitch" should be banned.
Oh, and all videos related to the "glitch" were purged from the internet, or so they said.
It just fit so well on the topic of what I consider hardware abuse to affect a game, and what the real-time speedrun community (in this case the Goldeneye speedrun community) thinks of it.
Are there any Gamecube TAS that press the digital trigger without adjusting its analog value?
I remember removing a spring from my controller back in the day to make SSBM wavedashing easier (for me, not to even try and claim any real skill). No big deal, anybody can do it. Should that be banned from a TAS?
In fact, do most of the TAS for systems with analog+digital buttons bother ensuring that the analog is a strict representation of what a physical controller would read or do they just send the digital press? Maybe they do, I dunno, feel free to correct me, I'm just stream of consciousnessing here.
For arbitrary buttons in SNES - Isn't it perfectly valid to have a NES keyboard plugged into a SNES controller adapter, plugged into a bunch of multitaps?
For the Goldeneye glitch, isn't it interesting to see? Wouldn't a TAS that implemented it be worth watching as a side movie, not replacing the main?
Wouldn't it be interesting as all fawk to go to somebody's house and have them say "I dunno why it happens, but when I put my SNES controller in the microwave for 45 seconds it beats Super Mario World using Sonic"? If that could be replicated through emulation, shouldn't it be?
In fact, do most of the TAS for systems with analog+digital buttons bother ensuring that the analog is a strict representation of what a physical controller would read or do they just send the digital press?
I'm not an expert on this, but I believe that with some controllers for some systems it's possible to input "impossible" values through the controller port. Values that are not possible with an official unmodified controller (but may be with a modified one, or a third-party one).
Consider, for example, that most gamepad analog sticks are restricted to a circular motion at their outer edge, while the values they send to the console are most probably within a square. For example, the two values for the X and Y positions of the stick may be within the range from 0 to 255 (ie. 8 bits), but combinations like 0,0 (which would be eg. the extreme top left corner) or 255,255 (which would be the extreme bottom right corner) are impossible for the mere reason that the stick can't move to those positions because there's a physical barrier stopping it. But if you physically remove that barrier, they might become possible.
(Note that this might not always be the case, as many gamepads will map the circle within which the stick moves onto the entire 256x256 address space. But for some systems it might be the case.)
If some system has thumbstick positions that are impossible on the official unmodified controller, should those impossible inputs be allowed in a TAS? That's a difficult question.
For the Goldeneye glitch, isn't it interesting to see? Wouldn't a TAS that implemented it be worth watching as a side movie, not replacing the main?
If I understood correctly, the only thing that the glitch (triggered by abusing the second controller) does is that it stops the game from incrementing the internal timer during certain cutscenes in certain levels. The run itself doesn't really change, only the final in-game time. Thus there wouldn't really be anything different about the run to see.
I would say that if these kinds of "hacking" allows for some good entertainment value, then why not? They obviously can't compete with other runs, or obsolete other runs, because as you open up these things, the sky is the limit and that really makes impossible to compete fairly.
But TASVideos has historically allowed runs for pure entertainment if I'm not wrong, not just purely aiming for best time. So in that sense, why not? I find it siimlar to Arbitrary Code Execution, that while possibly through normal controller inputs, once activated, the sky is the limit.
Those are my thought anyway.
But TASVideos has historically allowed runs for pure entertainment if I'm not wrong, not just purely aiming for best time.
In general, with extremely few exceptions, at the very least the run has to complete the game, so it's not like anything goes as long as it's "entertaining".
So in that sense, why not? I find it siimlar to Arbitrary Code Execution, that while possibly through normal controller inputs, once activated, the sky is the limit.
The problem with arbitrary code execution is that unless it's used to jump directly to the end of the game (I'm not going to the question of whether that's a "legit" completion of the game of not), it essentially just wastes time. Not really a speedrun.
The problem with arbitrary code execution is that unless it's used to jump directly to the end of the game (I'm not going to the question of whether that's a "legit" completion of the game of not), it essentially just wastes time. Not really a speedrun.
TASVideos isn't just all about speedruns. Lots of videos makes entertainment tradeoffs, and there are playarounds too. So in a sense, not all videos are speedruns because they don't complete the game as fast as possible.
But perhaps these kinds of videos might be better suited as things like glitch showcases.
If I understood correctly, the only thing that the glitch (triggered by abusing the second controller) does is that it stops the game from incrementing the internal timer during certain cutscenes in certain levels.
Ah, I skimmed it at work with the volume off so couldn't really tell what was going on.
It might not be flashy, but I'm actually incredibly interested in how that works. So, they press on a chip, which sends some unknown signal to the N64 and stops the timer. Doesn't that create a burning need within the depths of your soul to know what that signal is and why it has that specific effect?
What if you could replicate the effect by twisting the sides of the controller in opposite directions, applying the stress on the chip without opening it up? Wouldn't that then be valid "superplay"? (Don't do it on 'my' controller, but what the hell, neat to see somebody else do on theirs)
...Now I'm not gonna be able to concentrate on anything else until I know more. Off to read about Goldeneye...
There are (at least) two ways of counting time on a computer. (1) There are interrupt-driven timers, which will tell the CPU to run some code after a set period of time. That code will then do something like increment a counter. (2) There is also a "wall clock" which will increment a number in a hardware register periodically, without the CPU having to do anything. The CPU looks at this "wall clock" when it wants to see how much time has passed since the last time it checked. On the N64, the peripheral interface chip (PIC) is connected to the CPU's non-maskable interrupt (NMI) line connected to the main CPU. When NMI is asserted, the CPU will run the NMI interrupt handler function. There is no way for the CPU to ignore the NMI, hence non-maskable. If NMI is continuously asserted, nothing else will be able to run on the CPU, including ordinary interrupt handlers that might advance a type (1) counterm as described above. The "wall clock", however, will continue to increment. Here, what probably happens is that the glitched controller sends invalid data to the PIF chip, which asserts NMI. This causes the CPU to be stuck in its NMI handler, preventing it from running code that counts the level time. When the glitched controller is released, the game checks if the event is finished by looking at the "wall clock", which has advanced during this time. Thus, the event will finish even though the level time hasn't been counting forwards.
Assuming that's accurate then I would agree that it's not (normally) TAS appropriate. I still find it incredibly interesting as something that can be reasonably recreated by the average person though. Have a broken controller? Open it up and use it for this. Probably tons of neat effects in various games that could be triggered.
TASVideos isn't just all about speedruns. Lots of videos makes entertainment tradeoffs, and there are playarounds too. So in a sense, not all videos are speedruns because they don't complete the game as fast as possible.
In general, "speed/entertainment tradeoff" is usually made when the absolutely fastest completion time would be very boring to watch, and a slightly (usually only very slightly, although there are probably exceptions) slower way is much more viewer-friendly. That's why it's called a tradeoff: Sacrifice a bit of speed to make the run less boring. Pay something, gain something.
Quite clearly a custom demo that's run using ACE isn't a "speed/entertainment tradeoff". It's not sacrificing a bit of speed to make the otherwise boring run a bit more viewer-friendly.
Outright playarounds are quite an exception rather than the rule, and often (although not always) done with games that have a less-defined "goal" or "ending", and where "completion speed" makes less sense as a concept. For example the Family Feud and Brain Age "TASes" are playarounds because they make much more sense given these particular games.
But what are ACEs? They aren't speedruns, they aren't "superplays" (getting the ACE to trigger is "superplay" of the base game that's being run, but that stops when control of the console is gained). They are just custom demos. The method by which they are injected into the console is technically very interesting, but they are still just custom demos. Limited romhacks of sorts.
Have there been any situations where it's technically ACE but so slow or limited that it's more interesting to just use it as a quick skip?
I'm thinking something like default data being an instruction to skip to the next room, but maybe if you spent 20 minutes arranging your inventory it would be ACE.
Have there been any situations where it's technically ACE but so slow or limited that it's more interesting to just use it as a quick skip?
I'm thinking something like default data being an instruction to skip to the next room, but maybe if you spent 20 minutes arranging your inventory it would be ACE.
There are multiple cases where ACE has been used to simply skip game elements to reach the end faster without introducing new elements to the game or demonstrating something unrelated to the game itself.
It's not in a published TAS (yet), but the SMB3 run abusing the NES DPCM glitch with subframe inputs that warps directly to the end-game almost instantly after power-on is technically an ACE example that simply skips gameplay.
Link to videoThis SMB3 run is another example of using ACE for a game end glitch.
This Mega Man run also uses ACE for a game end glitch.
These are all examples of runs that simply use ACE to skip some degree of gameplay without adding any custom payload/demonstration.
Ah, already forgot about this thread.
1. In case you don't know, I already started and having a page with good up-to-date informations listed down at Wiki: MESHUGGAH/ForbiddenTechniques
I still favor p4wn3r's view. And I couldn't find any counter arguments or different approach for the opposite of these:
p4wn3r wrote:
Frankly, arguments as "the game should be played like X" are useless for TASing. It's just not how things work here, we already play games at extremely unrealistic conditions. We're definitely not interested in how things were intended to be, we're interested in how they are.
(I also checked all posts, no additional techniques were mentioned apart from what I already written down.)
2. I guess I should apologize for my last comments in this thread (page 3 bottom and next page few comments) that could read as me being too ignorant or demeaning. Sorry if anyone took it as a personal attack or thought I'm not listening to other opinions or any offense whatever.
I would have some excuse but it's not important. I still waiting for a different view without flaws opposing my approaches written down (my comments and my forbidden techniques page).
3. Wulf2k: Hmm... I think you meant "A TAS that uses ACE as minimally as possible to skip some parts instead of using more ACE that requires more time".
In this case, I don't really think. Since if you know that there is an ACE but it requires a lot of time, you will probably go with memory corruption.
Now NES Battletoads cames to my mind.
- #3356: feos & MESHUGGAH's NES Battletoads in 11:04.72: "but the target one is Level End (0x7F in address 0x3CD) that ends the level instantly with the same animation as in level 12.
The exact work of this glitch wasn't studied as we had luck to get the fastest result without heavy debugging."
- I've took the number 0x7F from AnS and others from feos and his co(mpany)'s docs. It turns out it was a coincidence.
- #3690: TheZlomuS & DyLaX's NES Battletoads "Glitched" in 01:02.68: "but some objects need special attribute values, that aren't read from descriptor lines, but loaded other ways."
- #3750: MESHUGGAH's NES Battletoads "Glitched" in 00:56.94: now since we know that we can do a lot more than just spawning an object, we use "more" memory corruption to end the game instead of just skipping 1 level.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
1. In case you don't know, I already started and having a page with good up-to-date informations listed down at Wiki: MESHUGGAH/ForbiddenTechniques
I still favor p4wn3r's view. And I couldn't find any counter arguments or different approach for the opposite of these:
p4wn3r wrote:
Frankly, arguments as "the game should be played like X" are useless for TASing. It's just not how things work here, we already play games at extremely unrealistic conditions. We're definitely not interested in how things were intended to be, we're interested in how they are.
It's not really a question of how "realistic", or "possible", or "intended" something is for a human player to do. My own contention with speedruns (be they unassisted or tool-assisted) is how much the behavior of the game is influenced from the outside, ie. using things that are not part of the game itself.
Some people have the opinion of "if it's possible (without eg. modifying the hardware or using cheating devices), anything is allowed". I don't agree with that. And neither do these people! (At least the vast majority of them.) Let's take an extreme example:
You are speedrunning a Windows game, and you save the game as soon as it starts and is possible. You then immediately alt-tab away from the game, launch a hex-editor, and use it to edit the savefile of the game so that when you return to the game and load it, it jumps right to the end of the game.
Would this be acceptable by anybody (even those whose opinion is "anything goes")? No. Yet, it's perfectly possible to do that, completely within the system itself, and we didn't even need any hardware abuse, reset buttons, pulling the powerplug, or anything.
Many people would say "ok, as long as it can be done from within the game, anything goes". Yet, once again, this is not the majority consensus either. For example, when running Source Engine games (such as Half-Life), it's generally forbidden to open the developer console and enter some cheat codes there, or jump to the last level, or anything. Even though this can be fully done from within the game, and we didn't even need to exit it, or use any sort of hardware abuse to do it.
So there are reasonable limits to what a runner (unassisted or tool-assisted) ought to be allowed to do. There just have to be, by necessity. The question is merely where those limits should be put.
If even many things that are fully doable from within the game, using the game's own input, may sometimes be banned, more the reason to ban hardware abuse, or any other form of influencing the behavior of the game from the outside, using things that are not input to the game itself.
Many people say "TAS means tool-assisted superplay. SUPERPLAY!!!" Ok, well, play the game then. Don't break it using input not intended for the game, such as the reset button. Or break it by running your own custom code by abusing an exploit within the game (even if it can be done with controller input alone). That's not playing the game.
I know I'm almost alone with this, but I do not consider any speedrun (unassisted or tool-assisted) to be legit if it doesn't actually play the game at all points, and instead resorts to external ways to influence it (or runs custom code). Glitching the game is ok (although the difference between glitching and ACE can become fuzzy at some extreme levels), but only when it happens within the terms of the game itself. (For example, I don't consider resetting while the game is saving, in order to corrupt the savefile to be legit gameplay. Sorry, I just don't.)
