Hey GhostSonic. Do you happen to own a copy of Earthbound? I would love to see this run on console. :)
I really want EarthBound considering it's one of my favorite games ever, but the cost of a copy is way too expensive nowadays. Also that run is made Snes9x. I wonder if it'd be possible on lsnes.
Hey GhostSonic. Do you happen to own a copy of Earthbound? I would love to see this run on console. :)
I really want EarthBound considering it's one of my favorite games ever, but the cost of a copy is way too expensive nowadays. Also that run is made Snes9x. I wonder if it'd be possible on lsnes.
You can get a snes powerpak for less then the price of one Earthbound cart. Unsure how feasible/easy it would be to modify its Menu/Bios to auto-load a rom instead of showing a menu, and maybe clearing ram upon load to prevent desynch due to unclean ram.
Hell, might be possible to automatically "pause" the game after its done loading, until your SNES bot feeds it some data, maybe a standard set of keypress saying "I'm starting the movie now, let the game run"
I'm not educated in such thing, so all of this might be impossible.
Finally managed to replay the recent Super Mario World run on a console. Apparently bsnes isn't 100% accurate so a slight change had to be made to the input sequence at the very end in order to sync properly on console. It's still the same exact amount of frames (5994), syncs on both bsnes and console, and is visually identical to the published run.
Link to video
Finally managed to replay the recent Super Mario World run on a console. Apparently bsnes isn't 100% accurate so a slight change had to be made to the input sequence at the very end in order to sync properly on console. It's still the same exact amount of frames (5994), syncs on both bsnes and console, and is visually identical to the published run.
<Video>
1. You got a multi-tap/fourscore/the multiplayer extension just for this? That's really nice of you. :)
2. Same amount of frames with only changes to the input at the very end? That's quite lucky. :P
1. You got a multi-tap/fourscore/the multiplayer extension just for this? That's really nice of you. :)
I was able to do this without the multi-tap, I just had the data-out for two of the shift registers connected to the secondary data pin of the controller ports since Super Mario World doesn't actually do the necessary stuff to read from the other two possible controllers on the multi-tap.
Will people still insist that the PUBLISHED version was not verified and the flag can't be set? Because for that flag we would need to replace the published movie which is stupid. The whole concept is verified, it only required minimal tweaks due to inaccuracy of the most accurate emulator in history.
I would set the flag, but what do others think now?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
If there is no difference in frame-count, maybe the published movie-file can be replaced with the one that works on console? If possible it would at least make me feel better about the Verified-tag.
If there is no difference in frame-count, maybe the published movie-file can be replaced with the one that works on console? If possible it would at least make me feel better about the Verified-tag.
But then it wouldn't work in bsnes, would it? (I understand that bsnes and console are currently different in how they emulate this. Once a new version comes out that reconciles this there won't be a problem.)
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Patashu wrote:
Warepire wrote:
If there is no difference in frame-count, maybe the published movie-file can be replaced with the one that works on console? If possible it would at least make me feel better about the Verified-tag.
But then it wouldn't work in bsnes, would it? (I understand that bsnes and console are currently different in how they emulate this. Once a new version comes out that reconciles this there won't be a problem.)
GhostSonic wrote:
Finally managed to replay the recent Super Mario World run on a console. Apparently bsnes isn't 100% accurate so a slight change had to be made to the input sequence at the very end in order to sync properly on console. It's still the same exact amount of frames (5994), syncs on both bsnes and console, and is visually identical to the published run.
It syncs in lsnes, both with standard bsnes controller timings and experimential controller timings I whipped up based on poll test video on real SNES (those new timings still need some adjustment, but look to be quite near correct).
The old movie failed on both real SNES and with the experimential timings.
The changes in timings:
- VBlank detection is done at cycle 0 (old) -> -128 (new)
- Autopoll busy is set at cycle 0 (both)
- Controllers are latched at cycle 0 (both)
- Controllers are unlatched at cycle 0 (old) -> 256 (new)
- Registers are not cleared (old) -> registers are cleared at cycle 0 (new).
- Registers are shifted left with read bit shifted in on cycles 0,256,512,...,3840 (old) -> 384, 640,...,4224 (new).
- Autopoll busy is cleared at cycle 3840 (old) -> 4224 (new).
Negative VBlank detection cycle means that VBlank must have been raised that much before normal autopoll time for autopoll to start.
What is not emulated:
- The times things become visible can be off by a few cycles.
- "Glitching" is not emulated, that is, incorrect values returned by registers (e.g. 0080 to 0100 shift reading 0180 for few cycles).
That it syncs on lsnes isn't surprising, given that the new movie avoids reading autopoller registers during poll active. The hardware is a lot less forgiving on that.
Oh, I determined that the old and new video when dumped from lsnes differ in 3 frames...
Finally managed to replay the recent Super Mario World run on a console. Apparently bsnes isn't 100% accurate so a slight change had to be made to the input sequence at the very end in order to sync properly on console. It's still the same exact amount of frames (5994), syncs on both bsnes and console, and is visually identical to the published run.
http://www.youtube.com/watch?v=yGFimiKRTII
This is one of the best things I have ever seen! Way to freakin' go!
I think next time you should switch the autofocus of the camera off. The constant change in focus is quite annoying.
I just figured out how to actually stop the autofocus on my S4 after I recorded that. I kind of want to rerecord the SMW video because of how bad the autofocus was acting during it.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Here is someone talking about Gamecube recording inputs from the controller, he also talks about Dolphin and TAS. His device uses an Arudino.
http://www.youtube.com/watch?v=7CWMi5M5GFY
OK, so I've console verified Zelda and Rockman 2 on NES, two games that people were thinking wouldn't be verifiable.
What about other games?
Also, I don't have other games. I do have dozens of EPROMs. Anyone have games or donor carts I can verify with? :(
