lulolwenThe build process for sf4e really, really sucks now that I'm on Linux, but it does at least function enough to continue working- bonus and combo notices are saved and loaded, although the semantics of the data is likely incorrect.
JangofattToday is #ultrastreetfighter4 day because my poster & my move lists arrived today. Going to frame the mini poster above my #popeye cab. Probably not going to install the marquees onto the #vewlix. I just wanted to add the move list to spruce up the cab. #arcade #gaming #collecting #taitotypex2 #originalhardware
_FINALLY_ got CI cooking. It's not the way I want it to build- I'd rather distribute MSIs so that no one tries to run this out of the zip and wonders why it doesn't work- but at least I can distribute authoritative builds without my own host's filenames showing up.
Just played the inaugural game of #sf4e rollback over the public internet. Some audio and visual glitches, but no desyncs as far as I can tell. I'm very tired and have a bunch of release engineering to do and a cat to attend to, but my brother's _immediate_ response within 10 seconds of the game ending:
"gimme another"
I think it works.
WE COOK.
My strategy was always to only simulate the UI on forward simulation, but that breaks the KO hitstop and slowdown if a KO gets rolled back. Saving and loading the KO state means we need to save and load pretty much all the UI state to prevent jarring animations.
I didn't think this would be possible, but it is: SF4 does have an intermediary layer that has the current frame index which can be modified, copied, and restored.
Well, that's a problem- SF4's training mode save states don't save inputs that occur exactly on the frame before saving.
GGPO's delta encoding is pretty inefficient in pathological cases- pathological cases that can easily be generated if, for example, you're writing an automated tool to mash inputs as fast as possible to look for desyncs. It's so inefficient GGPO can overflow the memory allocated to input serialization, which is identified by an assert but halts the program- yikes.
Patch here, if anyone needs it: https://github.com/adanducci/ggpo/commit/c88b6676a31b52baa4ba925dab0a652aa62f3569
I wasn't even considering loads happening between update and rendering- there's no rollbacks there, sf4e calls `ggpo_idle()` before the update!
`ggpo_advance_frame()` not only saves a new state, but also frees old ones that are no longer necessary. Freeing a state in sf4e right now actually requires loading the victim state into the engine before freeing it, since freeing the state traverses pointers. So in order to save... we load.
I think I figured out meter flickering for real. It wasn't until I remembered that SF4 has already had weird loading behavior, and sure enough...
It's a bug in SF4's load code. Similar to how loading a training state zeroes your inputs, it also tries to load state of the SC meter sprites. However, loading doesn't set their _position_- only the game update does. It works outside sf4e because loading never occurs between update and rendering.
Offline, non-rollback reproduction conditions for the "flashing" UI. Makes it way easier to debug.
1. Be between 50% and 75% meter
2. Save state
3. Use one EX move
4. Disable HUD updates
5. Load state
6. Re-enable HUD updates
This is a contiguous clip- when Ryu teleports forward, I'm pressing the training-mode load key, but since HUD updates are disabled when I do it, the training mode load icon doesn't display.
#streetfighter #streetfighter4 #ultrastreetfighter4 #sf4 #usf4 #sf4e