Joined: 8/14/2009
Posts: 4089
Location: The Netherlands
Most of them desynced during either the first stage, the first boss, or after the first boss. (Notably, the latest Rockman run desynced right where the first "major" glitch was supposed to happen in Ice Man's stage).
One exception is Mega Man 6, which managed to sync until somewhere in the 8th Robot Master stage - almost halfway through the run.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
It's interesting how some runs get VERY far before desyncing (like Mega Man 6 and Punch Out) while others desync immediately. Obviously something very very subtle is off.
I think so too. Otherwise how could this movie desync while another movie of the same game sync? Or is there a reason for that?
Also, if "invalid" is an incorrect word, then what word should be used to describe movies from games that may be emulated incorrectly?
One more thing: what are the odds of a movie that heavily relies on luck sync?
Depends on the source of randomness. If it's deterministic, it should always (?) sync unless the mechanism that generates the numbers required for a run to sync is emulated inaccurately. Such as, if a randomness depends on absolute frame timer, a difference of one frame during a fadeout, laggy scene, or some kind of loading, throws the synchronization off completely.
I am not surprised with this result because the main point of this movie was to perform lag reduction on a very laggy game. (And now, has the movie lost its point?)
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
None of my carts worked because they came from SDA and refused to be TASed. Sorry guys...
In all seriousness, I'm kinda sad none of them worked. Out of all the games I posted on the previous page, which ones would be most likely to work or is it some kind of crap-shoot? Add Battletoads and Ninja Gaiden to that list.
Until now, except for Gradius only Nintendo games synced. Maybe those games stick to some kind of "NES-standard" in terms of input polling, while others don't. Although there are other Nintendo games which do not sync... isn't it possible, that those games have a higher sync possibility compared to others?
Just a thought. This was the first thing that came to my mind when I had a look at the list. Of course this might be a coincidence.
I've never read this topic and I don't know if it's been posted already but I think this thing could be useful for verifying movies?
http://www.youtube.com/watch?v=2JNf0lAo3Ns
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
Our member micro500 is the inventor of this device and he is the one who is verifying everything. If you read the last 3-4 pages of this topic you can find youtube videos of the verifications and a lot of information about the device.
sorry for the useless post
I have to say, I absolutely love this and micro500 gets all my respect :) hope for it to be developed further and for more emulators too
edit: I think it could be a good idea to add something along the lines "This TAS has been verified." maybe with a link to the video(?) in the published page or wherever
Well, they already add checks to publications that have been verified, as in http://tasvideos.org/movies.cgi?id=1332,1349,1715. Notice that those three publications, at least, already have links to verification videos. I haven't checked other verified publications.
It will totally depend on the polling method. For example, Genesis will never work (without modifying the console) because the polling is done internally. Each wire is linked to a button, (identical to the Atari and the SMS).
Playstation (and any other CD based consoles) will probably never work, because of the inherent stochastic nature of reading CDs.
The turbografx might work, because it does use a polling line. The N64 uses a bi-directional data line so... maybe? I doubt the emulation in Mupen is accurate enough for any run to sync, however.
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.
Couldn't you do something along the lines of replacing the Playstation's CD drive with a solid-state drive? Sure you wouldn't be running on the original console any more, but you'd be using the console's logic, just with a different (and transparent to the console) loading method.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
From my (very limited) experience with Playstation emulation, it seems like you'd have to put some pretty intense hardware between the CD input to the board, and the playstation itself. It isn't simply like a standard IDE connection, you'd have to build a piece of hardware to translate the CD commands.
http://emudocs.org/Genesis/genhw.txt
I was looking at this doc - It appears that the genesis puts out a vsync signal through the cartridge port! This would actually make it more sync stable than the NES bot (where micro500 is forced to approximate the vsync).
Unfortunately, I've heard grumbling in the past that gens is not really a very accurate emulator, so who knows how sync-stable any movie would be.
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.
How many times would a movie be tested before it is "invalid"?
When I'm doing these checks I try to test each movie a few times before giving up and moving on. I usually try to make sure the game fails in the same way each time to make sure it wasn't one of a few other problems that could come up.
One game that was especially bad at that was SMB3. With earlier versions of my code that game would desync completely randomly. I've since learned that is due to the PCM bug, and I've more or less worked around it. Other problems include power button bounce. If you press the power button too slowly, the console can flicker on and off for a short period of time before actually staying on. If the game polls for input in that time my bot will react, but just continue to increment the frame count instead of resetting with the console. That could cause the input to be a few frames too soon, usually meaning the game doesn't start (that one is fairly obvious). I've also had problems with other electrical devices causing interference, like my dorm fridge. When that thing kicks on, movies almost instantly desync.
DarkKobold wrote:
I was looking at this doc - It appears that the genesis puts out a vsync signal through the cartridge port! This would actually make it more sync stable than the NES bot (where micro500 is forced to approximate the vsync).
When I built the NESBot I had the intention of making a bot that plugged in as a controller and did not modify the console at all, since that was theoretically how TASes work anyway. The NES does have a vsync pin, but it is also internal to the console. I need a little free time, but I plan to try using that, even if just to see if it works as I'd like. It'll break up the clean plug-in design of the bot if it does, but if more runs work as we'd like then I'm fine with that. Maybe I'll end up with a completely hacked TAS playing console when I'm all done.
ALAKTORN wrote:
hope for it to be developed further and for more emulators too
I have the parts in the mail (somewhere, silly international shipping) to make an SNES version. I've heard from multiple people that it's less likely to work due to the SNES emulators being less accurate than FCEUX is, but I figure its worth a shot considering that the electronics required are almost identical to what I currently have. I will need to borrow games for that testing though, since I only have LoZ LTTP. I don't personally have a genesis, but I'd love to mess with one if I could get my hands on one. I have looked into doing this for an N64, and it doesn't seem overly complicated, but it is very doubtful that any runs we currently have will sync. But who knows, maybe mupen64 is better than we think!
ALAKTORN wrote:
edit: I think it could be a good idea to add something along the lines "This TAS has been verified." maybe with a link to the video(?) in the published page or wherever
This page lists all movies that have been verified on the console: Wiki: ConsoleVerifiedMovies. And as zidanax mentioned, there is a check mark next to the title of the run which indicates it has been shown to run on the console.
Joined: 11/18/2006
Posts: 2426
Location: Back where I belong
micro500 wrote:
I don't personally have a genesis, but I'd love to mess with one if I could get my hands on one.
I have a Genesis and several games (all sonic games, vectorman 1 and 2, a few others) that I'd be willing to donate to the cause. PM me when you're done with the SNES version if you're interested.
Another thought, although not very well thought out; now that we have a bot that can play a video we've recorded on a computer, is there any chance we can rig it to record input to the NES? Not particularly useful for TAS, but it'd be awesome to have a recording utility for the NES that plays back actual key presses. Might also make it easier to see why movies desync.
Just like mmbossman, definitely PM me when you have a SNES version running.
I guess...it'd be easier to compare it to an emulator's movie recording utility. The difference would be that you'd record directly off of an NES and get a file that resembles a .fm2 file which can be played back on the NESBot or on an emulator (Though odds are, it'd desync on the emulator for the same reason that files generated on an emulator might desync on a console). Going further, I could even suggest implementing TASing tools for a given console to guarantee that it would run on a console, but that sounds highly unrealistic.
(Though odds are, it'd desync on the emulator for the same reason that files generated on an emulator might desync on a console).
OTOH it would probably greatly help in improving the emulation accuracy (although doing so would obviously break backwards compatibility with existing keypress files, as they would start desyncing exactly as they do on the real console).