Project64 Dev Forum

W.I.P Dev => Project 64 1.6.1 Dev => Netplay => Topic started by: Witten on December 31, 2011, 09:26:55 am

Title: Netplay... ideas and questions.
Post by: Witten on December 31, 2011, 09:26:55 am
Smart clients: each client runs pj64 with emulated core, pi input is sent in both directions
-each client is different... how to sync the cores? ProgramCounter difference too high, pause CPU?
-how to deal with ramdom generated numbers?

Dumb clients variant 1: client receives dlists and alists to process, pi input is sent to the server
-synced using vi and ai events?
-bandwidth limitations? how much data?
-do dlists and alists need RDRAM?

Dumb clients variant 2: audio and/or video streaming, pi input is sent to the server
-bandwidth limitations? resolution limited?
-how much power is needed on the server side?

Please share your insight and remarks on this topic!
Title: Re: Netplay... ideas and questions.
Post by: Gent on December 31, 2011, 11:27:09 am
straight away i will ask are we talking UDP or TCP here? afaik kaillera uses UDP and is the incredibly crap, so any netplay port primarily should be looking towards TCP imo.

Next comment is whoa Wit, you have been sleeping on this a bit and milling it over, i like it.

Title: Re: Netplay... ideas and questions.
Post by: Jabo on December 31, 2011, 05:51:05 pm
i would get in touch with the guy who made that netplay plugin we have been using he has this nicely done

that being said technically speaking the way I've always implemented netplay is purely sending input (for N64 this would be the PIF command results) back and forth over the wire.

trying to synchronize the actual emulated states will probably not work, it's too much data and since the timing of Project64 is so inaccurate there's the chance each side might have slightly different timing.

another challenge is going to be keeping things consistent ... with timing so inaccurate you have to come up with a way to make sure that you are sending/receiving in a consistent way. One way for the N64 I did this was just doing it simply on every PIF read... but I can't really decide if that's all the criteria that should be considered.
Title: Re: Netplay... ideas and questions.
Post by: azimer on January 03, 2012, 04:43:20 pm
Hi Jabo!  Happy new year old friend!

If you are looking for the most successful netplay, you need to control all the variances from external sources: plugins, controller reads, core config settings, etc.  If both emulators are identical and start in the exact same state, you will never go out of sync as long as the input stays in sync.  I hope that gives you something to chew on.

graphics and audio use rdram->imem and imem->rdram DMA extensively.  Personally I would do delayed input reads on vsync, lockdown the settings, and emulate all the exceptions within the core instead of the plugins.  You now have the same environment regardless of which plugins the end user chooses.
Title: Re: Netplay... ideas and questions.
Post by: Hacktarux on February 06, 2012, 02:16:23 pm
I totally agree with azimer. If i had to start somewhere, i would look at the audio interrupts. If i remember right, in pj64, it was generated by the audio plugin and based on the host pc time. Obviously it is totally wrong. You must estimate the amount of emulated cpu opcodes required to play the buffer and generate the interrupt within the core.

There are potentially other sources of variances but this is probably the most obvious.
Title: Re: Netplay... ideas and questions.
Post by: icepir8 on February 23, 2012, 08:41:08 pm
My idea is to use a client/server setup.
Server would run the core emulation and send the graphics/audio commands to the client.
the client would do the rendering and audio playback
the client would send the controller infromation to the server.
The client should cache the textures and vertex data.
The client can requests textures/vertexes from the server.
Azimer sugested that it probably would be best to process the Audio List at the server and stream the audio to the client.
I think that the connections could be UPD and just ignore incomplete frames.
I would have a seperate port for each graphics, audio and controller, and a set for each of the players.
When connecting the client would request the next availible controller and connect to the assigned ports.
also the server could support connections to let non-player clients connect to the server so that game play could be watched and recorded by other persons.
The existing plugin system could be used but a new plugin interface could be defined for an all in one plugin instead of multiple plugins.