Mupen64Plus v2.0 Design Proposal 3

Primary Goal

The primary goal of this re-architecture is to split this large project into smaller projects which may proceed to be developed independently of each other. The advantages of the new architecture are:

• The build system can be greatly simplified
• Each module can use its own build system. For example, the Qt GUI might switch to cmake for better Qt integration.
• Porting the emulator core to other platforms (namely Win32) will be greatly simplified by removing the most platform-specific pieces.
• Making releases for each package will be simpler and faster
• Mupen64Plus may be included into the Debian/Ubuntu repositories since glN64 (with its 'unknown' license) will be a separate project

Topography

This re-architecture will force us to lay boundaries with well-defined APIs between different parts of the emulator. Here are some initial suggestions for the new layout of the modules:

1. Mupen64plus-core
   • To simplify porting to other platforms, the core needs to be as lean as possible
   • For this reason, the GUI interfaces, the ROM cache, and the zip/lzma/7zip decompressors will be removed
   • The core will contain the code for:
     • Emulating the R4300 main CPU and memory systems
     • Loading and configuring plugins
     • Reading, parsing, and writing all configuration files for the core + plugins
     • Parsing and returning information about ROM images
     • Core user interface for keyboard and LIRC input
     • Savestates and screenshots
     • An on-screen display
     • Cheat and debugger core functions
     • 'Dummy' plugins
2. Mupen64plus-console, Mupen64plus-gtk, Mupen64plus-qt
   • Command-line only, GTK, and Qt front-end interfaces
   • Each front-end for the core library will be a separate project
   • The ROM cache code will be forked and included into both GUIs
   • The front-ends will be responsible for finding and loading the core library and the plugins
   • The dynamic library handle of the core will be passed to all the plugins, and the dynamic library handle of the plugins will be passed to the core
   • The front-ends will be responsible for loading and decompressing the ROM image, and passing a pointer to the core
3. Plugins (RiceVideo, glN64, glide64, Blight Input, JTTL Audio)
   • The plugins will be spun off into separate projects
   • The plugin API will change, and will be incompatible with the old Zilmar spec

Project Owners

Richard42 will retain ownership of the Mupen64plus-core and Mupen64plus-console modules. I will recommend that Slougi take ownership of the Qt GUI. The plugins and GTK GUI are up for grabs.

Work To Do

Tasks which have been completed will be marked with the strikethrough format.

Prior to starting on the code

1. Write design document for Core API
   • Front-end + debugger + cheat
   • Configuration interface
   • Video plugin
   • Audio plugin
   • Input plugin
   • RSP plugin
2. Set up new Mercurial repository for project

Coding tasks

1. First steps
   • Split & fork the source files into new structure
2. Core
   • Refactor/simplify makefiles
   • Remove #include statements from header files
   • Write new configuration load/parse/save functionality
   • Separate event loop out of main.c into new source file
   • Fix broken WM_KeyDown/WM_KeyUp commands sent to input plugin
   • Remove main() function
   • Remove main/winlnxdefs.h
   • Add new shared library interface (Must be thread-safe and re-entrant where necessary)
     • api/callbacks.c
     • api/common.c
     • api/config.c
     • api/debugger.c
     • api/frontend.c
     • api/vidext.c
   • Refactor core code for new debug info interface (instead of printf(), send back to front-end)
   • Modify plugin-handling code to use new plugin API
   • Fix 64-bit dynamic recompiler for dynamic lib
   • Update translate.c file handling and translations
   • Update cheat.c cheat code handling
   • Remove compare_core.c, add core comparison feature to console-ui
   • Generate versioned core library
   • Simplify makefile / pre.mk
   • Refactor install.sh
   • Go through google code issue list, apply patches and close issue reports
3. Front-ends
   • Refactor/simplify makefiles
   1. CLI
      • Write from scratch, based on main.c
      • Update man page
   2. GUI-Qt
      • Adapt from previous mupen64puls Qt GUI code, pulling code from CLI front-end (Slougi)
   3. GUI-GTK
      • Adapt from previous mupen64puls GTK GUI code, pulling code from CLI front-end (TBD)
4. Plug-ins
   • For each plug-in:
     • m64p-rsp-hle
     • m64p-audio-sdl
     • m64p-video-rice
     • m64p-input-sdl
   • Remove existing configuration read/write code
   • Add Deadzone and Scaling parameters to Blight Input plugin
   • Refactor to use new configuration interface through core library
   • Refactor for changes in core plugin API
   • Refactor for new debug info interface (instead of printf(), send back to front-end)