Open andres-asm opened 7 years ago
Tatsuya79
commented
7 years ago Core options should only handle internal core state. It shouldn't handle cosmetic stuff.
What is the problem here with netplay? Are NES palettes or filters like Blaarg NTSC causing issues?
andres-asm
commented
7 years ago No I don't think those are specially problematic but we have a slew of features in the front-end that could handle them....
But yeah I wouldn't now what to do with palettes or AR options... I meant things like screen composition, those should have dedicated callbacks.
On Fri, Jan 27, 2017, 7:38 AM Tatsuya79 notifications@github.com wrote:
Core options should only handle internal core state. It shouldn't handle cosmetic stuff. What is the problem here with netplay? Are NES palettes or filters like Blaarg NTSC causing issues?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/libretro/RetroArch/issues/4516#issuecomment-275656508, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpC0Iudeu-oYwhEG2xX8dSmd4VnDbdtks5rWeVFgaJpZM4LvVO4 .
andres-asm
commented
7 years ago @GregorR
Easier netplay is great, but it exacerbates the problems and limitations we have with the API.
The problem:
We have two (actually three but the multidisc stuff doesn't seem too relevant) subsystems that are leveraged to manipulate how a core works, core options and the controllers interface.
Core options
These usually affect internal core state only, the easiest way to handle these would be to sync them over the wire when starting a session or whenever these are changed.
Examples:
FBA's bios stuff, or dip switches, and even controller core options. For example I was playing mslug3, and I had my neogeo scheme set to newgen, the other peer had it set to classic. All I could see is the other player jumping frenetically and lots of re-syncs since the state had deviated (on every shoot button press my side was emulating a jump and viceversa)
TGB Dual GBE link, if this option isn't matched netplay will flat out disconnect
Notable exceptions: TGB Dual's screen selection options don't really affect the internal state and everything works pretty much perfect if P1 is watching P1 screen and P2 is watching P2 screen, actually this is probably what we should provide in a core that offers assymetrical gameplay.
Controllers & Remapping
The controls interface allows the core to expose different (and labeled!) buttons depending on the emulated input device which is good. This probably should be synced over the wire since it affects internal core state (the controller type)
On the other hand there is remapping, this is a frontend side feature and from my own testing's it's perfect doesn't need to change internal core state, if only affects how the frontend forwards inputs to the core.
Possible Solutions:
Cores should leave input mapping stuff other than emulated device to the frontend. No core options for inputs!. Frontend remapping is not a silver bullet, it doesn't work perfect so far, doesn't allow analogs to digital or kbd to gamepad mapping but it's consistent and doesn't mess up internal core state. The advantage of having internal core options controlling how inputs work is that it allows for an easier out of the box experience, but a steady internal state should be more important if we're hoping to offer a good netplay experience with cores such as FBA or MAME in the future.
Core options should only handle internal core state. It shouldn't handle cosmetic stuff, maybe we should have a way to tell the frontend the screen is a composite screen, then we would have a way to change how the screen looks without messing with core options (this is just an example. Other use cases may arise). Once core options don't mess with both sides of the equation we could safely sync them.
Alternatively, cores may need to be "netplay aware" and then we could change/force some options from within the core depending on which player is controlling each instance.