Forum

Nintendo 64 Games

Super Mario 64 Game: Super Mario 64

Showing items [8426 - 8450] of 8454

1 2

337 338 339

Posted: 11/5/2020 9:37 PM

Quote

Ramzi

Joined: 3/25/2004
Posts: 459

I don't know how the colors from a real N64 compare to the colors from the emulator. Unfortunately, I only found a low quality YouTube video for DOTA's video. I downloaded it in Mp4 format. VLC's frame extraction tool apparently wasn't working on Mp4s. My Windows 10 had some strange Read-Only folder bug which wouldn't let me gain write access. It took me a while to fix this as most solutions didn't work. I wrote a Java program to take 300 fullscreen screengrabs while I played the video in fullscreen in VLC. Hopefully this captured every frame available, but maybe there are missing frames uncaptured. I looked up edge detection algorithms. There is Canny's and Sobel's. Sobel's looked to give better results, so I went with that one. The original results returned black images with white edges. I found an inversion algorithm to return white images with black edges. I produced the inverted edges images for the 300 frames I screenshotted. I don't know if it would be wiser to compare colors from the original video, to colors from the outputted screenshot from the emulator, or if it would be wiser to compare the colors of the edges from the original video and the outputted screenshot from the emulator. My hope in creating the black-and-white edge images would be to make it easier to write an algorithm to compare a frame from the original video with an outputted frame from the emulator. Going one frame at a time, we need to store the set of inputs which yield a match of the edges for that frame, given the input sequence up to that frame. Also, thoughts about running a genetic algorithm keep popping into my mind. Rather than just fuzz-testing with random inputs, or inputs that match the images or image of the edges, I'm thinking we give a fitness value to how close the images match, and a gigantic boost to the fitness value if the upwarp occurs. That is, between the frames where Mario is on the lower platform to when he is on the higher platform, if those inputs can yield a match, then we have a winner. I guess if we have a winner we don't need to assign a fitness value and evolve the inputs any more, because we would already have a faithful replication of the glitch. Anyway, I'm just trying to think of ways of fuzz testing this more intelligently than random inputs. My ideas have been around simplifying the frame comparisons, and also using genetic algorithms to evolve the inputs more intelligently toward finding the solution. Because I posted this video without the hanging ceiling: https://www.youtube.com/watch?v=VV1dzNzRYkU I am inclined to think this is a replicable glitch, even though I know that video was taken of a ROM hack. I would post all the inverted edge pics somewhere, but all 300 of them come out to around 180mb. Here is a frame to show the kind of results I got. I think the effect of a disappearing coin (after Mario touched it) is visible in it near the platform. https://i.ibb.co/f2gThDn/frame099.png If I had a higher quality original video than the one downloaded from YouTube, I would expect the edges to come out crisper.

Posted: 11/5/2020 9:41 PM

Quote

jongyon7192p

Joined: 8/13/2014
Posts: 14

Also everything was labelled manually. At least one person had to read every code that you see labelled, and usually a lot more people read it like every day for the sake of testing some theory someone might have that might save a frame for any category or an A press or explain some glitch any randos come in to ask about.

DeRockProject: the Life-changing Project (TAS is perfection in this imperfect world. TAS is the answer to the longest math problems we have, called video games. TAS perfects worlds. TAS is god. TAS is the future. TAS needs us. Let it govern us. All hail TAS.)

Posted: 11/5/2020 9:49 PM

Quote

Ramzi

Joined: 3/25/2004
Posts: 459

Am I correct that Dane only replicated the first 50 frames? https://ukikipedia.net/wiki/History_Of_The_TTC_Upwarp#August_8.2C_2016 https://www.youtube.com/watch?v=TD1-b3-60xY The description says: "Currently 50/300 frames have been TASed, but those where the easy ones. Once Mario is free to move, TASing is much more difficult since we include analog inputs." If that's true, wouldn't it be fruitful to try to attempt to replicate more frames past the 50th?

Posted: 11/5/2020 10:11 PM

Quote

nim

He/Him

Joined: 11/5/2020
Posts: 8

The upwarp video you posted in a romhack is completely irrelevant because that upwarp was programmed in intentionally by the romhack creator to prevent softlocks. There is no known upwarp method in vanilla SM64 besides the hanging ceiling and water upwarps, and no upwarp glitch in a romhack has ever been found to be present in the vanilla game.

Posted: 11/5/2020 10:13 PM

Quote

nim

He/Him

Joined: 11/5/2020
Posts: 8

Also, trying to replicate frames is kind of pointless because small variations in joystick inputs are often much smaller than a single pixel. Combined with DOTA's low stream quality, it makes it mostly impossible to conclusively determine exactly what DOTA inputted and exactly where the upwarp occurred.

Posted: 11/5/2020 10:16 PM

Quote

XkyRauh

He/Him

Joined: 6/9/2005
Posts: 171
Location: Southern California

I wonder if the timing of the glitches coincides with the loop of the slow/medium/fast timing of TTC with moving parts? Like, does the code that freezes TTC simply set the loop to a freakishly long time, set it to 0, or otherwise screw with the timing of said loop in another way?

Posted: 11/5/2020 10:32 PM

Quote

Ramzi

Joined: 3/25/2004
Posts: 459

> The upwarp video you posted in a romhack is completely irrelevant because that upwarp was programmed in intentionally by the romhack creator to prevent softlocks Can you explain this a bit more? What causes the softlock, and why would an upwarp be the mechanism to fix it? And does that method of softlocking occur in vanilla, even if a level editor was used to create a custom environment to allow it? > Also, trying to replicate frames is kind of pointless because small variations in joystick inputs are often much smaller than a single pixel. Combined with DOTA's low stream quality, it makes it mostly impossible to conclusively determine exactly what DOTA inputted and exactly where the upwarp occurred. I'm thinking that the input doesn't need to be EXACT to replicate it, just close enough. Also, how many "analog" inputs are inputtable? My idea of the genetic algorithm on the "matching" inputs would test precisely this. Since there may be multiple inputs which produce identical or near-identical frames, some kind of intelligent search on those inputs might yield a result or a set of results which replicate the glitch.

Posted: 11/6/2020 12:01 AM

Quote

Really_Tall

She/Her

Editor, Player (184)

Joined: 9/29/2014
Posts: 122
Location: Scotland

Ramzi, this has been researched for five years, and the entire game has been decompiled in that time. Everything you can think of has likely been tested extensively. I'd strongly suggest joining the SM64 server (which has a channel specicially for this topic) if you want to discuss this further, because arguing with the experts here is going to get absolutely nowhere. https://discord.gg/ECskvyF

YouTube: https://www.youtube.com/Really_Tall Twitter: https://twitter.com/Really_Tall Discord: Really_Tall

Posted: 11/6/2020 2:21 AM

Quote

Ramzi

Joined: 3/25/2004
Posts: 459

I am a member of these forums, but I'm not a member of Discord. I'm conversing and asking questions. You say "arguing" as if it were a hostile activity, but I'm merely trying to collaborate. I'm not trying to act like I know better than experts, but I am a computer programmer, and in my experience programs can give very surprising output even for simple programs which I wrote in their entirety. It is not obvious from code alone what output can occur. Game companies have game testers because they find glitches which occur with elaborate setups, which the developers couldn't anticipate from unit tests alone. Do you think things like the bottle glitch in Ocarina of Time, door warping in GoldenEye, fast pauses in GoldenEye, screen warping in the 2D Zeldas, or sliding through walls in the Super Mario Bros. 1 and 3 could have been anticipated through code alone, even if the original source code was available? Do you think something like a Glider in Game of Life could have been anticipated from the simple functions that comprise Game of Life alone? You say everything I can think of has likely been tested extensively, but from what I've been made aware of, only the first 50 frames have been faithfully reproduced, and I haven't been told that more frames have been reproduced. I have read that exhaustive fuzz testing has been applied without success, but that doesn't clearly tell me that the rest of the frames were reproduced. If this problem hasn't been solved in 5 years, then progress on it is going nowhere regardless of what medium conversation about it is held in. I'm asking the same questions here as I would there, for anyone who would want to answer them here. I haven't been bolding asserting, "The number of analog inputs is small enough to brute force!" or, "A genetic algorithm will solve it!" I have been asking questions like, "How many possible analog inputs are there per frame?" and, "Would a genetic algorithm be a novel approach to this problem?"

Posted: 11/6/2020 2:32 AM

Quote

Bloopiero

Any

Active player (368)

Joined: 1/9/2017
Posts: 56
Location: Bothell, WA

If this problem hasn't been solved in 5 years, then progress on it is going nowhere regardless of what medium conversation about it is held in. I'm asking the same questions here as I would there, for anyone who would want to answer them here.

All this seems to be saying is that you don't actually care about getting the answers. If you want to discuss this with the people who can go in-depth on these things, then the sm64 discord is where you need to go, because relatively few of those people are here. You're being redirected there for a reason.

Whale eat again

Posted: 11/6/2020 3:04 AM

Quote

Xander

He/Him

Joined: 12/31/2016
Posts: 17
Location: Canada

Ramzi wrote:

I'm conversing and asking questions. You say "arguing" as if it were a hostile activity, but I'm merely trying to collaborate.

Arguments do not have to be hostile. We are supporting claims with evidence and you are disregarding them. We are trying to help you understand the situation and collaborate as well.

Ramzi wrote:

Do you think things like the bottle glitch in Ocarina of Time, door warping in GoldenEye, fast pauses in GoldenEye, screen warping in the 2D Zeldas, or sliding through walls in the Super Mario Bros. 1 and 3 could have been anticipated through code alone, even if the original source code was available?

Quite frankly, yes. I think that is the general consensus from everyone except you. This is what we are trying to explain but you keep waving it off by saying "but how can you know?" As a programmer you should understand that you can look at code and walk through it to see errors / unintended side effects. I appreciate the enthusiasm for this, and by all means try what you're trying for fun, but do not expect it to work. Here's some info that might be of use: Mario can face 65536 angles, high and low magnitudes will make a difference. This is a miniscule amount of info compared to what is available on Discord.

Ramzi wrote:

Can you explain this a bit more? What causes the softlock, and why would an upwarp be the mechanism to fix it? And does that method of softlocking occur in vanilla, even if a level editor was used to create a custom environment to allow it?

The video you linked is on a ROM Hack. The creator of that ROM Hack programmed it so that if you get stuck in a squish it will teleport Mario up to get him out of the softlock. This will never happen in the vanilla game.

Super Mario Galaxy/64 TASer

Posted: 11/6/2020 4:15 AM

Quote

nim

He/Him

Joined: 11/5/2020
Posts: 8

> Mario can face 65536 angles, high and low magnitudes will make a difference. This is a miniscule amount of info compared to what is available on Discord. (fwiw: while technically true, there are practically only 4096 angles because trig functions in sm64 round to the nearest multiple of 16. also, on a given frame, fewer than 4096 angles are achievable because joystick resolution can often not be enough to reach a given angle, necessitating camera rotations to actually reach all 4096)

Posted: 11/6/2020 4:23 AM

Quote

nim

He/Him

Joined: 11/5/2020
Posts: 8

This is unrelated to the current conversation, but...

Personman wrote:

So I was reading this neat article about someone who found a remote execution vulnerability in Morita Shogi 64, and it contains this intriguing paragraph:
For example, Super Mario 64 is fully decompiled so I took a quick look and was able to find a write to an out of bounds pointer if sSoundMode (offset 0x1d1, 1 byte) is too large, which can be triggered by pressing the sound option box on the file select screen. That can be used to NOP out some code in the title screen renderer, but I gave up trying to exploit that - maybe someone reading will be interested in the challenge... if you could do it, you could potentially make a payload that patches Mario's colour to green to 'unlock Luigi' on a real cartridge, a feat people have been attempting since its release in 1996!
I have no idea if this will actually turn out to be exploitable, but it seems like folks here ought to be made aware of it..

I read this article too, and I took a look at how exploitable this might be across the 3 main versions of SM64, and it's not very feasible. You can't actually NOP out any code like he said, and I think the best you could do would be to crash the game or *maybe* mess up some models in star select. Even if I'm totally wrong, that entire code segment is unloaded when you exit the menu, so...

Posted: 11/6/2020 8:29 AM

Quote

jongyon7192p

Joined: 8/13/2014
Posts: 14

> You say "arguing" as if it were a hostile activity, It kind of was since the beginning, wasn't it... I've been in the sm64 community for 4 years now. I made friends, and I just wish nobody insult my friends. This community existed since the gamefaqs days. I know they're good people, I wish nobody mischaracterizes them. That's all, that's why.

Posted: 5/5/2021 3:38 AM

Quote

Patashu

He/Him

Joined: 10/2/2005
Posts: 4042

New big any% timesave Link to video

My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu

Posted: 5/17/2021 9:44 PM

Quote

Patashu

He/Him

Joined: 10/2/2005
Posts: 4042

Finally after 2 years, ABC any% gets one step closer to being solved: Link to video If you're wondering why it took so long and still isn't done, it's terifyingly hard, but theoretically possible: https://pastebin.com/TiCGb954

Posted: 5/17/2021 10:59 PM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3809)

Joined: 11/30/2014
Posts: 2828
Location: US

Woah, any% time save and 0xA progress only days apart, incredible.

Posted: 6/1/2021 10:49 PM

Quote

FractalFusion

Editor, Expert player (2072)

Joined: 6/15/2005
Posts: 3282

Saw the any% time save in this video (go to 6:50): Link to video The video talks about TAS for around 30 seconds starting at 6:50.

Posted: 6/2/2021 4:32 AM

Quote

Synx

Joined: 3/17/2009
Posts: 496

FractalFusion wrote:

Saw the any% time save in this video (go to 6:50): Link to video The video talks about TAS for around 30 seconds starting at 6:50.

Nice catch! This should save time over the published tas

Posted: 6/2/2021 6:36 PM

Quote

TheKDX7

He/Him

Player (118)

Joined: 7/9/2011
Posts: 392
Location: Switzerland

Synx wrote:

FractalFusion wrote:
Saw the any% time save in this video (go to 6:50): Link to video The video talks about TAS for around 30 seconds starting at 6:50.
Nice catch! This should save time over the published tas

This is the same time saver as the video Patashu posted in the discussion thread above.

Posted: 10/4/2021 2:33 AM

Post subject: New clip discovered in DDD

Quote

DruidVorse

He/Him

Joined: 2/1/2016
Posts: 18
Location: Argentina

https://twitter.com/ChipGroove64/status/1444536128569282561?s=19 Link to video

Posted: 10/4/2021 12:16 PM

Post subject: Re: New clip discovered in DDD

Quote

Patashu

He/Him

Joined: 10/2/2005
Posts: 4042

DruidVorse wrote:

https://twitter.com/ChipGroove64/status/1444536128569282561?s=19 Link to video

I was surprised to find out this was new, because I thought it was already in the SM64 120 star TAS, and it... kind of is? https://www.youtube.com/watch?v=xL6VE_5PddM&t=20m03s Same kind of glitch, but in a different position. This new place to do it looks like it's never been done before, after all? Surprising but exciting!

Posted: 10/27/2021 5:27 PM

Quote

Synx

Joined: 3/17/2009
Posts: 496

https://www.youtube.com/watch?v=fByjyOR0KSU One of the top RTA runners, previous WR holder reacting to the old 120 TAS :D I found this pretty cool!

Posted: 1/5/2023 12:24 AM
(Edited: 1/5/2023 12:30 AM)

Post subject: TASing in mobile

Quote

TAS_Quicker

He/Him

Joined: 12/21/2022
Posts: 4
Location: Brasil , RJ

Q: TASing on mobile is possible? A: Yes! But not be happy because is very hard to do this any N64 EMULATOR for mobile or iphone. Any mobile emulator don't have movie to record any moviment u need a download any Recorder to record your emulator, thats not easy to make u need 100 or 200 retryies but u want try good luck Have nice day/night!!

New TASer?

Posted: 1/22/2023 10:00 PM

Quote