The most important thing about using bsnes-derived emulator core for TASing is that it allows for Console Verification.
If the timing of lag frames, loading times, etc is even slightly incorrectly emulated, then the game may not proceed the same on emulator vs on console. Console Verification, playing back a TAS on the real console, was required to showcase Masterjun's Super Mario World 'executes arbitrary code' TAS at the AGDQ2014 event live, for example.
If your computer can't handle Bizhawk at all, though, note that we still accept snes9x 1.5x TASes for SNES.
If you need someone explaining what buttons they press while doing it, there's always sockfolder's old tutorial.
http://www.twitch.tv/sockfolder/c/2081384
Note that it's not necessarily the only or fastest way to do it. lukehhh might be doing something faster/better for example, and a TAS might have something better yet.
I seem to recall that Saturn made a TAS using the GT code and it got rejected for using a cheat code.
But in the case of Saturn's GT code TAS, it didn't do anything interesting with the GT code. A GT code into space/time beam TAS shows off something you will never see in any other category, complete annihilation of the game.
I think the fact that the GT code is necessary probably would make such a TAS unfit for publication here, and Space/Time beam is kind of tricky territory to begin with as its behavior is at least somewhat emulator dependent and might not be the same as on console. But I guess it could be interesting to throw together as a proof of concept and see what kind of time is possible to reach (most likely somewhere around 00:10). Either way It's great that someone finally took the time to sit down and make a legitimate effort with Space/Time.
'I think the fact that the GT code is necessary probably would make such a TAS unfit for publication here'
Is this really true though? The old Earthbound glitched TAS accessed the debug menu (via a glitch, but it was still accessing a developer intended debug feature). So what's the difference? That you access the GT code by the developer intended way? (e.g. if it was glitched into triggering mistakenly it would be ok?)
(I'm also curious - does an emulator as accurate as bsnes-derived core still have differences in its Space/Time emulation relative to console? Or do the worries mostly stem from snes9x/zsnes/etc?)
Seconding that a TAS of this would be sick, all concerns aside :D
I would have loved to see the whole thing advance by not introducing democracy mode, but instead just removing the step limit in the Safari zone (would have been still a problem when you are out of balls but maybe they would have managed to finish it that way).
Removing the step limit would make the experience feel illegitimate, though. I mean, in the case of romhacks that add more pokemon to catch, that doesn't really make the game easier, it just gives you more options for how to compose your team (similar options to if you had started on a different version, say). But removing the step limit? Imagine how awful that would be in retrospect - you'd be describing TPP Gen 1 to someone, they'd gasp and ask 'But how'd they get through the Safari Zone?' and you'd have to sheepishly admit that we couldn't do it, we had to neuter it by gouging the code for the Safari Zone out. Or maybe you wouldn't know that it happened because you weren't there for the Safari Zone, and you'd be clueless to how it was really done, and instead think it was some amazing feat of anarchical co-ordination - even worse.
JMO though.
There is only one TPP, and it is the creator of TPP's alone, and no one else's vision/ideal.
Why is the streamer using a hacked rom? That kind of deteriorates the feeling of authenticity of the project, and somewhat defeats the purpose (which is to see if 50 thousand people can beat Pokemon Crystal. This isn't Pokemon Crystal. This is a custom modification. It doesn't feel like a genuine project.)
Why are you obsessed with the need for 'purity'? After all, the entire project is molded by how well twitch stream delay and twitch chat work, which is subject to swings, variations and so on. The experiment would have worked out VERY differently if it was done on a site (or at a different time in twitch's history) where stream delay is 0-10 seconds. Spurtiness/lag in chat sending messages to the stream vs smoothness can vary how well the game is controlled by chat as well. etc.
Also, the final battle with Red will almost certainly be modified to include a powered up version of our ending team from TPP Gen 1. Hacking the ROM is the name of the experiment.
New category!!!
Link to video
Beeline to GT Code, equip the Space-Time Beam, and then destroy the coherence of reality in the name of going fast.
Very glitchy, very silly, reportedly works on console the same way.
It is very inconsistent and often crashes or softlocks the game though, so real time speedrunners are interested in finding out what alters the behavior of the space-time beam (what code and variables it calls, etc) so they can make better setups.
I think what we REALLY need to do is, as a community, come up with a term that unambiguously means 'You can do small, localized, well defined in scope memory corruption glitches (putting a chuck in your power up, trainer fly, things like that) but you can't do large scale, global, arbitrarily wide scope memory corruption glitches (anything that reads to or writes from many unrelated fields, especially in an arbitrary or many-at-once manner)' so we can concisely describe categories better. It might need to be a new piece of jargon, which is OK if the whole community can agree on what it should be. But I'm kind of tired of the war between 'overly precise, cold and technical descriptions' and 'easier to understand, but not considered technically precise enough' category labels and I wish it would go away with a nice solution.
If you are amused by silly things, the stream is now playing Keitai Denjuu Telefang while waiting for gen 2 to start (still 13 hours to go)
http://www.twitch.tv/twitchplayspokemon
tried making a test run for credits warp TAS to see what sort of time a finished product might get, but even just doing everything as close to exactly similar to sock's finished real-time test of the route still results in crashes no matter what i do. just optimizing everything from the save corruption onwards is probably going to be at least as obnoxious for me as making the entirety of the normal TAS, considering I didn't come into TASing this game expecting to have to understand ASM to have a grasp of how some speed trick works.
I'll keep at it for now, but this is seriously a pain.
I suggest you watch sockfolder's after-run explanation on how SoS and the setup works: http://www.twitch.tv/sockfolder/b/506995128?t=2h19m20s
In particular, he goes over an important thing that will randomly make the setup not work - If the minutes, seconds or the frames of the timer has exactly the same byte value as the ID's byte value of the weapon you're dropping (and trying to swap it with something deeper in memory, in this case the music pointer), then the timer will 'grab' the item and the setup is ruined. He has a hex editor open while doing the setup, so make sure that your hex is behaving the same as his as he does the setup. In addition, the real time you wait after fully corrupting the music pointer is significant, since a certain instruction needs to be mutated into a 'correct' new instruction.
(And don't feel obliged to do this, of course :) )
EDIT: Romscout can't get it either. So sockfolder needs to elaborate on what we're missing as mere mortals.
It’s surprising that such a run receives so negative feedback on Youtube
It's not surprising to me. Mario TASes have notoriously bad like/dislike ratios on youtube, because people watching them think the glitches are cheats (because they don't look very glitch-y, such as passing through a pirahna plant's graphic without getting hit, or doing a walljump). This one in particular is a warpless walkathon, so it's about the slowest TAS intended for speed you could make.
Technically, for the disappearance of a verification movie to be a problem, post TAS publication, would require ALSO that you don't trust everyone who verified that the verification movie correctly creates the SRAM used for the published TAS to be reliable.
