Experienced Forum User, Published Author, Player
(152)
Joined: 9/1/2014
Posts: 235
Location: Italy
Alyosha wrote:
Plush wrote:
Yeah we knew about this months ago before getting public lol
but did you all do any work on it? Is there a prevailing theory? Or was what was in the video the extent of what was thought up?
I looked at the original video again and looked at the MHS data. I think at the point mario hits the wall, he is under the higher (-173) polygon. This sets his horizontal speed to zero. Then it looks like at the point he hits the ground he is back under the lower ceiling (-2641) you can see him inch to the right in the video. So the control stick is being held in the opposite direction, and since mario's speed got set to zero he can go backwards.
I think maybe recreating this will be a step in the right direction, has it been tried yet? I didn't see it in pannenkoek's video comparing warp to ceiling to warp to changed bit value.
I tried but can't control mupen well enough to get just the right state
Personally I just tried for 10 minutes or so, couldn't get any result.
Here's the opinion of the bois:
From a month ago. Someone probably changed their idea.
Experienced Forum User, Published Author, Player
(152)
Joined: 9/1/2014
Posts: 235
Location: Italy
Yesterday night I found something interesting by messing up with the spot
http://imgur.com/a/eAwDv
I definitely didn't know lag frames could've been graphically (and not only I think) different from the previous input frame. Shoutouts to Biz
Experienced Forum User, Published Author, Player
(152)
Joined: 9/1/2014
Posts: 235
Location: Italy
GothicLogic wrote:
Alyosha wrote:
pannenkoek2012 wrote:
And Mario wasn't even jumping at the time, he was landing.
I did a bit of testing and my guess is that Mario might actually have been jumping at the time (the same frame he lands.) I managed to land in roughly the right spot with speed such that I can jump and hit the wall 1 frame later. I would theorize that this happens at the same time that the height of the ceiling is changing, and the game is getting confused about what Mario is colliding with. Mario also reflects off the wall at a different angle, this might also have some impact. I don't know the tools enough to do serious testing though.
I noticed the original video came out in 2013, and pannenkoek2012 says it was shown to him a 'short while' ago. I'm guessing since he put $1000 on it he put considerable effort into reproducing it. Is there any documentation about what ideas were being tested at the time?
When I asked Kyman about it early July, he said he'd shown it to the ABC guys last year and didn't get a response: https://gyazo.com/2e453274c902b374839c09f4b639dab6
He asked again though and this time it did, obviously. So this "short while" will have been in the past month, however, there have been other things discovered like PUs so I guess that may have delayed working on it at all.
Yeah we knew about this months ago before getting public lol
Experienced Forum User, Published Author, Player
(152)
Joined: 9/1/2014
Posts: 235
Location: Italy
GothicLogic wrote:
MortyOak wrote:
I have an idea I would like to share.
You know how you can go to this glitched area that leads to the second floor, yet there is this barrier that prevents you from going to the second floor? There is also a BLJ spot in that same exact area. I wonder if you can gain enough speed with that BLJ spot to access PUs to get yourself to the second floor, without even needing the key from BitFS. I don't know if it's possible, but if it is, it may be possible to finish the game in less than 4 minutes.
I do have my doubts though. Unlike the moat door, the door leading to the second floor doesn't load a new area. It is simply a continuation of one loading zone. However, if it is possible to access a painting like WDW or TTM, you can get to the second floor simply by dying or grabbing a star, more likely the former in a speedrun. It would probably be easier to die in TTM than it is to die in WDW though.
You need the key to trigger the loading zone. If you were to somehow get to a PU, the difference in the key door and the moat door is simply that, you need a key. I don't understand much with this PU stuff but I'm fairly sure it wouldn't help in this situation.
Sick to see you here. For the other guy: how can you say that the door doesn't load a new area? It does as far as I know :/
Experienced Forum User, Published Author, Player
(152)
Joined: 9/1/2014
Posts: 235
Location: Italy
jlun2 wrote:
GoombaHeart wrote:
BTW, could you use the shell for PUs, how long would that take? I'm guessing it's not though since if nothing else I think it'd be impossible not to crash.
I swear I've seen a video of someone using the shell and getting stuck in some spot while moving backwards for 30 minutes just to build up speed. Or maybe that was the remake.
That is interesting. I don't recall any spot to get stuck with shell building speed :O
Experienced Forum User, Published Author, Player
(152)
Joined: 9/1/2014
Posts: 235
Location: Italy
andypanther wrote:
There's still no reason to not publish the file. This just automatically looks suspicious to people.
What's exactly suspicious about it? BitFS is legit, MKDasher first did 18''07, and even I have 18''07 BitFS. The BLJ on Bowser2? It looks completely normal. If it's about the time, I predicted a 4'58 flat a long time ago, right when Snark said he improved 9f on Bowser2 lol
Experienced Forum User, Published Author, Player
(152)
Joined: 9/1/2014
Posts: 235
Location: Italy
Mitjitsu wrote:
Kyman wrote:
Reminder that them not submitting to TASVideos is nothing new, and they aren't obligated to share anything. Be glad there is at least a YouTube video.
Very well done TAS I must say. :)
EDIT: Also I think this is console sub 5?
It's not, NTSC frame rate is 59.85fps, while Mupen is perfect 60. On top of that there is likely to be more lag on console. I'd estimate the final time would be 5:00.97
Really? Isn't that 59.97fps? Or maybe that's NES
EDIT: I'm stupid
EDIT2: It should actually be 59.94. Not sure where you took that .85 from
EDIT3: Without counting console lag: 4'58 flat is 298 seconds, 298 / 59.94 = ~4'58''3. If lag adds up 1''7 hanging myself :(
Experienced Forum User, Published Author, Player
(152)
Joined: 9/1/2014
Posts: 235
Location: Italy
Spikestuff wrote:
Plush wrote:
Many people use Direct64 for encoding
Please tell me you're joking 'cause that's the biggest bullshit thing I have ever heard.
Direct64 really? Really?
Direct64 cannot even do fog emulation correctly.
You know what can? Those 4 different plugins in BizHawk right now.
You're just being silly now.
Also please. Citation is required.
Experienced Forum User, Published Author, Player
(152)
Joined: 9/1/2014
Posts: 235
Location: Italy
Samsara wrote:
Plush wrote:
I won't bother answering if you keep shitposting lol
Yo if I'd been following that logic I don't think I ever would've answered any of your posts since you joined the forums.
At least I've been explaining my stuff. You've been keeping it vague the whole time, not even caring about what I have to say. How close-minded can someone be?
Experienced Forum User, Published Author, Player
(152)
Joined: 9/1/2014
Posts: 235
Location: Italy
Spikestuff wrote:
Plush wrote:
You think 4 plugins is good? lololo
Technically 5, in the future GlideN is in.
Also, you haven't created a point on why you need more than 5 plugins for N64.
and Mupen64 > BizHawk64 is quite hysterical.
'cause BizHawk is using the Mupen64 Plus core which has been proven to be "capable of accurately playing many games".
Mupen64 =/= Mupen64 Plus
EDIT: nvm, read that wrong lol, but yeah again, it's not too hard to understand, mupen64 has more plugin compatibility and lags way less on bad PCs. If you have a bad PC, you should be wise enough to choose mupen64 over Biz on the games that allow both emulators.
Experienced Forum User, Published Author, Player
(152)
Joined: 9/1/2014
Posts: 235
Location: Italy
Mothrayas wrote:
I see your point. Though even if some people still prefer using Mupen, and if their SM64 movies can be converted to BizHawk anyway, Mupen is still a horrible and deprecated emulator. It is highly recommended for everyone to move over to BizHawk anyway at some point.
If there is any feature Mupen has or fault BizHawk has, I'm sure the developers of the latter would love to know about it so they can fix it for any possible Mupen switchers.
As I already said many times. one big flaw of Biz is that it runs slow on trash PCs, while mupen is way more versatile and quick.
EDIT: Also, last time I checked, Biz couldn't run many different plugins, which just sucks.
Experienced Forum User, Published Author, Player
(152)
Joined: 9/1/2014
Posts: 235
Location: Italy
Mothrayas wrote:
Plush wrote:
LOL I can't believe there's still people who force TASers to use Biz.
If someone personally prefers mupen then it just means we're doing m64 conversion to bk2 in the end. There's nopoint whatsoever on TASing with Biz if you prefer mupen. Stop with your Biz bullshit already.
This works for SM64, but I'm pretty sure it didn't work for the Zelda games, or most other games.
And there's still the fact that Mupen causes enough desyncs that making a 100% OoT run is apparently impossible in Mupen, and yet the TASers prefer to splice runs instead, which means the TASes technically are not even valid. I mean, they choose to do that, and I'm fine with that, but we just think that is an extremely silly and/or counterproductive thing to do.
I was referring to a more general case, since I see people telling to use Biz for almost every N64 game, even when not necessary. Zelda doesn't work on mupen so it HAS to be done on Biz though, I completely agree with this.
From a month ago. Someone probably changed their idea.You got the 3 encoder ones and the TASing one.