Made a test of this at the beginning of this month, it enters hyrule field the exact same frame as the last any% tas did, but i think what i did is improvable, so i think doing zora's river this way would be faster by just a few frames
Link to video
I came close to trying this strategy after the last any% but I thought it'd be too unlikely to be faster, but if this actually does end on the same frame (and this looks greatly improvable) I may TAS this in the coming days.
Yeah, i'm more certain it's faster and what I did should definitely be improvable.
I use BizHawk and I need help learning to TAS on OOT since it is so complicated. I am also relatively new to TASing. Thank you so much to anyone who can teach me at least the basics! <3
there doesn't seem to be any competition currently though as nobody is TASing the game ATM. I would agree that the quality of the already published TAS in every category is really high though
Do one that is fun for you. Maybe one you know from when you were a kid.
But tbh, I think you can start with OoT. I think all the current N64 Zelda tasers started with either MM or OoT. Just don't expect to be any good for a while. It takes practice.
recently released a big update to a memory mapper program for the Zelda 64 engine called Spectrum
I think it should work for any 32 bit N64 emulator, provided you set it up to locate the start of ram. Could be of use to someone here
I have a question. Why is TASing a game from a totally different console with totally different tools gonna help me learn how to TAS n64 games? Am I missing something? Especially with zelda64, frame advance doesn't seem to be too useful when I use it, and I don't understand. Could someone please help?!
The tools shouldn't be completely different. Bizhawk is similar between all consoles. But as I said, you can start with OoT, it will just take a while to learn.
Not sure what to tell you regarding frame advance. It work for everybody else and you haven't really said what your problem is.
mzxrules wrote:
recently released a big update to a memory mapper program for the Zelda 64 engine called Spectrum
It sounds interesting. Although I don't quite understand what it does. :D
@Slowking: Spectrum creates a map of how things are laid out in RAM. It is quite helpful for understanding different aspects of a number of glitches.
With Wrong Warping, some cutscenes are stored in actor overlay files, meaning that the cutscene pointer will be placed within a space in ram I call "Actor Heap". With spectrum you can better understand how that memory is being utilized, and perhaps find new manipulations with these types of cutscene pointers.
Ocarina of Time also has a number of glitches related to memory management, from the "Hyrule Field" glitch where the game simply runs out of free "Actor Heap" space, to the Ganon Barrier duplication glitch, to the more recent glitch where feeding a Bombchu to a Dodongo corrupts the block list managing "Actor Heap".
Lastly, the code blocks for actor files are mapped dynamically to a ram address, meaning that for example, the code file for Dodongos will have a different start address in ram depending on how you progress through the dungeon. Spectrum allows you to easily hone in on the start address, making debugging easier.
More on topic, it was recently discovered that you can in fact perform GIM in the Deku Tree on N64. In order to accomplish this, you need to first buy a bean plant. Then, when you perform Get Item Delay with Deku Nuts, you simply pull out the bean, which will change your GI object file to the bean plant's. This is enough to avoid the crash.
Another way to do GIM in the Deku Tree on N64 is to do double GIM (do it with nuts, then with seeds). This requires getting the Slingshot first ofc. Apparently this isn't common knowledge, I was talking with nathanisbored and he brought it up.
MOD EDIT: this and the next few posts were split from the SM64 "1 key" submission thread for being offtopic. <3 samsara
Great TAS guys!
Synx wrote:
This could have been a total disaster for one simple reason. The PU stuff so often causes crash on console. That the team avoided abusing emulator to ignore such crashes was a brilliant decision. Well done on getting the TAS verified on console! Some day I hope the OoT community will follow the great example you guys have set with this TAS. As I have observed the trend in OoT speedrunning, I must admit I was skeptical when you, the authors were so secretive about this TAS in the Super Mario 64 Thread on the forum here. I feared it would be because the run would not play on console. I am happy to be proven wrong. Congratulations on this great run! MOAT DOOR HYPE!
You can't console verify OoT, otherwise it would have been done already. So what are you talking about?
This could have been a total disaster for one simple reason. The PU stuff so often causes crash on console. That the team avoided abusing emulator to ignore such crashes was a brilliant decision. Well done on getting the TAS verified on console! Some day I hope the OoT community will follow the great example you guys have set with this TAS. As I have observed the trend in OoT speedrunning, I must admit I was skeptical when you, the authors were so secretive about this TAS in the Super Mario 64 Thread on the forum here. I feared it would be because the run would not play on console. I am happy to be proven wrong. Congratulations on this great run! MOAT DOOR HYPE!
You can't console verify OoT, otherwise it would have been done already. So what are you talking about?
There's a difference between an actual console verification and using a trick that is known to always crash on console (at least in the way that is used for any%).
Current project: Gex 3 any%
Paused: Gex 64 any%
There are no N64 emulators. Just SM64 emulators with hacky support for all the other games.
This could have been a total disaster for one simple reason. The PU stuff so often causes crash on console. That the team avoided abusing emulator to ignore such crashes was a brilliant decision. Well done on getting the TAS verified on console! Some day I hope the OoT community will follow the great example you guys have set with this TAS. As I have observed the trend in OoT speedrunning, I must admit I was skeptical when you, the authors were so secretive about this TAS in the Super Mario 64 Thread on the forum here. I feared it would be because the run would not play on console. I am happy to be proven wrong. Congratulations on this great run! MOAT DOOR HYPE!
Can you link a specific OoT TAS you'd expect to crash? I want to see if it crashes for the same reason as the SM64 crashes, now that they can be detected without a console.
