If you'd like to have your videos used as verifications on site, please start recording right before you turn on the console (Avoid talking please), and record until the credits finish running. If you have a tripod, this could help a lot. If you do this for all of the SM64 runs, obsolete and current, you will be my hero.
I was talking to show it was legit and show my design. I'll eventually get around to recording a good quality video, too. Any why would I verify obsolete SM64 TASes? That's rather unnecessary. Besides, I got the (relatively old) 120star run to sync just fine; I am 100% certain the other old TASes will also.
Btw, my design is so strange and twisted, no one will ever be able to understand or reverse engineer what I did. If there is a free blog or something I can sign up for, I can put my code and design materials online for everyone to see. Just know if you want to try to verify things yourself, you'll need about $350 worth of software and hardware.
This is unexpected and awesome news. I'm hoping for there to be Genesis/Mega Drive verifications sometime in the near future. Go forth and conquer, you bot making people!
Don't get me wrong, the current runs take priority, and you should verify those first. If you have other games you could verify, do the current ones for those first as well. However, once that is done, you should also do the obsolete runs because it will increase the number of runs on the site that are verified. We currently have about 2% of the site validated. Imagine how nice it would look for the site if we could put on the front page "We have been able to play back 50% of our runs on the original consoles. Our technology owns hundreds of world records!"
Btw, my design is so strange and twisted, no one will ever be able to understand or reverse engineer what I did. If there is a free blog or something I can sign up for, I can put my code and design materials online for everyone to see. Just know if you want to try to verify things yourself, you'll need about $350 worth of software and hardware.
There are several, plus free Google Code / Github accounts.
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Brandon wrote:
If you'd like to have your videos used as verifications on site[...]
I feel compelled to dispel the notion that we have formal standards on what should and shouldn't be in a verification video - we don't. (I think we can at least agree that the console actually needs to be shown in the video and that the run needs to be completed, though.)
Wait... it looks highly doubtful to me that you managed to make this run syncs on a real N64. There are a lot of lag differences between a real N64 and Mupen64, especially in Super Mario 64.
Also, how in hell would you get the same exact RNG when playing back the "120 stars" run? Really, really inconceivable...
Wait... it looks highly doubtful to me that you managed to make this run syncs on a real N64. There are a lot of lag differences between a real N64 and Mupen64, especially in Super Mario 64.
Also, how in hell would you get the same exact RNG when playing back the "120 stars" run? Really, really inconceivable...
My guesses as the answers to these questions: it's possible to detect if the console is lagging by monitoring the voltage input to the controller (so the N64bot can automatically adjust for Mupen being wrong about what the lag actually is), and that the RNG is reset to a constant value at power-on (with the problems matching up the RNG only happening when hexing during a run, because obviously TASes don't battery-save and reset the console). I don't know for certain, though.
Wait... it looks highly doubtful to me that you managed to make this run syncs on a real N64. There are a lot of lag differences between a real N64 and Mupen64, especially in Super Mario 64.
Also, how in hell would you get the same exact RNG when playing back the "120 stars" run? Really, really inconceivable...
Input is polled seperately for SM64 unlike say OoT or any game on an older console. As for the RNG its always starts at the same value when the power is switched on, which probably won't be the case for CD based games. When the guy played back SMB3 on console earlier this year, I believe he wrote a program that would ignore lag when playing it back.
My guesses as the answers to these questions: it's possible to detect if the console is lagging by monitoring the voltage input to the controller (so the N64bot can automatically adjust for Mupen being wrong about what the lag actually is), and that the RNG is reset to a constant value at power-on (with the problems matching up the RNG only happening when hexing during a run, because obviously TASes don't battery-save and reset the console). I don't know for certain, though.
You could just ask how I did it. :). It is actually 10x simpler than that; I don't even have a lag counter, in fact it never crossed my mind why I would need one. I'm just sending a new frame of commands every time the n64 asks for it. The only connection between my processor and the n64 is a wire that sends a pulse saying 'I'm ready for new controller stuff.' However I did have to modify the hell out of the m64 to play it back right, but all frame and button data is the exact same (just some formatting). And N64bot sounds a little bland. My suggestion is the Droid64.
And boom goes the TNT.
Link to video
If you'd like to have your videos used as verifications on site[...]
I feel compelled to dispel the notion that we have formal standards on what should and shouldn't be in a verification video - we don't. (I think we can at least agree that the console actually needs to be shown in the video and that the run needs to be completed, though.)
I feel compelled to show the console and walk around the TV to show nothing else is connected. I also like to talk a little about it and explain what it is (some of my YouTube subscribers thought I programmed an AI to play, or it was actually me.) I'm currently recording the 120star TAS btw.
If you'd like to have your videos used as verifications on site[...]
I feel compelled to dispel the notion that we have formal standards on what should and shouldn't be in a verification video - we don't. (I think we can at least agree that the console actually needs to be shown in the video and that the run needs to be completed, though.)
I feel compelled to show the console and walk around the TV to show nothing else is connected. I also like to talk a little about it and explain what it is (some of my YouTube subscribers thought I programmed an AI to play, or it was actually me.) I'm currently recording the 120star TAS btw.
You'll note that SM64 has already been set to console verified. However, I would like to see the technical write-up for this. It would help if we could make it cheaper and easier to reproduce.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
As for a place to host your src, we already have a repository for console verification related code: http://code.google.com/p/console-tas/
I would happy to add you as member so you can check in your code, I would just need a google account email.
Just wow. I didnt think this was possible with the way people were saying how inacurate mupen was. While you did have to modify the file for it to play properly, it still prove that the glitches/shortcut used are valid, and that if mupen 64 was fully accurate, that the run would be 100% verifiable. Great work. Did not expect that.
While you did have to modify the file for it to play properly, it still prove that the glitches/shortcut used are valid, and that if mupen 64 was fully accurate, that the run would be 100% verifiable.
I interpreted the statement about conversion differently:
N64Bot (or Droid64) can't directly read .m64s, so SoulCal apparently took the .m64 file and converted it to whatever format N64Bot/Droid64 reads (most likely raw binary dump to be sent to N64 according to clocking).
There is only one possible result for such conversion for each .m64.
Sometimes extra frames are inserted to fix sync problems (sometimes that helps) but it doesn't sound SoulCal needed to do that here.
Due to nature of .m64 format, what wasn't validated here is correctness of lag on Mupen64.
While you did have to modify the file for it to play properly, it still prove that the glitches/shortcut used are valid, and that if mupen 64 was fully accurate, that the run would be 100% verifiable.
I interpreted the statement about conversion differently:
N64Bot (or Droid64) can't directly read .m64s, so SoulCal apparently took the .m64 file and converted it to whatever format N64Bot/Droid64 reads (most likely raw binary dump to be sent to N64 according to clocking).
There is only one possible result for such conversion for each .m64.
Sometimes extra frames are inserted to fix sync problems (sometimes that helps) but it doesn't sound SoulCal needed to do that here.
Due to nature of .m64 format, what wasn't validated here is correctness of lag on Mupen64.
If that is the case, then that's even better. But he did say "However I did have to modify the HELL out of the m64 to play it back right, but all frame and button data is the exact same (just some formatting)." So to me it somewhat sounds like he had to insert a bunch of blank frame here and there, but I am most likely wrong, and like your answer much better!
I would have never believed that a tasbot could be built for such a modern console as the N64. It's awesome.
Of course the little skeptic in me always makes be slightly cautious. After all, believing in the veracity of the video is a question of trusting the person who made it. Basically the only way to make absolutely sure that the video is legit is for an admin or a trusted contributor/member of the site to either go there in person and verify it, or build the device himself and test it.
I would have never believed that a tasbot could be built for such a modern console as the N64. It's awesome.
Of course the little skeptic in me always makes be slightly cautious. After all, believing in the veracity of the video is a question of trusting the person who made it. Basically the only way to make absolutely sure that the video is legit is for an admin or a trusted contributor/member of the site to either go there in person and verify it, or build the device himself and test it.
If my project is a shame, I should get an award for "biggest trollolol ever!" But seriously, I actually did this as my graduation project at Texas Tech University. I will try and set up a blog or something of the sort and reveal all my research materials, since I was required to keep a notebook of everything to begin with as per the class expectations.