Street Fighter Alpha 3 Max broken in more recent (or at least post-1.9.3) builds

[AdamN]

(05-24-2020 03:28 PM)Adhenovan Wrote:  

(05-22-2020 05:36 AM)AdamN Wrote:  As far as i know most of the freezes (permanent freezes) are either due to using blocking socket with infinite timeout (0), OR due to access violation exception within PSP side (crashes with fast memory or freezes without fast memory) probably due to register/memory corruption during a callback/mipscall, while minor freezes (short freezes) are usually due to lost packets

Currently i'm trying to implement a better blocking socket implementation by using sceIo as references to fix the freezes related to blocking sockets, but hecks i don't even understand how sceIo works LOL

well i cannot figure it out either how to not block the main emulator host os thread even tunneling project aka amultios protocol all use non blocking operation. as all of the packet is queued on another host os thread and use compression alot it can travel on network very fast. i don't even understand how ppsspp main thread work to just continue the emulation and not waiting the packet as its already processed in the background instead of inside HLE call.

looks like we re working on same issues actually need to figure it out how to make better blocking socket. the timing is so sensitive here so i need to delay some packet that arrived too fast or just block when its not arrived and give up. most of our packet timing is faked in getState or getPeerList the game that broke by this implementation is Digimon World Re:Digitize . Monster Hunter is fine if the packet time that fake time received can handled properly.

the one that make game permanent freeze is for sure is on sceNetAdhocctlInit function that not implement another psp thread do its work (friend finder etc) if we fail to connect into adhoc control (proadhocserver) just create the adhoc control and update it later from the real server. this is what real psp do update the control later when we re connected like peer and such. we cannot rely on single point of failure here were simulating adhoc network the create is never fail if its meets the requirement based on previous HLE call. ppsspp just return the error wrong code often if we fail.

already implement this partially in amulios protocol but not really create the adhoc control thread on psp kernel yet to make it work properly. we have some error like ERROR_NET_NOMEDIUM << this can be used if the control is not connected but create should be never fail. there is an issues on digimon that i use to dig this behavior how the game use the adhocctl function with some proper test on 2 PSP . still waiting on another of my 2 PSP to arrive.

another short freeze is that timeout 0 on blocking socket yes its waiting for packet but we must avoid blocking the hle thread . just keep the networking thread in host background running and poll from there with the timeout parameter. game like tekken is really helped with this implementation especially over internet as we re always have packet if there is no packet in the background then thats means the connection sucks :v . on local play its looking really good relying with this implementation.

right now im working on something that like SocketManager , NetPlayProtocolManager , and some of PacketManager to handle the packet in the background and sync that with the emulated sceNetAdhocPdp and sceNetAdhocPtp so we can simulate the timing better. looks like we re getting into working on sames issues to be resolved on https://github.com/hrydgard/ppsspp/issues/10832

I didn't like current AdhocctlInit either LOL because some games try to connect to adhoc server as soon as it booted and if a player is pausing by going to PPSSPP settings for too long, it will get kicked out of adhoc server and the game need to be rebooted in order to reconnect which is troublesome

If real PSP can reconnect later it does make sense, no wonder it need to be faked to success to prevent some games from stuck/freezing forever if error was returned.

Regarding blocking behavior implementation, sceIo is a good example as it have similar function (ie. Read/Write which usually have blocking behavour also on a real hardware)

[nadaking]

Serious question - why can't we get this version going with some sweet GGPO netcode and just make this the defacto version it should be?

It would be so dope to be able to set up tournament lobbys and shit too

right now when i connect it just immediately says 'connection closed'. but that doesnt matter if it is delay based netcode anyway

[Zinx777]

(06-13-2020 09:09 PM)nadaking Wrote:  Serious question - why can't we get this version going with some sweet GGPO netcode and just make this the defacto version it should be?

It would be so dope to be able to set up tournament lobbys and shit too

right now when i connect it just immediately says 'connection closed'. but that doesnt matter if it is delay based netcode anyway

I think its because netcode is not emulator dependent but game dependent.
You cant make the emulator network handeling better for the games (maybe for some few cases i think).
Better to just play the 30th year collection on steam or play on FBneo.