Parrying Frame Data

Summary

Shields do not seem to grant a longer active parry window, which appears to be 13 frames regardless of shield usage.

Method

Testing was done on 28175. Two equipment sets were tested. No enchantments, facets, rings or other items were used. The sets were as follows:

  • a Pig Sticker and empty off-hand,
  • a Pig Sticker and Wooden Shield.

For each set, I recorded around eight minutes of attempts to parry the dummy at 60 fps. I used vsync and inspected frame timings to minimise frame-counting errors. Then, stepping through the footage of failed and successful parries frame-by-frame, I determined, counting from the first animation frame:

  • A: the latest frame in which I could still take damage,
  • B: the earliest frame in which I could successfully parry,
  • C: the latest frame in which I could successfully parry,
  • D: the earliest frame in which I could take damage again,
  • E: the earliest frame in which I could move after initiating the parry.

The differences B–A and D–C should be 1 frame. This is both a sanity check (values must be non-negative) and a sign that enough data has been acquired (differences of 2 or more would suggest I should’ve recorded more). C–B+1 is the active parry window.

Errors for A to D should be within 1 frame. This means differences B–A and D–C may be 0.

While E makes recovery comparable, moving tends to be the slowest recovery cancel (compared to attacking, dodging, or blocking) in Souls games. Beginning of movement is difficult to determine due to acceleration and a lack of a trackable fixed point. Testing dodge would have been smarter.

Results

Set A B C D E
Pig Sticker, empty off-hand 4 5 17 18 26
Pig Sticker, Wooden Shield 6 7 19 20 46

This is an active parry window of 13 frames for both sets.

Differences B–A and D–C look sensible.

The window begins and ends two frames later for the Wooden Shield relative to the visible start of the parrying animation.

Discussion

The two-frame shift between shield and no shield may be explained by animation differences. This is supported by the identical length of the window. Also see below; in an older game version, startup for shields was closer to my data for the estoc.

From frame timings and how frequently specific frames occur in my data, I would also consider an active parry window of 14 frames plausible, but decidedly not 12 frames.

Time until walking is possible is very short for empty off-hands and considerable for the shield. If anyone feels like testing earliest-cancel frames, please do.

As a point of reference, non-special shields in Dark Souls PtDE have 7 active parry frames at 30 fps, equivalent to 14 frames in 60 fps.

There’s still a chance frame data differs by weapon type or even by weapon.

Additional Testing

On a hunch, I tested one set in the crucible_legacy branch by parrying one of the Risen.

Set A B C D E
Blood-Rusted Sword, Wooden Shield 4 5 15 16 44

An 11-frame parry window nearly matches Dammitt’s database. Speculatively, frame data in Dammitt’s database is based on an old build and a 60-fps metric. It does not match current builds in either a 30-fps or 60-fps metric.

I expected a larger difference between legacy and live, but that just shows the impact of a small difference in frames.

(I also tested cancelling the recovery by dodging, which was possible from frame 35. Testing moving really wasn’t optimal.)


@Silas-Inservio-Pax, @sBAM: Please forgive the ping. I believe this may be of interest to you.

5 Likes

This is crazy work. Amazing!

As far as feel goes, do you believe that shields introduce additional input delay, or that it is merely visual but the timing stays the same?

I can’t tell, neither subjectively nor from the data.

Extended rambling on methods

I considered recording more footage and seeing if I could notice a shift of the ‘average’ frame I’d parry on muscle memory, but that veers too close to statistics.

Outside of slowing down the game artificially and locking the framerate to something very low, I can’t think of a way to time my inputs reliably. I don’t have access to a way to trigger the parry event software-side and frame-perfectly. Even then game-speed manipulations could break frame data.

After noticing the difference I re-examined the start of the animation, but it snaps directly from neutral to a very different stance. Then I considered there could be two ‘do-nothing’ frames at the start and I would be none the wiser, and gave up on testing start-up frames. My method above deliberately avoids them using nested intervals.

Incidentally, a successful parry was judged based on the golden sparks appearing, which always coincided with the dummy snapping to a different stance; and damage frames were based on the blood-smeared screen border, which always coincided with my character being moved and my health bar adjusting. It was reassuring that those consistently happened on the same frame.

I’m especially careful not to start the next rumour. Inputs involve too many factors. Since I deliberately parried early or late, there’s little muscle memory to compare against, and I don’t trust my gut on a two-frame difference.

1 Like

Yes it is :slight_smile:

excellent myth busting work

1 Like

There was a mysterious change in Hotfix 8.

Not sure what this change means – I initially assumed it’d refer to a longer recovery window, but comparing against the testing footage I am able to move as early as before and spam parries as fast as before. I’d appreciate any insight.

1 Like

Not what I expected to find: Two separate parry animations.

1 Like

Uh. Same timings? /20

that looks like a successful parry animation is playing as its own separate animation?

Well spotted! It appears that, once this bug is primed, the first parry of every weapon class will play the ‘successful’ animation. This happens reliably after restarting the game, and occasionally after realm-switching or Crucible runs. Might make it a habit to throw a random parry every so often and see if I can spot a pattern.

I only checked a few examples due to the effort of reproducing this, but it appears frame data is not affected and this is purely visual.

1 Like