[Request] RetroArch - OpenXband Project

General Development
#1

Long - But important post warning …

Retroarch’s cross platform netplay support makes Retroarch the greatest damn emulator ever… It has one problem that shouldn’t in theory be too hard to solve? <— Subjective, as the rest is directly related to my teams implementation needs

History : Imagine a free / cross platform front end that has some cool features in it. (If you already know what the Sega / SNES Xband modem is you can skip ahead)

A few years back myself and my team rocked a huge undertaking writing a frontend for Zsnes. We’ll use mario kart for snes as an example. You would choose what game you wanted to play from a currently supported list. Our servers would matchmake you with someone… It would execute the emulator and rom, and then watch the hex of the emulator. When it determined who won the match, it would report back to our server and drop the ranking stats in our database. We’re talking adding matchmaking and ranked play to retro games!

It was decently successful but it had one major problem… NAT Traversal!

My team would love to dedicate our time to making a really cool / badass looking / cross platform user community for retro arch, including adding more and more support for games, but we could never find a cross platform netplay emulator… until now.

My question : Would it be possible to make a dedicated server application that could work with a stable fork of RetroArch so that NAT Traversal wasn’t an issue? Something we could basically send a userID to, and it would exchange the UDP packets between those 2 users?

-Krazystyle

#2

Well RetroArch’s netplay is not server based… it’s P2P but I guess anything is possible. NAT tranversal is indeed a bitch… the proper way to get that working correctly is to open ports though. Pinching holes in a firewall by using a connection with a third party will always add latency.

I know there are plans to add an alternate netplay implementation that supports more users and that is not rollback based but nothing has really been done on that front.

#3

TBH : I appreciate not only the fast response, but not being told directly that i’m crazy :smiley:

Yeah, we’ve been trying to revive Xband for severalll years. We gave up on the hardware , even with pieces of the original source code given to us by the original developers.The next best thing would be to rebuild it with emulation… We did… But back then we were terrible .net programmers. We’re are lightyears ahead of where we were in almost every way, we’ve even come a long way in 3d rendering! I should’ve probably noted : Seeing alot of the posts around here, everything that we build will be free, and open source. I also understand that anything we’re currently asking for is going to be difficult. Regardless, we’re wiling to pay for the insanely fast server hosting for such a project out of pocket, and hopefully scale to become one of the greatest places to play retro games online

#4

I don’t think the NAT traversal necessarily needs to wreck latency. I think if you have the server/traversal just for the initial handshake and a direct UDP connection after that, it shouldn’t be any different from just directly connecting in the first place.

OTOH, mednafen already has a “laggy” netplay implementation that uses a server anyway, so that might be better for your purposes.

#5

Truth HunterK. A NAT traversal doesn’t have to wreck a P2P implementation (Take Skype for example)… The problem always being that not every type of NAT traversal is guaranteed to work in every situation is the true bitch in itself. UDP Hole punching, insecure UPNP, STUN… etc. So many different types of checks to implement to decide which has to be used per situation.

I’m talking wtih the people over at Medna right now, appreciate the direction. From my current tests it is pretty laggy, even running off a dedicated server with >500 upstream. Perhaps I just haven’t played with the latency settings enough yet…

But yeah, the best route is probably going to be some sort of NAT Traversal server to transition to P2P UDP