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.
I've been working on my GBA project recently (the YouTube posted earlier is an earlier try at it). You can detect a VBlank off the SPS pin.
I've been having issues with that approach though -- inputs are either being dropped or not recognized, and I'm not sure if it's due to my setup or just differences between emulation and the real hardware. My inputs should be tied to a single frame, as you can see here:
Last signal is the SPS pin that I'm keying off of, which has the expected frequency of 59.73 Hz. GBA buttons are active low. There is some latency on the order of 50 uS, but I don't think that's the problem.
The game I'm testing against is Super Mario Advance 2. As far as I can tell, there's no standardized way of polling buttons for the GBA (and buttons can actually drive interrupts), so I'm not 100% certain that setting a button for a single frame actually does work for it/other games.
Input latency is probably going to be important if button interrupts are used. I am not sure which games use this though, if any. It's not necessarily important on gameboy.
It is very likely emulation quality is not there yet. To determine if input timing is an issue, inject your own delay and determine if the results are deterministic.
Input latency is probably going to be important if button interrupts are used. I am not sure which games use this though, if any. It's not necessarily important on gameboy.
It is very likely emulation quality is not there yet. To determine if input timing is an issue, inject your own delay and determine if the results are deterministic.
From what I read, button interrupts are usually used to wake the GBA out of stop mode, so that's probably not the issue.
Looking at vba-m's code, the inputs are set right at the beginning of VBlank. I changed the code to set button inputs in the middle, as so:
This helped with dropped inputs, but the replay still doesn't play out correctly. On the first stage Mario always jumps too soon. I doubled the length of each button press and he jumps too late.
I'll post the videos of that if anyone is interested, but I'm gonna assume its emulation at this point.
Moderator, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
I know I said I wouldn't be doing console verification at SGDQ 2015, but I've asked endrift if I can take a stab at console verifying Sonic Advance from my laptop (endrift, thanks for agreeing to lend me the hardware and the game). I'm not yet certain if this will result in a console verification run at SGDQ or not, but if we can do it it would be really awesome and I bet I could ham it up quite a bit. Either way I'll be simultaneously playing back the camhack encode so people can see what's going on.
I don't own Rockman to try console verifying it and trying with Mega Man desyncs after the first level but I plan on running that one in an emulator anyway. And, of course, Ikaruga and the entire line of disc-based consoles is pretty much never going to be console verifiable, but there are still plenty of other things we can potentially target in the future.
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.
I'm not sure I understand. The only part of this run that's unoptimized is the part at the beginning where I wait for the RNG seed to line up. Beyond that, everything else is 100% optimized the same way as the original movie file. I guess I didn't watch the movie in question in that post, but due to severe timing differences between VBA-rr and console, this is all that can be done. Which I suppose might be your point.
My point is that even if I and you consider this verified, there can be tons of people getting insane over how terrible idea it is (to them).
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.
Going back and rereading the thread again, yes, I inserted 3 blank frames between every level. I was told before doing this that that's generally how console verifications work, so if not, I'd been misled at some point.
Going back and rereading the thread again, yes, I inserted 3 blank frames between every level. I was told before doing this that that's generally how console verifications work, so if not, I'd been misled at some point.
I think it’s fine if all you’re doing is adding/removing blank frames to play around with lag. But if you’re changing anything else (such as 700+ wait frames at the start for RNG?) then the movie shouldn’t be considered console-verified.
It won't replay in VBA-rr though, and I've also confirmed that it doesn't *quite* work in mGBA (although it's way closer). It's probably possible to make a more optimized run than this assuming a much more accurate emulator but...therein lies the problem :P
I might be stating the obvious (and possibly repeating what has already been said previously, but I'm too lazy right now to go through 16 pages to check), but if you need to add frames to a movie in order to run it in a console, shouldn't it be the emulator that's fixed (and made to run more like the console)?
To clarify a bit on how those several seconds are used, and why (with fake numbers since I don't know the exact numbers):
When in emulator, the game runs for 2000 frames with the level counter spinning, then presses Start on the first frame it can. However, since it's running "faster" than console, this is fewer frames than on the actual console. Thus, when the same 2000 frames have passed on actual console, Start cannot be pressed yet, and it must wait 20 frames (less than a second), but at this point the frame counter is 2020, thus offsetting the seed by 20. The way I fixed this was to do a soft reset (A+B+Start+Select) to reset the frame counter to 0, but the point in the intro sequence where it resets to is actually 800 frames into the sequence without the reset. As such, I can wait only 1220 frames until I can press start, but I need to wait an additional 780 frames until it reaches the 2000 seed. So if the emulator had waited those 20 frames (or whatever the actual number is--I'm pretty sure it's less than 60, and I know it's less than 120, thus way less than however long I waited) instead of pressing start immediately, and used that seed, the reset wouldn't have been necessary.
So it's still REALLY close, but I had to do tricks to get it to work.
Moderator, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
I'm fully of the opinion based on all of the work I've done that it is absolutely allowed to add or remove empty (lag) frames when performing console verification. This was especially required for Pokemon Red where the SGB had very specific characteristics we had to work around. So, yeah, I'm generally inclined to "blame" the emulator and not the hardware.
This is a pointless discussion since NitroGenesis already decided it is verified. Who am I to argue.
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.
I'm fully of the opinion based on all of the work I've done that it is absolutely allowed to add or remove empty (lag) frames when performing console verification.
Don’t think anyone’s arguing against that. I’m arguing against the fact that suddenly the console requires a soft reset and extra wait time (not lag) to sync up the RNG.
feos wrote:
This is a pointless discussion since NitroGenesis already decided it is verified. Who am I to argue.
Moderator, Senior Ambassador, Experienced player
(898)
Joined: 9/14/2008
Posts: 1007
ALAKTORN wrote:
Don’t think anyone’s arguing against that. I’m arguing against the fact that suddenly the console requires a soft reset and extra wait time (not lag) to sync up the RNG.
Unless I misunderstood endrift's explanation, in order to line up the RNG the game is reset to start from a known RNG state and isn't started until the RNG lines up again at a predictable time, as in, the net effect is that only the number of "lag" / empty frames is changed. The design could be altered to have two movies, one to erase the savestate and another that would work directly from power-on, but this is *far* more convenient (trust me, after you re-test the same file for the umpteenth time you really, really want a way to make the operation a bit more automatic - I had a movie for Pokemon Red that did this type of data deletion for me for similar reasons although it operated slightly differently).
We've only ever been discussing "extra wait time", the name lag frame is convenient shorthand but isn't particularly accurate. I think what's happening here is just fine.
As I explained, perhaps a bit verbosely, the problem here is that the console has "too many" lag frames compared to the emulator; what's effectively happening is removing lag frames (and not even that many), even if the means are a bit roundabout. But it's true that this is a sizable discrepancy from the emulation. VBA-rr is just that bad, so it's unavoidable. I guess that could mean that none of the VBA-rr movies should or will ever be verified, though.
We've only ever been discussing "extra wait time", the name lag frame is convenient shorthand but isn't particularly accurate.
Don’t use it if it’s not what you mean, then. Lag = not input. Empty frames = input. Just because they’re empty doesn’t mean it’s not input, 0 is still an important value. A movie syncing on console with the same input should be considered verified, one that requires different input shouldn’t. Therefore this one shouldn’t.
dwangoAC wrote:
I think what's happening here is just fine
I disagree.
endrift wrote:
I guess that could mean that none of the VBA-rr movies should or will ever be verified, though.
Quite possible. That’s what happens when you have poor emulation.
Emulator Coder, Site Developer, Site Owner, Expert player
(3599)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
endrift wrote:
Going back and rereading the thread again, yes, I inserted 3 blank frames between every level. I was told before doing this that that's generally how console verifications work, so if not, I'd been misled at some point.
This isn't the first console verified movie to be different in length vs the reported time. Why is no one upset that the SM64 console verifications differ DRASTICALLY in completion time to the emulation time? At some point maybe we could add a verification time to the publication info.
In the meantime, 3 empty frames to get it to sync is perfectly fine within our constraints for claiming console verification.
Going back and rereading the thread again, yes, I inserted 3 blank frames between every level. I was told before doing this that that's generally how console verifications work, so if not, I'd been misled at some point.
This isn't the first console verified movie to be different in length vs the reported time. Why is no one upset that the SM64 console verifications differ DRASTICALLY in completion time to the emulation time? At some point maybe we could add a verification time to the publication info.
In the meantime, 3 empty frames to get it to sync is perfectly fine within our constraints for claiming console verification.
I think it was because SM64 didn't need to add/remove any extra input frames, and it was just Mupen reporting the wrong time. Someone please correct if wrong.
I guess this can sorta count as verified, with a note saying how many extra blank frames were added?
A movie syncing on console with the same input should be considered verified, one that requires different input shouldn’t. Therefore this one shouldn’t.
While I certainly sympathize with this argument (it absolutely makes sense), having a small leeway (1) for emulators that are possibly years away from being sufficiently hardware-accurate (2) in non-gameplay places of the movie (fadeouts, cutscenes, level transitions) is definitely the way to go for the concept to remain around. Why? Because the concept of console verification came about as a proof that what we're doing here is not exploiting emulation bugs/inaccuracies nor hacking games; feeding pure input to the console is the only thing required to finish a TAS. In this respect the movies remain console-verified, but said leeway should remain in sane, non-controversial bounds. Three blank frames during a level transition should indeed be considered fine in that regard.
Realistically—at least as far as I understand—at the moment there are at most three (?) platforms emulated well enough to not explicitly require such leeway: NES, SNES, and possibly Genesis (when done on Bizhawk or a compatible emulator); instead you just get runs that sync and runs that don't. And even then it doesn't seem to save those that do from occasional desync; I remember adelikat's Gradius TAS failing twice on AGDQ 2014 (but then again, it was made on an ancient FCEU version, so that might have been the reason).
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
This isn't the first console verified movie to be different in length vs the reported time. Why is no one upset that the SM64 console verifications differ DRASTICALLY in completion time to the emulation time? At some point maybe we could add a verification time to the publication info.
In the meantime, 3 empty frames to get it to sync is perfectly fine within our constraints for claiming console verification.
Please actually read the topic before posting next time.
moozooh wrote:
Three blank frames during a level transition should indeed be considered fine in that regard.
You may want to read the topic as well if you think 3 blank frames during a level transition is all that was modified of the input file.
moozooh wrote:
having a small leeway (1) for emulators that are possibly years away from being sufficiently hardware-accurate (2) in non-gameplay places of the movie (fadeouts, cutscenes, level transitions) is definitely the way to go for the concept to remain around. Why? Because the concept of console verification came about as a proof that what we're doing here is not exploiting emulation bugs/inaccuracies nor hacking games; feeding pure input to the console is the only thing required to finish a TAS. In this respect the movies remain console-verified, but said leeway should remain in sane, non-controversial bounds.
Yes, I thought myself that the differences being outside of gameplay (just in menus) could be a factor in favor of it being console-verified. Overall what you say here makes sense. Defining those sane, non-controversial bounds may become hard though, if you go outside hard-set rules such as “only playing around with lag is allowed”.
Last signal is the SPS pin that I'm keying off of, which has the expected frequency of 59.73 Hz. GBA buttons are active low. There is some latency on the order of 50 uS, but I don't think that's the problem.
The game I'm testing against is Super Mario Advance 2. As far as I can tell, there's no standardized way of polling buttons for the GBA (and buttons can actually drive interrupts), so I'm not 100% certain that setting a button for a single frame actually does work for it/other games.
This helped with dropped inputs, but the replay still doesn't play out correctly. On the first stage Mario always jumps too soon. I doubled the length of each button press and he jumps too late.
I'll post the videos of that if anyone is interested, but I'm gonna assume its emulation at this point.
