Mupen64Plus - API Driven Core

[okaygo]

An idea that the team is considering and discussing is turning Mupen64Plus into an API based core, which interacts with a GUI.

The core would be a back-end, and the GUI would be the front-end. You can see this in an emulator such as MAME (which has been very successful).

Such calls that would be needed in an API would be.

Emulator driven calls:

START_ROM(path);
PAUSE_ROM();
STOP_ROM();
SELECT_CORE(type);
SET_WINDOW(window);

Plugin based calls:

LOAD_PLUGIN(type,path);
UNLOAD_PLUGIN(type);
CONFIGURE_PLUGIN(type);
TEST_PLUGIN(type);
CALL_PLUGIN(call,type);


the way this would work is that: the GUI would interact with the core, allowing for a clean core with little dependency. this would make portability a lot easier. a lot of things might have to be rewritten, and this is only an idea... but it might be the course this project needs.

discuss

 

[ebenblues]

okaygo and I have already talked about this a little, but just to give my 2 cents...

When I did the gui/nogui merge, I separated out a lot of common functions that could be used by any gui toolkit (handling of translation files, reading/writing mupen64plus.conf file, etc). But I did not do any abstraction of platform-specific code. Right now, the code in main/ has a lot of platform-specific calls (SDL, gnu, ...).

I wanted to point this out to be clear that okaygo's idea doesn't conflict with any of the work I did. What I think okaygo is proposing is splitting that into 2 layers, the backend layer would be platform-independent code and surface an API to the frontend which would be platform-specific code. Once that structure is in place with as much common function on the backend side as possible, porting mupen64plus would require just writing the frontend for that platform. The merged gui/nogui code in main/ would become the *nix/SDL frontend, but then we could have a Windows frontend, and a osx frontend, etc.

The real work is defining the API and what function goes on which side of the fence.

 

[Richard42]

I'll throw in my 2 cents as well. If I were going to design this, I would totally break apart the front-end from the emulator. They should be separate projects, compiled separately. The emulator should be command-line only, with a powerful, stable, and well-documented interface. The front end should call the emulator through a system call (shell, popen, etc) for all interaction. There are compelling advantages to this approach:

1. Simplicity - the emulator is simpler, the build system is way simpler, debugging is simpler
2. Stability - link-level APIs are much harder to maintain and debug than a command-line interface
3. Flexibility - this approach makes it very easy to integrate the core emulator into any sort of device (like mythtv)
4. GUI development is totally spun-off and can be done independently of the emulator

The core emulator and plugins should be written in the most platform-independent way, using SDL and OpenGL for OS-abstraction, so that it will compile and run under any system. The GTK GUI should be spun off into the first front-end. Then people can start working on whatever kind of GUIs they want.

The emulator will need some additional functionality to support the front-end, but it won't be too bad. It will need to have functions to do things like scan a ROM folder and spit out a CSV-style list of game data for the front end to use. We could use XML but it's not worth the complexity and code bloat for a simple table.

 

[okaygo]

The problem with making the core command line only is that without a way to make calls to the core, one would have limited functionality with the GUI. We discussed making Mupen64Plus as OS-Independent as possible, and then having main.c (and each port) be the GUI, so instead of having to change a core each time you want to modify or build upon something, all one would have to do is redesign the GUI or tweak it.

The emulator would spit call-backs to main.c telling it when certain things have happened.

Any other ideas?

 

[Richard42]

The emulator would spit call-backs to main.c telling it when certain things have happened.

The API-driven core is basically what we have right now, but it's not formalized. This is fine if you're only supporting one system. I think this is great while we're focusing on linux. But if you want to support osx and win32, the command-line interface (which is what MAME uses) is much easier to maintain. And what does the close API buy you other than the ability to put play and pause buttons on the toolbar?