You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi there, I have limited knowledge on the subject, but my understanding is that the networking of this port is adapted from Chocolate Doom code. I imagine that what this entails is that the base game ticrate of 35 per second is being used for communication logic.
When playing the game even in solo netplay with the framerate uncapped / set to a rate higher than 35, the frames get blended together in a way that is rather headache inducing. While the obvious workaround is to limit the framerate to the vanilla 35, this is obviously not the most ideal solution in a port that otherwise handles frame interpolation really well.
I was wondering if there's any potential solutions for playing above 35 that could be looked into? I know this isn't a multiplayer focused port, but I can see this being good for those who want a more conservative multiplayer experience that has compatibility up to the MBF21 mapping standard.
The text was updated successfully, but these errors were encountered:
This is more of a question/feature request as I don't really have the know-how to contribute. I realize this is a niche use case and I don't want to sound entitled that this is something that needs to be prioritized or anything like that. Just was interested in opening a dialogue about it to see if people would think it would be worthwhile to look into at some point.
Have you tried running a network game with the -oldsync command line parameter?
There are plans to improve netcode using rollback techniques. This should allow demo compatibility with old multiplayer demos, but I'm not sure if it will work.
That's a cool idea, I know that the fighting game community pretty much relies on this nowadays for competitive.
I can confirm that at least when doing solo netplay, the -oldsync parameter does in fact resolve any weirdness with the frame presentation. I haven't had the time to test with two devices over a large distance to see if that holds up though.
Unsure if this should be marked as resolved or if the issue should be renamed. Thanks for the workaround for the time being.
Hi there, I have limited knowledge on the subject, but my understanding is that the networking of this port is adapted from Chocolate Doom code. I imagine that what this entails is that the base game ticrate of 35 per second is being used for communication logic.
When playing the game even in solo netplay with the framerate uncapped / set to a rate higher than 35, the frames get blended together in a way that is rather headache inducing. While the obvious workaround is to limit the framerate to the vanilla 35, this is obviously not the most ideal solution in a port that otherwise handles frame interpolation really well.
I was wondering if there's any potential solutions for playing above 35 that could be looked into? I know this isn't a multiplayer focused port, but I can see this being good for those who want a more conservative multiplayer experience that has compatibility up to the MBF21 mapping standard.
The text was updated successfully, but these errors were encountered: