Open Call for Mupen64Plus Developers

Developers, users, and fans:

After a great deal of work, late nights, and accompanying marital tension, I have finally finished the initial draft of the Mupen64Plus v2.0 API. It can be viewed on the developers' wiki:

http://www.emuwiki.com/index.php?title=Mupen64Plus_v2.0_Core_API_v1.0

I'm pretty excited about this, because while the re-architectured emulator won't look a lot different from the user's perspective, there will be a lot of improvements "under the hood". The big high-level changes are in splitting the monolithic Mupen64Plus application into separate Core and GUI/Front-End parts, and going from a single integrated release to a bunch of smaller projects which can be independently developed and released. Some of the benefits of the new architecture are:

- Faster releases, more development
- simpler and less problem-prone installation and configuration on Unix
- inclusion in more Linux distributions
- simplified makefiles on Linux/OSX
- clean, native MSVC build for Win32
- better handling of log/debugging text output
- better error handling
- improved video plugins, based off of newer sources

Mostly I'm optimistic that the resulting Mupen64Plus projects will attract more developers and improve at a faster pace after the 2.0 release. Now comes the fun part, writing the code and implementing all of the changes.

So I would like to request help from anyone interested, willing, and qualified. There's lots of work to be done, and it starts with reviewing the API at the link above. Get on the IRC channel or drop us a line at the Mupen64Plus Google Group to voice your comments. I would particularly like to hear if anyone finds a current feature of the GUIs which can't be implemented with the new API, or any future features that might be added which would require an extension of the API.

While the API is under review, I'll be setting up new source code repositories hosted by Mercurial, a Python-based distributed source code control system. When the API review wraps up, we'll jump into the code. I plan to maintain ownership of the Core library and the new Console front-end and spend most of my time on these projects. I would to hear from developers who are able to contribute their effort on the following tasks:

1. Leadership of the GTK GUI front-end. If someone doesn't step up to fill this role, the GTK GUI may die and we will only have a Qt GUI.
2. Leadership of the plugins. I can manage the smaller plugins myself for a while, but the video plugins are big and complex. Anyone willing to take over development and releases of any plugins should contact me. I can provide SVN or Mercurial source code repositories, or you can host it yourself.
3. Windows developers. I would like to have good Win32 C developers who can help port and maintain the plugins. In particular the video plugins will take some effort to assimilate properly into Windows.
4. Porting plugins to the new architecture.
5. Front-end developers. Anyone willing to help out improving or porting the GTK or Qt Front-ends is welcome.

Anyone who's willing to step up, be a hero, and make a name for yourself in the N64 emulator world, now's your chance. The more developers we have, the quicker we'll get it done, so let's get started!

segalion said:

Could you think in the future Nokia N900 hardware?

It has Os Maemo 5 (linux), over a ARM Cortex-A8 600 MHz, PowerVR SGX with OpenGL ES 2.0 and seems to have power enough to make a good emulation.

Click to expand...

This doesn't affect the redesign of the API, but at any rate a 600MHz ARM is nowhere near powerful enough to run the r4300 emulator in mupen64plus. If someone wrote a dynamic recompiler for this architecture, and it was running at 2-3x the clock rate then it would be fast enough.

Surkow said:

At least a start is made: http://www.gp32x.com/board/index.php?/topic/49358-mupen64plus/

Click to expand...

Yeah that's really funny. Just when someone here asked a question about the ARM, a guy on the gp32x forum announced that he has written a dynamic recompiler for the ARM. That's great to hear. I don't think there are any solid performance numbers announced, and they still need to work on at least one of the video plugins to make it run under OpenGL ES, but here's to hoping that they get it running well on the Pandora and ARM-based devices. It seems like there is a lot of interest in this.