|
| ||
| Views: 6,895,904 | Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 04-23-24 09:06 AM |
| Guest: | ||
| 0 users reading Wanting a better understanding of Download Play | 1 bot |
| Main - General - Wanting a better understanding of Download Play | Hide post layouts | New reply |
| Blockboy |
| ||
|
Mario Party Netplay Enthusiast Level: 6 
Posts: 6/6 EXP: 591 Next: 316 Since: 11-16-19 Last post: 1395 days ago Last view: 392 days ago |
Hey everyone, while following the development of MelonDS, I’ve been most interested in download play emulation. The main reason I’m interested in this emulator is to achieve Mario Party DS netplay, and that requires download play emulation to be functional. From reading the responses to the progress on download play, the most common thing I see is that the timings are very strict for download play since it assumes you’d be in the same room as the other system you’re connecting to, and even with great internet those timings usually can’t be reproduced online. I want to learn more about how download play works, and I’m hoping someone who knows more about download play can educate me on it.
For example, I have a simple idea to solve the issue of download play timings, and I know it’s probably oversimplified and wrong, but I don’t know why it’s wrong. The idea is basically to set up a middleman between the systems (assuming just 2 systems connecting to each other). Whenever system 1 (the host) requests something from system 2 (the client), like inputs or other information, the middleman would send something to the host. Whenever the client wants any inputs or info from the host, the middleman would also send something to the client. Whenever an input is ready, the middleman simply sends that input through, but if an input is not ready, the middleman would send through something telling it to wait to prevent a time-out. The waiting command could be equivalent to if player took their hand off of the controller, or it could be something else, but the core concept is the same. This would stop the connection from timing out because there is always a response due to the middleman, and gameplay would become more responsive as ping is lowered, just like with other forms of netplay. Basically, it would look something like this: !If the client responds back:
Host to middleman: Give me an input Middleman to client: Do you have an input? Middleman waits X number of ms Client to middleman, within the timeframe of X ms: Yes it is *input* Middleman to host: *input* !If the client doesn’t respond back: Host to middleman: Give me an input Middleman to client: Do you have an input? Middleman waits X number of ms Client doesn't respond back within X ms Middleman to host: *hold input* If download play works more on an interrupt system, then the host can simply do its thing and the middleman would send through an input every X ms. Again, it would be a hold input if the client doesn't respond, and it would be the actual input if the client tells the middleman within the time frame. If anyone could explain why this wouldn’t work, I would appreciate it. |
| SIGMA |
| ||
|
Member Irregular Level: 11 
Posts: 17/25 EXP: 5980 Next: 5 Since: 01-16-18 From: Internet Last post: 392 days ago Last view: 77 days ago |
So where would the middleman exist exactly? Would it be on the hosts end or the client's end? |
| Generic aka RSDuck |
| ||
 Big fire melon Administrator Level: 44 
Posts: 84/593 EXP: 587417 Next: 23868 Since: 10-12-19 Last post: 2 days ago Last view: 2 hours ago |
First of all you're assuming we're sending inputs, but we don't. The games send messages with content we have no control over. And second of all, those packets are being sent every few miliseconds, i.e. multiple times a frame.
The reason local multiplayer with both instances on the same computer (where the latency is effectively non existing) doesn't work well, is because with a frame cap, once a frame is finished we just wait. Which means if you have a fast enough computer, both instances run for a short enough time that they miss each other and thus think the other one died. This could be solved by running both instances in lockstep. Theoretically there are solutions to local multiplayer over the internet, beyond just streaming once instance. Both player could have two instances running and then inputs could be exchanged, which is a "solved" problem (similar to how you described it), see N64 multiplayer or retroarch netplay. But that's all far away and it's questionable how pratical it is. ____________________ Take me to your heart / never let me go! "clearly you need to mow more lawns and buy a better pc" - Hydr8gon |
| Main - General - Wanting a better understanding of Download Play | Hide post layouts | New reply |
|
Page rendered in 0.027 seconds. (2048KB of memory used) MySQL - queries: 27, rows: 80/80, time: 0.018 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |