RetroArch
RetroArch copied to clipboard
Netplay with Mac to Windows not working, but works Windows to Windows
Description
Cannot start netplay session between macOS and Windows. It works fine if I boot into Windows.
Expected behavior
Connect using one of the verified netplay working cores (GPGX in this case).
Actual behavior
The message "This core does not support inter-architecture netplay" appears, then promptly disconnects both players.
Steps to reproduce the bug
- Download the latest stable build of RetroArch and use the online updater to get the current version of a core.
- Forward ports and setup general netplay settings. Load a game with identical file names between both parties.
- Start a host on one side, have the other attempt to join session.
- RetroArch: 64-bit Version 1.4.1, build date February 2, 2017
Environment information
- OS: macOS 10.11.6 for me, Windows 10 for my friend
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
GPGX does not support netplay between those two platforms, hence the inter-architecture message. Try picodrive instead.
We've tried PicoDrive, same message.
PicoDrive isn't listed as being platform dependent for netplay, so it is strange that it's not working for you, and that you are getting that message. Do any other cores have this same problem? Can you also try again with the latest version of RetroArch?
Pico works on the new version, albeit it has way more input delay than GPGX on our Windows to Windows sessions.
The only other cores we've tried are bsnes (balanced) and Mednafen. bsnes gave the same error, while Mednafen connected but had extreme audio and video stutter.
Is GPGX's lack of cross-platform support due to the core itself or its implementation within libretro?
IIRC it is due to the core itself (e.g. the "long" type is 64-bit on one platform and 32-bit on another, due to LP64 vs LLP64, or some math always assumes big vs little endian), and we just mark that core as platform/endian-dependent within the libretro part of its code... but @GregorR would know better than me.
Neither bsnes nor picodrive has inter-arch issues. GPGX's cross-platform problems are due to the core itself (you'd also have issues if you save a state on one platform and move it to another, although it's possible that those particular two platforms would work). Neither bsnes nor mednafen* have ever had inter-arch issues, so if you're getting that message, there's a problem somewhere.
I asked the GPGX dev about it. Rather than quote it I'll just link it here: https://github.com/ekeeke/Genesis-Plus-GX/issues/123
I definitely do have an Intel Mac. Is it only the processor that affects endianness? Like the title mentions, our Windows to Windows sessions connect just fine, and that's on the same hardware.
Are you sure you're on the same revision of the core? I've had several instances where the git revision has a mismatch even after doing an update.
Yes, if it wasn't it would say "implementations differ."
it's not just endian-ness though. It can be storage sizes for instance. Not all cores have cross platform save states,
https://github.com/GregorR/RetroArch/wiki/Netplay-core-testing
⁴ Savestates are architecture-specific, so netplay will not work in some inter-architecture circumstances.
Debugging savestates requires time and patience, and the target device that you want to debug and I don't have a MAC.
I did some debugging for FBA for instance together with @aliaspider we managed to fix CPS1/CPS2/NeoGeo/CPS3 savestates for android/windows compatibility.
Same problem with genesis plus gx using linux (64bit) and windows (64bit) systems
Tried it this week between Linux (64bit) and Windows (64bit), Retroarch 1.15.0 and GPGX 1.7.4 and got the same message and problem.