|
|
|
#1
|
|||
|
|||
|
Hello everyone. I've been working on an input plugin that supports netplay. I've attached it to this post for people that want to try it out. This is meant to be a workaround until zilmar implements netplay directly in Project64.
Instructions:
Golf Mode: To turn golf mode on and off, use the "/golf" command. Every player must turn golf mode on for golf mode to work. What golf mode does is allow certain games to be played with absolutely no lag no matter how much latency there is on the connection. It will only work with games where only one player plays at a time. The reason it is called golf mode is because I designed it specifically for Mario Golf. To use golf mode, wait until it is your turn to play. Before you play, press the Z button. What this will do is set your own lag to 0, but set everyone else's lag to what your lag was previously set to. Now you are free to do your turn without any lag. When it is someone else's turn, they will simply to the same thing. I chose the Z button because it is unnecessary in Mario Golf. I could always change this or make it more flexible if people find use for golf mode in other games. Notes: From my experience lag is fairly low and often not very noticeable. It is much better than my experience with Kaillera. Of course, the huge advantage of the netplay plugin has over Kaillera is that it works with Project64 1.7, the best N64 emulator in my opinion. You can use the netplay plugin with other N64 emulators, too. However, in my experience, most of them, including Project64 1.6, will desync while playing a game. I have never had a desync occur while using Project64 1.7 though. I recommend going to Options, Settings, and unchecking "Pause emulation when windows is not active?" That way you can adjust the lag easily while the game is running. Otherwise, every time you click the window that lets you adjust the lag setting, the game will pause. Let me know if you encounter any bugs. Enjoy Project64 1.7 with netplay support! Changes: v0.20:
v0.13:
v0.12:
v0.11:
v0.10:
Last edited by aqwertyz; 2nd October 2011 at 09:41 PM. Reason: Uploaded v0.20 |
|
#2
|
||||
|
||||
|
Sweet I must try this out tomorrow.
One initial curiosity though. What about like, using the plugin on other emulators? What's it like to make the plugin a NetPlay plugin that interacts with any N64 emulator using the plugin spec of Project64? |
|
#3
|
|||
|
|||
|
You can use the plugin with other N64 emulators. In fact, you can use two different emulators at the same time. For example, I tested Mario Kart 64 with Project64 1.6 and Mupen 0.5. I finished the first lap of a race but then the game desynced. I hit a banana on one emulator but not the other. However, so far I have never had a desync occur when everyone was using Project64 1.7. Everyone must have the same save file when the game starts though. The games I've tested this with so far are Mario Party 1, 2, and 3, Mario Golf, Mario Kart, Diddy Kong Racing, and Snowboard Kids 1 and 2.
Writing an input plugin that supports netplay is tricky. Obviously zilmar did not design the spec with netplay in mind. However, it seemed like it was possible so I decided to find out. I made a much simpler version of this plugin and was pretty surprised to find out how well it worked. That was about a year ago. More recently, I decided to make a nicer version so I could post it here. Basically, the netplay plugin pretends it is an emulator and loads another input plugin for getting input. That way I didn't have to reinvent the wheel when it comes to reading input from the keyboard or USB controllers. When the emulator asks the netplay plugin which buttons are being pressed, the netplay plugin gets input from the input plugin it is using, sends that data over the internet to the other netplay plugins via the person hosting the server. The server responds with every other player's input data. Then, the netplay plugin is able to report everyone's input data back to the emulator. It is more complicated than that though because each netplay plugin buffers the input data based on the lag setting you pick. This is necessary to deal with the delay it takes to send packets on the Internet. I forgot to mention this, but the netplay plugin does not support raw data or the use of any packs (memory, rumble, etc.) This was to prevent desyncs. Last edited by aqwertyz; 19th May 2012 at 05:38 PM. |
|
#4
|
||||
|
||||
|
Oh great thanks for the info, but it's pretty clear now why this was designed as a solution for people with Project64 1.7 and not between different emulators if desync can happen randomly. I understand basics of NetPlay science from reading info off the Kaillera site though, but yeah...how did you write this plugin even though NetPlay functions weren't designed in the Controller section of the common plugin spec?
Why is disabling memory pak emulation to help prevent desync? I imagine the reason wasn't if everyone isn't using the same exact controller pak file binary, because well...that can be arranged, so was there some technical reason? Connect -Host: "LOL" -Port: 27999 "No such host is known." awww ![]() Heh anyway as you can see I gave this a test, although I haven't picked someone to play to test this with just yet. So I have questions on, Step 4? When it says send a save file for that game to the other players, does that happen automatically, or do I do it manually? Cause I noticed after step 3, I just go to step 5 then it works. Or I guess you just mean "Make sure the save file in $emudir\Save is the one you want your adversaries to use during the game." Yeah, desync can happen really easy if everyone isn't using the same save. Well apparently I made it up to step 7 anyway. Okay so I leave it blank, and the others should know what my IP address is if they want to join. Very simple, thanks. So yeah in 1 player test, setting the lag to 0 / as low as possible had no effect on the speed, and that I think is because with one player there is no transfer between other participants and the NetPlay server. Oh yeah about the pause emulation when window is not active, I think Kaillera completely disabled pausing the game while a NetPlay game is in session iirc. Just a note I recall. Or maybe the pause from the host can be sent to the other players' emulators as well. |
|
#5
|
|||
|
|||
|
I was able to write a netplay plugin as a controller plugin because controller plugins are what feed the input data (which buttons are being pressed) to the emulator. That is how netplay works. As long as everyone's emulator is receiving the same input data from one frame to the next, the same events occur in the game.
I mainly disable memory packs because I didn't want to take any chances with desync. Those features work by exposing raw data to the controller plugin. I really don't know any more details about it, so I turned it off to be safe. Maybe I will experiment more with it in the future. If you want to test the netplay plugin alone, do this: Make an entire copy of the Project64 folder so you have two Project64s. Open two Project64s. Start the same game in both emulators. In one emulator, leave the host blank and click start server. In the other emulator, use "127.0.0.1" for the host and click connect. 127.0.0.1 is the loopback interface, so it means you will connect to yourself. Now, in either emulator, click Start Game. My plugin cannot send save files to other players because input plugins don't have access to that information. The user has to do it manually. When you play alone or test the plugin on your computer with multiple emulators running, lag 0 will work fine because there is no network delay. |
|
#6
|
||||
|
||||
|
Very, very cool. Well done, sir.
I've played SSB with a buddy of mine back home, but that's as far as my testing has gone. As you said, it works much better on 1.7 than 1.6, or any other emulator for that matter. |
|
#7
|
|||
|
|||
|
I know I have not gotten net play in to the core, something I wanted to do. 1.6 has fundemental issues that would cause the game to desync. A lot of the work is done to make 1.7 stable so that it would not desync.
At some stage I will get it in. I hope you enjoy the plugin your using. |
|
#8
|
||||
|
||||
|
aqwertyz I'll get to the self-connect test method, just setting this up for someone else on here to test this out with. I just noticed that if you end emulation then restart it with the same plugins, Project64 crashes with the fault module name stated as your plugin. I wonder if that has something to do with that question in the other thread about the movement of the closeROM() function. Going to test this with a buddy then do what you said. Even when NetPlay is internally added to the emulator it's still really cool you made this--as well as useful for other emulators.
Mr. zilmar lol don't worry we will. |
|
#9
|
|||
|
|||
|
I tried what you described but I can't seem to cause Project64 to crash. Which input plugin did you use with the netplay plugin? Were you using the most recent version of Project64?
|
|
#10
|
||||
|
||||
|
Yeah I think so, Project64 build 50.
I was using N-Rage's DirectInput 2.00b (overhaul version by rabiddeity). I tried it again, though, and it didn't happen. IIRC it was before the part when you plug in a controller for each player, but I haven't reproduced it since then. Well I have Vista anyway. |