Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
This is how I imagine GBA network multiplayer .
I read a message from the admin of this forum where they shared how they imagined the online multiplayer, something involving the two machines involved doing the complete emulation for both mCores.

That was featured by the admin as something hard to implement and the problem to do traditional communication between the two machines each one with one mCore was the tight timing required that discards the chance to do that without risking to frequent timeouts.

I have come to think that other way that is between these two may exists and I am trying to implement something similar.

We know local cable link communication in a single machine between multiple mCoreThreads already work almost flawlessly. (At least for the games I tried.)

Then a approach that I thought may be worth to try is that every mCores involved in the multiplayer is played in a single machine, the Host, and every other machine involved is simply a Client for that Host that receives via network sockets the video and audio and sends the emulation input for its core like key presses.

And what it is better, it can be done without the user even noticing without "restarting" the emulation thanks to savestates.

In a hello packet the client sends its rom and its savestate and magically the emulation continues in the remote host.

I do not know if the forum will penalize me or delete the message if I share the git repositories of my proof of concept using libmgba to achieve remote emulation, so I will share it in a follow up message.

(I have been kindly asked to stop using the github issues of mgba as a support forum.)

These are the codes, still undocumented, but obvious to configure/compile to someone that knows Perl and C.

I will document it more when I actually achieve something more than simply getting the remote video.

This is basically the same thing that Multigba S does on Android, but it introduces several issues:

1. Latency leading to input lag. Rollback netplay can't really fix this due to the fact what the user on the other end sees is just several frames behind what is actually happening. It would probably wind up being a stuttery mess to fix this, especially with higher latency concerns.
2. Video bandwidth requirements are rather high, compared to gameplay bandwidth. It's tractable for many users, but it's still higher than a proper every-system-in-sync approach.

Forum Jump:

Users browsing this thread:
1 Guest(s)

Powered By MyBB, © 2002-2024 Melroy van den Berg.