Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
I think it's kind of weird that console timing isn't in the conversation for being the standard. Like, it doesn't get any more accurate than that. I understand there are issues with determining the start point, but that seems minor compared to the inaccuracies of RDP emulation.
Like mkdasher said, the 1 Key TAS was optimized for console, not any particular emulator. A notable example was BitFS, which didn't lag at all (IIRC) on Mupen but had a lot of lag on console, particularly when Mario was around the elevator. We had to scrap a really cool POV where we got the camera stuck in the elevator so you could see Mario's entire BLJ, because it introduced additional lag. The movement was redone several times, and the movement + camera you see in the run yielded the least lag on console. I think DDD fixed cam also reduced lag.
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Not the section of the run people really want to know about, but I added a detailed explanation and analysis of how we saved a frame on the second floor by fully optimizing the "Clock Punch". I think the Clock Punch mechanism is very interesting, and it was fresh in my mind, so I did that first.
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Weatherton wrote:
So I just realized that skipping the first key would very likely be done in the 120 star run as well. Is there any reason not to do that? Am I missing something that would make it slower?
This is a great question, and we discussed it a bit in our group earlier this year. 0 Star VCUtM entry will definitely be the new beginning for 120 Star, but after that it gets less obvious. There are several possibilities:
1a. Press "!" Switch and collect VCUtM Red Coin Star->Save and Quit->Enter castle front door
After Mario collects the star, he is ejected from the VCUtM entry hole and the save options come up as they would without water. Mario doesn't start swimming until after the save menu. Selecting "Save and Quit" and restarting is much faster than selecting "Save and Continue" followed by swimming out of the moat. The whole process would make pounding the pillars in the basement unnecessary, and would undoubtedly save a lot of time as a result.
1b. Same as 1a but select "Save and Continue"->Soft Reset
I don't know which is faster. Same goes for hard reset I guess.
2. Same as 1, but enter VCUtM again after reset and do Moat Door Skip
Like Weatherton said, most of the time saved from Moat Door Skip comes from skipping the Bowser 1 fight, due to the cutscenes and loading times. That time comparison there (52 vs 44) makes it looks like this is probably better than 1, although I think there are other factors that have to be considered.
3. Moat Door Skip->Pound pillars to drain moat->Head back to VCUtM as in current 120 route->Switch + Star->Jump back into VCUtM->Exit Course into Castle
I feel like this is best but I have no evidence to back that up.
I don't think I left anything out. Also, SSL uses Wing cap, so that complicates things for 2 and 3, because they will either need to use a slower strat for the affected stars, or reenter the basement through the moat door later (in which case 2 would need to pound pillars). I think all these combos need to be tested, and I'm excited to see which is best!
EDIT: 1 would still fight Bowser 1 and get 1st key. Also, 3 wouldn't necessarily have to go back to VCUtM right away. It could do basement stuff and then go back to VCUtM via the front door later.
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
(Repost from workbench thread)
Just want to say, thanks for all the positive feedback (and Yes votes)! I won't speak for the other authors, but I had a lot of fun working on this, although there were plenty of frustrating moments. I'm pretty new to both the SM64 and TAS communities, and my participation in both was really an accident, so producing a significant run like this is surreal to me. It was great to collaborate directly with legends like MKDasher, sonicpacker and SilentSlayers, and to see firsthand how they work.
SM64 was the first game I ever played, back when I was just a wee lad in the hospital with an ear infection. It got me hooked on gaming. I remember trying to open the underwater moat door as a little kid, and thinking how awesome it would be to pull it off. Now here we are in 2016. Anime isn't real, Bernie Sanders isn't President of the US, and we aren't living on Mars with robot slaves--but at least we got that damn moat door open.
Also, I'm sorry about the fetal state of the submission text. I am writing most of it, and I have a very busy schedule, but I am working on it as I can. I promise I will divulge all the juicy details, so please be patient. :)
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Just want to say, thanks for all the positive feedback (and Yes votes)! I won't speak for the other authors, but I had a lot of fun working on this, although there were plenty of frustrating moments. I'm pretty new to both the SM64 and TAS communities, and my participation in both was really an accident, so producing a significant run like this is surreal to me. It was great to collaborate directly with legends like MKDasher, sonicpacker and SilentSlayers, and to see firsthand how they work.
SM64 was the first game I ever played, back when I was just a wee lad in the hospital with an ear infection. It got me hooked on gaming. I remember trying to open the underwater moat door as a little kid, and thinking how awesome it would be to pull it off. Now here we are in 2016. Anime isn't real, Bernie Sanders isn't President of the US, and we aren't living on Mars with robot slaves--but at least we got that damn moat door open.
Also, I'm sorry about the fetal state of the submission text. I am writing most of it, and I have a very busy schedule, but I am working on it as I can. I promise I will divulge all the juicy details, so please be patient. :)
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Wow, that was one of the most amazing things I have ever watched. Although I had seen most of the content on your YT before, it was awesome to view everything at once in the completed run. I haven't read the sub text yet, but your creativity and technical skill is obvious.
I thought there was a pretty good ratio of actual racing to major lap skips, and both were highly entertaining. Specifically, the use of the island in Sherbet Land was hilarious and poetic. Sub 20 Choco Mountain? GTFO. You found a use for almost every item in the game, and showed off pretty much everything the game has to offer (well, at least what I know about, I was never much good at it).
Yes, yes and yes that was entertaining. Thank you Weatherton and all others who were involved in this masterpiece.
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Yeah, amazing work by mkdasher, snark and ToT. However the RR strats are almost guaranteed to crash on console. With that said a fix shouldn't be too difficult, although it would probably add some time.
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Hophoolio wrote:
comparing accuracies between diffrent emulators sounds very arbitrary. What if the most accurate emulator only had 1 inaccuracy that let you beat the game super fast or with 0 a presses? Who should decide (arbitrarly) which emulator is the most accurate?
Also, as far as I know, SoulCal have a controller that plays back N64 games from input file on consoles. And as far as I know, it played back several Super Mario 64 runs on N64 already.
Do you still think that this trick that would crash the N64 should be allowed to reduce the A press counts? Because that's what it sounds like to me...
Arguing that it's possible on Wii's VC would only reduce A presses for Wii's VC runs.
I think using emulators should be considered tools when making TAS inputfiles for runs that can be verified on console. If you use a more accurate emulator you're just using a better tool for your tool assisted run. If you're aware of flaws in the tools you use, then you have to adjust how you use the tools.
I completely agree with this. You could make an emulator with perfectly accurate lag, but screw up the exception handler and allow ACE on every game. Glitches due to emulator inaccuracies really shouldn't ever be considered part of the game. Wii VC is a little different because it'a an official emulator, but in that case, it's really just a very similar remake of the original game. Wii VC Super Mario 64 is a separate game from DS Super Mario 64 and N64 Super Mario 64. As for the SA entry in ABC 100% TAS, I don't think it will be included. Plush and I are both against it. Ultimately pannenkoek's opinion matters the most, but I think he's leaning towards no as well.
It's definitely a cool trick however, and is a great example of how the smallest discrepancies in emulation can make a big difference. Pan did a great job planning and executing the route; anything involving PU strats is a lot of work. Hopefully we can find a lower speed strat that will put this all to rest.
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Dom Dunc wrote:
question for the parallel universe wizards here.
using this technique is it possible to gain an infinite amount of speed? Im thinking once you enter the PUs you could keep hitting blj locations to keep increasing your speed. if that is the case, what happens when Mario's speed overflows? Does it just wrap back round to a negative number or does it have some weirder effect similar to how mario's lives get screwed up when you collect 1000 coins in the Japanese version?
You can get infinite speed pretty easily, and PUs aren't part of the process. One thing that surprised me when I started looking into BLJs more is that most BLJs do have a speed cap. Once Mario's speed is enough to take him out of bounds, his speed resets to 0 (only if he's airborne; on the ground he keeps his speed and doesn't move). So, most BLJs have an implicit upper limit imposed by the geometry of the level, because eventually once Mario is going fast enough his speed will take him out of bounds no matter where in the level he is.
The exception to this is a BLJ on a platform that's moving upwards, aka an elevator BLJ (EBLJ). The motion of the platform induces a mechanism that causes Mario's speed to be retained even once his speed is sufficient to move him OOB. Moving platforms are processed earlier in the frame than Mario, so when the game gets to Mario, the platform has already moved up a little and Mario is slightly inside the platform, below the upper surface. When Mario's motion is calculated and it is found that he is about to move OOB, the game compares the height of where Mario is trying to move to the height of the platform he is standing on. Normally, Mario's new height will always be higher than where he jumped from, because obviously an LJ gains height. However, as I said before, Mario doesn't jump from the surface of the elevator, because the platform's upward motion has already happened. Instead he jumps from a point slightly below the surface, and the first frame of the LJ will also be below this height provided the elevator is moving up at a sufficient speed.
When the game does that height comparison and finds that Mario's new position is still lower than the surface he jumped from, it assumes Mario was moving downward and actually landed ON the surface. So, it moves Mario up to the elevator surface, puts him in a landing/grounded state, and most importantly, doesn't touch his speed. So, the EBLJ is the only BLJ that is truly uncapped. That's why we have to use it for PU strats.
To actually answer your question, because BLJs gain speed exponentially (about a 50% increase per frame), it doesn't take very long to reach the maximum floating point value (about 3.402823 * 10^38). Starting at 16 speed and assuming an exact 50% increase every frame, it would take about 212 BLJs to reach the max float. With 1 BLJ every other frame, that's about 14 seconds. Most elevators aren't that long without pause-buffering, but you can do it non-tas on the BBH elevator. Just make sure to have fixed cam on, because it's easy to warp through to a PU at a lower speed, which will also cause a crash without fixed cam.
As for what actually happens when you max out the value, that depends on what you're playing on. On emulator (using a memory watching program) your speed becomes "Inf" as does your position, and you move to a PU-like spot, except you can't move horizontally because you can't increment infinity. On console, the game crashes, most likely because of a floating-point exception caused by the overflow. I don't know about VC.
Glad to help out the original BLJ master with a BLJ question :)
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Alyosha wrote:
So I tried messing around with bob-omb's and coins and such looking for collision detection anomalies, and this happened.
For 1 frame, Mario got snapped to wall horizontally (sorry for the bad pic) while being pushed into the grating by the bob-omb.
Not really sure what to make of it, anyone seen this before? He pops back out normally the next frame.
Here is a savestate, just hold down on the control stick after it loads to recreate this effect.
https://www.dropbox.com/s/9lpfcs66wk3kxkm/Super%20Mario%2064%20%28J%29%20%5B%21%5D.st1?dl=0
You can do other interesting things from that savestate too. If you hold left on the control stick until the bob-omb explodes, you get pushed out of bounds.
EDIT: you can even do a ground pound while in this orientation. and he ground pounds towards the wall instead of the floor (but hits the grating instead)
EDIT2: also, the game thinks mario is under the triangel at -5365, even though he is only at -5211, so it must have put him there at some intermediate step
my only guess is that the game can't resolve what to do with Mario, so it rotates his sprite to at least fit him in the wall for a frame and hopes for things to change. Does anyone know the address for mario's sprite orientation?
I wasn't able to recreate it, can you provide an .m64? I can say that Mario's graphical behavior often appears strange when nothing particularly abnormal is happening, but you mentioned being able to Ground Pound, which suggests this might be a temporary hyperspeed spot.
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Dom Dunc wrote:
I'm also reminded of the cannonless star glitch. Maybe mario is trying to grab the ledge of the platform and since there's no room there (the ledge is up against a wall) the game snaps him to the nearest grabbable ledge in vertical range (in this case the intersection of those two ceilings). Just some ideas.
That can happen (see 50 Star Room Stairs ABC strat), but there's a height limit of 239 units on the glitch, which isn't all that high.
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Mitjitsu wrote:
NTSC frame rate is 59.85fps, while Mupen is perfect 60.
Finally, someone who knows the actual value. I couldn't find that information anywhere.
For people complaining about the camera angles in Snark's TAS, with the BitFS PU strat (and most PU strats) it is required to turn on fixed cam in order to prevent the game from crashing. The crash is console only, so it's very important to console verify the .m64. I wish they had written a proper description because I think the information is important to know.
Also, although that TAS was not console verified, Soulcal did just verify the 18'57 strat! So that bodes well for it as well as future improvements.
Finally, no point in submitting that when we're gonna cut 30 seconds soon anyways ;)
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
With regards to the ABC complaints, I have some context to pass along. I mostly help pannenkoek2012 with ABC strats, and the PU glitch, moat skip and new BitFS strat all were results of ABC research. So even if you don't like the concept of ABC itself, the strats for it are definitely relevant to the standard categories. Also, I think a full 70-star "No A Press" run will be hard to not enjoy if we can make it happen :)
GoombaHeart wrote:
Any Rainbow Road PU strats yet?
Not yet. Depends how good the BLJ on the red coins elevator is. Other than that pretty sure there's no promising spots on that course.
coldsun0630 wrote:
So currently, is Tyler the only person who can move mario correctly on PU? Or is there any ways to learn how to TAS on PU?
Right now, kinda lol. Mkdasher is picking it up very quickly however. I have a huge excel file I made that makes the process much easier. Once I get a better handle on things I think I'll make a tutorial/informational vid about it. the concepts aren't too hard but routing is kinda brute force-ish.
New vid coming out soon, has to do with something that rhymes with "Club Drive"!
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
I've seen that bully glitch before in one of Kyman's freeruns. Apparently when Mario hits a bully it;s actually modeled after a 2D elastic collision (like billiard balls on a table), using the radii of Mario and the bully to estimate mass. So if Mario hits the bully at high speed, a lot of that speed will be transferred to the bully, and vice versa I think. As for the blinking/not falling behavior, that's due to the bully's weird OOB physics, where it kinda bounces back to near where it was without falling. Neat glitch for sure.
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Samlaptop wrote:
Does it like like it will be possible to do it in a 0 star TAS?
Yes, using a weird trick (trainers hate him!) where Mario gains negative V speed for 1 frame proportional to his H speed. It's a WIP. Most likely possible, but not sure if we can save time yet with it or not. Also, there's a PU BitFS strat we're working on that will hopefully save a little time.
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Nahoc wrote:
Please share your theory, I'm interested in how you plan on doing it.
You know how if you BLJ a lot, you can end up in a weird invisible OOB area where you can run around (on emulator/VC at least, it always seems to crash on console)? Idk if you know why that is, but for those who don't, the function that checks for the floor triangle below Mario converts Mario's position to short integers for the calculations. Since shorts range from -32768 to 32767, if Mario's coordinates are outside of that range they will overflow back into it. This creates an infinite 2D grid of invisible copies of the level, spaced every 65536 units.
The copies (in the ABC chat we were calling them "parallel universes/PUs", idk if that will catch on) have the exact same arrangement of floor and ceiling triangles, but all wall triangles are missing, as are most objects, and all water is gone. Doors are gone, so we can't just open the moat door in a PU, but the fact that the water is missing is key.
With no water in the PU moat, Mario can get down to the height of the moat door. So if he's going fast enough (REALLY fast)), he can just run right into the door in the real map, and open it in the 1f you get before Mario starts to swim. I confirmed this with hacked position/speed; I placed Mario 4 PU away where the moat door would be, and gave him sufficient speed so he would reach the real door at the end of 1 frame, and he opened it.
The amount of speed you need to reach an adjacent PU is about 4*2^16, or 260k. Apparently this is only possible with a "stuck" BLJ spot, or by hyperspeed walking. I can't find an appropriate BLJ spot in the castle grounds, and hyperspeed walking would probably take about 30-60 mins to get enough speed. Alternatively, with the wing cap unlocked, we could enter VCutM and get the required speed with a BLJ on the elevators there. When you die in VCutM your speed is preserved into castle grounds because you spawn in water.
I've thought about trying to TAS this, but I kinda suck so I hope someone else does. GLHF
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Does anyone have an N64, Gameshark Pro, and a copy of Mario 64 that can test something for me?
Also, idk if anyone else has tried it, but I'm like 95% sure moat door skip is possible on VC. The route crashes on console, but there might be a way around it if I can understand the crash better (hence my question above). It doesn't save any time though, unless there's a better BLJ spot in castle grounds.
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
jlun2 wrote:
Well...
Does a question regarding the remake count?
But if it has to be the N64 version, it was mentioned before that duping too many goobas crash the game. What exactly does the game overwrite? Does it have any potential for gamebreaking glitches?
For the DS version, I have no idea. It's a completely different game really.
As for the crash from too many goombas, that's an interesting case. Most likely there are just too many polygons to render on the screen at one time. The behavior of the crash changes depending on what emulator you use, and even what graphics plugin, so it's hard to tell what it would do on console. However, I would think it crashes on console, and wouldn't be useful.
Experienced Forum User, Published Author, Player
(152)
Joined: 6/23/2015
Posts: 22
Location: United States
Yeah, really wish we could reproduce the "SAVED DATA EXITS" thing (plox Kyman).
An interesting thing about the erase file crash when performing this glitch is that the crash doesn't occur because the game tries to erase a nonexistent file. The actual crash happens when the game tries to shrink the button of the file, but ends up operating on a NULL pointer, which is a big no-no.
This is also why you can shrink other buttons like in Exchord's video. An array of object pointers exists that uses the file number as an index, and the game uses this to determine which button it should shrink. Each screen (SCORE, COPY, ERASE etc.) has it's own array, and it just so happens that the array for the COPY screen is right before the ERASE array. When you perform this glitch, the selected file is -1, so the game will actually try to shrink the button right before the beginning of the ERASE screen array, which is the last button in the COPY screen array. So by going to the COPY screen first, you can load different buttons into that position. If you don't, the game will crash when you select NO at the erase file prompt.
The game always crashes when you select YES, which is because there is a different array of button pointers used for this, and there is no array directly before it that we can take advantage of. IDK why it's set up like that.
BTW I'm Tyler Kehne, just made an account here. Not a TASer but I do extensive SM64 research, mostly ABC stuff. If anyone has weird SM64 glitches they've experienced but haven't been able to explain, hit me up and I can probably figure out what happened.
So I tried messing around with bob-omb's and coins and such looking for collision detection anomalies, and this happened. For 1 frame, Mario got snapped to wall horizontally (sorry for the bad pic) while being pushed into the grating by the bob-omb. Not really sure what to make of it, anyone seen this before? He pops back out normally the next frame. Here is a savestate, just hold down on the control stick after it loads to recreate this effect. https://www.dropbox.com/s/9lpfcs66wk3kxkm/Super%20Mario%2064%20%28J%29%20%5B%21%5D.st1?dl=0 You can do other interesting things from that savestate too. If you hold left on the control stick until the bob-omb explodes, you get pushed out of bounds. EDIT: you can even do a ground pound while in this orientation. and he ground pounds towards the wall instead of the floor (but hits the grating instead) EDIT2: also, the game thinks mario is under the triangel at -5365, even though he is only at -5211, so it must have put him there at some intermediate step my only guess is that the game can't resolve what to do with Mario, so it rotates his sprite to at least fit him in the wall for a frame and hopes for things to change. Does anyone know the address for mario's sprite orientation?