Posts for Sophira

Posted: 11/6/2017 3:58 PM
Post subject: Re: TAStudio input duplication bug
Quote
Sophira
She/Her
Joined: 8/4/2015
Posts: 2
Location: Scotland
feos wrote:
Sophira wrote:
input duplication bug in TAStudio
Thank you!!!!!!!!! This controller test rom revealed what bizhawk fails to catch. Duplicate input is sent to the core if we're capturing new frames. It's been there forever, and now it's finally fixed.
Awesome to hear! I'll test when I can. I assume based on commit messages that the fix is this commit? (If so, my apologies for putting this bug in the wrong thread - I thought it was TAStudio sending duplicate inputs rather than an issue with BizHawk itself!)
Posted: 10/30/2017 11:35 PM
Post subject: TAStudio input duplication bug
Quote
Sophira
She/Her
Joined: 8/4/2015
Posts: 2
Location: Scotland
Hi, There seems to be an input duplication bug in TAStudio; if you put an input on either of the last two frames shown in the TAStudio window, those inputs will be duplicated to the next frame in the emulator the first time those frames are played (but will not be duplicated in the piano roll). This could lead to incorrect states and unexpected desyncs. I uploaded a video showing the problem (using a free unofficial controller test Genesis ROM) at https://www.youtube.com/watch?v=sgGZ0gBDvbM .
  • The first two inputs placed in the video show normal and correct behaviour, as they were placed in the middle of the piano roll. These inputs show up in the emulator precisely two frames later (which to my knowledge is correct) and last for precisely one frame only.
  • The second two inputs placed show the bug; these frames are placed on the last frame shown (although this bug also occurs if they're placed on the second-to-last frame shown). These inputs will again show up in the emulator two frames later, but this time the inputs last for two frames instead of one. This results in incorrect savestates being recorded for the frame.
  • After showing the bug, I then go back frame by frame to show how BizHawk recalculates the savestates from the previous frames. Here, the distance between the inputs and the playback cursor is short enough that BizHawk can correctly determine what these frames should look like based on the frames before it. (Note that I have "Turbo seek" turned on.) However, had I not known about this glitch and continued TASing a game based on the incorrect states, the resulting movie would have desynced.
The video was taken using BizHawk 2.2, but I have confirmed that this bug still exists in BizHawk 2.2.1 (released yesterday). I have also heard that the bug exists even in 1.x versions of BizHawk, but have not personally tested this. If you need any more info, please let me know! [edit: Oops, forgot to mention an important piece of information - this is using the Genesis core! Sorry about that.] [edit 2: Clarified that the duplication occurs in the emulator inputs, and not in the displayed piano roll.]