Multiplayer support #25
Comments
|
I support this. Net play would be MUCH harder and really isn’t worth the time. I don’t think anyone has gotten it to work. However. Emulating bolth GBAs in the cloud and streaming it live with a video link would actually work. And simply syncing the battery files at the end of the play session to work. However an implementation like this would mandate a paid service that would be rather unpopular (not like unliked but unused) becuase many people don’t play GBA. Local multiplayer is the best way to go. Like it was with the GBA. If people want to multiplayer there are other options and the switch is not well suited to this. |
|
But with local multiplayer one switch could emulate BOLTH game boys and stream the game to the other switch (should be plenty powerful enough to do this) and sync the battery files over the local link at the end of the play session. This would be tough to implement but it could work quite well. Glitches in the stream would only cause visual issues and audio issues. |
|
And in a full disconnect bolth switches could simply try to reconnect. And if it fails. The host switch could could dump the other players save file to the sdcard and let the players sort it out. There would be a page on this in the manual with instructions on how to get the file to the other player with a PC And make sure multiple save files could be saved. (Ie with a date-time-link.sav) |
|
Tell me if my solution is too ambitious I got the idea from steam link. With proper optimization the switch could do all of this. |
|
It's very ambitious, essentially you'd have to figure out how to encode the video in a way that doesn't interfere with the performance of the game, and send it to the other switch to be displayed with as little latency as possible. I absolutely believe it would be possible, but it would require research into how to transfer video data via local multiplayer. Honestly, doing it over LAN might actually be easier. I still personally think splitscreen would be more than enough. |
|
With such a low resolution and such a high bandwidth available There are already plenty of formats that have minimal compression. We could easily drop the frame rate a bit. Doesn’t the tegra have a hardware codec? |
|
Yeah. Tegra X1 has a HEVC codec suitable for the process. https://developer.nvidia.com/content/tegra-x1 HEVC also significantly reduces bandwidth required to play. If we must we could also half the frame rate to 30fps |
|
Switch is outside of my realm. I could not dream to implement this but with the tegra X1’s hardware codec we don’t have to implement the codec in software meaning it cuts out a helluva lot of overhead and even more work! |
|
And with uncompressed video at GBA resolution were talking about 70 megabits per second. We can half that easily by dropping to 30fps witch is totally enjoyable. At that point we can stream this uncompressed video over the internet xD . We could get WAY more than that on the switch. The switch supports 802.11AC 802.11n can realistically get about 300 megabits. Let’s drop that to half because its never going to be a perfect solution. That leaves more than double the bandwidth our uncompressed 60Hz and arround 5x our 30Hz stream. PLENTY of bbandwidth for synchronizing our sync file every second or so and getting the control inputs from the client switch to the host. The numbers work suprisingly well. The hard part is exactly how we will set it up. Do we create an infrastructure or use Adhok Do we let the users negotiate the connections or do we do it programmatically. I’d like to just have it happen in the background. You start the connection from your game and when the emulator realizes the game is trying to connect it pauses it and starts negotiation. You do the same in the other game and when they find another switch running vba-next Once a connection is established we decide who is host and who is guest. Once that’s done we transfer the rom, gba memory and battery file (in the form of a savestate) to the host which are stored in ram. The host then loads the savestate into the guests emulator and starts a stream. At this point we resume bolth emulators at the same time and wait for the games to work out their magic. While its running we save the battery state normally and transfer the battery file back over the link at a decided rate (once every 2 seconds?) When the communication is terminated via the game we again pause bolth emulators. take a savestate and send it back to the guest where we restore that savestate for single player play and resume. Then we send an OK message to the host. On the host we wait for the guest to sort itself out. Once we get an OK from the guest that nothing went wrong we kill the guests emulator session and call garbage collection. We then delete the battery file and rom we buffered on our own storage from our guest. Then we unpause our emulator. Session finished. If something goes wrong anywhere in this process we stop the link and try to send a savestate back to the guest. If this fails we error out and notify bolth users that something bad happened and where their latest savestate and battery file are located on our own sdcard. We then kill the guests emulator. Call garbage collection and resume our own into single player mode and let the game deal with the desync.
|
|
How does my methodology sound. Any holes in it? Anything need clarification? Am I looking at this all wrong? |
|
We don't even have GPU access yet, so there's a clear no to this one. Besides I think the whole concept of streaming would be a bit of an overkill. The problem with splitscreen is that the emulator architecture is built in a way that allows only one emulator at the time. So probably would need some work on the core emulator to get this one done. But it's far more realistic. Otherwise LAN multiplayer would probably be the easiest to implement, because it can be integrated from other variants of VBA, although I don't know good it's going to end up. |
|
What it be possible to make a hotspot that the other player can connect to inside of VPN next |
|
there is support for hosting a local wireless network in the Switch, which is used quite often in games with local multiplayer(Mario Kart, …). Unfortunately libnx currently doesn't support interfacing the necessary services, so you would have to be in the same LAN. |
|
If it's possible to do it within the same LAN, in theory some or all of the same code could be reused and adapted to the local multiplayer network once libnx has support for it. Plus, having the feature at all (even in limited form) is always nicer than nothing. |
|
Yeah. It’s definitely something that could be viable in the future though if/when libnx is extended to support these features. |
(I'm moving this from the comments on #22)
Several GBA games support multiplayer, for example:
These games especially have a very "splitscreen-like" experience, and having them running in a splitscreen configuration (by emulating 2-4 simultaneous GBAs) would be a perfectly viable gameplay experience for these titles. Each GBA would simply be associated to player 1-4's input on the Switch (this would benefit from #23, or at least single sideways joycon controls).
The one question for implementation - how would you manage save files?
I would personally suggest one of these two implementations:
Netplay, online, or NFC/wireless multiplayer might be far more challenging to implement. The GBA's link cable expects zero latency, and most games will crash or freeze when the link cable desyncs. The only viable alternative I can imagine is to extend the splitscreen functionality in the style of RetroArch/Dolphin/console netplay: button input sync. Rather than broadcasting the link cable data over the internet, each console would simultaneously emulate both GBAs and would synchronize the save data with each other, and would simply broadcast and sync button inputs.
This still has issues with desync and latency of course, so I still don't know if netplay is worth the trouble.
The text was updated successfully, but these errors were encountered: