Need Help With Unnusual Frame Data

S

Solid_Altair

[09] Warrior
I have two weird questions about frames. If if any of you know the answer or how to viably test things to get the answer, please help.

1- For the simultaneous press inputs, such as A+G, how many frames do we have as a margin of error? Do we have to do it in the same frame? Can we press the buttons one frame apart from one another? More than one frame?

2- And this one is weird because it's the frame data of an immobility, or rather, of a block stun. Knowing one would reveal the other, but currently all I know is how negative the move is on block. The move I'm talking about is Pyrrah's stab (236B). Does anyone know what is the block stun on Pyrrah's stab?

The reason I wanna know this is that this block stun seems to be on the verge of whether or not buffing a punishment is viable. It oculd be used as a guideline of the shortest block stun you can have from a strike after which the defender is supposed to fire back.

Thanks in advance!
 
There maybe some buffer for that kind of with the throws. Button inputs aren't as strict in SC... @Slade would probably know the answer to that.

What I can tell you is Pyrrha's stab is -18 on block
 
Thanks.

And yes. The net frames are -18. They used to be -16. And I suspect they added the 2 frames as a compensation to the short time the blcoker has to buff a punishment. So, I'm still curious about the frames of the actual block stun (or the immobility).

If SCV had the frame data on practice mode like in DOA5, whiffing the attack would show the full immobility. Then I could simply subtract the 18 and get the block stun information I need.
 
You could probably work it out by looking at the frame data in Pyrrhas soul arena:

14 frames till impact + 18 frames of recover on block = the whole animation being around 32 frames in total
 
Or if you have a capture card and high quality video editing soft ware that allows you to go frame by frame
 
The 18 frames are the net disadvantage. Her immobility (recovery) is more than that. We gotta add the block stun frames. Then we can have the frames of her whole attack. Counting the frames in actually a good idea, but I don't have the equipment.
 
Total move frames are acquired by this:

Impact frame (I) + Negative Frames on JG (J) + 14 (This is the frames of blockstun JG gives)

So, I+J+14.

In this scenario, that's 14 + 25 + 14 = 53.

So, the move takes up 53 frames in total, and has 39 total recovery frames.
 
ZER0 said:
There maybe some buffer for that kind of with the throws. Button inputs aren't as strict in SC... @Slade would probably know the answer to that.
Click to expand...
I’m not sure. Every game at its heart has a game loop which repeatedly processes inputs and redraws the screen, but the specifics of how those two actions relate to one another vary from game to game.

The problem is that in theory there’s no reason that the processing of inputs need be tied to frame rate. While it’s a necessary condition for games with logic tied to frame rate to use a locked frame rate (otherwise one runs into situations like the Dark Souls II glitch where equipment degrades twice as quickly when the game runs at 60 FPS on the PC), it’s not a sufficient one, so it would be incorrect to infer that SCV ties its inputs to frame rate from the fact that it’s locked to 60 FPS.

It’s possible that it doesn’t make sense to talk about inputs (or even worse, some types of inputs but not all) in terms of frames. For example, certain conditions on inputs could use “frames” as a unit (i.e. to determine if a 1-frame slide input did in fact have both button presses occur within one sixtieth of a second), but those 1 frame intervals may not actually be aligned with what we think of when we say “frames.” Which is to say that an input that occurs like this:
Code: 
F1  F2  F3  F4
┌────┬────┬────┬─
  ├────┤
   a~B
may occur within one “frame” (i.e. 1/60th of a second) relative to how the game processes input and thus be considered a 1-frame slide even though it occurred over the span of two actual frames. There’s also the question of whether certain actions (specifically blocking and crouching) can be performed within 1 frame, e.g. if I’m 1 frame away from being hit and I press and hold G half a frame later, will I block the attack?

The gist of what I’m saying here is that I have no clue when it gets to the level of stuff that happens within 1 frame or less because none of that is testable without using a programmable input device.
 
You must log in or register to reply here.
Back