I'm gonna go against what some of the other have said and say, yes, I found this run very entertaining. Watching the game be completed literally within a second of the console turning on is absolutely hilarious, and everyone I show this to (who isn't a member here) seems to agree. This run is so uniquely absurd, just leaving in vault would be a terrible choice in my opinion.
Having it obsolete the current "Game End Glitch" would suck though. I would rather advocate for a new category, as arbitrary as it may be now. But I would also err towards what dwangoAC said on the matter.
Haven't recorded one of these in a while. I noticed that no one did the last one and I thought it was worth keeping the current SMB runs console verified.
Link to video
This was a SMB+Duck Hunt cart, if you're wondering what that beep at the beginning was.
When the original 1/0 star routes were discovered, seeing how time was being saved just by BLJing in weird spots, I always thought "I bet you could use the moat door if you just BLJ outside".
Apparently it was 50x more complicated than just that, but you essentially made my dreams come true.
I won't be making it a YouTube module, so bare with me here on how I'm going to explain it.
First Semi-TAS that was created, by using a special name in the name field.
I'm pretty sure that was just done by using the slowdown feature in Cheat Engine. Still no input taken while running through Hourglass.
Did a console-verification recording real quick. Quality isn't great, sorry about that, but you get the idea.
Thank you very much for taking this on! I was unable to finish setting up audio before I had to leave on a business trip. It's good to see other people involved in console verification.
(As an aside, I did not mean any insult to the other authors of the run, I just typed Masterjun's name out of habit - congrats to *all* the authors. :)
I was just happy to see a single-controller Super Mario World TAS that's actually verifiable. Been a while since I could verify something new and cool.
Here is how the desync looks when there are no input modifications:
Link to video
Looks identical to my old video.
Link to video
The link to Exodus is dead. Last I remember, the dev kept debating on how to license his code if he open-sourced.
I've talked about this in the IRC before, but I've found you can sort-of get around the desyncs in Sonic 2 by pausing the game until the universal timer (which controls the flippers on Chemical Plant Zone, amongst various other events) resyncs to what it was on emu. I believe the additional lag introduced on console causes the timer to differ than what it was on emulator, thus when it reaches the boss on CP Act 2, the panels are in a completely different position than what they should be.
I tried S3&K on my setup once, never could get very far there.
You're a hell of a man delving into the Genesis like this.
I can confirm it runs just fine after resyncing to the Mario + Duck Hunt cart. It would take a while for me to actually be able to upload any sort of video though.
So I made an interesting discovery on the Genesis side of thing. There's an updated Genesis core in one of the recent Bizhawk Betas, using GenesisPlusGX, that's apparently more accurate than Gens, so I decided to test things out by trying to sync the Sonic 2 run I tried to console-sync a while back. I used a lua script that can play the lag-frame stripped files I used on the verifier bot on Bizhawk. The result is that it basically syncs until the same general point in de-syncs on console, just not the same exact way.
http://i.imgur.com/gkN7OFZ.pngIt's those stupid panels on the floor again. There's also a few more lag frames in Bizhawk, one of them originating from before the title screen. I noted that I thought the console was lagging a lot more at a certain point in Chemical plant than Gens was, and that's the same place where it lagged additionally in Bizhawk. (Screenshot of around where that was).
Speaking of Arduinos, I've always wondered how these guys made an N64 bot with an Arduino Uno. The N64's controller protocol is much more complicated then the NES/SNES/Genesis', so I never really bothered trying myself.
I just recently completed this exact thing. As long as you use inline assembly, it's totally within reach. The protocol happens at 1 MHz (sub-bit are sent at 1us intervals), and the Uno has a 16 MHz processor, so you get 16 cycles between sub-bits.
Since most instructions take 1 cycle (except for some branching or larger arithmetic instructions), you have "plenty" of time to do any work you need. Most of the assembly consists of wait loops to make sure the timing is okay.
(Doing it with interrupts is out of the question, the latency from receiving an external interrupts to actually running code is too great.)
Oh, neat. I've only dealt with a tiny bit of inline assembly with arduino myself. Do you mind sharing the code?
Which bot? My bot, the Arduino NESBot design or a custom bot?
It's a custom one I made for both NES and SNES, but I'd guess it's quite similar to already existing designs. I'm just using an Arduino Uno and CD4021 shift-registers and then sending the controller data over serial in realtime to it.
Probably one of the easier bots to make considering the simplicity of working with an Adruino. Same basic design for an SNES bot, just more pins and an extra 4021 needed. I actually went and tried to verify some NES runs on a friends NES once with my SNES Arduino design, but the games they had besides Super Mario Bros weren't syncing out of the get-go (including Tetris, which I'm not sure why that is, but I wasn't about to waste my time on it). Awesome job getting a few more games verified by the way!
Speaking of Arduinos, I've always wondered how these guys made an N64 bot with an Arduino Uno. The N64's controller protocol is much more complicated then the NES/SNES/Genesis', so I never really bothered trying myself.
http://tasvideos.org/795M.htmlhttp://tasvideos.org/1713M.html
These two are the only "complete" runs I've ever sucessfully verified and the first one required modifications to resync. I don't have much faith in many other Genesis games until a much more accurate emulator is suddenly created and adapted.
Out of idle curiosity: when you tried to verify the Genesis movies, did you try passing the movies through a script of one sort of another to remove lag frames from the input file? I ask because the GMV keeps input in lag frames, and this could cause additional problems when trying to verify the run.
Something tells me you were already aware of this and had already dealt with it, but it doesn't hurt to ask to be sure...
Yes, they were passed through a lua script to create a new input file sans lag frames.
GhostSonic's previous attempts have shown that the Genesis emulator used for TASing is not very accurate, so genesis verifications will be difficult to do (about equal in difficulty to verifying a SNES TAS not made with Bizhawk/bsnes)
http://tasvideos.org/795M.htmlhttp://tasvideos.org/1713M.html
These two are the only "complete" runs I've ever sucessfully verified and the first one required modifications to resync. I don't have much faith in many other Genesis games until a much more accurate emulator is suddenly created and adapted.
Tested with modified bsnes core (more accurate emulation of autopolling). Works fine.
You think there's a chance of this being console verifiable then? I don't currently own Yoshi's Island so I can't test it at the moment. I wonder if the bsnes core emulates the Super FX 2 accurately enough to work properly. I remember the old run not syncing at all on newer version of Bizhawk and lsnes.
It just a marketing strategy for them as in "our product does better".
Sony ads says "It only does everything" for PS3, it doesn't do PS2, install other OS anymore.
To be fair, having the hardware for backwards compatibility was (apparently) causing the unsavory price for the PS3 early in its lifespan. There's no shortage of PS2s at least, considering that it's the most sold console of all time.
TH
EN
close enough for me.
10/10 Background could be bluer.
Yes vote of course.
