Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Emulation inaccuracy causes deterministic desync at the first underground area. Tested with RAM reset to FCEUX pattern and it does the same thing. BizHawk acts similarly to FCEUX at least up to a little past this area. This game uses no mapper hardware. All known variables have been made constant or have otherwise been tested; seems like emulation inaccuracy.
I will record a video capture of this when I get my capture card in so it can be frame-compared with the run. If someone has time maybe this emulation problem can be fixed and a run created/updated to get this game to sync.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I could win auction, convert BTC, etc...
I can pay it if it is cheap and you trust the person to send it. China sellers can ship cheap, don't know about RU shipping.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
TheAxeMan wrote:
true wrote:
This matches exactly the FM2.
I guess I should have said that it doesn't match FCEUX. When you play a movie back on the emulator with the input display on it shows the input frame by frame regardless of controller polling. I don't question the accuracy and obviously the result is the same. It's just that the conversion from frame-based to poll-based input makes it look different.
Not at all. I dumped by frames.
The bot has no idea what a "frame" is and only knows what is polled. (My old bot tried to guess but did a shit job at it, so I dropped it.) Thus, it can't know there is deadtime unless I program in fake deadtime. But if I do that, then the button is hardly lit, which makes it less visible. So why do that?
One could autofire in that time. It doesn't matter. The console never sees it. And I give a shit less about matching FCEUX; FCEUX should match the NES. If anything, consider anything shown on unpolled input frames a meaningless artistic show.
TheAxeMan wrote:
true wrote:
Did you change it after it was submitted?
There have been no changes since I submitted but there have been since I sent you the first full fm2. I changed it so that I run from the first battle, saving a couple minutes. The encode in one of the first few posts has the right movie.
I was pretty sure I downloaded this one. I guess my surety doesn't matter. Oh well, it can be redone and the video updated if necessary. This is >99.6% identical right now anyway.
Catastrophe wrote:
In the case of submission 3389 (Pokemon Yellow) the new submission was merely a resynch. Masterjun even said that the strategy was the same. He just re-executed the same run on a more accurate emulator. He did no original work.
That was an emulator-to-emulator resync. This is an emulator-to-console resync, which has a completely different purpose. After all, we try to TAS games here, not their emulators. Any further provided reasoning is less important than this reason alone, or serves to back up this point.
Catastrophe wrote:
This submission is passively saying that most reset button use is inaccurate or at least inaccurately timed.
This isn't saying this passively or actively. What is being said is that a run with resets cannot be run in real-time in the amount of time shown on-site. There is no exception or corner case.
Once a bot supports resets, using them may or may not be deterministic. This is what we don't know right now.
Catastrophe wrote:
(I don't know what a fair reset is, but magically zeroing out all the RAM in one frame is unfair.)
I know you weren't saying this, but as it could be misread this way, let me state: Resets do not clear memory. Power cycle / POR will typically have most/all console memory cleared. Resets jump code to the reset vector. POR is also at the reset vector. Power cycle is instant in an emulator, but will take some seconds to hours on a console. Reset, done physically, is also likely to take some physical time to do, which can vary.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I want to start on this game, but also don't. So I need some help.
The biggest reason I would want to complete this game, other than this game being an amazing work of art, would be to console verify a TAS of it. And to console verify it, I need the game.
Well it's $20 on eBay and not particularly uncommon so might go fo around that. Want to help me get it? Because I don't want to pay for this masterpiece. http://www.ebay.com/itm/yup_somari_woot/171518802091
If I get Somari (I will come up with the famicom adapter somehow) I will TAS this game, then verify the TAS. A game this glorious deserves no less.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
My latest bot supports as many players as can fit with the inputs I have. In practice, this will mean 4 controllers for N64, 8 (multiplexed) controllers for SNES, ...
However, different consoles have different clock skew, so even if turned on at exactly the same time, will drift. Why not just use multiple bots then? Well, yeah, multiple bots would be used in that case.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
MESHUGGAH wrote:
True wrote:
I'm sorry; what? If you know something about my bots (that everyone calls TASbot now) that I don't I'd like to know?
That was the name for AGDQ 2014 as the runner name. After that, everywhere it was noted as TAS Bot (youtube, the news, twitch chat, reddit etc).
Also note that tom7's playfun which demonstrated at April 2013 also called as tasbot in the trunk (a bot that learns through playing and watching memory)
Probably that's why everyone refer to "TASbot" or platform+bot to devices that either replay or play a game on it's own. Misconceptions.
You must have replied to the wrong thing, because my reply there was in response to someone telling me that my bot is not reliable enough, and not expressing why. Nothing ever came of it, as expected. I don't know what your response has to do with this now that hasn't already otherwise been discussed in this short thread.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
TheAxeMan wrote:
Nice! The explanation of the erasing process in the beginning is good. The controller visualization is nice. Looks like it holds the buttons through lag frames so it doesn't exactly match the fm2.
This matches exactly the FM2. It doesn't matter what is done with the button until it is polled for, so it is "pressed" before it is polled. The NES asks the controller what button is being pressed and the controller responds; the controller cannot interrupt the NES and force it data. As Final Fantasy polls so infrequently it looks to be "holding." It is completely accurate here.
TheAxeMan wrote:
Also, it looks like you are using the generated result (that we ran earlier right when I finished). I changed the submitted fm2 to run from the first fight, saving a couple minutes.
I ran the original posted movie. Did you change it after it was submitted?
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
creaothceann wrote:
True wrote:
I don't have access to this game, nor do I have a donor cart yet :(
Aren't there flash (?) cards where you just have to copy the ROMs from your PC over? Then you just need e.g. the No-Intro set.
Perhaps, but that is not similar to original hardware. Most also have some kind of loaders, have loading delays to load from SD into SRAM, or other code that executes. I need the cart to be as close to original as possible for verification to be considered authentic. (That doesn't mean that others wouldn't be helpful, but at that point it is not verifying the game as it was originally on the console...)
That's also more money to spend and I'm tired of spending money on this hobby.
I have a 32mbit EEPROM and a conversion board to change the pinout to SNES mode. What I need to do is change the pinout again to a standard EEPROM pinout to program it, and use a donor cart. In this case, a battery backed cart with SRAM is needed, and I don't have that.
I also don't know what cart types there are for SNES, other than DSP types of course, or if it makes a difference. At least there isn't the mapper mess like there is on NES.
About this run: is it likely SoE has the glitch (probably not)? I have access to that :)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
feos wrote:
dwangoAC wrote:
after a fair bit of twiddling I was able to get the movie file to console verify.
Oh god can you make a video?!
Otherwise, is there a possibility to strip lag frames out of the verification movie and make it feed input only when there's a poll?
AFAIK SGB uses AutoPoll and thus it doesn't matter if it is frame-based or latch-based input, the input will be the same.
This also means SGB can have input skew from console input. Basically, GBx runs in SGB mode need to be done more accurately for verification to happen.
dwangoAC wrote:
I'll edit my post to clarify that I only got up to the point where FractalFusion tries to save the game, as any further would require an extremely accurate reset solenoid.
A reset save run will not happen with a solenoid. As in, yes, it may happen eventually, but it won't work for marathon presentation. Guaranteed. It's too slow and timing is not exact (it's a physical device moving through air to press a lever to press a switch...)
dwangoAC wrote:
So, I stopped right before saving, which has been good enough to prove what I feared - that SGB emulation accuracy inside of lsnes isn't accurate enough.
Yes, this was known...just have hard proof now I guess?
dwangoAC wrote:
One interesting experiment would be to have someone do the exact same thing with Gambatte (or the BizHawk core) so we can count frames during the transitions and see how far off SGB emulation in lsnes is.
As well, I have a shitty cheap capture card coming in (slowly from China), and when I get that I can cap the composite input so frames can be compared - this is the hope anyway.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Ford wrote:
I attempted to run this movie, but it only managed to run at all in snes9x v1.53, instead of v1.51 like your submission states. And when it does, it just hangs out in the name-pickin' spot and does slightly weird things.
WHAT DO?
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I would to have loved to have tested this on console, but
1. It likely wouldn't sync with this emulator choice
2. I don't have access to this game, nor do I have a donor cart yet :(
Nice run, though I wish you weren't a tease about it in the thread.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
The art of TAS has surpassed merely playing a game. TASing is the game itself, and sometimes even that is eclipsed by making things play that game for you too. Metagaming of sorts.
The best players of this game know how to break all the rules, and do so as a matter of course; this necessitates understanding the architecture and peculiarities of the target, and of the tools used to work said target.
Generally, this means understanding how to write computer code. This is because it often means knowing how to tear these platforms and code apart (see the post by feos), as much as it does writing your own.
For the motivated, learning to program isn't hard. Learning to do it well can be :)
edit: slightly updated "quote"
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I have verified this iteration of the run verifies on console, if DPCM bug is worked around: in other words: input is not exactly as it would be from controller. This was true of the original movie as well. That said, if a button mashing robot tied to buttons played this back it would also very likely sync.
Video will come when all the others do, in a couple weeks.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Scepheo wrote:
True wrote:
To replay power cycle with an unmodified console, basically the movie is split on power button presses, and a robot (or a human if timing isn't important) powers the console off. The problem is the NES case where this turns into a multi-step process of power off, remove cart, run RAM clear cart, while powered (and in reset for a frontloader) swap to original cart, then press (release) reset, and while doing this configure the replay bot, and hope it all works.
I'm inclined to disagree with this (although my opinion isn't very well founded, so if you have good arguments otherwise ...). If, in an actual NES, a power cycle does not clear the RAM, then any emulator simply shouldn't either. It just seems like an emulation inaccuracy, rather than an issue on the verification side of things.
It does eventually zero, but as Derakon said, it takes time. Also different chips might not always zero; some bits may be set after cold power-on. SRAM can clear pretty quickly without power though. (Some games use a "powered on" flag in RAM, that is cleared when power is cycled; this is how they detect power on vs reset. If you have played a game that does this, and tried power cycling, you would notice RAM state decays pretty fast.)
The biggest problem right now is that the emulator, FCEUX, sets a specific RAM pattern that a console will never naturally reproduce. Without this problem, it'd probably still take more time than this run to ensure RAM was decayed, or would require a bank of cold NES ready to go.
It would seem that a bot-controlled power switch is viable to actually perform the hard resets, and if this doesn't correspond to what happens in an emulator, the emulator is at fault.
This does correspond to what happens in an emulator (sort of - read above or my many previous posts in this thread), but the dead time without the console running is not counted in the times on this site. If verifying a single-segment run that involves power cycles, as verifying TAS typically is, then this dead-time should be counted in the run timer for verification. As it stands right now, even if power cycles and resets were implemented and it was run on an emulator without an unrealistic power on RAM state, the total real-life runtime would be longer than this run. And if you decided to not count this time (in which case should the site call it "multi-segment?), it may still not work reliably because of RAM state decay. And by that point, one would need a clear cart again to retry from the beginning because of the RNG being located in battery backed RAM.
If power cycle runs would work on any game, FF is it though. But it isn't doable now, and will likely be slower than this run.
I hope that's the last time I write that a run with power cycles and resets will likely take longer than this run. Because I've said that a lot.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I have received two GBAs and some Spongebob games from someone who wants to remain anonymous; thanks! I can try verifying games as long as there is some way to detect input poll or screen update on the hardware, will need to look for that. Hopefully someone has already done the work.
---
Been discussing SMS stuff here, and it looks like SMS verification apart from emulator accuracy will take a while yet. And as far as emulator accuracy is concerned, I don't think we're there yet either, at least with Wonder Boy. Still need to work at this but it isn't hopeful.
Maxim wrote:
The BIOS really doesn't do much, it's about detecting a cartridge and enforcing region detection. Some emulators bypass the checks in order to avoid having to emulate the multi-slot nature of the system, and that would account for a lot of the time difference you see.
The time difference I was talking about was a variable difference depending on the game. I would imagine the BIOS execution until game instruction start would be the same? But it doesn't seem to be.
---
NES and SNES controller visualization boards should be here in a week or two. I will then resume recording verification videos for the backlog of NES games.
EDIT Shipping is slow as shit from China right now, from the latest holiday and maybe the protests in Hong Kong. My stuff is waiting to get on a plane. No idea how long this will take... I'm just starting to get other unrelated stuff shipped from Shenzhen and HK that was ordered a week prior, so maybe this is still on target for next week.
EDIT 2 Boards are in. Verification videos are being made.
