Did you hold down the button so as to avoid negative edge specials?
Mr. D, how are you getting input lag? Just curious because if I use MAME-RR, pause it, and use the frame-by-frame tool, if I press the button during an active frame, then the next frame the move starts coming out. If there was 4 frames of input lag of any sort, wouldn’t that mean I’d have to advance by 4 frames before I see an attack 5 frame start up meaning it would take 9 frames to get to the active attack hit box? Because when I do it, I press the button, and an attack with 5 start up frames has 5 start up frames and there is no input lag…
This. I fell into this trap at first, too. There are a lot of mindfucks like this when testing 
Hoho! And this is why peer review is important.
Exactly as you say, when the button is held down, the results differ. And they agree with the negative edge hypothesis; the earlier frame is no longer “reversible”.
#&7 W10 -_D6.W90.5.W2+L.D.DL.W2._4.W5! #too early. no dp
#&7 W10 -_D6.W90.5.W2+L.D.DL.W3._4.W5! #too early. no dp
#&7 W10 -_D6.W90.5.W2+L.D.DL.W4._4.W5! #rev dp
#&7 W10 -_D6.W90.5.W2+L.D.DL.W5._4.W5! #too late, dp stuffed
I rescind my earlier results! Single reversal frame it is. Justice is restored 
Thanks for double-checking! And DSP is wrong, again!
As a follow up, I turned frameskip back on and altered my script to still produce reversal timing. I then step through successive number of wait frames before bison’s slide, to influence the frameskip that occurs during the script (i.e., whether the reversal frame occurs around a frameskip or not).
The game rom setting was set to JP “Turbo 3” (equivalent to US Turbo 2) in system configuration (not free select). This is in the default ssf2t rom in mame-rr 139 test2.
#&7 W11 -_D6.W70.5.W1+L.D.DL…_4.W5! #rev dp
#&7 W12 -_D6.W70.5.W1+L.D.DL._4.W5! #rev dp
#&7 W13 -_D6.W70.5.W1+L.D.DL…_4.W5! #rev dp
&7 W14 -_D6.W70.5.W1+L.D.DL…_4.W5! #no rev dp available!
#&7 W15 -_D6.W70.5.W1+L.D.DL…_4.W5! #rev dp
#&7 W16 -_D6.W70.5.W1+L.D.DL…_4.W5! #rev dp
#&7 W17 -_D6.W70.5.W1+L.D.DL…_4.W5! #rev dp
#&7 W18 -_D6.W70.5.W1+L.D.DL…_4.W5! #rev dp
#&7 W19 -_D6.W70.5.W1+L.D.DL…_4.W5! #rev dp
#&7 W20 -_D6.W70.5.W1+L.D.DL…_4.W5! #rev dp
The reversal timing shifts around a bit (from a gap of 1f after the downforward position, to 4f after the DF position), i.e. in different frame skip situations the button press could need to be offset up to 3 frames… except for the W14 case, where I was unable to find ANY frame that would allow a reversal.
I’m a little skeptical since the frame skip interval with ST T3 (JP) is supposedly 2,2,3,2,2,3… (see http://dammit.typepad.com/blog/2011/05/turbo-speed-frameskip-revisited.html) which should imply I’d get at least 3 such cases where I was unable to reversal (in a sample set of 10 frames).
Any problems with methodology, please chime in. I’m interested in getting ground truth facts here, so want to get things right
edit: turbo frameskip stats updated
Which region does trust use? Remember there are slight discrepencies inthe turbo speed names throughout the different regions
(turbo 3 us = turbo 4 jp etc…)
Ok. Here are my current findings for the “blocking crossup every time” “technique”.
Setup:
SSF2T, mame-rr, frameskip DISABLED.
Guile on 1p side vs Zangief (for no reason other than I had a savestate with this matchup).
Guile throws Zangief to the right and then performs J.LK or crossup J.LK to hit meaty as Gief gets up (crossup must be blocked by Gief holding LEFT).
These scripts have zangief “super perfect block” (press the correct joystick direction on the SINGLE necessary frame to block).
&1 W10 R3.W73._R.W26,U.W3.4.W43.-L.! crossup, block frame
&1 W10 R3.W74._R.W25,U.W3.4.W43.-R.! not crossup, block frame
All good. Gief blocks in both these cases. Inputting the other direction results in the J.LK hitting. All as expected.
Just to confirm what we already know:
&1 W10 R3.W73._R.W26,U.W3.4.W43.-LR.!crossup, block frame
&1 W10 R3.W74._R.W25,U.W3.4.W43.-LR.!not crossup, block frame
If you were able to input both left and right at the same time, it doesn’t matter whether the attack hits crossup or not, it is “double” blockable.
So now to begin the testing of the “block all xups”.
There are two solid “here’s something to test” questions I saw.
#1) Press up for a single frame at some point when getting up, and the act of returning to neutral makes you block crossups.
Here’s a sweep of plenty of frames around the “super perfect block” frame:
#&1 W10 R3.W73._R.W26,U.W3.4.W36.-U.! #7 frames earlier. fails.
#&1 W10 R3.W73._R.W26,U.W3.4.W37.-U.! #6 frames earlier. fails.
#&1 W10 R3.W73._R.W26,U.W3.4.W38.-U.! #5 frames earlier. fails.
#&1 W10 R3.W73._R.W26,U.W3.4.W39.-U.! #4 frames earlier. fails.
#&1 W10 R3.W73._R.W26,U.W3.4.W40.-U.! #three frames earlier. fails.
#&1 W10 R3.W73._R.W26,U.W3.4.W41.-U.! #two frames earlier. fails.
#&1 W10 R3.W73._R.W26,U.W3.4.W42.-U.! #one frame earlier. fails.
#&1 W10 R3.W73._R.W26,U.W3.4.W43.-U.! #crossup, basic up test on “super perfect block” frame. fails.
#&1 W10 R3.W73._R.W26,U.W3.4.W44.-U.! #one frame later. fails.
#&1 W10 R3.W73._R.W26,U.W3.4.W45.-U.! #2 frames later. fails.
#&1 W10 R3.W73._R.W26,U.W3.4.W46.-U.! #3 frames later. fails.
Zangief gets hit in all cases.
#2) Hold up while being knocked down, release into neutral to block crossups.
Another timing sweep:
#&1 W10 R3-_U.+W73._R.W26,U.W3.4.W38.-^U.W10! #zangief hit
#&1 W10 R3-_U.+W73._R.W26,U.W3.4.W39.-^U.W10! #zangief hit
#&1 W10 R3-_U.+W73._R.W26,U.W3.4.W40.-^U.W10! #zangief hit
#&1 W10 R3-_U.+W73._R.W26,U.W3.4.W41.-^U.W10! #zangief hit
#&1 W10 R3-_U.+W73._R.W26,U.W3.4.W42.-^U.W10! #zangief hit
#&1 W10 R3-_U.+W73._R.W26,U.W3.4.W43.-^U.W10! #“super perfect block” frame, zangief hit
#&1 W10 R3-_U.+W73._R.W26,U.W3.4.W44.-^U.W10! #zangief hit
#&1 W10 R3-_U.+W73._R.W26,U.W3.4.W45.-^U.W10! #zangief hit
#&1 W10 R3-_U.+W73._R.W26,U.W3.4.W46.-^U.W10! #zangief hit
#&1 W10 R3-_U.+W73._R.W26,U.W3.4.W47.-^U.W10! #zangief hit
#&1 W10 R3-_U.+W73._R.W26,U.W3.4.W48.-^U.W10! #zangief hit
So far, as mythbusters would say, so far it’s looking busted. The claim is it should work on “all crossups” so chars etc shouldn’t really matter.
If people picked up other ideas on how this technique is performed, I can probably test them out.
Can you try my idea? The idea was block as normal, i.e. hold back, but before the cross up hits, let go. The idea is that possibly as the attack animation starts, the game puts you into block, and then it stays in block as you go to neutral and it auto blocks. Kind of like how when someone forces you to be in block mode, and they maintain a block string you can let go and the game keeps blocking. Not that I think this would work, I think the whole thing is BS but whatever.
Can you also try Down instead of Up?
Thanks for confirming this.
Tested Down instead of up, Zangief still got hit in all cases.
Also tested your idea, which is to hold R while getting up (which would block a non-crossup, but not a crossup), then letting go of the stick at varying frames around the ‘wakeup’ point, i.e.
#&1 W10 R3.W73._R.W26,U.W3.4.-_R.W41.^R.!
#&1 W10 R3.W73._R.W26,U.W3.4.-_R.W42.^R.!
#&1 W10 R3.W73._R.W26,U.W3.4.-_R.W43.^R.!
(again, with frameskipping OFF)
If people are interested in what these scripts are doing, the basic explanation that &n is load save state n, Wn is wait for n frames, LRDU are directions, 123456 are the buttons (except after a W), - is switch to p2 input, _ is hold the following input, ^ is release the following input. Period is advance a frame.
So these scripts are saying “p1 guile press right and fierce (for a throw), wait a bit, hold right and wait a bit (walking), press up while still holding right to jump up/right, wait a tiny bit, do J.LK. Switch to Zangief, hold right (to block a non crossup), wait, let go of right”.
I tried more values than this, but none of them resulted in Zangief blocking.
Some technical details I’ve noticed while investigating this: Zangief’s “player 2 character state” memory value (at address [FONT=Arial][SIZE=15px]00FF8851)[/FONT][/SIZE] while being thrown is 20, and it stays this value until the ‘wakeup’ frame, whereupon it can be 0 (neutral), 8 (“blocking”), or some other values. If Zangief is hit by a meaty, he enters neutral for a frame before entering state 14 (being hit). No ‘turning around’ (value 6) occurs until after he has recovered from the crossup meaty attack (or been allowed to enter neutral), it’s “I’m knocked down” all the way up until wakeup, even if he’s holding a direction, Guile is attacking, or anything. No ‘proximity guard’ type effect seems to occur while knocked down. It’s possible no inputs are really being considered until the neutral frame?
I say state 8 is “blocking” with quotes because it only seems to be ‘entered proximity blocking state’. If Zangief wakes up CROUCH blocking the correct direction, he still enters state 8 for a frame and THEN gets hit. Likewise, if he high blocks a low attack, he enters state 8 for a frame before being hit. I had hoped this state 8 was enough of a ‘correct block’ flag that I could use that as a test, but not quite. I have yet to determine the CPU instruction address which is the “successful block” case.
I have a hunch that this state 8 might have something to do with blocking giving extra frame advantage to the attacker (the attackee is put in state 8 AGAIN for a single frame after recovering from state 14 [being hit], and no such additional state occurs for being hit). I have to do some frame counting before I can confirm this though.
Another potentially interesting thing (although completely off topic) is that a throw tech doesn’t put the character that teched in state 20 (thrown), but in state 14 (hit). Almost as if it converts the throw into a hit of some kind. Certainly no “takes the damage from the throw and then regains health” occurs during a tech. Death from a tech throw either leaves the character that teched in state 0 (neutral) or 20 (thrown) [not sure why it varies at times]. Never the 14 that a tech throw puts them in. Strange stuff.
Anyone else who has fiddled around with memory in SF2 games may want to chime in at this point and tell me I’m hopelessly naive and should be looking at other memory addresses X Y and Z. Please do.
So I take it these all got hit as well? That settles that, myth busted. I don’t think there is any other possibility we’ve overlooked.
Great research and report! Great explanation of how you went through and explained it thoroughly too, even including the script notation itself. (For anyone still hesitant to jump in and try it for himself, notice also that fluxcore’s scripts are basically the same one-line script each time, with SLIGHT variances, i.e. “Wait 41 frames” becomes “Wait 42 frames” on the next line, etc.)
I just wish Wolmar could have tried this out himself directly when he made his video- it was a good method, but apparently something wasn’t quite right. Any comment Wolmar? If you like, you can still try your method and see if you can get it to block from down (or down+left / down+right) to neutral.
Moonchilde I don’t remember now, but maybe it had to do with my particular setup, and I wouldn’t call it “input lag” per se, just the way the game works- but if you don’t see the start up then I’ll take your word for it, maybe what I was noticing was actually the game deciding whether to have my character start walking or the first frame of blockstun.
As for the frameskip disabling, is that a script just telling YOU which frames get skipped or not? Or is it forcing the game to NOT skip the frames that it wants to? I haven’t messed around with any of that yet. You indicate that when it was on, a reversal DP was possible only on one frame for that particular scenario, but when you turned frameskip off (disabled frameskip), you were able to get multiple possible frames to get a reversal DP? Did I read that right?
I assume there was a L/R direction input in there somewhere which corresponded to correct blocking at the right time, but it’s hard to know…
I’m not quite sure what you’re talking about, but from what I can tell if you block incorrectly (i.e. walk into the crossup) there is 1 frame of walk animation before the hit takes effect. This doesn’t seem to exist when blocking it correctly.
The ‘frameskip disabled’ is a MAME cheat code that dammit/d9x made which allows tweaking of the turbo value down to the speed of SSF2. Basically if there are normally TURBO 0/1/2/3 settings, then this is NORMAL, haha! It stops all the frameskipping from happening, anyway, which is very useful for testing things out IMO. Basically testing reversals without frameskipping should give you the same results every time, no matter where or when you perform the setup. And so far they do - there’s 1 and only 1 frame you can input a reversal on (at least, on knockdown, still not sure about these other cases that supposedly have different reversal windows…?). Anyway, that frame always exists in the absence of frameskipping.
With frameskipping ON (i.e. Turbo), you expect to see some variation of the timing for the reversal window based on how many frames were skipped through the duration of the script up to that point. So if you wait n number of frames before the initial action in the script, the script will probably need to be slightly different than if you wait n+1 frames first, simply due to how the frameskip pattern falls during it.
What I didn’t expect to find was that so many reversal frame opportunities still existed. I had thought that if roughly 1 frame was skipped out of 4, you should lose 1 in 4 of your reversal frames too. So being unable to find a reversal frame only once out of ten script start positions is surprising to me.
With thr reversal thing, again keep in mind that theres more than 1 frame. And the frameskip pattern is 32 frames so the only time theoretically where you cant find a reversal frame is if the frameskip pattern starts and ends with a frameskip
Eg 1001001001001001…001
Where 1 is a frameskip and 0 is not. At the end of the 32 sequence pattern is the only place where you dont get a reversal frame. Because when the sequence is looped it will have a segment like
0011001001
Does the state 8 happen whenever anyone blocks, whether they get hit or not?
It almost sounds like a conditional.
Well, my earlier findings in the thread show there is only 1 reversal frame, what evidence do you have that there is more than 1?
I’ll have to think about your claim of the pattern being the reason for missing reversal frames. I guess it would make sense if there are 2 reversal frames, but I don’t know why they would make patterns that would allow for that case to occur (not that that means they didn’t…)
Yes, if you are put into proximity blocking (which includes block the right direction but not the right ‘height’), the character enters ‘state 8’
It’s quite possible it’s an animation state value rather than anything more significant. There is definitely code which is doing conditional checking, and it won’t be too far from where this ‘state 8’ is set, but I haven’t gone looking yet.
So no one has found where collisions are handled?
yeah you’re right. I was basing my post on your non-edited findings… I didn’t realize you edited your post to show there’s only 1 reversal frame till just now…
i’m confused as fuck about how the system works now.
Can you run a script doing the same thing. to show if 1 frame links drop due to the frameskip?
Yep, that’s a very good test to do! [S]I don’t suppose you (or anyone else) have an example of a natural 1f link do you? I’d rather not simulate it with a 2f link as the second-to-third hit in a combo if possible, to minimise frameskip weirdness.[/S]
I found a natural 1f link example, conveniently on dammit’s site about framedata collection (http://code.google.com/p/macrolua/wiki/FrameDataExamples):
cammy cl.MK, far MK (link test)
&7 W10 5.W28,5.! far MK doesn’t come out
&7 W10 5.W29,5.! far MK combos
&7 W10 5.W30,5.! far MK doesn’t combo
So I’ll try muck around with this example tonight.
Also, I found http://sonichurricane.com/?p=1864 which mentions the “2f reversal window”, but Maj doesn’t offer up any evidence for it…