NRage Input Plugin on Mupin64Plus

[Falkoner]

Out of all the input plugins available, NRage seems to be the most powerful, as far as complete featureset(GBA Packs) and compatibility(XInput support). However, it's currently built for the Zilmar spec, so I wanted to know if there's any way to get it working on Mupen64Plus, and if it has to be ported, is there anyone who has documented the necessary changes to port a plugin over to Mupen?

Should I get into the process of porting it, I'll likely do a makeover on its interface while I'm at it, since that's perhaps its only downside.

Thanks for any responses in advance!

 

[Falkoner]

So, beginning to do a bit more research, it's obvious that the interface would need to be redone no matter what, since Zilmar's spec uses Windows GUI code, and the current interface is written in Visual C++.

Outside of the changes to the interface code, what changed between Mupen64Plus's spec and Zilmar?

 

[bobby.smiles32]

Outside of the changes to the interface code, what changed between Mupen64Plus's spec and Zilmar?

The main difference is the addition of a "config" API, which allows plugins to store/retrieve parameters values in a plateform agnostic way.
This has several benefits :
-configuration parsing is factorized into the core (no more duplication between plugins)
-UI code can be moved to frontends, allowing plugins and core to remain plateform agnostic and relieve plugin authors to write such code.

Hope you can contribute something to this project

 

[Falkoner]

The main difference is the addition of a "config" API, which allows plugins to store/retrieve parameters values in a plateform agnostic way.
This has several benefits :
-configuration parsing is factorized into the core (no more duplication between plugins)
-UI code can be moved to frontends, allowing plugins and core to remain plateform agnostic and relieve plugin authors to write such code.

Hope you can contribute something to this project

Well, I figure Gonetz is overhauling the graphics plugin for a final push, why not do the same for controller plugins, particularly considering it's a substantially less complicated project now that the complex stuff has been handled.

I think I'm going to be using librocket/ for the interface to get cross-platform compatibility and to simplify the coding for me.

 

[V1del]

You don't really have to provide a GUI if you intend to make a plugin for mupen64plus, this is ideally handled by the frontend completely separate of the plugin. so you wouldn't have to use librocket as the GUI wouldn't be your job to do anyway, a bigger problem you'd have to worry about is porting the plugin away from DirectInput/XInput to SDL or similar without losing the advanced features if you intend to provide the plugin to all platforms mupen64plus supports (you could also make a windows only variant by only adjusting to the spec differences)

 

[Falkoner]

You don't really have to provide a GUI if you intend to make a plugin for mupen64plus, this is ideally handled by the frontend completely separate of the plugin. so you wouldn't have to use librocket as the GUI wouldn't be your job to do anyway, a bigger problem you'd have to worry about is porting the plugin away from DirectInput/XInput to SDL or similar without losing the advanced features if you intend to provide the plugin to all platforms mupen64plus supports (you could also make a windows only variant by only adjusting to the spec differences)

Well, outside of adding the missing Hey You, Pikachu! mic support, the biggest reason I wanted to work on this project was to rewrite the GUI, any suggestions as to how I should code it to easily integrate into Mupen's front end but also go nicely into PJ64 and others that follow zilmar spec?

 

[V1del]

Well if you want to remain compatible you could do a compile time separation and only compile the GUI when compiling for Zil spec, you'd likely need two different DLLs for m64p and standard Zil spec anyway.

Integration into various mupen64plus frontends would be done by the frontends themselves, and you'd only need to expose the new configuration APIs so that they can set the configuration options. Otherwise if you create a GUI to be used by both specs, this could break immersion with certain frontends/certain frontends would remove the GUI specific code anyway before including your plugin into their repos (e.g. Retroarch, OpenEmu and similar which have a tightly integrated way of handling plugins and configuration)

 

[Falkoner]

Well if you want to remain compatible you could do a compile time separation and only compile the GUI when compiling for Zil spec, you'd likely need two different DLLs for m64p and standard Zil spec anyway.

Integration into various mupen64plus frontends would be done by the frontends themselves, and you'd only need to expose the new configuration APIs so that they can set the configuration options. Otherwise if you create a GUI to be used by both specs, this could break immersion with certain frontends/certain frontends would remove the GUI specific code anyway before including your plugin into their repos (e.g. Retroarch, OpenEmu and similar which have a tightly integrated way of handling plugins and configuration)

Ahh, interesting, has anyone standardized the API already for handling gamepacks and memorypacks? Not to mention my desire to use a mic as a controller.. I suppose I may have to also get into editing one of the front-ends eventually.