I'm also not very confident that the compatibility rate will be on par with the tried and true LLE approach, but the only way to find out is to try out. I will need to clean it up and implement a bunch of the more minor details. The current implementation is also a bit of a pile of hacks. On the other hand, I don't have it working yet. On one hand, the way wifi works at a high level seems to provide enough leeway that I could get away with somewhat lax sync, and thus better performance. It's too early to tell, but if I can get it working, it may be a good base for local multiplayer and netplay on lower-end platforms, as I said before. So far, I got to the point that there's some data exchange going on, but the connection isn't working due to a timing problem - I need to rework when I send data frames and how to keep all the melonDS instances in sync. However I've also been able to do some melonDS-related work. I've mostly been chilling, bathing, toasting under the Summer sun, pretty standard vacation stuff. I've been taking some vacation time, so this helps a lot, too. Been tired, a bit of a depression burst, medication adjustment and stuff, but overall I'm doing well. So yeah, I have been pretty silent lately, sorry about it. HLE, wifi, netplay: recent developments and ideas I thought that in theory it should be possible to send the CMD frame to clients early, and even have the clients send their reply early as soon as possible, and delay the actual emulation of the CMD/reply/ack exchange until the end of the CMDCOUNT window, and thus things would run more smoothly.ģ comments (last by Julian) | Post a comment The first way would be to abuse the pretty generous CMDCOUNT window games use when sending a CMD frame. I came up with two ways to work around this, and experimented with them, but so far they both have issues. From a performance standpoint, this is far from ideal - it largely negates the benefits of multi-core CPUs. ![]() This means that in our case, with the current sync mechanism, clients will spend a whole lot of time waiting for a CMD frame, then having to catch up a whole lot while the host is waiting for reply frames. Pictochat is a bit different - it does send CMD frames every ~4ms, but it also does that thing where it polls 3 or 4 clients per frame in a rolling order, so it amounts to a pretty similar thing anyway. In most games, the host only sends a CMD frame once per video frame (that is, once every ~16.67ms). However, I observed that local multiplayer exchanges aren't as tight as I thought before. And the host discards stale reply frames to prevent itself from running too far ahead. Clients may not run ahead of the host - when they receive a frame from the host, they know how much they need to catch up, when to start actually receiving that frame, and in the case of a CMD frame, how long they can run ahead before waiting for another frame. It is actually fairly simple: each frame that is sent has a timestamp attached to it, that is used to keep things in sync. Since version 0.9.5, melonDS uses a synchronization mechanism to ensure this works smoothly. However, the CMD frame and subsequent reply frames use the 802.11 duration field to reserve the needed timeslot for the entire CMD exchange, so that everything can be pretty tight. In a real world setting, you'll want to ensure your wifi channel isn't being used before sending stuff, so that's what the delay is. The CMD frame isn't sent immediately, there is always a variable delay before. I've been experimenting, but for now, nothing really conclusive came out of it.īasically, if you remember your local multiplayer 101, this is how it goes: In the previous post, I mentioned I had an idea to optimize LLE wifi. If you're running into trouble: Howto/FAQ
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |