What's new

Street Fighter Zero 3 Upper - Finally fixed?

Darksoft

Darksoft

Staff member
Immortal
Joined
Jun 12, 2015
Messages
13,340
Reaction score
20,327
Location
Poland
Good stuff!

To measure this: most modern phone cameras have slow mo video recording.
If you wire up an led with resistor to player 1 button 1 (jamma buttons are active low = led on until the button is pressed, can't remember if JVS is he same) then tape the led to the CRT screen beside a character.

Press the button a few times to confirm the led switches on/off.

Get the character up on screen, record the slow mo video ideally on a tripod, then quickly press the P1 button 1.

Play the slow mo video back. Count the number of CRT beam passes (frames) in the video from when the led light changes (i.e. when the button is pressed) to when the character animation starts.

Really simple test to carry out.
 
Good idea. I'll see if I can rig something up this weekend.
Have you also tested the game during VC activation and custom combos? When I played the game, it had significant slow downs during customs. It might also be stage specific. It was happening to the point where I thought my Naomi was busted.
 
Okay I gave it a quick try just now and I guess it feels better? Can’t really say scientifically. I need to get my equipment and do some actual measurements. The slowdown issues are definitely still there though and I don’t know if you fix that or not. And also if you can add crouch canceling back into it. Kattobi cancels also seem to still be gone and of course other random Upper jank.
 
VodkaGobalsky said:
Okay I gave it a quick try just now and I guess it feels better? Can’t really say scientifically. I need to get my equipment and do some actual measurements. The slowdown issues are definitely still there though and I don’t know if you fix that or not. And also if you can add crouch canceling back into it. Kattobi cancels also seem to still be gone and of course other random Upper jank.
Click to expand...
I believe the sprites are scaled as they were based off the PS1 port before the DC backport to Naomi. I definitely see some shimmering in the backgrounds but I am not sure how this impacts the hurt/hitboxes compared to the PS1 boxes. I believe many if not all of the hurt/hitboxes were different in the PS1 port and now this is carried over to the Upper release.
 
~33F of lag (~550ms) is a surprisingly slow result, even if I'm aware of the SFA3U's reputation of being laggy. I'm not sure this is directly comparable due to methodologies used, but the inputlag.science website shows CPS2 usually has about 2.6F of lag, so even if we subtracted 3F from the result, that's still pretty awful.

For context, I recall the natural delay of Warcraft 3 using battle.net back in 2004ish to be around 250ms... Half the amount of lag for a game that was built with 56k modem players in mind. That felt pretty bad and it was a revelation when private servers like Garena with reduced delay was introduced.

I'll have to fire up the game myself and give it a try again since I've never put any real time into SFA3U before... If I ever get the motivation to drag out the mess that is a Netboot setup.
 
It’s not 33 frames of lag on the button press rather how long it took for the video capture to register a change. As I have said in the video, the capture itself has latency. Whether it is the capture card or OBS. But that duration doesn’t matter because both versions were tested with the same setup. I expected the updated version to be faster than the original and it was not.
 
VodkaGobalsky said:
It’s not 33 frames of lag on the button press rather how long it took for the video capture to register a change. As I have said in the video, the capture itself has latency. Whether it is the capture card or OBS. But that duration doesn’t matter because both versions were tested with the same setup. I expected the updated version to be faster than the original and it was not.
Click to expand...
Please try the other 2 versions I have attached you If you haven't unmounted the setup, please
 
Several of you have contacte me asking for more information about this fix.

As I said, I got the request from @Tailsnic Retroworks to fix this as people were claiming 7–8 frames delay. I have found more or less several places that if fixed, they could account for ~5 frames delay.
  • JVS, 2 frames: the I/O board
  • Render, 3 frames: the graphics library's default mode sends frame k to the PowerVR vertex processor (TA) at V-blank k+1. Rendering takes place starting at k+2, and the frame is displayed at k+3.
I could optimize up to a total of 5 frames, plus the game's own inherent reaction frames (which the CPS2 also has).
I decied to fix the Render one. The game initializes the library with flags 0x00100000 (PC=0x8C34DCDC).
I changed the 0x00 to 0x10. This mode is supported by the library; in fact, the library uses 0x00100010 as its default configuration.

With bit 0x10 enabled, the library itself sends the lists to the TA at the end of the frame. This is already used at PC=0x8C36A160.
This way, rendering starts at k+1 and the frame appears at k+2.

There is one byte at file offset 0x32DCDC (0x8C34DCDC), 0x00100000 → 0x00100010. What I achieved with that bit set, is that 0x8C36A160 hands the display lists to the PowerVR vertex processor (TA) at end of scene instead of doing that int V‑blank ISR, so the frame reaches the screen one V‑blank earlier.
 
You must log in or register to reply here.
Back
Top