TASVideos

Tool-assisted game movies
When human skills are just not enough

Desync Help TAS

It happens quite often, especially on newer emulators. You carefully construct your TAS and when you check your progress, the movie goes off at some point and does something wrong.

The majority of desyncs when creating a TAS is due to inconsistent savestates. What happens is that, at some point, an emulator error or savestate error or both will cause you to start using a wrong savestate. Once that happens, your movie will now go down the wrong track. If such a thing happens, recreate your savestates at the most recent point where the movie plays as intended.

While you are making a movie, make it a habit to periodically play through your whole movie to verify that it works, and always make a backup of the working copy.

If your run goes wrong, no one can help you recover the lost work. It is up to you to be careful.

Table of contents [expand all] [collapse all]

There are a number of causes of inconsistent savestates.

Emulator problems

PCSX, Mupen64, Dolphin and FBA-rr

  • In general, these emulator have some desync issues. Be careful.

FCEUX

  • For some reason, FCEUX might secretly add reset events to the movie. To fix this problem, simply clear the unwanted reset events inside the movie file.

Snes9x

  • Official version of Snes9x 1.43/1.51/1.52 has some desync issues. Use SNES9x Rerecording instead. (The improved Snes9x can play and record movies in both Final and WIP timing.)
  • Snes9x 1.43/1.51 has trouble with sound. Games with timing to music or sound might desync. Some state saving/loading patterns during music changes might cause trouble as well. Using the improved version, disabling sound emulation entirely or using Fake Mute mode may prevent it from happening.
    • SNES9x 1.52 improved sound emulation logic overall, and the issue above has probably been fixed. If you don't need some advanced TAS features (such as Lua scripting), you should use SNES9x Rerecording 1.52.

Visual Boy Advance

  • VBA v20 has some emulation problems with SGB games. You may try recording with other versions instead. (The timing of GBx games is mostly different in v20.)
  • VBA versions prior to v21 has a bug that may automatically disable the GBA Lag Reduction setting. If this happens, you may try to hex-edit the GBA Lag Reduction flag stored inside your desynced movie according to the VBM format description.
  • VBA might load settings from an obscure configuration file named vba-over.ini, which can override save type and RTC settings. (TODO: verify this.)

JPC-RR

  • Stopping emulation when executing very long instruction sequences without any (conditional) jump instructions (and also some other instructions) can lead to desync. Fortunately, such sequences are extremely rare.
  • Savestating while joystick is being polled will cause a desync in versions before r11.4. If you enable joystick (it isn't enabled by default), use r11.4 or newer.
  • Certain forms of self-modifying code may very rarely produce desyncs if pipeline flushing is not enabled.

Savestate problems

  • You loaded savestates in the wrong order. For example, you should never load a savestate which is ahead of your current time. Implementation of "bullet-proof rerecording" prevents this. Due to current standards, this has become an obsoleted problem. This only happens in Famtasia and older versions of Gens and should not happen in most of nowadays emulators.
  • Some savestates are flawed and will not exactly save what is supposed to be in the system at that moment. For example, savestates in older versions of Snes9x do not save the C4 memory used by games such as Mega Man X2, so critical or even functionally visible errors occur with savestating when C4 memory is used. There may be no choice but to use guesswork, and to keep checking the movie until you are out of the desync zone.
  • Loading a non-movie savestate while read-only is off may break your movie where you attempted this. Try to avoid this and don't overwrite your movie savestates with non-movie ones.
  • Loading a movie savestate from a different movie before resuming recording. This may even happen with current "bulletproof rerecording" emulators as listed below:
    • "Bullet-proof rerecording" is imperfect. Some emulators may allow you to load savestates from the movie while the movie is being played in read-only mode, and you may resume recording from the already desynced movie by toggling off read-only mode or making a new savestate and then loading it. Avoid loading wrong savestates during replaying, or at least do not overwrite your correct movie savestates with desynced ones. Implementation of "bullet-proof replaying" prevents this problem.
    • At the present moment, no known emulator can prevent you from producing two distinct movies which share the same movie identifier, by using an external tool (e.g. a movie editor). The safest way to this issue is to discard any old movie savestate that was made in a different timeline from where your current movie is in.

Other

You have external codes on (ex. Game Genie codes)

Be very careful that you don't have external codes on. It is easy to miss. If your movie requires external codes to play back correctly, TASVideos cannot accept your movie.

You changed the settings by accident

If this happens, try to rectify what you can. Do not continue with inconsistent settings.

Replay is not quite deterministic

If you discover that different ways of playing the movie yield different results, it is recommended to stop TASing that game, at least until the problem is diagnosed.

Game suddenly resets

Some versions of some emulators may insert spurious resets in some conditions (this is an emulator bug), resulting movie that suddenly resets the game. These can be fixed by editing the movie file to remove the spurious reset.

TODO: update info.

Combined RSS Feed
DesyncHelpTAS last edited by feos on 2011-06-26 10:37:04
Page info and history | Latest diff | List referrers | View Source