[$threadinfo[title]]

[orbitaldecay]

Are there any plans to implement any network multiplayer features in any upcoming releases of mupen?

[Tillin9]

Its on the todo list, but currently not a priority. Netplay won't be in 1.4 (which should be coming soon) and probably not in 1.5 either. Sorry.

[orbitaldecay]

No apologies necessary, I'm a programmer and I was considering tinkering with it myself, I was just wondering if anyone else already had the idea in the works. :bouncy:

[Tillin9]

Well then, let me be the first to say welcome aboard. :) As far as dev. progress on netplay, Okaygo had been responsible for the Mupen64k netplay build using kaillera. Sadly he lost the source and open kaillera does not seem to have a bright future due to license issues with the new kaillera owner.

To that end, it was suggested we pick another cross-platform netplay library. I wasn't aware of any, but Slougi knew of a few and gave me some links in IRC. Since I'm not a networking expert, nor really in a position to test which was better, I decided to focus my efforts elsewhere.

I'd suggest you help with the porting efforts since if we have a single codebase building and working (to some degree) on all three major platforms (Linux, Win32, and OSX) we'd be in a better situation to evaluate and implement netplay.

[orbitaldecay]

Yes, I've been looking over the source from the svn and I was thinking SDL_net might be a nice choice being as that mupen already uses SDL for input and video

[nmn]

To be honest, SDL_Net is actually a pretty bad networking library - Using Win32 and POSIX sockets seperately may be better, because they are very alike. Nonetheless, SDL_Net does have everything we need (I think) so it can be done.

[DarkJezter]

SDL_Net is actually a pretty bad networking library

Any idea what issues exist with SDL_Net?

[orbitaldecay]

Yeah, win32 and posix sockets aren't difficult to port between either, the function names are mostly the same. What issues with SDL_net have you experienced and/or heard of?

[Tillin9]

The only objection I have towards SDL_net is its low-level, but so is posix sockets (and win32 is basically the same since MS took that from BSD). I actally think SDL_net is a good cross-platform library as that's what Blizzard uses.

However, ideally we wouldn't have to re-invent the wheel and could use a higher level library that could handle some of the synchronization issues with actual gameplay and some of the lobby functions necessary to find and initiate multiplayer itself.

[okaygo]

I can help with the multiplayer aspect ;)

Things to remember:

Key data must be sent everytime there is an interrupt to query keydata.

Other than that, the games should sync.

[nmn]

The only objection I have towards SDL_net is its low-level, but so is posix sockets (and win32 is basically the same since MS took that from BSD). I actally think SDL_net is a good cross-platform library as that's what Blizzard uses.
Wow, I didn't know that.
SDL_Net is OK, but compared to the native libraries it lacks a lot.

However, ideally we wouldn't have to re-invent the wheel and could use a higher level library that could handle some of the synchronization issues with actual gameplay and some of the lobby functions necessary to find and initiate multiplayer itself.
Well, if we want it to be as optimal as possible, no. Since for this type of netplay not much can be done for optimization, using another networking library with a crapload of functions for syncing sprites and other things would be useless, and maybe even limit our ability to minimize bandwidth.

That said, most optimization techniques i can think of are at a higher level than the packets themselves, like buffering input + zlib.

[robotman5]

Actually theres one for project64 its called Project64k

[X-Fi6]

Actually theres one for project64 its called Project64kYeah everyone knows that...

There is even "Mupen64k" which is basically the old version of Mupen64 that has Kaillera support in it. But it's not being worked on anymore AFAIK and it's from a different guy than the Mupen64Plus team. And again it's only the old version of Mupen64.

[okaygo]

No, I am the same guy who made Mupen64K, and Mupen64++ (Not Mupen64Plus, Windows only) And am also a developer for Mupen64Plus

[nmn]

Yes, he is the same person. (I know you edit Wikipedia so don't change the Mupen64 article which maintains that this is the same person. I'm more worried that you already did than you will after reading this, but I'm just way too busy and lazy to check right now.)

[civilian0746]

http://kaillera.movsq.net/temp/n02_scG.png
http://kaillera.movsq.net/temp/n02_scI.png
may not work with emulinker and emulinker sf server since theyre both incomplete

[okaygo]

Civilian, Kaillera is god awful... we are writing something more flexable for n64. But great job on getting a linux port for KDE...

[civilian0746]

It's not a KDE port but thanks for the attempted compliment. Kaillera is indeed limited. I'm also working towards a replacement in my spare time. Being a full time student sucks.

[nmn]

KDE looks cool but not that cool ;)
That's a nice looking GUI. Did you write it yourself?

[civilian0746]

Totally dood. My own widgets...my own windoing system... my own version of X...my own version of distro...everything was coded from scratch... also my own designed hardware...even the cpus used on the computers the package was developed in were made on my handmade microchip factory...



No I'm not that retarded. That cute little windowing system is part of a package called juce. It was the smallest and the best looking one among all the ones I've tried. Those windows and everything look identical in windows and mac as well. I should really be thanking juce... I didn't port that client to linux for the longest time because of the gui ambiguity stuff.

[nmn]

No I'm not that retarded. That cute little windowing system is part of a package called juce. It was the smallest and the best looking one among all the ones I've tried. Those windows and everything look identical in windows and mac as well. I should really be thanking juce... I didn't port that client to linux for the longest time because of the gui ambiguity stuff.

Huh? Honestly I thought it looked cool. I meant it didn't look like KDE as in the widgets on it looked cool and i knew that wasn't a standard Qt window. For something like Kaillera, that's perfectly fine to do. I know on OS X they probably bit you up for integration though. Man do they love integration.

I've written my own widgets in the past and they've looked cool at times but never really that good... Usually it was all stuff written atop OpenGL and GLX - heh, writing your own widget system in X is perfectly fine compared to doing something insane like using OpenGL for it :P

[civilian0746]

Huh? Honestly I thought it looked cool. I meant it didn't look like KDE as in the widgets on it looked cool and i knew that wasn't a standard Qt window. For something like Kaillera, that's perfectly fine to do. I know on OS X they probably bit you up for integration though. Man do they love integration.

I've written my own widgets in the past and they've looked cool at times but never really that good... Usually it was all stuff written atop OpenGL and GLX - heh, writing your own widget system in X is perfectly fine compared to doing something insane like using OpenGL for it :P
Using OpenGL should be perfectly fine too. A lot of games should have widget like things implemented on top of D3D/OpenGL. Coding widgets are fine. It's a vary simple concept and there are tons of them around to prove that to be the case. But well how should I put this...for something like that client...if you add writing widgets to the list => the project will end up being more about that widgets instead of what it is. It's like bringing in tanks and cannons to kill a fly.