Street Fighter Zero 3 Upper - Finally fixed?

I dont know what @HDemon did to this game but this fix is done 100% by me without using information from anyone.
 
IMG_9730.jpeg
 
LOOOL. That was a comment that I saw in the video uploaded to Youtube. I'm confused as well
 
I dont know what @HDemon did to this game but this fix is done 100% by me without using information from anyone.
You bastard! 😄

I was about to get back to this! XD

I was trying to port the changes from Capcom Fighting Collection 2 to NAOMI, but I hit a dead end. I also had some personal issues going on, so I ended up leaving the project.

Congratulations, and thank you for achieving this!
 
The important thing is not the frames. It's that now you can do the combos. Of course lag has improved as well.
 
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.
Top Class Wizardry right here! :thumbsup: Thank you!
 
What is NEON B build?

The version published here by Darksoft is A. The other 2 versions I gave you are B and C (discarded)
 
Great video @VodkaGobalsky
My goal was to make it possible to execute the combos first then remove delays. Do the original and Neon B allow for combos like the cps2 version? Did you use the same JVS in all tests? If there is a version with sometimes one extra frame, I can look into that, but now with my version finally combos are active again and that's what was stopping people from even making competitions with this game.

Where can I get that neon-b version?
 
Last edited:
I have not yet tried versions B and C. I got it from her directly. You can DM her on Twitter. https://x.com/neonbitchi. She reached out to me since she’s been hacking Upper on her own and doing other various random projects and needed help testing on real hardware. I’m using the same JVS for all the Naomi tests. While doing all this is great and a fun demonstration, I’m going to be honest with you guys here, Upper won’t become an anything more than a novelty. I don’t see it becoming competitive. Actual players playing A3 will stick with vanilla. There’s just too much jank with upper even if you fix all the performance stuff. Plus nobody has an easy way of actually playing the fixed version. Best they got is A3 Upper on cfc2 and barely anyone is playing that. That being said, the 2 main issues with Upper from a performance standpoint are
1) input lag
2) the slowdowns during the game especially during VC activation

Gameplay wise,
1) lack of crouch cancels
2) different guard damage calculations from original
3) other various gameplay differences that some may or may not care about such as no meter build on whiff grabs, no kattobi cancels, no true gouki unblockable setups. These are just some off of the top of my head but sure there are more.
 
Back
Top