Mupen64Plus Wiki - User contributions [en]

Mupen64Plus v2.0 Core Video Extension

2022-08-06T02:58:10Z

Richard42:

[[Mupen64Plus v2.0 Core API v1.0|Mupen64Plus v2.0 API]]

= Mupen64Plus v2.0 Video Extension API =

Most libmupen64plus functions return an <tt>m64p_error</tt> return code, which is an enumerated type defined in [[Mupen64Plus v2.0 headers#m64p_types.h|m64p_types.h]]. Plugin code should check the return value of each call to a libmupen64plus function.

All of these functions should only be called from within the video plugin; they should not be called from the front-end.

== Startup/Shutdown Functions ==
{| border="1"
|Prototype
|'''<tt>m64p_error VidExt_Init(void)</tt>'''
|-
|Input Parameters
|N/A
|-
|Requirements
|This function should be called before any other Video Extension functions.
|-
|Usage
|This function should be called from within the RomOpen() video plugin function call. The default SDL implementation of this function simply calls SDL_InitSubSystem(SDL_INIT_VIDEO). It does not open a rendering window or switch video modes.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error VidExt_Quit(void)</tt>'''
|-
|Input Parameters
|N/A
|-
|Usage
|This function closes any open rendering window and shuts down the video system. The default SDL implementation of this function calls SDL_QuitSubSystem(SDL_INIT_VIDEO). This function should be called from within the RomClosed() video plugin function.
|}
 

== Screen Handling Functions ==
{| border="1"
|Prototype
|'''<tt>m64p_error VidExt_ListFullscreenModes(m64p_2d_size *SizeArray, int *NumSizes)</tt>'''
|-
|Input Parameters
|'''<tt>SizeArray</tt>''' Pointer to an array of <tt>m64p_2d_size</tt> objects, defined in [[Mupen64Plus v2.0 headers#m64p_types.h|m64p_types.h]] 
'''<tt>NumSizes</tt>''' Pointer to an integer which contains the size of '''<tt>SizeArray</tt>''' for input, and the number of size objects stored for output.
|-
|Requirements
|The video extension must be initialized before calling this function.
|-
|Usage
|This function is used to enumerate the available resolutions for fullscreen video modes. An array '''<tt>SizeArray</tt>''' is passed into the function, which is then filled (up to <tt>*'''NumSizes'''</tt> objects) with resolution sizes. The number of sizes actually written is stored in the integer which is pointed to by '''<tt>NumSizes</tt>'''.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error VidExt_ListFullscreenRates(m64p_2d_size Size, int *NumRates, int *Rates)</tt>'''
|-
|Input Parameters
|'''<tt>Size</tt>''' <tt>m64p_2d_size</tt> object, defined in [[Mupen64Plus v2.0 headers#m64p_types.h|m64p_types.h]] of the resolution you want to retrieve the fullscreen refresh rates from. 
'''<tt>NumRates</tt>''' Pointer to an integer which contains the size of '''<tt>Rates</tt>''' for input, and the number of size objects stored for output. 
'''<tt>Rates</tt>''' Pointer to an array of integers which will contain the refresh rates.
|-
|Requirements
|The video extension must be initialized before calling this function.
|-
|Usage
|This function is used to enumerate the available refresh rates for a given resolution. An '''<tt>m64p_2d_size</tt>''' object is passed into the function, which will contain the resolution of the refresh rates you want to retrieve, an array '''<tt>Rates</tt>''' is passed into the function, which is then filled (up to <tt>*'''NumRates'''</tt> objects) with resolution sizes. The number of sizes actually written is stored in the integer which is pointed to by '''<tt>NumSizes</tt>'''.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error VidExt_SetVideoMode(int Width, int Height, int BitsPerPixel, m64p_video_mode ScreenMode, m64p_video_flags Flags)</tt>'''
|-
|Input Parameters
|'''<tt>Width</tt>''' Horizontal resolution in pixels of desired video window 
'''<tt>Height</tt>''' Vertical resolution in pixels of desired video window 
'''<tt>BitsPerPixel</tt>''' Pixel color resolution of desired video window. This value must be 16, 24, or 32 
'''<tt>ScreenMode</tt>''' Either <tt>M64VIDEO_WINDOWED</tt> or <tt>M64VIDEO_FULLSCREEN</tt> 
'''<tt>Flags</tt>''' Logical-OR combination of flags which describes the video plugin's capabilities.
|-
|Requirements
|The video extension must be initialized before calling this function.
|-
|Usage
|This function creates a rendering window or switches into a fullscreen video mode. Any desired OpenGL attributes should be set before calling this function.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error VidExt_SetVideoModeWithRate(int Width, int Height, int RefreshRate, int BitsPerPixel, m64p_video_mode ScreenMode, m64p_video_flags Flags)</tt>'''
|-
|Input Parameters
|'''<tt>Width</tt>''' Horizontal resolution in pixels of desired video window 
'''<tt>Height</tt>''' Vertical resolution in pixels of desired video window 
'''<tt>RefreshRate</tt>''' Fullscreen refresh rate 
'''<tt>BitsPerPixel</tt>''' Pixel color resolution of desired video window. This value must be 16, 24, or 32 
'''<tt>ScreenMode</tt>''' Either <tt>M64VIDEO_WINDOWED</tt> or <tt>M64VIDEO_FULLSCREEN</tt> 
'''<tt>Flags</tt>''' Logical-OR combination of flags which describes the video plugin's capabilities.
|-
|Requirements
|The video extension must be initialized before calling this function.
|-
|Usage
|This function creates a rendering window or switches into a fullscreen video mode. Any desired OpenGL attributes should be set before calling this function.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error VidExt_SetCaption(const char *Title)</tt>'''
|-
|Input Parameters
|'''<tt>Title</tt>''' Pointer to a NULL-terminated string containing the desired title text of the emulator rendering window
|-
|Requirements
|The video extension must be initialized before calling this function.
|-
|Usage
|This function sets the caption text of the emulator rendering window.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error VidExt_ToggleFullScreen(void)</tt>'''
|-
|Input Parameters
|N/A
|-
|Requirements
|The video extension must be initialized before calling this function. The rendering window should already be created.
|-
|Usage
|This function toggles between fullscreen and windowed rendering modes.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error VidExt_ResizeWindow(int Width, int Height)</tt>'''
|-
|Input Parameters
|'''<tt>Width</tt>''' Horizontal resolution of resized window in pixels 
'''<tt>Height</tt>''' Vertical resolution of resized window in pixels
|-
|Requirements
|The video extension must be initialized before calling this function. The rendering window should already be created.
|-
|Usage
|This function is called when the video plugin has resized its OpenGL output viewport in response to a ResizeVideoOutput() call, and requests that the window manager update the OpenGL rendering window size to match. If a front-end application does not support resizable windows and never sets the M64CORE_VIDEO_SIZE core variable with the M64CMD_CORE_STATE_SET command, then this function should not be called.
|}
 

===Window Resizing===
The window resizing functionality is particularly complicated, so here is a high-level description of the events which make it happen:

====Without video extension:====
# In VidExt_SetVideoMode(), check if M64VIDEOFLAG_SUPPORT_RESIZING is set
#* if True, create SDL window with RESIZABLE attribute
# Core receives SDL_RESIZE messages in SDL event loop
# If present, Core calls ResizeVideoOutput function in video plugin
# Video Plugin calls ResizeWindow function in Video Extension
#* Core calls SDL_SetVideoMode()
# Core emits M64CORE_VIDEO_SIZE state changed callback

====With video extension:====
# in Front-end SetVideoMode() callback
#* if M64VIDEOFLAG_SUPPORT_RESIZING is set, create resizable window frame
# Front-end GUI gets window resize notification
# Front-end calls CoreDoCommand w/ M64CMD_CORE_STATE_SET, w/ M64CORE_VIDEO_SIZE
# If present, Core calls ResizeVideoOutput function in video plugin
# Video Plugin calls ResizeWindow function in Video Extension
# Core emits M64CORE_VIDEO_SIZE state changed callback

In the Core Video Extension function ResizeWindow, the SDL function SetVideoMode() is called. This function will destroy the current OpenGL context and create a new one. For this reason, any video plugin which supports resizable windows must completely reset its OpenGL state including uploading any textures, FBOs, programs, etc after calling the VidExt_ResizeWindow function.

== OpenGL Functions ==
{| border="1"
|Prototype
|'''<tt>void * VidExt_GL_GetProcAddress(const char* Proc)</tt>'''
|-
|Input Parameters
|'''<tt>Proc</tt>''' Pointer to a NULL-terminated string containing the name of the desired OpenGL extension function.
|-
|Requirements
|The video extension must be initialized before calling this function.
|-
|Usage
|This function is used to get a pointer to an OpenGL extension function. This is only necessary on the Windows platform, because the OpenGL implementation shipped with Windows only supports OpenGL version 1.1.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error VidExt_GL_SetAttribute(m64p_GLattr Attr, int Value)</tt>'''
|-
|Input Parameters
|'''<tt>Attr</tt>''' Enumerated type (defined in [[Mupen64Plus v2.0 headers#m64p_types.h|m64p_types.h]]) specifying which OpenGL attribute to set 
'''<tt>Value</tt>''' Value to set for the attribute
|-
|Requirements
|The video extension must be initialized before calling this function. The desired attributes should be set before calling '''<tt>VidExt_SetVideoMode</tt>'''
|-
|Usage
|This function is used to set certain OpenGL attributes which must be specified before creating the rendering window with '''<tt>VidExt_SetVideoMode</tt>'''.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error VidExt_GL_GetAttribute(m64p_GLattr Attr, int *pValue)</tt>'''
|-
|Input Parameters
|'''<tt>Attr</tt>''' Enumerated type (defined in [[Mupen64Plus v2.0 headers#m64p_types.h|m64p_types.h]]) specifying OpenGL attribute of which to get value 
'''<tt>pValue</tt>''' Pointer to integer Value which will be set to attribute's value
|-
|Requirements
|The video extension must be initialized before calling this function.
|-
|Usage
|This function may be used to check that OpenGL attributes where successfully set to the rendering window after the '''<tt>VidExt_SetVideoMode</tt>''' function call.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error VidExt_GL_SwapBuffers(void)</tt>'''
|-
|Input Parameters
|N/A
|-
|Requirements
|The video extension must be initialized before calling this function. The rendering window should already be created.
|-
|Usage
|This function is used to swap the front/back buffers after rendering an output video frame.
|}
 
{| border="1"
|Prototype
|'''<tt>uint32_t VidExt_GL_GetDefaultFramebuffer(void)</tt>'''
|-
|Input Parameters
|N/A
|-
|Requirements
|The video extension must be initialized before calling this function. The rendering window should already be created.
|-
|Usage
|On some platforms (for instance, iOS) the default framebuffer object depends on the surface being rendered to, and might be different from 0. This function should be called to retrieve the name of the default FBO. Calling this function may have performance implications and it should not be called every time the default FBO is bound.
|}

Mupen64Plus v2.0 API Versioning

2022-08-06T02:56:08Z

Richard42:

[[Mupen64Plus v2.0 Core API v1.0|Mupen64Plus v2.0 API]]

= Mupen64Plus v2.0 API Versioning =

== Goal ==

The Mupen64Plus API versioning scheme was invented to give a more friendly and less confusing experience for users as the various components evolve over time. There are 6 basic components to the Mupen64Plus system, which may be independently built and installed:

# The Front-end UI application
# The Core emulator library
# The Video plugin
# The Audio plugin
# The Input plugin
# The RSP plugin

These components interact with each other in several different ways. The design goal of the versioning scheme is to gracefully handle all situations in which two components support different versions of their common API (due to one component being newer than the other). In particular, each pair of components sharing a common API must discover whether or not they are compatible with each other. They must make this determination early enough in the startup process to inform the user of an incompatibility and gracefully exit the software if necessary without crashing. There are 2 different decisions that pertain to the compatibility determination:

# Major API version. The various API version numbers are 32-bit. The major version number is stored in the upper 16 bits, and the minor version number is in the lower 16 bits. If two components have different major API version numbers, then they are definitely incompatible.
# Minor API version. If two components with a common API have different minor version numbers, then the newer component may decide whether or not it can interact with the older component based upon the older component's version number. The newer component may optionally disable new features and still retain backwards compatibility, or it may refuse to operate with the older component. This decision is left to the component author when new features are added.

== Basic Design ==

In mupen64plus-core/src/plugin/plugin.h, the following macros are defined:

#define RSP_API_MAJOR_VERSION 0x20000
#define GFX_API_MAJOR_VERSION 0x20000
#define AUDIO_API_MAJOR_VERSION 0x20000
#define INPUT_API_MAJOR_VERSION 0x20000

In mupen64plus-core/src/main/version.h, the following macros are defined:

#define FRONTEND_API_VERSION 0x020000
#define CONFIG_API_VERSION 0x020000
#define DEBUG_API_VERSION 0x020000
#define VIDEXT_API_VERSION 0x020000

# When the front-end application calls the CoreStartup() function, it passes it's Core<-->Front-end API version to the core. If the API major version numbers for the core and front-end don't match, the core will return from this function with a failure code of M64ERR_INCOMPATIBLE.
# The Console-UI front-end also checks for API compatibility, during the AttachCoreLib() function call. It is not strictly necessary for a front-end application to verify the API compatibility with the core, since the core will also check during CoreStartup(). However, by doing so, an updated front-end may detect a core library using a newer (but backwards-compatible) API, and enable some extra features as a result of the expanded API.
# At the time each plugin is attached to the core (during CoreAttachPlugin function call), the core checks the version number of the plugin API by calling the PluginGetVersion function. If the major version number of the plugin's reported API (APIVersion & 0xffff0000) does not match the corresponding version number for that plugin type in the core (defined in plugin.h), then the plugin is incompatible and cannot be attached to the core. Currently the plugins have no way to request the major version number required for a particular plugin type in the core library.
# The emulator core exports several different API groups which may be used by the front-end and plugin modules. Currently, these groups are: Front-end, Config, Debug, and Video Extension. A front-end application or any plugin may call the CoreGetAPIVersions() function to retrieve the API version numbers for these groups. Any plugin or front-end which can use any updated (not present in the original "2.0" API) functions in one of these groups should call the core's CoreGetAPIVersions() function (during PluginStartup for a plugin or at core attach time for a front-end) to check the version # of the API supported by the core, and react accordingly.
# All front-ends and plugins should verify API version compatibility for the Config API.

== Handling Future Changes ==

=== New feature added to a plugin library ===
If the feature is backwards-compatible with older cores, then plugin API minor version will be bumped. Otherwise, major version number will be bumped. If change is backwards-compatible, then newest core can test the plugin's API version and only enable the feature if present.

=== New feature added to Core<-->Front-end API ===
Typically this will happen when a new function or a new feature of an existing function is added to the core. If the older front-ends will still be compatible with newer cores, then the minor version number of the front-end API will be bumped. Otherwise the major version number will be bumped. A newer front-end can check the version of the API supported by the core and choose whether to retain backwards-compatibility with older cores or refuse to interoperate.

=== New feature added to Core Config API ===
If older plugins can still use the Core Config API with the new feature, then Config API minor version will be bumped. Otherwise, major version number will be bumped. Newer plugins should check the Core's Config API version and maintain backwards compatibility with older cores if possible.

=== New feature added to Core Debug API ===
If older front-ends can still use the Core Debug API with the new feature, then Debug API minor version number will be bumped. Otherwise, major version number will be bumped. Newer front-end applications should check the Core's Debug API version and maintain backwards compatibility with older cores if possible.

=== New feature added to Video Extension API ===
This is the most complicated interface, because it involves 3 components: the video plugin, the core, and the front-end application. If older video plugins can still use the newer Video Extension API with the core, *and* newer front-end applications can work with older cores, then the Video Extension API minor version number will be bumped. Otherwise, the major version number will be bumped. Newer video plugins can check the Core's Video Extension API version and maintain backwards compatibility with older cores if possible, otherwise they can refuse and give a compatibility error. Front-end applications (such as the default console-ui) which do not hook into the Video Extension do not need to check the Core's Video Extension API version. However, front-end applications which do hook into the Video Extension must check the API version. If the Core and Front-end have different API major version numbers, then they are incompatible. Also if the Core has a *newer* minor version than the front-end, then they are incompatible. This is a unique restriction, and it must be checked and verified by the front-end; the Core has no way to check this.

== Changelog ==
* Version 2.0.0 is the base for all APIs
* '''FRONTEND_API_VERSION''' version 2.0.1:
** added "m64p_command" type "M64CMD_CORE_STATE_SET", handled by CoreDoCommand()
** added "m64p_core_param" type "M64CORE_SPEED_LIMITER", handled by "M64CMD_CORE_STATE_QUERY" and "M64CMD_CORE_STATE_SET" commands
* '''FRONTEND_API_VERSION''' version 2.0.2:
** added "m64p_command" types:
*** M64CMD_GET_SCREEN_WIDTH
*** M64CMD_GET_SCREEN_HEIGHT
*** M64CMD_READ_SCREEN
*** M64CMD_VOLUME_UP
*** M64CMD_VOLUME_DOWN
*** M64CMD_VOLUME_GET_LEVEL
*** M64CMD_VOLUME_SET_LEVEL
*** M64CMD_VOLUME_MUTE
*** M64CMD_RESET
*** M64CMD_ADVANCE_FRAME
** extend command M64CMD_STATE_SAVE to support saving uncompressed PJ64 savestate files as well as zip compressed
* '''FRONTEND_API_VERSION''' version 2.1.0:
** removed "m64p_command" types:
*** M64CMD_GET_SCREEN_WIDTH
*** M64CMD_GET_SCREEN_HEIGHT
*** M64CMD_VOLUME_UP
*** M64CMD_VOLUME_DOWN
*** M64CMD_VOLUME_GET_LEVEL
*** M64CMD_VOLUME_SET_LEVEL
*** M64CMD_VOLUME_MUTE
** added new "m64p_core_param" types:
*** M64CORE_VIDEO_SIZE
*** M64CORE_AUDIO_VOLUME
*** M64CORE_AUDIO_MUTE
*** M64CORE_INPUT_GAMESHARK
*** M64CORE_STATE_LOADCOMPLETE
*** M64CORE_STATE_SAVECOMPLETE
* '''FRONTEND_API_VERSION''' version 2.1.1:
** Core command M64CMD_CORE_STATE_SET will now accept M64CORE_VIDEO_SIZE parameter
*** will call the video plugin function ResizeVideoOutput()
* '''FRONTEND_API_VERSION''' version 2.1.2:
** added "M64CMD_SET_MEDIA_LOADER" command to allow frontend to specify several media files (such as GB cartridge ROM and RAM files).
* '''CONFIG_API_VERSION''' version 2.1.0:
** add new function "ConfigSaveSection()" to save only a single config section to disk
* '''CONFIG_API_VERSION''' version 2.2.0:
** add new function "ConfigHasUnsavedChanges()" to determine if a given Section (or all sections) of the Mupen64Plus Core configuration file has been modified since it was last saved or loaded.
** add new function "ConfigRevertChanges()" to revert changes previously made to one section of the configuration file, so that it will match with the configuration at the last time that it was loaded from or saved to disk.
* '''CONFIG_API_VERSION''' version 2.3.0:
** add new function "ConfigSetParameterHelp()" sets the value of one of the emulator's configuration parameters.
* '''CONFIG_API_VERSION''' version 2.3.1:
** add new functions "ConfigExternalOpen()" "ConfigExternalClose()" "ConfigExternalGetParameter()" that allows plugins to leverage the core INI parser to read config files.
* '''DEBUG_API_VERSION''' version 2.0.1:
** add new function "DebugBreakpointTriggeredBy()" which allows a front-end application to determine which memory address and action (read, write, execute) caused a breakpoint to fire.
** add new function "DebugVirtualToPhysical()" which allows a front-end application to find the physical address which corresponds to a given virtual address.
* '''VIDEO_API_VERSION''' version 2.1.0:
** video render callback function now takes a boolean (int) parameter, which specifies whether the video frame has been re-drawn since the last time the render callback was called. This allows us to take screenshots without the On-Screen-Display text
* '''VIDEO_API_VERSION''' version 2.2.0:
** add (optional) ResizeVideoOutput function in video plugin. If this function is not present in video plugin, then resizing the output video window will not work.
* '''VIDEXT_API_VERSION''' version 3.0.0:
** add VidExt_ResizeWindow() function in video extension. This function is called by the video plugin to notify the window manager (SDL if no video extension is registered by the front-end) that the OpenGL render window size should change.
** add m64p_video_flags parameter to the VidExt_SetVideoMode() function. Currently the flags are only used to notify the window manager that resizing is supported by the video plugin, and it should create a resizable window if possible. This may be extended in the future to support other features.
* '''VIDEXT_API_VERSION''' version 3.1.0:
** add VidExt_GL_GetDefaultFramebuffer() function in video extension. This function should be called to get the name of the default FBO.
* '''VIDEXT_API_VERSION''' version 3.2.0:
** add the VidExt_ListFullscreenRates and VidExt_SetVideoModeWithRate functions, which allow setting and getting the fullscreen refresh rate
* '''INPUT_API_VERSION''' version 2.0.1:
** add (optional) RenderCallback function to input plugin. This function is called by the core after rendering on screen text (OSD) and before the graphics plugin swaps the buffers. The purpose of this function is to enable the input plugin to draw on screen content, for example buttons in a touch input plugin. If this function is not present the core will ignore it and on screen rendering by the input plugin will be disabled.
* '''INPUT_API_VERSION''' version 2.1.0:
** This is not an API change, but reflects an internal behavior change. On March 23, 2018, the SDL_PumpEvents() call was moved from being in the core to only being in the input plugin. After this point, newer builds of the core would not register keyboard input when used with older builds of the input plugin, which did not call SDL_PumpEvents. As such, core libraries with INPUT_API_VERSION of 2.1.0 will refuse to work with older input plugins.
* '''FRONTEND_API_VERSION''' version 2.1.3:
** added "M64CMD_PIF_OPEN" command to allow using a binary PIF Boot ROM (instead of the included HLE implementation).
* '''FRONTEND_API_VERSION''' version 2.1.4:
** added "M64CMD_ROM_SET_SETTINGS" command to allow setting ROM settings for the currently opened ROM until the ROM is closed.
* '''CONFIG_API_VERSION''' version 2.3.2:
** add ConfigOverrideUserPaths() function to allow front-ends to override user paths.
* '''INPUT_API_VERSION''' version 2.1.1:
** add optional functions: SendVRUWord(), SetMicState(), ReadVRUResults(), ClearVRUWords(), SetVRUWordMask(). These functions add support for the VRU (Voice Recognition Unit). Also added a new int to the CONTROL struct: Type. Type can be CONT_TYPE_STANDARD (0) or CONT_TYPE_VRU (1).

CompilingFromGit

2020-10-17T21:45:14Z

Richard42: /* Compiling Mupen64Plus from source code under Linux */

== Compiling Mupen64Plus from source code under Linux ==

This guide is for people who want to play with the latest Mupen64Plus code under development, by grabbing the source code from our development repository and compiling it yourself.

=== Requirements ===

* Build environment (GCC, G++, GNU Make, nasm, pkg-config, etc)
* Git distributed SCM
* Development packages for dependencies
# SDL 1.2 or 2.0
# libpng
# FreeType 2
# zlib
# OpenGL (GL, glu)
# Boost (for glide64mk2 video plugin)
* Optional development packages for dependencies
# libsamplerate
# libspeexdsp
# liblircclient

If you are using Ubuntu, Mint, Debian, or a derived Linux distribution, you may install the pre-requisite packages with this command:

<nowiki>$ sudo apt install build-essential libz-dev libpng-dev libsdl2-dev libfreetype-dev nasm libboost-dev libboost-filesystem-dev</nowiki>

=== Installing Git ===

If you do not have git installed, launch your favorite application manager and search for '''git'''. If you are on Ubuntu or Debian this line will work in the console:'''

<nowiki>$ sudo apt-get install git</nowiki>

=== Checking out, building, and updating the source code ===

Part of the re-design of our emulator has involved breaking it up from a single big package into 6 separate modules which must all be built separately. In order to make this easier for developers, I have written a few simple shell scripts for checking out and building the code. You make download an archive of the scripts here:

[https://github.com/mupen64plus/mupen64plus-core/raw/master/tools/m64p_helper_scripts.tar.gz m64p_helper_scripts.tar.gz] (updated Dec 18, 2013)

To check out, build, and run the new Mupen64Plus code, unzip these scripts into an empty directory and run:

<nowiki>./m64p_get.sh && ./m64p_build.sh && ./m64p_test.sh</nowiki>

If, at a later time, you want to pull the latest changes and rebuild all of the code, you may do the following:

<nowiki>./m64p_update.sh && ./m64p_build.sh</nowiki>

The build script will create a <code>test</code> directory and place all of the necessary files there. You can go into this directory and run the console front-end (named <code>mupen64plus</code>) to run ROMs.

=== Custom Builds ===

The makefiles of the Mupen64Plus modules support many different compile-time options. Some of these options are specific to a single module, while others are common to several modules. You can build the modules individually, passing options to the makefile in the <code>projects/unix/</code> folder of the module, or you can append options to the <code>./m64p_build.sh</code> script and build all the modules with the same options.

==== Common Options ====
<nowiki>
General Options:
BITS=32 == build 32-bit binaries on 64-bit machine
APIDIR=path == path to find Mupen64Plus Core headers
OPTFLAGS=flag == compiler optimization (default: -O3)
PIC=(1|0) == Force enable/disable of position independent code
Install Options:
PREFIX=path == install/uninstall prefix (default: /usr/local)
SHAREDIR=path == path to install shared data files (default: PREFIX/share/mupen64plus)
LIBDIR=path == library prefix (default: PREFIX/lib)
PLUGINDIR=path == path to install plugin libraries (default: LIBDIR/mupen64plus)
DESTDIR=path == path to prepend to all installation paths (only for packagers)
Debugging Options:
DEBUG=1 == add debugging symbols
V=1 == show verbose compiler output
</nowiki>

==== Mupen64Plus-Core Only ====
<nowiki>
General Options:
LIRC=1 == enable LIRC support
NO_ASM=1 == build without assembly (no dynamic recompiler or MMX/SSE code)
SHAREDIR=path == extra path to search for shared data files
OSD=(1|0) == Enable/disable build of OpenGL On-screen display
NEW_DYNAREC=1 == Replace dynamic recompiler with Ari64's experimental dynarec
Install Options:
INCDIR=path == path to install core header files (default: PREFIX/include/mupen64plus)
Debugging Options:
PROFILE=1 == build gprof instrumentation into binaries for profiling
DEBUGGER=1 == build graphical debugger
DBG_CORE=1 == print debugging info in r4300 core
DBG_COUNT=1 == print R4300 instruction count totals (64-bit dynarec only)
DBG_COMPARE=1 == enable core-synchronized r4300 debugging
DBG_PROFILE=1 == dump profiling data for r4300 dynarec to data file
</nowiki>

==== Mupen64Plus-Audio-SDL Only ====

<nowiki>
General Options:
NO_OSS=1 == build without OSS; disables Open Sound System support
NO_SRC=1 == build without libsamplerate; disables src-* high-quality audio resampling
NO_SPEEX=1 == build without libspeexdsp; disables speex-* high-quality audio resampling
</nowiki>

==== Mupen64Plus-Input-SDL Only ====

<nowiki>
Debugging Options:
PLUGINDBG=1 == print extra debugging information while running
</nowiki>

==== Mupen64Plus-UI-Console Only ====

<nowiki>
General Options:
COREDIR=path == default path to search for Mupen64Plus Core (must end with slash)
PLUGINDIR=path == default path to search for plugins
SHAREDIR=path == default path to search for shared data files
PIE=(1|0) == Force enable/disable of position independent executables
Install Options:
BINDIR=path == path to install mupen64plus binary (default: PREFIX/bin/)
MANDIR=path == path to install mupen64plus manual page (default: PREFIX/share/man)
</nowiki>

==== Mupen64Plus-Video-Rice Only ====

<nowiki>
General Options:
NO_ASM=1 == build without inline assembly code (x86 MMX/SSE)
</nowiki>

CompilingFromGit

2020-10-17T21:42:15Z

Richard42: /* Installing Git */

== Compiling Mupen64Plus from source code under Linux ==

This guide is for people who want to play with the latest Mupen64Plus code under development, by grabbing the source code from our development repository and compiling it yourself.

=== Requirements ===

* Build environment (GCC, G++, GNU Make, pkg-config, etc)
* Git distributed SCM
* Development packages for dependencies
# SDL 1.2 or 2.0
# libpng
# FreeType 2
# zlib
# OpenGL (GL, glu)
# Boost (for glide64mk2 video plugin)
* Optional development packages for dependencies
# libsamplerate
# libspeexdsp
# liblircclient

=== Installing Git ===

If you do not have git installed, launch your favorite application manager and search for '''git'''. If you are on Ubuntu or Debian this line will work in the console:'''

<nowiki>$ sudo apt-get install git</nowiki>

=== Checking out, building, and updating the source code ===

Part of the re-design of our emulator has involved breaking it up from a single big package into 6 separate modules which must all be built separately. In order to make this easier for developers, I have written a few simple shell scripts for checking out and building the code. You make download an archive of the scripts here:

[https://github.com/mupen64plus/mupen64plus-core/raw/master/tools/m64p_helper_scripts.tar.gz m64p_helper_scripts.tar.gz] (updated Dec 18, 2013)

To check out, build, and run the new Mupen64Plus code, unzip these scripts into an empty directory and run:

<nowiki>./m64p_get.sh && ./m64p_build.sh && ./m64p_test.sh</nowiki>

If, at a later time, you want to pull the latest changes and rebuild all of the code, you may do the following:

<nowiki>./m64p_update.sh && ./m64p_build.sh</nowiki>

The build script will create a <code>test</code> directory and place all of the necessary files there. You can go into this directory and run the console front-end (named <code>mupen64plus</code>) to run ROMs.

=== Custom Builds ===

The makefiles of the Mupen64Plus modules support many different compile-time options. Some of these options are specific to a single module, while others are common to several modules. You can build the modules individually, passing options to the makefile in the <code>projects/unix/</code> folder of the module, or you can append options to the <code>./m64p_build.sh</code> script and build all the modules with the same options.

==== Common Options ====
<nowiki>
General Options:
BITS=32 == build 32-bit binaries on 64-bit machine
APIDIR=path == path to find Mupen64Plus Core headers
OPTFLAGS=flag == compiler optimization (default: -O3)
PIC=(1|0) == Force enable/disable of position independent code
Install Options:
PREFIX=path == install/uninstall prefix (default: /usr/local)
SHAREDIR=path == path to install shared data files (default: PREFIX/share/mupen64plus)
LIBDIR=path == library prefix (default: PREFIX/lib)
PLUGINDIR=path == path to install plugin libraries (default: LIBDIR/mupen64plus)
DESTDIR=path == path to prepend to all installation paths (only for packagers)
Debugging Options:
DEBUG=1 == add debugging symbols
V=1 == show verbose compiler output
</nowiki>

==== Mupen64Plus-Core Only ====
<nowiki>
General Options:
LIRC=1 == enable LIRC support
NO_ASM=1 == build without assembly (no dynamic recompiler or MMX/SSE code)
SHAREDIR=path == extra path to search for shared data files
OSD=(1|0) == Enable/disable build of OpenGL On-screen display
NEW_DYNAREC=1 == Replace dynamic recompiler with Ari64's experimental dynarec
Install Options:
INCDIR=path == path to install core header files (default: PREFIX/include/mupen64plus)
Debugging Options:
PROFILE=1 == build gprof instrumentation into binaries for profiling
DEBUGGER=1 == build graphical debugger
DBG_CORE=1 == print debugging info in r4300 core
DBG_COUNT=1 == print R4300 instruction count totals (64-bit dynarec only)
DBG_COMPARE=1 == enable core-synchronized r4300 debugging
DBG_PROFILE=1 == dump profiling data for r4300 dynarec to data file
</nowiki>

==== Mupen64Plus-Audio-SDL Only ====

<nowiki>
General Options:
NO_OSS=1 == build without OSS; disables Open Sound System support
NO_SRC=1 == build without libsamplerate; disables src-* high-quality audio resampling
NO_SPEEX=1 == build without libspeexdsp; disables speex-* high-quality audio resampling
</nowiki>

==== Mupen64Plus-Input-SDL Only ====

<nowiki>
Debugging Options:
PLUGINDBG=1 == print extra debugging information while running
</nowiki>

==== Mupen64Plus-UI-Console Only ====

<nowiki>
General Options:
COREDIR=path == default path to search for Mupen64Plus Core (must end with slash)
PLUGINDIR=path == default path to search for plugins
SHAREDIR=path == default path to search for shared data files
PIE=(1|0) == Force enable/disable of position independent executables
Install Options:
BINDIR=path == path to install mupen64plus binary (default: PREFIX/bin/)
MANDIR=path == path to install mupen64plus manual page (default: PREFIX/share/man)
</nowiki>

==== Mupen64Plus-Video-Rice Only ====

<nowiki>
General Options:
NO_ASM=1 == build without inline assembly code (x86 MMX/SSE)
</nowiki>

Mupen64Plus Plugin Parameters

2020-10-07T04:22:59Z

Richard42: /* Input-SDL */

[[Mupen64Plus v2.0 Core API v1.0|Mupen64Plus v2.0 API]]

= Plugin Parameters =

These are standard parameters which are used by the Mupen64Plus plugins. The behavior of the plugin library when these parameters are changed while the emulator is running is not defined here. Some plugins will load the parameters when starting and store internal copies of the parameters for use during emulation. Other plugins may read the value of the parameters while running.

=== Audio-SDL ===

{| border="1"
!Parameter Name!!Type!!Usage
|-
|Version
|M64TYPE_FLOAT
|Mupen64Plus Audio SDL config parameter set version number. Please don't change.
|-
|DEFAULT_FREQUENCY
|M64TYPE_INT
|Frequency which is used if rom doesn't want to change it
|-
|SWAP_CHANNELS
|M64TYPE_BOOL
|Swaps left and right channels
|-
|PRIMARY_BUFFER_SIZE
|M64TYPE_INT
|Size of primary buffer in output samples. This is where audio is loaded after it's extracted from n64's memory.
|-
|PRIMARY_BUFFER_TARGET
|M64TYPE_INT
|Fullness level target for Primary audio buffer, in equivalent output samples.
|-
|SECONDARY_BUFFER_SIZE
|M64TYPE_INT
|Size of secondary buffer in samples. This is SDL's hardware buffer.
|-
|RESAMPLE
|M64TYPE_STRING
|Audio resampling algorithm. "trivial" for fastest, lowest-quality algorithm. If compiled with SPEEX support, this can be "speex-fixed-0" to "speex-fixed-10". If compiled with libsrc support, this can be "src-sinc-best-quality", "src-sinc-medium-quality", "src-sinc-fastest", "src-zero-order-hold", or "src-linear".
|-
|VOLUME_CONTROL_TYPE
|M64TYPE_INT
|Volume control type: 1 = SDL (only affects Mupen64Plus output) 2 = OSS mixer (adjusts master PC volume)
|-
|VOLUME_ADJUST
|M64TYPE_INT
|Percentage change each time the volume is increased or decreased
|-
|VOLUME_DEFAULT
|M64TYPE_INT
|Default volume when a game is started. Only used if VOLUME_CONTROL_TYPE is 1
|-
|}

=== Video-General ===

{| border="1"
!Parameter Name!!Type!!Usage
|-
|Fullscreen
|M64TYPE_BOOL
|Use fullscreen mode if True, or windowed mode if False
|-
|ScreenWidth
|M64TYPE_INT
|Width of output window or fullscreen width
|-
|ScreenHeight
|M64TYPE_INT
|Height of output window or fullscreen height
|-
|}

=== Video-Rice ===

{| border="1"
!Parameter Name!!Type!!Usage
|-
|FrameBufferSetting
|M64TYPE_INT
|Frame Buffer Emulation (0=ROM default, 1=disable)
|-
|FrameBufferWriteBackControl
|M64TYPE_INT
|Frequency to write back the frame buffer (0=every frame, 1=every other frame, etc)
|-
|RenderToTexture
|M64TYPE_INT
|Render-to-texture emulation (0=none, 1=ignore, 2=normal, 3=write back, 4=write back and reload)
|-
|ScreenUpdateSetting
|M64TYPE_INT
|Control when the screen will be updated (0=ROM default, 1=VI origin update, 2=VI origin change, 3=CI change, 4=first CI change, 5=first primitive draw, 6=before screen clear, 7=after screen drawn)
|-
|NormalAlphaBlender
|M64TYPE_BOOL
|Force to use normal alpha blender
|-
|FastTextureLoading
|M64TYPE_BOOL
|Use a faster algorithm to speed up texture loading and CRC computation (may break hi-res texture loading)
|-
|AccurateTextureMapping
|M64TYPE_BOOL
|Use different texture coordinate clamping code
|-
|InN64Resolution
|M64TYPE_BOOL
|Force emulated frame buffers to be in N64 native resolution
|-
|SaveVRAM
|M64TYPE_BOOL
|Try to reduce Video RAM usage (should never be used)
|-
|DoubleSizeForSmallTxtrBuf
|M64TYPE_BOOL
|Enable this option to have better render-to-texture quality
|-
|DefaultCombinerDisable
|M64TYPE_BOOL
|Force to use normal color combiner
|-
|EnableHacks
|M64TYPE_BOOL
|Enable game-specific settings from INI file
|-
|EnableFog
|M64TYPE_BOOL
|Enable or disable fog generation
|-
|WinFrameMode
|M64TYPE_BOOL
|If enabled, graphics will be drawn in WinFrame mode instead of solid and texture mode
|-
|FullTMEMEmulation
|M64TYPE_BOOL
|N64 Texture Memory Full Emulation (may fix some games, may break others)
|-
|OpenGLVertexClipper
|M64TYPE_BOOL
|Enable vertex clipper for fog operations
|-
|EnableSSE
|M64TYPE_BOOL
|Enable SSE optimizations for capable CPUs
|-
|EnableVertexShader
|M64TYPE_BOOL
|Use GPU vertex shader
|-
|SkipFrame
|M64TYPE_BOOL
|If this option is enabled, the plugin will skip every other frame
|-
|TexRectOnly
|M64TYPE_BOOL
|If enabled, texture enhancement will be done only for TxtRect ucode
|-
|SmallTextureOnly
|M64TYPE_BOOL
|If enabled, texture enhancement will be done only for textures width+height<=128
|-
|LoadHiResTextures
|M64TYPE_BOOL
|Enable hi-resolution texture file loading
|-
|LoadHiResCRCOnly
|M64TYPE_BOOL
|Filter hi-resolution texture filenames based only on the CRC and ignore format+size tags (Glide64 compatibility)
|-
|DumpTexturesToFiles
|M64TYPE_BOOL
|Enable texture dumping
|-
|ShowFPS
|M64TYPE_BOOL
|Display On-screen FPS
|-
|FogMethod
|M64TYPE_INT
|Enable, Disable or Force fog generation (0=Disable, 1=Enable n64 choose, 2=Force Fog)
|-
|Mipmapping
|M64TYPE_INT
|Use Mipmapping? 0=no, 1=nearest, 2=bilinear, 3=trilinear
|-
|MultiSampling
|M64TYPE_INT
|Enable/Disable MultiSampling (0=off, 2,4,8,16=quality)
|-
|TextureEnhancement
|M64TYPE_INT
|Primary texture filter (0=None, 1=2X, 2=2XSAI, 3=HQ2X, 4=LQ2X, 5=HQ4X, 6=Sharpen, 7=Sharpen More, 8=External, 9=Mirrored)
|-
|TextureEnhancementControl
|M64TYPE_INT
|Secondary texture filter (0 = none, 1-4 = filtered)
|-
|ForceTextureFilter
|M64TYPE_INT
|Force to use texture filtering or not (0=auto: n64 choose, 1=force no filtering, 2=force filtering)
|-
|TextureQuality
|M64TYPE_INT
|Color bit depth to use for textures (0=default, 1=32 bits, 2=16 bits
|-
|OpenGLDepthBufferSetting
|M64TYPE_INT
|Z-buffer depth (only 16 or 32)
|-
|ColorQuality
|M64TYPE_INT
|Color bit depth for rendering window (0=32 bits, 1=16 bits)
|-
|OpenGLRenderSetting
|M64TYPE_INT
|OpenGL rendering level to support (0=auto, 1=OGL_1.1, 2=OGL_1.2, 3=OGL_1.3, 4=OGL_1.4, 5=OGL_1.4_V2, 6=OGL_TNT2, 7=NVIDIA_OGL, 8=OGL_FRAGMENT_PROGRAM)
|-
|AnisotropicFiltering
|M64TYPE_INT
|Enable/Disable Anisotropic Filtering for Mipmapping (0=no filtering, 2-16=quality). This is uneffective if EnableMipmapping is false. If the given value is to high to be supported by your graphic card, the value will be the highest value your graphic card can support. Better result with Trilinear filtering
|-
|ForcePolygonOffset
|M64TYPE_BOOL
|If true, use polygon offset values specified below (default=False). This can be used to eliminate stitching artifacts in textures and shadows, which are typically only a problem in mobile/embedded platforms (e.g. Android), where chipsets are inconsistent in their implementation of glPolygonOffset.
|-
|PolygonOffsetFactor
|M64TYPE_FLOAT
|Specifies a scale factor that is used to create a variable depth offset for each polygon. Ignored if ForcePolygonOffset is False, and typically only relevant for mobile/embedded platforms. This value is typically equal to PolygonOffsetUnits, and is found through trial and error. Mario's shadow in Super Mario 64 is a good test case when tuning this value. If the shadow flickers, use a larger magnitude for the float settings. Do not use a larger value than necessary to eliminate artifacts. As a guideline, typical values for mobile chipsets circa 2012-2014 are positive or negative values in the range 0.001 to 2.
|-
|PolygonOffsetUnits
|M64TYPE_FLOAT
|Is multiplied by an implementation-specific value to create a constant depth offset. Ignored if ForcePolygonOffset is False, and typically only relevant for mobile/embedded platforms. This value is typically equal to PolygonOffsetFactor, and is found through trial and error. Mario's shadow in Super Mario 64 is a good test case when tuning this value. If the shadow flickers, use a larger magnitude for the float settings. Do not use a larger value than necessary to eliminate artifacts. As a guideline, typical values for mobile chipsets circa 2012-2014 are positive or negative values in the range 0.001 to 2.
|}

=== Input-SDL ===

The Mupen64Plus-Input-SDL plugin uses a separate config section for each simulated N64 controller. The sections are named: <tt>Input-SDL-Control1</tt>, <tt>Input-SDL-Control2</tt>, <tt>Input-SDL-Control3</tt>, and <tt>Input-SDL-Control4</tt>. The 4 sections all contain the same parameters.

General-purpose Controller Configuration Parameters

{| border="1"
!Parameter Name!!Type!!Usage
|-
|version
|M64TYPE_FLOAT
|Mupen64Plus Input-SDL config parameter set version number. Please don't change.
|-
|mode
|M64TYPE_INT
|Controller configuration mode: 0=Fully Manual, 1=Auto with named SDL Device, 2=Fully automatic
|-
|device
|M64TYPE_INT
|Specifies which joystick is bound to this controller: -1=No joystick, 0 or more= SDL Joystick number
|-
|name
|M64TYPE_STRING
|SDL joystick name (or Keyboard)
|-
|plugged
|M64TYPE_BOOL
|Specifies whether this controller is 'plugged in' to the simulated N64
|-
|plugin
|M64TYPE_INT
|Specifies which type of expansion pak is in the controller: 1=None, 2=Mem pak, 5=Rumble pak
|-
|mouse
|M64TYPE_BOOL
|If True, then mouse buttons may be used with this controller, and mouse movement will map to X/Y analog stick
|-
|MouseSensitivity
|M64TYPE_STRING
|The sensitivity coefficients for the mouse to move the N64 controller axis value from 0. For X, Y axes. Values must be positive.
|-
|AnalogDeadzone
|M64TYPE_STRING
|The minimum absolute value of the SDL analog joystick axis to move the N64 controller axis value from 0. For X, Y axes.
|-
|AnalogPeak
|M64TYPE_STRING
|An absolute value of the SDL joystick axis >= AnalogPeak will saturate the N64 controller axis value (at 80). For X, Y axes. For each axis, this must be greater than the corresponding AnalogDeadzone value
|-
|}

Digital Controller Configuration
These parameters are used to bind input events with N64 Controller button presses. There are 14 simulated buttons and 2 special buttons for switching between the Mem Pak and Rumble Pak expansion units. Each configuration parameter is a string which specifies input events which will map to the given N64 button. The configuration strings consist of zero or more input event words. A list of available input event words is given here:

{| border="1"
!Input Event Word!!Usage
|-
|<tt>key(<keysym>)</tt>
|<keysym> = SDLK_* key symbol enumerated type
|-
|<tt>button(<num>)</tt>
|<num> = SDL Joystick Button Number (0 or greater)
|-
|<tt>axis(<num><dir>)</tt>
|<num> = SDL Joystick Axis Number, <dir> = axis direction (+ = positive, - = negative)
|-
|<tt>axis(<num><dir>,<deadzone>)</tt>
|<num> = SDL Joystick Axis Number, <dir> = axis direction (+ = positive, - = negative), <deadzone> = minimum axis value (max 32767) to activate button; default 6000
|-
|<tt>hat(<num> <dir>)</tt>
|<num> = SDL Joystick Hat Number, <dir> = hat direction (Up, Down, Left, or Right)
|-
|<tt>mouse(<num>)</tt>
|<num> = mouse button number (1 = left button, 2 = middle, 3 = right, etc)
|-
|}

 
{| border="1"
!Parameter Name!!Type!!Usage
|-
|DPad R
|M64TYPE_STRING
|Input event string for mapping the Right button on the D-pad
|-
|DPad L
|M64TYPE_STRING
|Input event string for mapping the Left button on the D-pad
|-
|DPad D
|M64TYPE_STRING
|Input event string for mapping the Down button on the D-pad
|-
|DPad U
|M64TYPE_STRING
|Input event string for mapping the Up button on the D-pad
|-
|Start
|M64TYPE_STRING
|Input event string for mapping the Start button
|-
|Z Trig
|M64TYPE_STRING
|Input event string for mapping the Z trigger
|-
|B Button
|M64TYPE_STRING
|Input event string for mapping the "B" button
|-
|A Button
|M64TYPE_STRING
|Input event string for mapping the "A" button
|-
|C Button R
|M64TYPE_STRING
|Input event string for mapping the Right "C" button
|-
|C Button L
|M64TYPE_STRING
|Input event string for mapping the Left "C" button
|-
|C Button D
|M64TYPE_STRING
|Input event string for mapping the Down "C" button
|-
|C Button U
|M64TYPE_STRING
|Input event string for mapping the Up "C" button
|-
|R Trig
|M64TYPE_STRING
|Input event string for mapping the Right trigger
|-
|L Trig
|M64TYPE_STRING
|Input event string for mapping the Left trigger
|-
|Mempak switch
|M64TYPE_STRING
|Input event string for toggling the Memory Pak unit
|-
|Rumblepak switch
|M64TYPE_STRING
|Input event string for toggling the Rumble Pak unit
|-
|}

Analog Controller Configuration
These parameters are used to bind input events with N64 Controller analog stick movements. There are only 2 analog stick axes, X and Y. Each configuration parameter is a string which specifies input events which will map to the given N64 controller axis movement. The configuration strings consist of zero or more input event words. A list of available input event words is given here:

{| border="1"
!Input Event Word!!Usage
|-
|<tt>key(<key_a>,<key_b>)</tt>
|<key_a> = SDLK_* key symbol for up/left movement. <key_b> = SDLK_* key symbol for down/right movement. The strength of these movements can be modulated with the Right-Shift and Right-Control keys.
|-
|<tt>button(<num_a>,<num_b>)</tt>
|<num_a> = SDL Joystick Button Number for up/left movement. <num_b> = SDL Joystick Button Number for down/right movement.
|-
|<tt>axis(<num_a><dir_a>,<num_b><dir_b>)</tt>
|<num_a> = SDL Joystick Axis Number for up/left movement, <dir_a> = axis direction for up/left movement (+ = positive, - = negative). <num_b> = SDL Joystick Axis Number for down/right movement, <dir_b> = axis direction for down/right movement.
|-
|<tt>hat(<num> <dir_a> <dir_b>)</tt>
|<num> = SDL Joystick Hat Number, <dir_a> = hat direction for up/left movement (Up, Down, Left, or Right), <dir_b> = hat direction for right/down movement
|-
|}

 
{| border="1"
!Parameter Name!!Type!!Usage
|-
|Y Axis
|M64TYPE_STRING
|Input event string for mapping the Y axis (up/down) of the analog stick
|-
|X Axis
|M64TYPE_STRING
|Input event string for mapping the X axis (left/right) of the analog stick
|-
|}

File:Teclado Mupen64Plus Inukaze.png

2020-09-17T06:17:36Z

Richard42: Richard42 uploaded a new version of "File:Teclado Mupen64Plus Inukaze.png"

SDL2 keycodes (Spanish)

KeyboardSetup

2020-09-05T06:26:11Z

Richard42:

===1. Default Key Commands In Emulator Core===

The emulator core supports key commands for many functions. The default key bindings are given below, but may be changed by editing the configuration file as described later in this document.

{| class="wikitable"
|-
|'''Key''' || '''Description'''
|-
|Escape || Quit the emulator
|-
|0-9 || Select virtual 'slot' for save/load state (F5 and F7) commands
|-
|F5 || Save emulator state
|-
|F7 || Load emulator state
|-
|F9 || Reset emulator
|-
|F10 || slow down emulator by 5%
|-
|F11 || speed up emulator by 5%
|-
|F12 || take screenshot
|-
|Alt-Enter || Toggle between windowed and fullscreen
|-
|p or P || Pause on/off
|-
|m or M || Mute/unmute sound
|-
|g or G || Press "Game Shark" button (only if cheats are enabled)
|-
|/ or ? || single frame advance while paused
|-
|F || Fast Forward (playback at 250% normal speed while F key is pressed)
|-
|[ || Decrease volume
|-
|] || Increase volume
|}

===2. Default Key Mappings for SDL-Input Plugin===

The keys or joystick/mouse inputs which will be mapped to the N64 controller for playing the games are determined by the input plugin. The SDL-Input plugin contains an auto-configuration function which will provide default joystick mappings for any recognized joystick. If there is no supported joystick connected, the input plugin will enable a default keyboard control mapping, as given below:

{| class="wikitable"
|-
|'''N64 Controller Action''' || '''Keys'''
|-
|Analog Pad || Arrow Keys (left, right, down, up)
|-
|C Up/Left/Down/Right || "I", "J", "K", "L"
|-
|DPad Up/Left/Down/Right || "W", "A", "S", "D"
|-
|Z trigger || "z"
|-
|Left trigger || "x"
|-
|Right trigger || "c"
|-
|Start || "Enter" ("Return")
|-
|A button || "left shift"
|-
|B button || "left control"
|-
|Select Mempack || ","
|-
|Select Rumblepack || "."
|}

[[File:keyboardMupen64Plus.png]]

When using the keyboard, the analog stick is normally moved by its full range when you press an arrow key. Sometimes you may need to make smaller moves. In this case, you can move the analog stick more gently by holding down the Right Control key (for -50%) or Right Shift key (-25%), or both (-75%).

===3. Configuration for Key Commands===

You may set your own key bindings for the emulator core and input plugins, by editing the Mupen64Plus config file. On Linux or OSX, this is located at <code>~/.config/mupen64plus/</code>, and on Windows it is in the "Application Data" sub-folder of your user folder. On Windows XP and prior, this is <code>C:\Documents and Settings\username\Application Data\Mupen64Plus\</code>, while on Windows Visa and newer this is <code>C:\Users\username\AppData\Mupen64Plus</code>.

See http://www.libsdl.org/release/SDL-1.2.15/include/SDL_keysym.h for Key IDs.

For documentation about the keyboard settings in this configuration file, refer to our Emuwiki site. The [[Mupen64Plus_Core_Parameters|Core Parameters]] page gives the names of the config parameters to set up the Emulator Core key commands, while the [[Mupen64Plus_Plugin_Parameters#Input-SDL|Plugin Parameters]] page tells how to configure the controls for the input plugin.

===4. SDL2 Keyboard configuration and layout (Spanish)===

Emulador : Solo puedes asignarle una tecla a cada función.

{| class="wikitable"
|-
|'''Nombre de la Función''' || '''Tecla''' || '''Valor SDL'''
|-
|Kbd Mapping Stop || ESC || "key(27)"
|-
|Kbd Mapping Fullscreen || F6 || "key(287)"
|-
|Kbd Mapping Save State || F5 || "key(286)"
|-
|Kbd Mapping Load State || 288 || "key(F7)"
|-
|Kbd Mapping Increment Slot || ¡ || "key(161)"
|-
|Kbd Mapping Reset || F9 || "key(290)"
|-
|Kbd Mapping Speed Down || F10 || "key(291)"
|-
|Kbd Mapping Speed Up || F11 || "key(292)"
|-
|Kbd Mapping Screenshot || F12 || "key(293)"
|-
|Kbd Mapping Pause || P || "key(112)"
|-
|Kbd Mapping Mute || M || "key(109)"
|-
|Kbd Mapping Increase Volume || + || "key(43)"
|-
|Kbd Mapping Decrease Volume || - || "key(45)"
|-
|Kbd Mapping Fast Forward || F || "key(102)"
|-
|Kbd Mapping Frame Advance || TAB || "key(9)"
|-
|Kbd Mapping Gameshark || G || "key(103)"
|}

Control de N64 - Jugador 1 :

{| class="wikitable"
|-
|'''Nombre de la Función''' || '''Tecla''' || '''Valor SDL'''
|-
|DPad R || D || "key(100)"
|-
|DPad L || A || "key(97)"
|-
|DPad D || S || "key(115)"
|-
|DPad U || W || "key(119)"
|-
|Start || ENTRAR || "key(13)"
|-
|Z Trig || Z / Ratón Botón Izquierdo || ""key(122)", mouse(1)"
|-
|B Button || CTRL IZQ / Ratón Botón Derecho || ""key(306)", mouse(3)"
|-
|A Button || MAYUS DER || "key(304)"
|-
|C Button R || L || "key(108)"
|-
|C Button L || J || "key(106)"
|-
|C Button D || K || "key(107)"
|-
|C Button U || I || "key(105)"
|-
|R Trig || C || "key(99)"
|-
|L Trig || X || "key(120)"
|-
|Mempak switch || , (COMA) || "key(44)"
|-
|Rumblepak switch || . (PUNTO) || "key(46)"
|-
|X Axis || IZQUIERDA & DERECHA Analogos || ""key(276,275)", axis(0-,0+)"
|-
|Y Axis || ARRIBA & ABAJO Análogos || ""key(273,274)", axis(1-,1+)"
|}

[[File:Teclado_Mupen64Plus_Inukaze.png]]

File:Teclado Mupen64Plus Inukaze.png

2020-09-05T06:15:47Z

Richard42: SDL2 keycodes (Spanish)

SDL2 keycodes (Spanish)

Mupen64Plus v2.0 Core Config

2020-06-28T18:24:17Z

Richard42:

[[Mupen64Plus v2.0 Core API v1.0|Mupen64Plus v2.0 API]]

= Mupen64Plus v2.0 Configuration API =

Most libmupen64plus functions return an <tt>m64p_error</tt> return code, which is an enumerated type defined in [[Mupen64Plus v2.0 headers#m64p_types.h|m64p_types.h]]. Front-end code should check the return value of each call to a libmupen64plus function.

== Selector Functions ==
These functions are used by the front-end to discover the sections in the configuration file, open a section, discover parameters within a section, and find out if a section has been changed.

{| border="1"
|Prototype
|'''<tt>m64p_error ConfigListSections(void *context, void (*SectionListCallback)(void * context, const char * SectionName))</tt>'''
|-
|Input Parameters
|'''<tt>context</tt>''' Void pointer to be passed to the SectionListCallback function 
'''<tt>SectionListCallback</tt>''' Pointer to function in front-end for receiving the name of every section in the Mupen64Plus Core configuration data. This function will be called once for each section in the core configuration data structure, and then the ConfigListSections() function will return.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>SectionListCallback</tt>''' pointer cannot be NULL.
|-
|Usage
|This function is called to enumerate the list of Sections in the Mupen64Plus Core configuration file. It is expected that there will be a section named "Core" for core-specific configuration data, "Graphics" for common graphics options, and one section for each plugin library.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigOpenSection(const char *SectionName, m64p_handle *ConfigSectionHandle)</tt>'''
|-
|Input Parameters
|'''<tt>SectionName</tt>''' Name of the Mupen64Plus configuration section to open. This name is case-insensitive. If no section exists with the given name, a new one will be created with no parameters. This name may consist of any ASCII characters between 32 and 127 except brackets "[]". 
'''<tt>ConfigSectionHandle</tt>''' This is a handle (defined in [[Mupen64Plus v2.0 headers#m64p_types.h|m64p_types.h]]) which is required to be used for subsequent calls to core configuration functions to list, retrieve, or set configuration parameters.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>SectionName</tt>''' and '''<tt>ConfigSectionHandle</tt>''' pointers cannot be NULL.
|-
|Usage
|This function is used to give a configuration section handle to the front-end which may be used to read or write configuration parameter values in a given section of the configuration file.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigListParameters(m64p_handle ConfigSectionHandle, void *context, void (*ParameterListCallback)(void * context, const char *ParamName, m64p_type ParamType))</tt>'''
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>context</tt>''' Void pointer to be passed to the ParameterListCallback function 
'''<tt>ParameterListCallback</tt>''' Pointer to function in front-end for receiving the name of every parameter in the given section of the Mupen64Plus Core configuration data. This function will be called once for each parameter in the section, and then the ConfigListParameters() function will return.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''' and '''<tt>ParameterListCallback</tt>''' pointers cannot be NULL.
|-
|Usage
|This function is called to enumerate the list of Parameters in a given Section of the Mupen64Plus Core configuration file.
|}
 
{| border="1"
|Prototype
|'''<tt>int ConfigHasUnsavedChanges(const char *SectionName)</tt>'''
|-
|Input Parameters
|'''<tt>SectionName</tt>''' Name of the Mupen64Plus configuration section to check for unsaved changes. This name is case-insensitive. If this pointer is NULL or points to an empty string, then all sections are checked.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. 
This function was added in the Config API version 2.2.0.
|-
|Usage
|This function is called to determine if a given Section (or all sections) of the Mupen64Plus Core configuration file has been modified since it was last saved. A return value of 0 means there are no unsaved changes, while a 1 will be returned if there are unsaved changes.
|}

== Modifier Functions ==
These functions are used for deleting parts of the configuration list or saving the configuration data to disk.

{| border="1"
|Prototype
|'''<tt>m64p_error ConfigDeleteSection(const char *SectionName)</tt>'''
|-
|Input Parameters
|'''<tt>SectionName</tt>''' Name of the Mupen64Plus configuration section to delete. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except brackets "[]". 
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function.
|-
|Usage
|This function deletes a section from the Mupen64Plus configuration data.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigSaveFile(void)</tt>'''
|-
|Input Parameters
|N/A
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function.
|-
|Usage
|This function saves the Mupen64Plus configuration file to disk.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigSaveSection(const char *SectionName)</tt>'''
|-
|Input Parameters
|'''<tt>SectionName</tt>''' Name of the Mupen64Plus configuration section to save. This name is case-insensitive.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The named section must exist in the current configuration. 
This function was added in the Config API version 2.1.0.
|-
|Usage
|This function saves one section of the current Mupen64Plus configuration to disk, while leaving the other sections unmodified.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigRevertChanges(const char *SectionName)</tt>'''
|-
|Input Parameters
|'''<tt>SectionName</tt>''' Name of the Mupen64Plus configuration section to modify. This name is case-insensitive. This pointer cannot be NULL.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The named section must exist in the current configuration. 
This function was added in the Config API version 2.2.0.
|-
|Usage
|This function reverts changes previously made to one section of the current Mupen64Plus configuration file, so that it will match with the configuration at the last time that it was loaded from or saved to disk.
|}

== Generic Get/Set Functions ==
These functions should be used for reading or writing configuration values in most cases.

{| border="1"
|Prototype
|'''<tt>m64p_error ConfigSetParameter(m64p_handle ConfigSectionHandle, const char *ParamName, m64p_type ParamType, const void *ParamValue)</tt>'''
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' NULL-terminated string containing the name of the parameter whose value is being set. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space. 
'''<tt>ParamType</tt>''' An <tt>m64p_type</tt> value giving the type of the data object that '''ParamValue''' points to. If this is different from the native data representation used by the core, it will be converted into the type used by the core. 
'''<tt>ParamValue</tt>''' Pointer to data object containing the value of the parameter to be set. 
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''', '''<tt>ParamName</tt>''' and '''<tt>ParamValue</tt>''' pointers cannot be NULL.
|-
|Usage
|This function sets the value of one of the emulator's configuration parameters in the section which is represented by '''<tt>ConfigSectionHandle</tt>'''.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigSetParameterHelp(m64p_handle ConfigSectionHandle, const char *ParamName, const char *ParamHelp)</tt>'''
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' NULL-terminated string containing the name of the parameter whose help string is being set. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space. 
'''<tt>ParamHelp</tt>''' NULL-terminated string containing some human-readable information about the usage of this parameter. Can be NULL. 
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''' and '''<tt>ParamName</tt>''' pointers cannot be NULL.
|-
|Usage
|This function sets the help string of one of the emulator's configuration parameters in the section which is represented by '''<tt>ConfigSectionHandle</tt>'''.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigGetParameter(m64p_handle ConfigSectionHandle, const char *ParamName, m64p_type ParamType, void *ParamValue, int MaxSize)</tt>'''
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' NULL-terminated string containing the name of the parameter whose value is being retrieved. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space. 
'''<tt>ParamType</tt>''' An <tt>m64p_type</tt> value giving the type of the data object that '''ParamValue''' points to. If this is different from the native data representation used by the core, it will be converted into the type given by '''ParamType'''. 
'''<tt>ParamValue</tt>''' Pointer to data object to receive the value of the parameter being retrieved. 
'''<tt>MaxSize</tt>''' Size (in bytes) of the data object that '''ParamValue''' points to.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''', '''<tt>ParamName</tt>''' and '''<tt>ParamValue</tt>''' pointers cannot be NULL.
|-
|Usage
|This function retrieves the value of one of the emulator's parameters in the section which is represented by '''<tt>ConfigSectionHandle</tt>'''.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigExternalOpen(const char *FileName, m64p_handle *Handle)</tt>'''
|-
|Return Value
|M64ERR_SUCCESS if the config file was successfully opened.
|-
|Input Parameters
|'''<tt>FileName</tt>''' The path to the config file. 
'''<tt>Handle</tt>''' A pointer to a <tt>m64p_handle</tt>.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. '''<tt>FileName</tt>''' cannot be NULL.
|-
|Usage
|This function opens an external config file and reads the contents into memory.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigExternalClose(m64p_handle Handle)</tt>'''
|-
|Return Value
|M64ERR_SUCCESS if the config file was successfully closed.
|-
|Input Parameters
|'''<tt>Handle</tt>''' A <tt>m64p_handle</tt> that was previously passed to ConfigExternalOpen().
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. '''<tt>Handle</tt>''' should have already been passed to ConfigExternalOpen().
|-
|Usage
|This function opens an external config file and reads the contents into memory.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigExternalGetParameter(m64p_handle Handle, const char *SectionName, const char *ParamName, char* ParamPtr, int ParamMaxLength)</tt>'''
|-
|Return Value
|M64ERR_SUCCESS if ParamName was found and ParamPtr is populated with the result.
|-
|Input Parameters
|'''<tt>Handle</tt>''' A <tt>m64p_handle</tt> that was previously passed to ConfigExternalOpen(). 
'''<tt>SectionName</tt>''' NULL-terminated string containing the name of the section to retrieve the parameter from. 
'''<tt>ParamName</tt>''' NULL-terminated string containing the name of the parameter whose value is being retrieved. 
'''<tt>ParamPtr</tt>''' An allocated char array that is at least as large as ParamMaxLength. The result, if found will be copied into this array. 
'''<tt>ParamMaxLength</tt>''' The maximum number of bytes to be copied into ParamPtr.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. '''<tt>Handle</tt>''' should have already been passed to ConfigExternalOpen. The '''<tt>SectionName</tt>''' and '''<tt>ParamName</tt>''' pointers cannot be NULL. ParamPtr must be a pre-allocated char array that is at least as large as ParamMaxLength.
|-
|Usage
|This functions allows a plugin to leverage the built-in ini parser to read any cfg/ini file.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigGetParameterType(m64p_handle ConfigSectionHandle, const char *ParamName, m64p_type *ParamType)</tt>'''
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' Pointer to a NULL-terminated string containing the name of the parameter whose type is being retrieved. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space. 
'''<tt>ParamType</tt>''' Pointer to an <tt>m64p_type</tt> value to receive the type of the parameter indicated by '''<tt>ParamName</tt>'''.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''', '''<tt>ParamName</tt>''', and '''<tt>ParamType</tt>''' pointers cannot be NULL.
|-
|Usage
|This function retrieves the type of one of the emulator's parameters in the section which is represented by '''<tt>ConfigSectionHandle</tt>'''. If there is no parameter with the given '''<tt>ParamName</tt>''', the error <tt>M64ERR_INPUT_NOT_FOUND</tt> will be returned.
|}
 
{| border="1"
|Prototype
|'''<tt>const char * ConfigGetParameterHelp(m64p_handle ConfigSectionHandle, const char *ParamName)</tt>'''
|-
|Return Value
|Pointer to a NULL-terminated string containing usage information for the '''<tt>ParamName</tt>''' parameter. May be NULL.
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' NULL-terminated string containing the name of the parameter for which usage information is being retrieved. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''', and '''<tt>ParamName</tt>''' pointers cannot be NULL.
|-
|Usage
|This function retrieves the help information about one of the emulator's parameters in the section which is represented by '''<tt>ConfigSectionHandle</tt>'''.
|}

== Special Get/Set Functions ==
These parameterized Get/SetDefault functions are provided for simplifying the task of handling default values within a single module. Each code module using the Core's configuration API should set the default values for all configuration parameters used by that module during its Startup() function. This allows the software to set up the default values automatically rather than storing them in a separate "default config file" which has proven problematic in the past. This also solves the problem which occurs when an upgraded module contains a new config parameter not present in the previous release.

The special Get functions return the configuration value directly rather than writing them through a pointer and returning an error code. For this reason, these parameterized Get functions should only be used within a module which 'owns' the configuration section and set up its default values in the Startup() function. Because these functions cannot signal an error to the caller, a front-end should not use these functions to retrieve configuration values for the core or the plugins, unless the names of the parameters have been enumerated with <tt>ConfigListParameters</tt> and are therefore guaranteed to exist.

 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigSetDefaultInt(m64p_handle ConfigSectionHandle, const char *ParamName, int ParamValue, const char *ParamHelp)</tt>''' 
'''<tt>m64p_error ConfigSetDefaultFloat(m64p_handle ConfigSectionHandle, const char *ParamName, float ParamValue, const char *ParamHelp)</tt>''' 
'''<tt>m64p_error ConfigSetDefaultBool(m64p_handle ConfigSectionHandle, const char *ParamName, int ParamValue, const char *ParamHelp)</tt>''' 
'''<tt>m64p_error ConfigSetDefaultString(m64p_handle ConfigSectionHandle, const char *ParamName, const char * ParamValue, const char *ParamHelp)</tt>'''
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' NULL-terminated string containing the name of the parameter whose value is being set. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space. 
'''<tt>ParamValue</tt>''' Integer or null-terminated string pointer containing the value of the parameter to be set. 
'''<tt>ParamHelp</tt>''' NULL-terminated string containing some human-readable information about the usage of this parameter. Can be NULL.

|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''' and '''<tt>ParamName</tt>''' pointers cannot be NULL.
|-
|Usage
|This function is used to set the value of a configuration parameter if it is not already present in the configuration file. This may happen if a new user runs the emulator, or an upgraded module uses a new parameter, or the user deletes his or her configuration file. If a parameter named '''<tt>ParamName</tt>''' is already present in the given section of the configuration file, then no action will be taken and this function will return successfully. Otherwise, a new parameter will be created its value will be assigned to '''<tt>ParamValue</tt>'''.
|}
 
{| border="1"
|Prototype
|
{|
|-
|'''<tt>int</tt>''' || '''<tt>ConfigGetParamInt(m64p_handle ConfigSectionHandle, const char *ParamName)</tt>'''
|-
|'''<tt>float</tt>''' || '''<tt>ConfigGetParamFloat(m64p_handle ConfigSectionHandle, const char *ParamName)</tt>'''
|-
|'''<tt>int</tt>''' || '''<tt>ConfigGetParamBool(m64p_handle ConfigSectionHandle, const char *ParamName)</tt>'''
|-
|'''<tt>const char *</tt>''' || '''<tt>ConfigGetParamString(m64p_handle ConfigSectionHandle, const char *ParamName)</tt>'''
|}
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' NULL-terminated string containing the name of the parameter whose value is being retrieved. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''' and '''<tt>ParamName</tt>''' pointers cannot be NULL.
|-
|Usage
|This function retrieves the value of one of the emulator's parameters in the section which is represented by '''<tt>ConfigSectionHandle</tt>''', and returns the value directly to the calling function. If an errors occurs (such as if '''<tt>ConfigSectionHandle</tt>''' is invalid, or there is no configuration parameter named '''<tt>ParamName</tt>'''), then an error will be sent to the front-end via the <tt>DebugCallback()</tt> function, and either a 0 (zero) or an empty string will be returned.
|}

== OS-Abstraction Functions ==

{| border="1"
|Prototype
|'''<tt>const char * ConfigGetSharedDataFilepath(const char *filename)</tt>'''
|-
|Return Value
|Pointer to a NULL-terminated string containing a full directory path and filename to a given shared data file, or NULL if this file was not found.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function.
|-
|Usage
|It is common for shared data files on Unix systems to be installed in different places on different systems. Therefore, this core function is provided to allow a plugin to retrieve a full pathname to a given shared data file. This type of file is intended to be shared among multiple users on a system, so it is likely to be read-only. Examples of these types of files include: the .ini files for Rice Video and Glide64, the font and Mupen64Plus.ini files for the core, and the cheat code files for the front-end. This function will first search in a directory given via the <tt>DataPath</tt> parameter to the '''<tt>CoreStartup</tt>''' function, then in a directory given by the <tt>SharedDataPath</tt> core configuration parameter, then in a directory which may be supplied at compile time through a Makefile or configure script option, and finally in some common system locations (such as /usr/share/mupen64plus and /usr/local/share/mupen64plus on Unix systems).
|}
 
{| border="1"
|Prototype
|'''<tt>const char * ConfigGetUserConfigPath(void)</tt>'''
|-
|Return Value
|Pointer to a NULL-terminated string containing the directory path to user-specific configuration files.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function.
|-
|Usage
|This function may be used by the plugins or front-end to get a path to the directory for storing user-specific configuration files. This will be the directory where the configuration file "mupen64plus.cfg" is located.
|}
 
{| border="1"
|Prototype
|'''<tt>const char * ConfigGetUserDataPath(void)</tt>'''
|-
|Return Value
|Pointer to a NULL-terminated string containing the directory path to user-specific data files.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function.
|-
|Usage
|This function may be used by the plugins or front-end to get a path to the directory for storing user-specific data files. This may be used to store files such as screenshots, saved game states, or hi-res textures.
|}
 
{| border="1"
|Prototype
|'''<tt>const char * ConfigGetUserCachePath(void)</tt>'''
|-
|Return Value
|Pointer to a NULL-terminated string containing the directory path to user-specific caching data files.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function.
|-
|Usage
|This function may be used by the plugins or front-end to get a path to the directory for storing user-specific caching data files. Files in this directory may be deleted by the user to save space, so critical information should not be stored here. This directory may be used to store files such as the ROM browser cache.
|}

Mupen64Plus v2.0 Core Netplay Protocol

2020-06-28T18:21:12Z

Richard42: Created page with "Mupen64Plus v2.0 API = Mupen64Plus Netplay Protocol = The Mupen64Plus netplay protocol is based on a client/server architecture. It suppor..."

[[Mupen64Plus v2.0 Core API v1.0|Mupen64Plus v2.0 API]]

= Mupen64Plus Netplay Protocol =

The Mupen64Plus netplay protocol is based on a client/server architecture. It supports syncing core settings and save files. It also supports raw input (tested with Raphnet input plugin).
TCP is used to deal with player registration, and syncing settings and saves.
UDP is used to transfer key input data.
Data is sent in Network Byte Order (Big Endian).

The server is responsible for maintaining healthy buffers and also for detecting desyncs. The server is the source of truth for input data (for instance, when player 1 pushes "A", it sends that information to the server via UDP. That "A" is not registered as input for player 1 until the client receives a packet from the server indicating what input frame to register that "A" in)

== UDP Packet formats ==
* Request input for a player (sent by client):
** 12 bytes
** byte[0] = 2
** byte[1] = player number (this is the player we need key inputs for)
** byte[2-5] = client registration ID
** byte[6-9] = current event count
** byte[10] = whether client is a spectator
** byte[11] = local buffer size of the client

* Key input data (sent by server):
** Variable length, payload cannot be larger than 512 bytes
** byte[0] = 1
** byte[1] = player number the key inputs pertain to
** byte[2] = current status. Bit 0 indicates whether the game has desynced (1 means desync). Bits 1-4 indicate whether a player has disconnected (for instance, if bit 2 is set, that means player 2 has disconnected). Bits 5-7 are currently unused.
** byte[3] = how far we lag behind the lead player
** byte[4] = number of events in this packet
** The following items will repeat/loop for the number of events in the packet
*** byte[5-8] = event count
*** byte[9-12] = key input data
*** byte[13] = current plugin

* Key input data (sent by client):
** 11 bytes
** byte[0] = 0
** byte[1] = player number
** byte[2-5] = current event count
** byte[6-9] = key input data
** byte[10] = current plugin

* Client sync data (sent by client):
** 133 bytes
** byte[0] = 4
** byte[1-4] = current VI count
** byte[5-132] = CP0 registers

== TCP Packet formats ==
* Player disconnection notice (sent by client):
** 5 bytes
** byte[0] = 7
** byte[1-4] = client registration ID

* Player registration request (sent by client):
** 8 bytes
** byte[0] = 5
** byte[1] = player the client is trying to register
** byte[2] = plugin for this player
** byte[3] = whether to use a raw input plugin
** byte[4-7] = client registration ID

* Player registration response (sent by server):
** 2 bytes
** byte[0] = response (1 if registration was successful, 0 otherwise)
** byte[1] = local buffer target for the client

* Send save file data (sent by client):
** Variable length
** byte[0] = 1
** byte[1 - next '\0'] = file name
** byte[4 bytes] = size of save file in bytes
** byte[size of file] = save file data

* Request save file data (sent by client):
** Variable length
** byte[0] = 2
** byte[1 - next '\0'] = file name

* Receive save file data (sent by server):
** Server responds with this data right after the above request
** Variable length
** byte[file size] = save file data

* Send settings (sent by client):
** 21 bytes
** byte[0] = 3
** byte[1-4] = count_per_op
** byte[5-8] = disable_extra_mem
** byte[9-12] = si_dma_duration
** byte[13-16] = emumode
** byte[17-20] = no_compiled_jump

* Request settings (sent by client):
** 1 byte
** byte[0] = 4

* Send settings (sent by server):
** Server responds with this data right after the above request
** 20 bytes
** byte[0-3] = count_per_op
** byte[4-7] = disable_extra_mem
** byte[8-11] = si_dma_duration
** byte[12-15] = emumode
** byte[16-19] = no_compiled_jump

* Request player registration data (sent by client):
** 1 byte
** byte[0] = 6

* Send player registration data (sent by server):
** 24 bytes
** The following bytes loop 4 times (once for each player)
*** byte[0-3] = player registration ID
*** byte[4] = player plugin
*** byte[5] = whether the player is using raw data input

Mupen64Plus v2.0 Core API v1.0

2020-06-28T18:18:52Z

Richard42:

Please note: as of January 2011, this API is a work in progress. 
The core Mupen64Plus v2.0 modules are complete, but work on GUI front-end applications is ongoing.

To view the design proposal which preceded this API definition, go to [[Mupen64Plus v2.0 Design Proposal 3|Design Proposal 3]].

== New Architecture ==

Earlier versions of Mupen64Plus (and other plugin-based N64 emulators) used a single monolithic application (containing the emulator core) and four plugins. The plugins were dynamically-loaded libraries, and the application used one plugin of each type: Video, Audio, Input, and RSP. Each plugin and the application contained its own GUI code for user interface, and each plugin and the application were individually responsible for finding their own data files and finding, loading, parsing, and storing their own configuration data files.

This was an acceptable architecture for emulators which were only designed to run on a single platform (such as Windows), but causes a lot of developer and user headaches when applied to a cross-platform emulator such as Mupen64Plus. For this reason, we are re-designing the layout of the emulator to solve some of the problems caused by the old architecture.

Under the new architecture, the old monolithic emulator application is split into two parts: a core emulator library and a main application, called the front-end. The front-end is primarily responsible for the user interface. All GUI code will be removed from the core and plugin libraries. The primary function of the core library is to emulate the R4300 CPU and memory system, attaching the plugins to form a full N64 system emulator. The core library also contains some utility functions which may be used by the front-end and plugins, such as a configuration parameter handler.

== High-level Usage ==

The expected sequence of operations which will be taken by the front-end application are as follows:

# Load core library (libmupen64plus.so) and set function pointers
# Call <tt>CoreGetVersion</tt>, check core version and capabilities
# Call <tt>CoreStartup</tt> to initialize the core library
# Load front-end configuration from core config API or through own mechanism
# Find plugins, open dynamic libraries, call <tt>PluginStartup</tt> for each
# Enter message loop for user interaction
# If user selects ROM and presses Play:
#* Load and de-compress the ROM
#* Use <tt>CoreDoCommand</tt> to open the ROM
#* Call <tt>CoreAttachPlugin</tt> to attach selected plugins to core
#* Use <tt>CoreDoCommand</tt> to start emulation
#* When emulation is finished, call <tt>CoreDetachPlugin</tt> on all plugins, then close the ROM

== Versioning ==
=== [[Mupen64Plus v2.0 API Versioning|API Versioning Scheme]] ===
Since the Mupen64Plus emulator comprises 6 different software modules which can be mixed and matched (the front-end app, the core library, and 4 plugins), and the interfaces between these modules change over time, there are many hard-to-diagnose bugs which could show up due to incompatibilities between these different modules. For this reason, we use a comprehensive versioning scheme which allows any 2 components to determine whether or not they are compatible, and to support forward and backward compatibility as necessary. This scheme is described in detail in this document.

== Core API ==
=== [[Mupen64Plus v2.0 Core Basic|Basic Core Functions]] ===

These two functions (<tt>PluginGetVersion</tt> and <tt>CoreErrorMessage</tt>) are utility functions and may be called at any time (even before core startup). These functions are used by both the front-end and the plugins.

=== [[Mupen64Plus v2.0 Core Front-End|Front-End Functions]] ===

There are several types of functions here, which are exported from the Core library to be used by the front-end. There are 'housekeeping' functions, for startup and shutdown, and attaching and detaching plugins. There is also a Command API which is used for many simple functions such as loading, executing, or stopping a ROM. Finally the Cheat API is here, for adding and removing cheat functions.

=== [[Mupen64Plus v2.0 Core Video Extension|Video Extension API]] ===

These functions are exported from the Core library for use by the video plugin. These functions are used for high-level video setup tasks such as enumerating available screen resolutions, setting the video mode, window caption, OpenGL attributes, and fullscreen mode. The video extension API allows for the abstraction of these functions away from the hard-coded SDL function calls currently in the video plugins, so that a front-end may override these functions and provide its own video API.

=== [[Mupen64Plus v2.0 Core Debugger|Debugger Functions]] ===

These are the debugger functions, which are also called only from the front-end. Most of these functions will return with an error if the core library was not compiled with the debugger enabled. A front-end may examine the <tt>Capabilities</tt> value returned by the <tt>CoreGetVersion</tt> function to determine if the core library was built with the debugger enabled.

=== [[Mupen64Plus v2.0 Core Config|Configuration API]] ===

These configuration functions are exported from the core library and are used by the core and the plugins to store all of their persistent configuration parameters. The front-end application may also use these functions to store its configuration options, or it may use a different mechanism. This section also contains two Operating System Abstraction functions. These functions are used by the core, plugins, and the front-end to find full filepaths to shared data files and user-specific data files.

== Plugin API ==
=== [[Mupen64Plus v2.0 Plugin API|Plugin API]] ===

This section lists all of the functions which are exported by the plugins. The front-end application should only use the <tt>PluginStartup</tt>, <tt>PluginShutdown</tt>, and <tt>PluginGetVersion</tt> functions. All other functions will only be called from the core.

== Netplay ==

Starting with version 2.6, Mupen64Plus has support for playing games with multiple players over a network. To support this, a few new command types were added to the CoreDoCommand function, as documented in [[Mupen64Plus v2.0 Core Front-End|front-end functions]]. The core handles the network I/O on its own, and the interface for handling netplay from the perspective of the front-end is very high level. The design of the netplay feature is such that a separate piece of server software (not part of Mupen64Plus) is also required. An example of such a server program is available [https://github.com/loganmc10/m64p-netplay-server here] from [https://github.com/loganmc10 loganmc10] on github. A description of the network protocol which is used for communication between the client emulators and the netplay server is available [[Mupen64Plus v2.0 Core Netplay Protocol|here]].

Mupen64Plus v2.0 Core Front-End

2020-06-28T17:55:59Z

Richard42:

[[Mupen64Plus v2.0 Core API v1.0|Mupen64Plus v2.0 API]]

= Mupen64Plus v2.0 Core<-->Front-End API =

Most libmupen64plus functions return an <tt>m64p_error</tt> return code, which is an enumerated type defined in [[Mupen64Plus v2.0 headers#m64p_types.h|m64p_types.h]]. Front-end code should check the return value of each call to a libmupen64plus function.

== Startup/Shutdown Functions ==
{| border="1"
|Prototype
|'''<tt>m64p_error CoreStartup(int APIVersion, const char *ConfigPath, const char *DataPath, void *Context, void (*DebugCallback)(void *Context, int level, const char *message), void *Context2, void (*StateCallback)(void *Context2, m64p_core_param ParamChanged, int NewValue))</tt>'''
|-
|Input Parameters
|'''<tt>APIVersion</tt>''' Integer containing the version number of the Core API used by the front-end. 
'''<tt>ConfigPath</tt>''' File path to folder containing Mupen64Plus.cfg. Can be NULL. 
'''<tt>DataPath</tt>''' Folder to search first when looking for shared data files. Can be NULL. 
'''<tt>Context</tt>''' Pointer which will be passed back to the '''<tt>DebugCallback</tt>''' function. Can be NULL. 
'''<tt>DebugCallback</tt>''' Pointer to function in front-end for receiving debug information and warnings from the core. This function must be thread-safe. Can be NULL. The value of <tt>level</tt> is 1 for an error, 2 for a warning, 3 for info, and 4 for verbose info. 
'''<tt>Context2</tt>''' Pointer which will be passed back to the '''<tt>StateCallback</tt>''' function. Can be NULL. 
'''<tt>StateCallback</tt>''' Pointer to function in front-end for receiving core state change notifications. This function must be thread-safe. Can be NULL.
|-
|Requirements
|This function must be called before any other libmupen64plus functions.
|-
|Usage
|This function initializes libmupen64plus for use by allocating memory, creating data structures, and loading the configuration file. If '''<tt>ConfigPath</tt>''' is NULL, libmupen64plus will search for the configuration file in its usual place (On Linux, in <tt>~/.config/mupen64plus/</tt>). This function may return <tt>M64ERR_INCOMPATIBLE</tt> if older front-end is used with newer core.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error CoreShutdown(void)</tt>'''
|-
|Input Parameters
|N/A
|-
|Usage
|This function saves the configuration file, then destroys data structures and releases memory allocated by the core library.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error CoreAttachPlugin(m64p_plugin_type PluginType, m64p_dynlib_handle PluginLibHandle)</tt>'''
|-
|Input Parameters
|'''<tt>PluginType</tt>''' Enumerated type specifying the plugin type to attach to the core. If this type of plugin is currently attached to the core, an error will be returned. 
'''<tt>PluginLibHandle</tt>''' Dynamic library handle (defined in [[Mupen64Plus v2.0 headers#m64p_types.h|m64p_types.h]]) corresponding with the plugin object to attach.
|-
|Requirements
|Both the core library and the plugin library must already be initialized with the <tt>CoreStartup()/PluginStartup()</tt> functions, and a ROM must be open. This function cannot be called while the emulator is running. The plugins must be attached in the following order: Video, Audio, Input, RSP.
|-
|Usage
|This function attaches the given plugin to the emulator core. There can only be one plugin of each type attached to the core at any given time.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error CoreDetachPlugin(m64p_plugin_type PluginType)</tt>'''
|-
|Input Parameters
|'''<tt>PluginType</tt>''' Enumerated type specifying the plugin type to detach from the core. If no plugin of this type is currently attached to the core, this function will exit with a return value of <tt>M64ERR_SUCCESS</tt>.
|-
|Requirements
|Both the core library and the plugin library must already be initialized with the <tt>CoreStartup()/PluginStartup()</tt> functions. This function cannot be called while the emulator is running.
|-
|Usage
|This function detaches the given plugin from the emulator core, and re-attaches the 'dummy' plugin functions.
|}

== Command Functions ==
{| border="1"
|Prototype
|'''<tt>m64p_error CoreDoCommand(m64p_command Command, int ParamInt, void *ParamPtr)</tt>'''
|-
|Input Parameters
|'''<tt>Command</tt>''' Enumerated type specifying which command should be executed. 
'''<tt>ParamInt</tt>''' An integer value which may be used as an input to the command. 
'''<tt>ParamPtr</tt>''' A pointer which may be used as an input to the command. 
|-
|Requirements
|The core library must already be initialized with the <tt>CoreStartup()</tt> function. Each command may have its own requirements as well.
|-
|Usage
|This function sends a command to the emulator core. A table of all commands is given below.
|}
 

{| border="1"
!Command!!Function!!Input Parameters!!Requirements
|-
|M64CMD_ROM_OPEN
|This will cause the core to read in a binary ROM image provided by the front-end.
|'''<tt>ParamPtr</tt>''' Pointer to the uncompressed ROM image in memory. '''<tt>ParamInt</tt>''' The size in bytes of the ROM image.
|The emulator cannot be currently running. A ROM image must not be currently opened.
|-
|M64CMD_ROM_CLOSE
|This will close any currently open ROM. The current cheat code list will also be deleted.
|N/A
|The emulator cannot be currently running. A ROM image must have been previously opened. There should be no plugins currently attached.
|-
|M64CMD_ROM_GET_HEADER
|This will retrieve the header data of the currently open ROM.
|'''<tt>ParamPtr</tt>''' Pointer to a <tt>rom_header</tt> struct to receive the data. '''<tt>ParamInt</tt>''' The size in bytes of the <tt>rom_header</tt> struct.
|A ROM image must be open.
|-
|M64CMD_ROM_GET_SETTINGS
|This will retrieve the settings data of the currently open ROM.
|'''<tt>ParamPtr</tt>''' Pointer to a <tt>rom_settings</tt> struct to receive the data. '''<tt>ParamInt</tt>''' The size in bytes of the <tt>rom_settings</tt> struct.
|A ROM image must be open.
|-
|M64CMD_EXECUTE
|This command will start the emulator and begin executing the ROM image. This function call will not return until the game has been stopped.
|N/A
|The emulator cannot be currently running. A ROM image must have been previously opened.
|-
|M64CMD_STOP
|This will stop the emulator, if it is currently running.
|N/A
|This command will execute asynchronously.
|-
|M64CMD_PAUSE
|This command will pause the emulator if it is running.
|N/A
|This function will return a non-successful error code if the emulator is in the stopped state. This command may execute asynchronously.
|-
|M64CMD_RESUME
|This command will resume execution of the emulator if it is paused.
|N/A
|This function will return a non-successful error code if the emulator is in the stopped state. This command may execute asynchronously.
|-
|M64CMD_CORE_STATE_QUERY
|This command will query the emulator core for the value of a state parameter
|'''<tt>ParamInt</tt>''' An <tt>m64p_core_param</tt> enumerated type specifying the desired state variable''' <tt>ParamPtr</tt>''' Pointer to an integer to receive the value of the requested state variable.
|None
|-
|M64CMD_CORE_STATE_SET
|This command will set the value of a state parameter in the emulator core
|'''<tt>ParamInt</tt>''' An <tt>m64p_core_param</tt> enumerated type specifying the desired state variable''' <tt>ParamPtr</tt>''' Pointer to an integer to containing the value of the requested state variable.
|The initial requirements vary depending upon the variable being set. Setting some variables requires the emulator to be running.
|-
|M64CMD_STATE_LOAD
|This command will attempt to load a saved state file. If '''<tt>ParamPtr</tt>''' is not NULL, this function will load a state file from a full pathname specified by this pointer. Otherwise ('''<tt>ParamPtr</tt>''' is NULL), it will load from the current slot.
|'''<tt>ParamInt</tt>''' Ignored''' <tt>ParamPtr</tt>''' Pointer to string containing state file path and name, or NULL
|The emulator must be currently running or paused. This command will execute asynchronously.
|-
|M64CMD_STATE_SAVE
|This command will save a state file. If '''<tt>ParamPtr</tt>''' is not NULL, this function will save a state file to a full pathname specified by this pointer. Otherwise ('''<tt>ParamPtr</tt>''' is NULL), it will save to the current slot.
|'''<tt>ParamInt</tt>''' This parameter will only be used if '''<tt>ParamPtr</tt>''' is not NULL. If 1, a Mupen64Plus state file will be saved. If 2, a Project64 compressed state file will be saved. If 3, a Project64 uncompressed state file will be saved. ''' <tt>ParamPtr</tt>''' Pointer to string containing state file path and name, or NULL 
|The emulator must be currently running or paused. This command will execute asynchronously.
|-
|M64CMD_STATE_SET_SLOT
|This command will set the currently selected save slot index
|'''<tt>ParamInt</tt>''' Value to set for the current slot index. Must be between 0 and 9''' <tt>ParamPtr</tt>''' Ignored 
|None
|-
|M64CMD_SEND_SDL_KEYDOWN
|This command will inject an SDL_KEYDOWN event into the emulator's core event loop. Keys not handled by the core will be passed to the input plugin.
|'''<tt>ParamInt</tt>''' Key value of the keypress event to inject, with SDLMod in the upper 16 bits and SDLKey in the lower 16 bits.
|The emulator must be currently running or paused.
|-
|M64CMD_SEND_SDL_KEYUP
|This command will inject an SDL_KEYUP event into the emulator's core event loop.
|'''<tt>ParamInt</tt>''' Key value of the keypress event to inject, with SDLMod in the upper 16 bits and SDLKey in the lower 16 bits.
|The emulator must be currently running or paused.
|-
|M64CMD_SET_FRAME_CALLBACK
|This command either registers or removes (if '''<tt>ParamPtr</tt>''' is NULL) a frame callback function. This function will be called after each video frame is rendered. The front-end callback function may call the video plugin's ReadScreen2() function to retrieve the frame if desired.
|'''<tt>ParamPtr</tt>''' Can be either NULL or a <tt>m64p_frame_callback</tt> object.
|None
|-
|M64CMD_TAKE_NEXT_SCREENSHOT
|This will cause the core to save a screenshot at the next possible opportunity.
|N/A
|The emulator must be currently running or paused. This command will execute asynchronously.
|-
|M64CMD_READ_SCREEN
|This command will copy the current contents of the video display to the buffer pointer by '''<tt>ParamPtr</tt>'''.
|'''<tt>ParamInt</tt>''' 1 to copy the buffer that is currently displayed (front buffer), 0 to copy the buffer that is being drawn (back buffer).''' <tt>ParamPtr</tt>'''A pointer to a buffer of at least width*height*3 bytes. The buffer will be filled with the current display. The format is RGB888 with the origin in the lower left corner.
|The emulator must be currently running or paused.
|-
|M64CMD_RESET
|Reset the emulated machine.
|'''<tt>ParamInt</tt>''' 0 to do a soft reset, 1 to do a hard reset.''' <tt>ParamPtr</tt>''' Ignored
|The emulator must be currently running or paused.
|-
|M64CMD_ADVANCE_FRAME
|Advance one frame (the emulator will run until the next frame, then pause).
|'''<tt>ParamInt</tt>''' Ignored''' <tt>ParamPtr</tt>''' Ignored
|The emulator must be currently running or paused.
|-
|M64CMD_SET_MEDIA_LOADER
|This command allow frontends to register their media (such as GameBoy cartridge or 64DD disk) loading functions. These functions will be called appropriately by the core at startup and when a new media is inserted.
|'''<tt>ParamInt</tt>''' must be sizeof(m64p_media_loader).''' <tt>ParamPtr</tt>''' A pointer to the m64p_media_loader to register, cannot be NULL.
|None
|-
|M64CMD_NETPLAY_INIT
|This command will initilize the netplay subsystem. It will also attempt to make an initial connection to the netplay server. Returns M64ERR_SYSTEM_FAIL on failure, M64ERR_SUCCESS on success.
|'''<tt>ParamInt</tt>''' This is the port number the netplay server is listening on.''' <tt>ParamPtr</tt>''' This is a string containing the IP or hostname of the netplay server.
|Emulator should be stopped.
|-
|M64CMD_NETPLAY_CONTROL_PLAYER
|This function is used for the client to request control of certain players. This function can be called more than once if a client would like to control multiple players. Local controllers are assigned in order. Returns M64ERR_INPUT_ASSERT if the server rejects the request. If this function is never called, the client is assumed to be a spectator.
|'''<tt>ParamInt</tt>''' This is the player number (from 1-4) the client would like to control.''' <tt>ParamPtr</tt>''' This is a pointer to a uint32_t that contains a unique registration ID (for instance a random number) for the client. This number should be the same each time if this function is called multiple times. The registration ID cannot be 0.
|Emulator should be stopped. The input plugin should be started.
|-
|M64CMD_NETPLAY_GET_VERSION
|This function is used to check API and core versions, the server can use this information to make sure everyone is using the same version of the software. The function returns M64ERR_INCOMPATIBLE if the API versions don't match, and M64ERR_SUCCESS if they do.
|'''<tt>ParamInt</tt>''' This is the Netplay API version that the frontend supports.''' <tt>ParamPtr</tt>''' This is a pointer to a uint32_t, the core fills this pointer with a core netplay version. This version number is incremented when changes are made to the core that would affect netplay sync.
|None
|-
|M64CMD_NETPLAY_CLOSE
|Closes the netplay subsystem, as well as any connections to the netplay server.
|N/A
|None
|}
 

== Core State Parameters ==
These core parameters may be read and/or written using the M64CMD_CORE_STATE_QUERY and M64CMD_CORE_STATE_SET commands. The front-end application will receive a callback (via the <tt>StateCallback</tt> function pointer given to the '''<tt>CoreStartup</tt>''' function) when these parameters change value. This callback will be sent even if the function which caused the state change was called by the front-end application itself. Not all of these parameters are readable or writable. Each parameter's value is held in a single 32-bit integer. The meaning of this integer is given in the Parameter Encoding column. See the table below for details on these core parameters.
 
{| border="1"
!Name!!Readable!!Writable!!<tt>int</tt> Parameter Encoding!!Notes
|-
|M64CORE_EMU_STATE
|Yes
|Yes
|<tt>enum m64p_emu_state</tt>
|<tt>1</tt>=Stopped, <tt>2</tt>=Running, <tt>3</tt>=Paused
|-
|M64CORE_VIDEO_MODE
|Yes
|Yes
|<tt>enum m64p_video_mode</tt>
|<tt>1</tt>=None (video not running), <tt>2</tt>=Windowed, <tt>3</tt>=Fullscreen
|-
|M64CORE_SAVESTATE_SLOT
|Yes
|Yes
|
|Valid values are 0 through 9.
|-
|M64CORE_SPEED_FACTOR
|Yes
|Yes
|Emulator playback speed in percent
|Valid values are 1 to 1000.
|-
|M64CORE_SPEED_LIMITER
|Yes
|Yes
|<tt>1</tt> to enable speed limiter, or <tt>0</tt> to disable speed limiter.
|When speed limiter is disabled, emulator will run as fast as possible (useful for benchmarking).
|-
|M64CORE_VIDEO_SIZE
|Yes
|Yes
|<tt>(ScreenWidth << 16) + ScreenHeight</tt>
|This parameter can only be read or written when the emulator is running or paused. This parameter may be written by the front-end application in response to a window resizing event. Upon receiving this command, the core will pass the new width and height to the ResizeVideoOutput function in the video plugin (video API v2.2.0). If the video plugin supports resizing, it will update its viewport and then call the video extension function VidExt_ResizeWindow to update the window manager.
|-
|M64CORE_AUDIO_VOLUME
|Yes
|Yes
|Volume level in percent, 0 - 100
|
|-
|M64CORE_AUDIO_MUTE
|Yes
|Yes
|<tt>1</tt> if muted, otherwise <tt>0</tt>
|
|-
|M64CORE_INPUT_GAMESHARK
|Yes
|Yes
|<tt>1</tt> when Gameshark button pressed, <tt>0</tt> when button released.
|Callback function will be invoked on both button press and release.
|-
|M64CORE_STATE_LOADCOMPLETE
|No
|No
|<tt>1</tt> if state loading was successful, <tt>0</tt> if state loading failed.
|This parameter cannot be read or written. It is only used for callbacks, because the state load/save operations are asynchronous.
|-
|M64CORE_STATE_SAVECOMPLETE
|No
|No
|<tt>1</tt> if state saving was successful, <tt>0</tt> if state saving failed.
|This parameter cannot be read or written. It is only used for callbacks, because the state load/save operations are asynchronous.
|}
 

== ROM Handling Functions ==
{| border="1"
|Prototype
|'''<tt>m64p_error CoreGetRomSettings(m64p_rom_settings *RomSettings, int RomSettingsLength, int Crc1, int Crc2)</tt>'''
|-
|Input Parameters
|'''<tt>RomSettings</tt>''' Pointer to <tt>m64p_rom_settings</tt> object to be filled in with data. 
'''<tt>RomSettingsLength</tt>''' Size of the object pointed to by '''<tt>RomSettings</tt>''' in bytes. 
'''<tt>Crc1</tt>''' A 32-bit integer value containing the first CRC (taken from the ROM header) to identify the ROM. 
'''<tt>Crc2</tt>''' A 32-bit integer value containing the second CRC (taken from the ROM header) to identify the ROM.
|-
|Requirements
|The core library must already be initialized with the <tt>CoreStartup()</tt> function. The '''<tt>RomSettings</tt>''' pointer must not be NULL. The '''<tt>RomSettingsLength</tt>''' value must be greater than or equal to the size of the <tt>m64p_rom_settings</tt> structure. This function does not require any ROM image to be currently open.
|-
|Usage
|This function searches through the data in the <tt>Mupen64Plus.ini</tt> file to find an entry which matches the given '''<tt>Crc1</tt>''' and '''<tt>Crc2</tt>''' hashes, and if found, fills in the '''<tt>RomSettings</tt>''' structure with the data from the <tt>Mupen64Plus.ini</tt> file.
|}
 

== Video Extension Functions ==
{| border="1"
|Prototype
|'''<tt>m64p_error CoreOverrideVidExt(m64p_video_extension_functions *VideoFunctionStruct);</tt>'''
|-
|Input Parameters
|'''<tt>VideoFunctionStruct</tt>''' Pointer to a structure (defined in [[Mupen64Plus v2.0 headers#m64p_types.h|m64p_types.h]]) containing pointers to the Front-end's custom Video Extension functions to override the default SDL functions
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. This function cannot be called while the emulator is running.
|-
|Usage
|This function overrides the core's internal SDL-based OpenGL functions which are called from the video plugin to perform various basic tasks like opening the video window, toggling between windowed and fullscreen modes, and swapping frame buffers after a frame has been rendered. This override functionality allows a front-end to define its own video extension functions to be used instead of the SDL functions, such as for the purpose of embedding the emulator display window inside of a Qt GUI window. If any of the function pointers in the structure are NULL, the override function will be disabled and the core's internal SDL functions will be used. The core library with a Video Extension API v3.0 expects the <tt>Functions</tt> struct member to be equal to 11 or more.
|}
 

== Cheat Functions ==
{| border="1"
|Prototype
|'''<tt>m64p_error CoreAddCheat(const char *CheatName, m64p_cheat_code *CodeList, int NumCodes)</tt>'''
|-
|Input Parameters
|'''<tt>CheatName</tt>''' Pointer to NULL-terminated string containing a unique name for this Cheat Function. 
'''<tt>CodeList</tt>''' Pointer to an array of <tt>m64p_cheat_code</tt> objects. 
'''<tt>NumCodes</tt>''' Number of <tt>m64p_cheat_code</tt> elements in the cheat code array.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. A ROM image must be currently opened.
|-
|Usage
|This function will add a Cheat Function to a list of currently active cheats which are applied to the open ROM, and set its state to Enabled. This function may be called before a ROM begins execution or while a ROM is currently running. Some cheat codes must be applied before the ROM begins executing, and may not work correctly if added after the ROM begins execution. A Cheat Function consists of a list of one or more <tt>m64p_cheat_code</tt> elements. If a Cheat Function with the given '''<tt>CheatName</tt>''' already exists, it will be removed and the new Cheat Function will be added in its place.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error CoreCheatEnabled(const char *CheatName, int Enabled)</tt>'''
|-
|Input Parameters
|'''<tt>CheatName</tt>''' Pointer to NULL-terminated string containing the name of an existing Cheat Function. 
'''<tt>Enabled</tt>''' Boolean value to which to set the enabled state of the specified Cheat Function.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. A ROM image must be currently opened.
|-
|Usage
|This function enables or disables a specified Cheat Function.
|}

Mupen64Plus v2.0 Core Config

2020-06-28T17:48:31Z

Richard42: /* Generic Get/Set Functions */

[[Mupen64Plus v2.0 Core API v1.0|Mupen64Plus v2.0 API]]

= Mupen64Plus v2.0 Configuration API =

Most libmupen64plus functions return an <tt>m64p_error</tt> return code, which is an enumerated type defined in [[Mupen64Plus v2.0 headers#m64p_types.h|m64p_types.h]]. Front-end code should check the return value of each call to a libmupen64plus function.

== Selector Functions ==
These functions are used by the front-end to discover the sections in the configuration file, open a section, discover parameters within a section, and find out if a section has been changed.

{| border="1"
|Prototype
|'''<tt>m64p_error ConfigListSections(void *context, void (*SectionListCallback)(void * context, const char * SectionName))</tt>'''
|-
|Input Parameters
|'''<tt>context</tt>''' Void pointer to be passed to the SectionListCallback function 
'''<tt>SectionListCallback</tt>''' Pointer to function in front-end for receiving the name of every section in the Mupen64Plus Core configuration data. This function will be called once for each section in the core configuration data structure, and then the ConfigListSections() function will return.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>SectionListCallback</tt>''' pointer cannot be NULL.
|-
|Usage
|This function is called to enumerate the list of Sections in the Mupen64Plus Core configuration file. It is expected that there will be a section named "Core" for core-specific configuration data, "Graphics" for common graphics options, and one section for each plugin library.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigOpenSection(const char *SectionName, m64p_handle *ConfigSectionHandle)</tt>'''
|-
|Input Parameters
|'''<tt>SectionName</tt>''' Name of the Mupen64Plus configuration section to open. This name is case-insensitive. If no section exists with the given name, a new one will be created with no parameters. This name may consist of any ASCII characters between 32 and 127 except brackets "[]". 
'''<tt>ConfigSectionHandle</tt>''' This is a handle (defined in [[Mupen64Plus v2.0 headers#m64p_types.h|m64p_types.h]]) which is required to be used for subsequent calls to core configuration functions to list, retrieve, or set configuration parameters.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>SectionName</tt>''' and '''<tt>ConfigSectionHandle</tt>''' pointers cannot be NULL.
|-
|Usage
|This function is used to give a configuration section handle to the front-end which may be used to read or write configuration parameter values in a given section of the configuration file.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigListParameters(m64p_handle ConfigSectionHandle, void *context, void (*ParameterListCallback)(void * context, const char *ParamName, m64p_type ParamType))</tt>'''
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>context</tt>''' Void pointer to be passed to the ParameterListCallback function 
'''<tt>ParameterListCallback</tt>''' Pointer to function in front-end for receiving the name of every parameter in the given section of the Mupen64Plus Core configuration data. This function will be called once for each parameter in the section, and then the ConfigListParameters() function will return.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''' and '''<tt>ParameterListCallback</tt>''' pointers cannot be NULL.
|-
|Usage
|This function is called to enumerate the list of Parameters in a given Section of the Mupen64Plus Core configuration file.
|}
 
{| border="1"
|Prototype
|'''<tt>int ConfigHasUnsavedChanges(const char *SectionName)</tt>'''
|-
|Input Parameters
|'''<tt>SectionName</tt>''' Name of the Mupen64Plus configuration section to check for unsaved changes. This name is case-insensitive. If this pointer is NULL or points to an empty string, then all sections are checked.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. 
This function was added in the Config API version 2.2.0.
|-
|Usage
|This function is called to determine if a given Section (or all sections) of the Mupen64Plus Core configuration file has been modified since it was last saved. A return value of 0 means there are no unsaved changes, while a 1 will be returned if there are unsaved changes.
|}

== Modifier Functions ==
These functions are used for deleting parts of the configuration list or saving the configuration data to disk.

{| border="1"
|Prototype
|'''<tt>m64p_error ConfigDeleteSection(const char *SectionName)</tt>'''
|-
|Input Parameters
|'''<tt>SectionName</tt>''' Name of the Mupen64Plus configuration section to delete. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except brackets "[]". 
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function.
|-
|Usage
|This function deletes a section from the Mupen64Plus configuration data.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigSaveFile(void)</tt>'''
|-
|Input Parameters
|N/A
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function.
|-
|Usage
|This function saves the Mupen64Plus configuration file to disk.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigSaveSection(const char *SectionName)</tt>'''
|-
|Input Parameters
|'''<tt>SectionName</tt>''' Name of the Mupen64Plus configuration section to save. This name is case-insensitive.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The named section must exist in the current configuration. 
This function was added in the Config API version 2.1.0.
|-
|Usage
|This function saves one section of the current Mupen64Plus configuration to disk, while leaving the other sections unmodified.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigRevertChanges(const char *SectionName)</tt>'''
|-
|Input Parameters
|'''<tt>SectionName</tt>''' Name of the Mupen64Plus configuration section to modify. This name is case-insensitive. This pointer cannot be NULL.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The named section must exist in the current configuration. 
This function was added in the Config API version 2.2.0.
|-
|Usage
|This function reverts changes previously made to one section of the current Mupen64Plus configuration file, so that it will match with the configuration at the last time that it was loaded from or saved to disk.
|}

== Generic Get/Set Functions ==
These functions should be used for reading or writing configuration values in most cases.

{| border="1"
|Prototype
|'''<tt>m64p_error ConfigSetParameter(m64p_handle ConfigSectionHandle, const char *ParamName, m64p_type ParamType, const void *ParamValue)</tt>'''
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' NULL-terminated string containing the name of the parameter whose value is being set. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space. 
'''<tt>ParamType</tt>''' An <tt>m64p_type</tt> value giving the type of the data object that '''ParamValue''' points to. If this is different from the native data representation used by the core, it will be converted into the type used by the core. 
'''<tt>ParamValue</tt>''' Pointer to data object containing the value of the parameter to be set. 
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''', '''<tt>ParamName</tt>''' and '''<tt>ParamValue</tt>''' pointers cannot be NULL.
|-
|Usage
|This function sets the value of one of the emulator's configuration parameters in the section which is represented by '''<tt>ConfigSectionHandle</tt>'''.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigSetParameterHelp(m64p_handle ConfigSectionHandle, const char *ParamName, const char *ParamHelp)</tt>'''
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' NULL-terminated string containing the name of the parameter whose help string is being set. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space. 
'''<tt>ParamHelp</tt>''' NULL-terminated string containing some human-readable information about the usage of this parameter. Can be NULL. 
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''' and '''<tt>ParamName</tt>''' pointers cannot be NULL.
|-
|Usage
|This function sets the help string of one of the emulator's configuration parameters in the section which is represented by '''<tt>ConfigSectionHandle</tt>'''.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigGetParameter(m64p_handle ConfigSectionHandle, const char *ParamName, m64p_type ParamType, void *ParamValue, int MaxSize)</tt>'''
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' NULL-terminated string containing the name of the parameter whose value is being retrieved. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space. 
'''<tt>ParamType</tt>''' An <tt>m64p_type</tt> value giving the type of the data object that '''ParamValue''' points to. If this is different from the native data representation used by the core, it will be converted into the type given by '''ParamType'''. 
'''<tt>ParamValue</tt>''' Pointer to data object to receive the value of the parameter being retrieved. 
'''<tt>MaxSize</tt>''' Size (in bytes) of the data object that '''ParamValue''' points to.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''', '''<tt>ParamName</tt>''' and '''<tt>ParamValue</tt>''' pointers cannot be NULL.
|-
|Usage
|This function retrieves the value of one of the emulator's parameters in the section which is represented by '''<tt>ConfigSectionHandle</tt>'''.
|}
 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigGetParameterType(m64p_handle ConfigSectionHandle, const char *ParamName, m64p_type *ParamType)</tt>'''
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' Pointer to a NULL-terminated string containing the name of the parameter whose type is being retrieved. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space. 
'''<tt>ParamType</tt>''' Pointer to an <tt>m64p_type</tt> value to receive the type of the parameter indicated by '''<tt>ParamName</tt>'''.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''', '''<tt>ParamName</tt>''', and '''<tt>ParamType</tt>''' pointers cannot be NULL.
|-
|Usage
|This function retrieves the type of one of the emulator's parameters in the section which is represented by '''<tt>ConfigSectionHandle</tt>'''. If there is no parameter with the given '''<tt>ParamName</tt>''', the error <tt>M64ERR_INPUT_NOT_FOUND</tt> will be returned.
|}
 
{| border="1"
|Prototype
|'''<tt>const char * ConfigGetParameterHelp(m64p_handle ConfigSectionHandle, const char *ParamName)</tt>'''
|-
|Return Value
|Pointer to a NULL-terminated string containing usage information for the '''<tt>ParamName</tt>''' parameter. May be NULL.
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' NULL-terminated string containing the name of the parameter for which usage information is being retrieved. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''', and '''<tt>ParamName</tt>''' pointers cannot be NULL.
|-
|Usage
|This function retrieves the help information about one of the emulator's parameters in the section which is represented by '''<tt>ConfigSectionHandle</tt>'''.
|}

== Special Get/Set Functions ==
These parameterized Get/SetDefault functions are provided for simplifying the task of handling default values within a single module. Each code module using the Core's configuration API should set the default values for all configuration parameters used by that module during its Startup() function. This allows the software to set up the default values automatically rather than storing them in a separate "default config file" which has proven problematic in the past. This also solves the problem which occurs when an upgraded module contains a new config parameter not present in the previous release.

The special Get functions return the configuration value directly rather than writing them through a pointer and returning an error code. For this reason, these parameterized Get functions should only be used within a module which 'owns' the configuration section and set up its default values in the Startup() function. Because these functions cannot signal an error to the caller, a front-end should not use these functions to retrieve configuration values for the core or the plugins, unless the names of the parameters have been enumerated with <tt>ConfigListParameters</tt> and are therefore guaranteed to exist.

 
{| border="1"
|Prototype
|'''<tt>m64p_error ConfigSetDefaultInt(m64p_handle ConfigSectionHandle, const char *ParamName, int ParamValue, const char *ParamHelp)</tt>''' 
'''<tt>m64p_error ConfigSetDefaultFloat(m64p_handle ConfigSectionHandle, const char *ParamName, float ParamValue, const char *ParamHelp)</tt>''' 
'''<tt>m64p_error ConfigSetDefaultBool(m64p_handle ConfigSectionHandle, const char *ParamName, int ParamValue, const char *ParamHelp)</tt>''' 
'''<tt>m64p_error ConfigSetDefaultString(m64p_handle ConfigSectionHandle, const char *ParamName, const char * ParamValue, const char *ParamHelp)</tt>'''
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' NULL-terminated string containing the name of the parameter whose value is being set. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space. 
'''<tt>ParamValue</tt>''' Integer or null-terminated string pointer containing the value of the parameter to be set. 
'''<tt>ParamHelp</tt>''' NULL-terminated string containing some human-readable information about the usage of this parameter. Can be NULL.

|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''' and '''<tt>ParamName</tt>''' pointers cannot be NULL.
|-
|Usage
|This function is used to set the value of a configuration parameter if it is not already present in the configuration file. This may happen if a new user runs the emulator, or an upgraded module uses a new parameter, or the user deletes his or her configuration file. If a parameter named '''<tt>ParamName</tt>''' is already present in the given section of the configuration file, then no action will be taken and this function will return successfully. Otherwise, a new parameter will be created its value will be assigned to '''<tt>ParamValue</tt>'''.
|}
 
{| border="1"
|Prototype
|
{|
|-
|'''<tt>int</tt>''' || '''<tt>ConfigGetParamInt(m64p_handle ConfigSectionHandle, const char *ParamName)</tt>'''
|-
|'''<tt>float</tt>''' || '''<tt>ConfigGetParamFloat(m64p_handle ConfigSectionHandle, const char *ParamName)</tt>'''
|-
|'''<tt>int</tt>''' || '''<tt>ConfigGetParamBool(m64p_handle ConfigSectionHandle, const char *ParamName)</tt>'''
|-
|'''<tt>const char *</tt>''' || '''<tt>ConfigGetParamString(m64p_handle ConfigSectionHandle, const char *ParamName)</tt>'''
|}
|-
|Input Parameters
|'''<tt>ConfigSectionHandle</tt>''' An <tt>m64p_handle</tt> given by the '''<tt>ConfigOpenSection</tt>''' function. 
'''<tt>ParamName</tt>''' NULL-terminated string containing the name of the parameter whose value is being retrieved. This name is case-insensitive. This name may consist of any ASCII characters between 32 and 127 except the equals and hash signs, and may not end in a space.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function. The '''<tt>ConfigSectionHandle</tt>''' and '''<tt>ParamName</tt>''' pointers cannot be NULL.
|-
|Usage
|This function retrieves the value of one of the emulator's parameters in the section which is represented by '''<tt>ConfigSectionHandle</tt>''', and returns the value directly to the calling function. If an errors occurs (such as if '''<tt>ConfigSectionHandle</tt>''' is invalid, or there is no configuration parameter named '''<tt>ParamName</tt>'''), then an error will be sent to the front-end via the <tt>DebugCallback()</tt> function, and either a 0 (zero) or an empty string will be returned.
|}

== OS-Abstraction Functions ==

{| border="1"
|Prototype
|'''<tt>const char * ConfigGetSharedDataFilepath(const char *filename)</tt>'''
|-
|Return Value
|Pointer to a NULL-terminated string containing a full directory path and filename to a given shared data file, or NULL if this file was not found.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function.
|-
|Usage
|It is common for shared data files on Unix systems to be installed in different places on different systems. Therefore, this core function is provided to allow a plugin to retrieve a full pathname to a given shared data file. This type of file is intended to be shared among multiple users on a system, so it is likely to be read-only. Examples of these types of files include: the .ini files for Rice Video and Glide64, the font and Mupen64Plus.ini files for the core, and the cheat code files for the front-end. This function will first search in a directory given via the <tt>DataPath</tt> parameter to the '''<tt>CoreStartup</tt>''' function, then in a directory given by the <tt>SharedDataPath</tt> core configuration parameter, then in a directory which may be supplied at compile time through a Makefile or configure script option, and finally in some common system locations (such as /usr/share/mupen64plus and /usr/local/share/mupen64plus on Unix systems).
|}
 
{| border="1"
|Prototype
|'''<tt>const char * ConfigGetUserConfigPath(void)</tt>'''
|-
|Return Value
|Pointer to a NULL-terminated string containing the directory path to user-specific configuration files.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function.
|-
|Usage
|This function may be used by the plugins or front-end to get a path to the directory for storing user-specific configuration files. This will be the directory where the configuration file "mupen64plus.cfg" is located.
|}
 
{| border="1"
|Prototype
|'''<tt>const char * ConfigGetUserDataPath(void)</tt>'''
|-
|Return Value
|Pointer to a NULL-terminated string containing the directory path to user-specific data files.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function.
|-
|Usage
|This function may be used by the plugins or front-end to get a path to the directory for storing user-specific data files. This may be used to store files such as screenshots, saved game states, or hi-res textures.
|}
 
{| border="1"
|Prototype
|'''<tt>const char * ConfigGetUserCachePath(void)</tt>'''
|-
|Return Value
|Pointer to a NULL-terminated string containing the directory path to user-specific caching data files.
|-
|Requirements
|The Mupen64Plus library must already be initialized before calling this function.
|-
|Usage
|This function may be used by the plugins or front-end to get a path to the directory for storing user-specific caching data files. Files in this directory may be deleted by the user to save space, so critical information should not be stored here. This directory may be used to store files such as the ROM browser cache.
|}

Mupen64Plus v2.0 Core Netplay

2020-06-28T17:45:28Z

Richard42: Mupen64Plus netplay protocol documentation

= Mupen64Plus Netplay API =

The Mupen64Plus netplay API is based on a client/server architecture. It supports syncing core settings and save files. It also supports raw input (tested with Raphnet input plugin).
TCP is used to deal with player registration, and syncing settings and saves.
UDP is used to transfer key input data.
Data is sent in Network Byte Order (Big Endian).

The server is responsible for maintaining healthy buffers and also for detecting desyncs. The server is the source of truth for input data (for instance, when player 1 pushes "A", it sends that information to the server via UDP. That "A" is not registered as input for player 1 until the client receives a packet from the server indicating what input frame to register that "A" in)

== UDP Packet formats ==
* Request input for a player (sent by client):
** 12 bytes
** byte[0] = 2
** byte[1] = player number (this is the player we need key inputs for)
** byte[2-5] = client registration ID
** byte[6-9] = current event count
** byte[10] = whether client is a spectator
** byte[11] = local buffer size of the client

* Key input data (sent by server):
** Variable length, payload cannot be larger than 512 bytes
** byte[0] = 1
** byte[1] = player number the key inputs pertain to
** byte[2] = current status. Bit 0 indicates whether the game has desynced (1 means desync). Bits 1-4 indicate whether a player has disconnected (for instance, if bit 2 is set, that means player 2 has disconnected). Bits 5-7 are currently unused.
** byte[3] = how far we lag behind the lead player
** byte[4] = number of events in this packet
** The following items will repeat/loop for the number of events in the packet
*** byte[5-8] = event count
*** byte[9-12] = key input data
*** byte[13] = current plugin

* Key input data (sent by client):
** 11 bytes
** byte[0] = 0
** byte[1] = player number
** byte[2-5] = current event count
** byte[6-9] = key input data
** byte[10] = current plugin

* Client sync data (sent by client):
** 133 bytes
** byte[0] = 4
** byte[1-4] = current VI count
** byte[5-132] = CP0 registers

== TCP Packet formats ==
* Player disconnection notice (sent by client):
** 5 bytes
** byte[0] = 7
** byte[1-4] = client registration ID

* Player registration request (sent by client):
** 8 bytes
** byte[0] = 5
** byte[1] = player the client is trying to register
** byte[2] = plugin for this player
** byte[3] = whether to use a raw input plugin
** byte[4-7] = client registration ID

* Player registration response (sent by server):
** 2 bytes
** byte[0] = response (1 if registration was successful, 0 otherwise)
** byte[1] = local buffer target for the client

* Send save file data (sent by client):
** Variable length
** byte[0] = 1
** byte[1 - next '\0'] = file name
** byte[4 bytes] = size of save file in bytes
** byte[size of file] = save file data

* Request save file data (sent by client):
** Variable length
** byte[0] = 2
** byte[1 - next '\0'] = file name

* Receive save file data (sent by server):
** Server responds with this data right after the above request
** Variable length
** byte[file size] = save file data

* Send settings (sent by client):
** 21 bytes
** byte[0] = 3
** byte[1-4] = count_per_op
** byte[5-8] = disable_extra_mem
** byte[9-12] = si_dma_duration
** byte[13-16] = emumode
** byte[17-20] = no_compiled_jump

* Request settings (sent by client):
** 1 byte
** byte[0] = 4

* Send settings (sent by server):
** Server responds with this data right after the above request
** 20 bytes
** byte[0-3] = count_per_op
** byte[4-7] = disable_extra_mem
** byte[8-11] = si_dma_duration
** byte[12-15] = emumode
** byte[16-19] = no_compiled_jump

* Request player registration data (sent by client):
** 1 byte
** byte[0] = 6

* Send player registration data (sent by server):
** 24 bytes
** The following bytes loop 4 times (once for each player)
*** byte[0-3] = player registration ID
*** byte[4] = player plugin
*** byte[5] = whether the player is using raw data input

Mupen64Plus v2.0 Core API v1.0

2020-06-28T17:44:39Z

Richard42: /* Core API */

Please note: as of January 2011, this API is a work in progress. 
The core Mupen64Plus v2.0 modules are complete, but work on GUI front-end applications is ongoing.

To view the design proposal which preceded this API definition, go to [[Mupen64Plus v2.0 Design Proposal 3|Design Proposal 3]].

== New Architecture ==

Earlier versions of Mupen64Plus (and other plugin-based N64 emulators) used a single monolithic application (containing the emulator core) and four plugins. The plugins were dynamically-loaded libraries, and the application used one plugin of each type: Video, Audio, Input, and RSP. Each plugin and the application contained its own GUI code for user interface, and each plugin and the application were individually responsible for finding their own data files and finding, loading, parsing, and storing their own configuration data files.

This was an acceptable architecture for emulators which were only designed to run on a single platform (such as Windows), but causes a lot of developer and user headaches when applied to a cross-platform emulator such as Mupen64Plus. For this reason, we are re-designing the layout of the emulator to solve some of the problems caused by the old architecture.

Under the new architecture, the old monolithic emulator application is split into two parts: a core emulator library and a main application, called the front-end. The front-end is primarily responsible for the user interface. All GUI code will be removed from the core and plugin libraries. The primary function of the core library is to emulate the R4300 CPU and memory system, attaching the plugins to form a full N64 system emulator. The core library also contains some utility functions which may be used by the front-end and plugins, such as a configuration parameter handler.

== High-level Usage ==

The expected sequence of operations which will be taken by the front-end application are as follows:

# Load core library (libmupen64plus.so) and set function pointers
# Call <tt>CoreGetVersion</tt>, check core version and capabilities
# Call <tt>CoreStartup</tt> to initialize the core library
# Load front-end configuration from core config API or through own mechanism
# Find plugins, open dynamic libraries, call <tt>PluginStartup</tt> for each
# Enter message loop for user interaction
# If user selects ROM and presses Play:
#* Load and de-compress the ROM
#* Use <tt>CoreDoCommand</tt> to open the ROM
#* Call <tt>CoreAttachPlugin</tt> to attach selected plugins to core
#* Use <tt>CoreDoCommand</tt> to start emulation
#* When emulation is finished, call <tt>CoreDetachPlugin</tt> on all plugins, then close the ROM

== Versioning ==
=== [[Mupen64Plus v2.0 API Versioning|API Versioning Scheme]] ===
Since the Mupen64Plus emulator comprises 6 different software modules which can be mixed and matched (the front-end app, the core library, and 4 plugins), and the interfaces between these modules change over time, there are many hard-to-diagnose bugs which could show up due to incompatibilities between these different modules. For this reason, we use a comprehensive versioning scheme which allows any 2 components to determine whether or not they are compatible, and to support forward and backward compatibility as necessary. This scheme is described in detail in this document.

== Core API ==
=== [[Mupen64Plus v2.0 Core Basic|Basic Core Functions]] ===

These two functions (<tt>PluginGetVersion</tt> and <tt>CoreErrorMessage</tt>) are utility functions and may be called at any time (even before core startup). These functions are used by both the front-end and the plugins.

=== [[Mupen64Plus v2.0 Core Front-End|Front-End Functions]] ===

There are several types of functions here, which are exported from the Core library to be used by the front-end. There are 'housekeeping' functions, for startup and shutdown, and attaching and detaching plugins. There is also a Command API which is used for many simple functions such as loading, executing, or stopping a ROM. Finally the Cheat API is here, for adding and removing cheat functions.

=== [[Mupen64Plus v2.0 Core Video Extension|Video Extension API]] ===

These functions are exported from the Core library for use by the video plugin. These functions are used for high-level video setup tasks such as enumerating available screen resolutions, setting the video mode, window caption, OpenGL attributes, and fullscreen mode. The video extension API allows for the abstraction of these functions away from the hard-coded SDL function calls currently in the video plugins, so that a front-end may override these functions and provide its own video API.

=== [[Mupen64Plus v2.0 Core Debugger|Debugger Functions]] ===

These are the debugger functions, which are also called only from the front-end. Most of these functions will return with an error if the core library was not compiled with the debugger enabled. A front-end may examine the <tt>Capabilities</tt> value returned by the <tt>CoreGetVersion</tt> function to determine if the core library was built with the debugger enabled.

=== [[Mupen64Plus v2.0 Core Config|Configuration API]] ===

These configuration functions are exported from the core library and are used by the core and the plugins to store all of their persistent configuration parameters. The front-end application may also use these functions to store its configuration options, or it may use a different mechanism. This section also contains two Operating System Abstraction functions. These functions are used by the core, plugins, and the front-end to find full filepaths to shared data files and user-specific data files.

=== [[Mupen64Plus v2.0 Core Netplay|Netplay API]] ===

== Plugin API ==
=== [[Mupen64Plus v2.0 Plugin API|Plugin API]] ===

This section lists all of the functions which are exported by the plugins. The front-end application should only use the <tt>PluginStartup</tt>, <tt>PluginShutdown</tt>, and <tt>PluginGetVersion</tt> functions. All other functions will only be called from the core.

UIConsoleUsage

2019-03-23T16:26:16Z

Richard42: /* Cheats */

==Console Options==

At startup, the mupen64plus program will look for a user configuration file called 'mupen64plus.cfg' (see [[FileLocations]] for more informations).

If this file does not exist, it will be created and default settings will be written. If desired, an alternate config directory can be specified using the --configdir commandline option.

Run 'mupen64plus --help' for a complete list of commandline options:
<nowiki>
$ mupen64plus --help
Usage: mupen64plus [parameter(s)] rom

Parameters:
--noosd : disable onscreen display
--osd : enable onscreen display
--fullscreen : use fullscreen display mode
--windowed : use windowed display mode
--resolution (res) : display resolution (640x480, 800x600, 1024x768, etc)
--nospeedlimit : disable core speed limiter (should be used with dummy audio plugin)
--cheats (cheat-spec) : enable or list cheat codes for the given rom file
--corelib (filepath) : use core library (filepath) (can be only filename or full path)
--configdir (dir) : force configation directory to (dir); should contain mupen64plus.cfg
--datadir (dir) : search for shared data files (.ini files, languages, etc) in (dir)
--debug : launch console-based debugger (requires core lib built for debugging)
--plugindir (dir) : search for plugins in (dir)
--sshotdir (dir) : set screenshot directory to (dir)
--gfx (plugin-spec) : use gfx plugin given by (plugin-spec)
--audio (plugin-spec) : use audio plugin given by (plugin-spec)
--input (plugin-spec) : use input plugin given by (plugin-spec)
--rsp (plugin-spec) : use rsp plugin given by (plugin-spec)
--emumode (mode) : set emu mode to: 0=Pure Interpreter 1=Interpreter 2=DynaRec
--testshots (list) : take screenshots at frames given in comma-separated (list), then quit
--set (param-spec) : set a configuration variable, format: ParamSection[ParamName]=Value
--gb-rom-{1,2,3,4} : define GB cart rom to load inside transferpak {1,2,3,4}"
--gb-ram-{1,2,3,4} : define GB cart ram to load inside transferpak {1,2,3,4}"
--core-compare-send : use the Core Comparison debugging feature, in data sending mode
--core-compare-recv : use the Core Comparison debugging feature, in data receiving mode
--nosaveoptions : do not save the given command-line options in configuration file
--verbose : print lots of information
--help : see this help message

(plugin-spec):
(pluginname) : filename (without path) of plugin to find in plugin directory
(pluginpath) : full path and filename of plugin
'dummy' : use dummy plugin

(cheat-spec):
'list' : show all of the available cheat codes
'all' : enable all of the available cheat codes
(codelist) : a comma-separated list of cheat code numbers to enable,
with dashes to use code variables (ex 1-2 to use cheat 1 option 2)
</nowiki>
==Cheats==
To list the available cheats in the rom:
<nowiki>
mupen64plus --cheats list "/path/to/my/rom.v64"</nowiki>
If there are cheats in the rom, you will get (in the output console):
<nowiki>
UI-Console: 3 cheat code(s) found for ROM 'MY ROM'
0: [Enable All Levels] (This is needed to be able to Play all Levels of the Game)
1: [Enable All Weapons] (This is needed to be able to Play with all Weapons of the Game)
2: etc...</nowiki>
All you have to do to use these cheats is:
<nowiki>
mupen64plus --cheats 0,1,2 "/path/to/my/rom.v64"</nowiki>

==Debugger==
===Setup===

You must use a mupen64plus core library which was built with the DEBUGGER flag set.

===Running===

Use the --debug command-line option to enable the console debugger.

The emulator mode should be set to "interpreter", as the dynarec seems to cause
issues when interacting with the debugging API. This can be done with the R4300Emulator
config setting or with the --emumode flag.

===Usage===

Once the emulator boots, it will be paused by default. You will be presented
with a prompt as follows:

<nowiki>(dbg) </nowiki>

The following commands can be entered:

<nowiki>
run
Unpauses the game.

pause
Pauses the game.

step <num-steps>
When paused, instructs the emulator to make a single step, or a series of
steps if num-steps is provided.

regs
Prints out general purpose register values.

pc
Print current value of Program Counter register

pc-1
Print previous value of Program Counter register

asm
Print assembly language instructions. Several forms are supported:

asm Print one instruction at the Program Counter register

asm <addr> Print one instruction at <addr>

asm <addr> <n> Print <n> instructions starting at <addr>

asm <addr> <n> <flags> Print <n> instructions starting at <addr> with flags
- If flags bit-3 is set (i.e. & 0x04): also print binary instruction data
- If flags bit-2 is set: prefix each instruction with its memory address
- If flags bit-1 is set: prefix each instruction with a counter from <addr>

mem
Print memory values. Several forms are supported:

mem <addr> Print one 32-bit word at <addr>

mem /N <addr> Print <N> 32-bit words at <addr>
mem /Nb <addr> Print <N> 8-bit bytes at <addr>
mem /Nh <addr> Print <N> 16-bit half-words at <addr>
mem /Nw <addr> Print <N> 32-bit words at <addr>
mem /Nd <addr> Print <N> 64-bit double-words at <addr>

mem /NxM <addr> Print <N> rows of <M> 32-bit words at <addr>
mem /NxMb <addr> Print <N> rows of <M> 8-bit bytes at <addr>
mem /NxMh <addr> Print <N> rows of <M> 16-bit half-words at <addr>
mem /NxMw <addr> Print <N> rows of <M> 32-bit words at <addr>
mem /NxMd <addr> Print <N> rows of <M> 64-bit double-words at <addr>

write
Write values to memory. Several forms are supported:

write <addr> <value> Write a (1) byte value to <addr>

write <addr> b <value> Write a (1) byte value to <addr>
write <addr> h <value> Write a half-word value (2 bytes) to <addr>
write <addr> w <value> Write a word value (4 bytes) to <addr>
write <addr> d <value> Write a double-word value (8 bytes) to <addr>

translate
Translates virtual memory addresses to physical memory addresses. Memory
read/write breakpoints must operate on physical addresses, in contrast to the
memory read/write commands and execution breakpoints that operate on virtual
addresses.

translate <virtual address> Print the 32-bit physical address for the
provided <virtual address> argument.

bp add
Adds a breakpoint at a given address. Several forms are supported:

bp add pc Add a breakpoint at the Program Counter, triggered
on EXEC, READ, and WRITE.

bp add <addr> Add a breakpoint at <addr>, triggered on EXEC,
READ, and WRITE.

bp add <addr> <n> Add a breakpoint starting at <addr>, extending <n>
bytes, triggered on EXEC, READ, and WRITE.

bp add <addr> <n> <flags> Add a breakpoint starting at <addr>, extending <n>
bytes, with specified trigger flags.
- M64P_BKP_FLAG_READ = 0x02
- M64P_BKP_FLAG_WRITE = 0x04
- M64P_BKP_FLAG_EXEC = 0x08

bp trig
Prints the reason for the most recently activated breakpoint trigger. Memory
read/write breakpoints will indicate the hit address.

bp rm <addr|index>
Removes a breakpoint by address or number.

bp list
Lists all breakpoints.

exit|quit
Stop emulator and quit debugger
</nowiki>
==64DD Support==

Some compatibility with the 64DD disk drive unit has been implemented, but there
are a few small usability issues of which users should be aware.

When using the 64DD, you need to pass a path to a cartridge rom, even if none is
strictly required. The IPL boot rom will execute first and select the disk if
you have one inserted, or just show the boot menu otherwise. We can remove this
requirement at a later time. For now all we need to remember is to use a Japanese
ROM (otherwise some region check will fail) with same features as the 64DD game
you want to play (think RumblePak, TransferPak, otherwise, they won't be available).

There is a sibling issue also with 64DD games in that there are no entries in the
game db (mupen64plus.ini) for them, and the core currently only relies on the cart
ROM loaded to fetch the ROM infos.

UIConsoleUsage

2019-03-23T16:24:37Z

Richard42: /* Console Options */

==Console Options==

At startup, the mupen64plus program will look for a user configuration file called 'mupen64plus.cfg' (see [[FileLocations]] for more informations).

If this file does not exist, it will be created and default settings will be written. If desired, an alternate config directory can be specified using the --configdir commandline option.

Run 'mupen64plus --help' for a complete list of commandline options:
<nowiki>
$ mupen64plus --help
Usage: mupen64plus [parameter(s)] rom

Parameters:
--noosd : disable onscreen display
--osd : enable onscreen display
--fullscreen : use fullscreen display mode
--windowed : use windowed display mode
--resolution (res) : display resolution (640x480, 800x600, 1024x768, etc)
--nospeedlimit : disable core speed limiter (should be used with dummy audio plugin)
--cheats (cheat-spec) : enable or list cheat codes for the given rom file
--corelib (filepath) : use core library (filepath) (can be only filename or full path)
--configdir (dir) : force configation directory to (dir); should contain mupen64plus.cfg
--datadir (dir) : search for shared data files (.ini files, languages, etc) in (dir)
--debug : launch console-based debugger (requires core lib built for debugging)
--plugindir (dir) : search for plugins in (dir)
--sshotdir (dir) : set screenshot directory to (dir)
--gfx (plugin-spec) : use gfx plugin given by (plugin-spec)
--audio (plugin-spec) : use audio plugin given by (plugin-spec)
--input (plugin-spec) : use input plugin given by (plugin-spec)
--rsp (plugin-spec) : use rsp plugin given by (plugin-spec)
--emumode (mode) : set emu mode to: 0=Pure Interpreter 1=Interpreter 2=DynaRec
--testshots (list) : take screenshots at frames given in comma-separated (list), then quit
--set (param-spec) : set a configuration variable, format: ParamSection[ParamName]=Value
--gb-rom-{1,2,3,4} : define GB cart rom to load inside transferpak {1,2,3,4}"
--gb-ram-{1,2,3,4} : define GB cart ram to load inside transferpak {1,2,3,4}"
--core-compare-send : use the Core Comparison debugging feature, in data sending mode
--core-compare-recv : use the Core Comparison debugging feature, in data receiving mode
--nosaveoptions : do not save the given command-line options in configuration file
--verbose : print lots of information
--help : see this help message

(plugin-spec):
(pluginname) : filename (without path) of plugin to find in plugin directory
(pluginpath) : full path and filename of plugin
'dummy' : use dummy plugin

(cheat-spec):
'list' : show all of the available cheat codes
'all' : enable all of the available cheat codes
(codelist) : a comma-separated list of cheat code numbers to enable,
with dashes to use code variables (ex 1-2 to use cheat 1 option 2)
</nowiki>
==Cheats==
To list the available cheats in the rom:
<nowiki>
mupen64plus --cheats list "/path/to/my/rom.v64"</nowiki>
If there are cheats in the rom, you will get (in the output console):
<nowiki>
UI-Console: 3 cheat code(s) found for ROM 'MY ROM'
0: [Enable All Levels] (This is needed to be able to Play all Levels of the Game)
1: [Enable All Weapons] (This is needed to be able to Play with all Weapons of the Game)
2: etc...</nowiki>
All you have to do to use this cheats is:
<nowiki>
mupen64plus --cheats 0,1,2 "/path/to/my/rom.v64"</nowiki>

==Debugger==
===Setup===

You must use a mupen64plus core library which was built with the DEBUGGER flag set.

===Running===

Use the --debug command-line option to enable the console debugger.

The emulator mode should be set to "interpreter", as the dynarec seems to cause
issues when interacting with the debugging API. This can be done with the R4300Emulator
config setting or with the --emumode flag.

===Usage===

Once the emulator boots, it will be paused by default. You will be presented
with a prompt as follows:

<nowiki>(dbg) </nowiki>

The following commands can be entered:

<nowiki>
run
Unpauses the game.

pause
Pauses the game.

step <num-steps>
When paused, instructs the emulator to make a single step, or a series of
steps if num-steps is provided.

regs
Prints out general purpose register values.

pc
Print current value of Program Counter register

pc-1
Print previous value of Program Counter register

asm
Print assembly language instructions. Several forms are supported:

asm Print one instruction at the Program Counter register

asm <addr> Print one instruction at <addr>

asm <addr> <n> Print <n> instructions starting at <addr>

asm <addr> <n> <flags> Print <n> instructions starting at <addr> with flags
- If flags bit-3 is set (i.e. & 0x04): also print binary instruction data
- If flags bit-2 is set: prefix each instruction with its memory address
- If flags bit-1 is set: prefix each instruction with a counter from <addr>

mem
Print memory values. Several forms are supported:

mem <addr> Print one 32-bit word at <addr>

mem /N <addr> Print <N> 32-bit words at <addr>
mem /Nb <addr> Print <N> 8-bit bytes at <addr>
mem /Nh <addr> Print <N> 16-bit half-words at <addr>
mem /Nw <addr> Print <N> 32-bit words at <addr>
mem /Nd <addr> Print <N> 64-bit double-words at <addr>

mem /NxM <addr> Print <N> rows of <M> 32-bit words at <addr>
mem /NxMb <addr> Print <N> rows of <M> 8-bit bytes at <addr>
mem /NxMh <addr> Print <N> rows of <M> 16-bit half-words at <addr>
mem /NxMw <addr> Print <N> rows of <M> 32-bit words at <addr>
mem /NxMd <addr> Print <N> rows of <M> 64-bit double-words at <addr>

write
Write values to memory. Several forms are supported:

write <addr> <value> Write a (1) byte value to <addr>

write <addr> b <value> Write a (1) byte value to <addr>
write <addr> h <value> Write a half-word value (2 bytes) to <addr>
write <addr> w <value> Write a word value (4 bytes) to <addr>
write <addr> d <value> Write a double-word value (8 bytes) to <addr>

translate
Translates virtual memory addresses to physical memory addresses. Memory
read/write breakpoints must operate on physical addresses, in contrast to the
memory read/write commands and execution breakpoints that operate on virtual
addresses.

translate <virtual address> Print the 32-bit physical address for the
provided <virtual address> argument.

bp add
Adds a breakpoint at a given address. Several forms are supported:

bp add pc Add a breakpoint at the Program Counter, triggered
on EXEC, READ, and WRITE.

bp add <addr> Add a breakpoint at <addr>, triggered on EXEC,
READ, and WRITE.

bp add <addr> <n> Add a breakpoint starting at <addr>, extending <n>
bytes, triggered on EXEC, READ, and WRITE.

bp add <addr> <n> <flags> Add a breakpoint starting at <addr>, extending <n>
bytes, with specified trigger flags.
- M64P_BKP_FLAG_READ = 0x02
- M64P_BKP_FLAG_WRITE = 0x04
- M64P_BKP_FLAG_EXEC = 0x08

bp trig
Prints the reason for the most recently activated breakpoint trigger. Memory
read/write breakpoints will indicate the hit address.

bp rm <addr|index>
Removes a breakpoint by address or number.

bp list
Lists all breakpoints.

exit|quit
Stop emulator and quit debugger
</nowiki>
==64DD Support==

Some compatibility with the 64DD disk drive unit has been implemented, but there
are a few small usability issues of which users should be aware.

When using the 64DD, you need to pass a path to a cartridge rom, even if none is
strictly required. The IPL boot rom will execute first and select the disk if
you have one inserted, or just show the boot menu otherwise. We can remove this
requirement at a later time. For now all we need to remember is to use a Japanese
ROM (otherwise some region check will fail) with same features as the 64DD game
you want to play (think RumblePak, TransferPak, otherwise, they won't be available).

There is a sibling issue also with 64DD games in that there are no entries in the
game db (mupen64plus.ini) for them, and the core currently only relies on the cart
ROM loaded to fetch the ROM infos.

UIConsoleUsage

2019-02-10T19:06:13Z

Richard42:

==Console Options==

At startup, the mupen64plus program will look for a user configuration file called 'mupen64plus.cfg' (see [[FileLocations]] for more informations).

If this file does not exist, it will be created and default settings will be written. If desired, an alternate config directory can be specified using the --configdir commandline option.

Run 'mupen64plus --help' for a complete list of commandline options:
<nowiki>
$ mupen64plus --help
Usage: mupen64plus [parameter(s)] rom

Parameters:
--noosd : disable onscreen display
--osd : enable onscreen display
--fullscreen : use fullscreen display mode
--windowed : use windowed display mode
--resolution (res) : display resolution (640x480, 800x600, 1024x768, etc)
--nospeedlimit : disable core speed limiter (should be used with dummy audio plugin)
--cheats (cheat-spec) : enable or list cheat codes for the given rom file
--corelib (filepath) : use core library (filepath) (can be only filename or full path)
--configdir (dir) : force configation directory to (dir); should contain mupen64plus.cfg
--datadir (dir) : search for shared data files (.ini files, languages, etc) in (dir)
--debug : launch console-based debugger (requires core lib built for debugging)
--plugindir (dir) : search for plugins in (dir)
--sshotdir (dir) : set screenshot directory to (dir)
--gfx (plugin-spec) : use gfx plugin given by (plugin-spec)
--audio (plugin-spec) : use audio plugin given by (plugin-spec)
--input (plugin-spec) : use input plugin given by (plugin-spec)
--rsp (plugin-spec) : use rsp plugin given by (plugin-spec)
--emumode (mode) : set emu mode to: 0=Pure Interpreter 1=Interpreter 2=DynaRec
--testshots (list) : take screenshots at frames given in comma-separated (list), then quit
--set (param-spec) : set a configuration variable, format: ParamSection[ParamName]=Value
--gb-rom-{1,2,3,4} : define GB cart rom to load inside transferpak {1,2,3,4}"
--gb-ram-{1,2,3,4} : define GB cart ram to load inside transferpak {1,2,3,4}"
--core-compare-send : use the Core Comparison debugging feature, in data sending mode
--core-compare-recv : use the Core Comparison debugging feature, in data receiving mode
--nosaveoptions : do not save the given command-line options in configuration file
--verbose : print lots of information
--help : see this help message

(plugin-spec):
(pluginname) : filename (without path) of plugin to find in plugin directory
(pluginpath) : full path and filename of plugin
'dummy' : use dummy plugin

(cheat-spec):
'list' : show all of the available cheat codes
'all' : enable all of the available cheat codes
(codelist) : a comma-separated list of cheat code numbers to enable,
with dashes to use code variables (ex 1-2 to use cheat 1 option 2)

==Cheats==
To list the available cheats in the rom:
<nowiki>
mupen64plus --cheats list "/path/to/my/rom.v64"</nowiki>
If there are cheats in the rom, you will get (in the output console):
<nowiki>
UI-Console: 3 cheat code(s) found for ROM 'MY ROM'
0: [Enable All Levels] (This is needed to be able to Play all Levels of the Game)
1: [Enable All Weapons] (This is needed to be able to Play with all Weapons of the Game)
2: etc...</nowiki>
All you have to do to use this cheats is:
<nowiki>
mupen64plus --cheats 0,1,2 "/path/to/my/rom.v64"</nowiki>

==Debugger==
===Setup===

You must use a mupen64plus core library which was built with the DEBUGGER flag set.

===Running===

Use the --debug command-line option to enable the console debugger.

The emulator mode should be set to "interpreter", as the dynarec seems to cause
issues when interacting with the debugging API. This can be done with the R4300Emulator
config setting or with the --emumode flag.

===Usage===

Once the emulator boots, it will be paused by default. You will be presented
with a prompt as follows:

<nowiki>(dbg) </nowiki>

The following commands can be entered:

<nowiki>
run
Unpauses the game.

pause
Pauses the game.

step <num-steps>
When paused, instructs the emulator to make a single step, or a series of
steps if num-steps is provided.

regs
Prints out general purpose register values.

pc
Print current value of Program Counter register

pc-1
Print previous value of Program Counter register

asm
Print assembly language instructions. Several forms are supported:

asm Print one instruction at the Program Counter register

asm <addr> Print one instruction at <addr>

asm <addr> <n> Print <n> instructions starting at <addr>

asm <addr> <n> <flags> Print <n> instructions starting at <addr> with flags
- If flags bit-3 is set (i.e. & 0x04): also print binary instruction data
- If flags bit-2 is set: prefix each instruction with its memory address
- If flags bit-1 is set: prefix each instruction with a counter from <addr>

mem
Print memory values. Several forms are supported:

mem <addr> Print one 32-bit word at <addr>

mem /N <addr> Print <N> 32-bit words at <addr>
mem /Nb <addr> Print <N> 8-bit bytes at <addr>
mem /Nh <addr> Print <N> 16-bit half-words at <addr>
mem /Nw <addr> Print <N> 32-bit words at <addr>
mem /Nd <addr> Print <N> 64-bit double-words at <addr>

mem /NxM <addr> Print <N> rows of <M> 32-bit words at <addr>
mem /NxMb <addr> Print <N> rows of <M> 8-bit bytes at <addr>
mem /NxMh <addr> Print <N> rows of <M> 16-bit half-words at <addr>
mem /NxMw <addr> Print <N> rows of <M> 32-bit words at <addr>
mem /NxMd <addr> Print <N> rows of <M> 64-bit double-words at <addr>

write
Write values to memory. Several forms are supported:

write <addr> <value> Write a (1) byte value to <addr>

write <addr> b <value> Write a (1) byte value to <addr>
write <addr> h <value> Write a half-word value (2 bytes) to <addr>
write <addr> w <value> Write a word value (4 bytes) to <addr>
write <addr> d <value> Write a double-word value (8 bytes) to <addr>

translate
Translates virtual memory addresses to physical memory addresses. Memory
read/write breakpoints must operate on physical addresses, in contrast to the
memory read/write commands and execution breakpoints that operate on virtual
addresses.

translate <virtual address> Print the 32-bit physical address for the
provided <virtual address> argument.

bp add
Adds a breakpoint at a given address. Several forms are supported:

bp add pc Add a breakpoint at the Program Counter, triggered
on EXEC, READ, and WRITE.

bp add <addr> Add a breakpoint at <addr>, triggered on EXEC,
READ, and WRITE.

bp add <addr> <n> Add a breakpoint starting at <addr>, extending <n>
bytes, triggered on EXEC, READ, and WRITE.

bp add <addr> <n> <flags> Add a breakpoint starting at <addr>, extending <n>
bytes, with specified trigger flags.
- M64P_BKP_FLAG_READ = 0x02
- M64P_BKP_FLAG_WRITE = 0x04
- M64P_BKP_FLAG_EXEC = 0x08

bp trig
Prints the reason for the most recently activated breakpoint trigger. Memory
read/write breakpoints will indicate the hit address.

bp rm <addr|index>
Removes a breakpoint by address or number.

bp list
Lists all breakpoints.

exit|quit
Stop emulator and quit debugger
</nowiki>
==64DD Support==

Some compatibility with the 64DD disk drive unit has been implemented, but there
are a few small usability issues of which users should be aware.

When using the 64DD, you need to pass a path to a cartridge rom, even if none is
strictly required. The IPL boot rom will execute first and select the disk if
you have one inserted, or just show the boot menu otherwise. We can remove this
requirement at a later time. For now all we need to remember is to use a Japanese
ROM (otherwise some region check will fail) with same features as the 64DD game
you want to play (think RumblePak, TransferPak, otherwise, they won't be available).

There is a sibling issue also with 64DD games in that there are no entries in the
game db (mupen64plus.ini) for them, and the core currently only relies on the cart
ROM loaded to fetch the ROM infos.

Mupen64Plus v2.0 API Versioning

2018-11-04T03:34:11Z

Richard42:

[[Mupen64Plus v2.0 Core API v1.0|Mupen64Plus v2.0 API]]

= Mupen64Plus v2.0 API Versioning =

== Goal ==

The Mupen64Plus API versioning scheme was invented to give a more friendly and less confusing experience for users as the various components evolve over time. There are 6 basic components to the Mupen64Plus system, which may be independently built and installed:

# The Front-end UI application
# The Core emulator library
# The Video plugin
# The Audio plugin
# The Input plugin
# The RSP plugin

These components interact with each other in several different ways. The design goal of the versioning scheme is to gracefully handle all situations in which two components support different versions of their common API (due to one component being newer than the other). In particular, each pair of components sharing a common API must discover whether or not they are compatible with each other. They must make this determination early enough in the startup process to inform the user of an incompatibility and gracefully exit the software if necessary without crashing. There are 2 different decisions that pertain to the compatibility determination:

# Major API version. The various API version numbers are 32-bit. The major version number is stored in the upper 16 bits, and the minor version number is in the lower 16 bits. If two components have different major API version numbers, then they are definitely incompatible.
# Minor API version. If two components with a common API have different minor version numbers, then the newer component may decide whether or not it can interact with the older component based upon the older component's version number. The newer component may optionally disable new features and still retain backwards compatibility, or it may refuse to operate with the older component. This decision is left to the component author when new features are added.

== Basic Design ==

In mupen64plus-core/src/plugin/plugin.h, the following macros are defined:

#define RSP_API_MAJOR_VERSION 0x20000
#define GFX_API_MAJOR_VERSION 0x20000
#define AUDIO_API_MAJOR_VERSION 0x20000
#define INPUT_API_MAJOR_VERSION 0x20000

In mupen64plus-core/src/main/version.h, the following macros are defined:

#define FRONTEND_API_VERSION 0x020000
#define CONFIG_API_VERSION 0x020000
#define DEBUG_API_VERSION 0x020000
#define VIDEXT_API_VERSION 0x020000

# When the front-end application calls the CoreStartup() function, it passes it's Core<-->Front-end API version to the core. If the API major version numbers for the core and front-end don't match, the core will return from this function with a failure code of M64ERR_INCOMPATIBLE.
# The Console-UI front-end also checks for API compatibility, during the AttachCoreLib() function call. It is not strictly necessary for a front-end application to verify the API compatibility with the core, since the core will also check during CoreStartup(). However, by doing so, an updated front-end may detect a core library using a newer (but backwards-compatible) API, and enable some extra features as a result of the expanded API.
# At the time each plugin is attached to the core (during CoreAttachPlugin function call), the core checks the version number of the plugin API by calling the PluginGetVersion function. If the major version number of the plugin's reported API (APIVersion & 0xffff0000) does not match the corresponding version number for that plugin type in the core (defined in plugin.h), then the plugin is incompatible and cannot be attached to the core. Currently the plugins have no way to request the major version number required for a particular plugin type in the core library.
# The emulator core exports several different API groups which may be used by the front-end and plugin modules. Currently, these groups are: Front-end, Config, Debug, and Video Extension. A front-end application or any plugin may call the CoreGetAPIVersions() function to retrieve the API version numbers for these groups. Any plugin or front-end which can use any updated (not present in the original "2.0" API) functions in one of these groups should call the core's CoreGetAPIVersions() function (during PluginStartup for a plugin or at core attach time for a front-end) to check the version # of the API supported by the core, and react accordingly.
# All front-ends and plugins should verify API version compatibility for the Config API.

== Handling Future Changes ==

=== New feature added to a plugin library ===
If the feature is backwards-compatible with older cores, then plugin API minor version will be bumped. Otherwise, major version number will be bumped. If change is backwards-compatible, then newest core can test the plugin's API version and only enable the feature if present.

=== New feature added to Core<-->Front-end API ===
Typically this will happen when a new function or a new feature of an existing function is added to the core. If the older front-ends will still be compatible with newer cores, then the minor version number of the front-end API will be bumped. Otherwise the major version number will be bumped. A newer front-end can check the version of the API supported by the core and choose whether to retain backwards-compatibility with older cores or refuse to interoperate.

=== New feature added to Core Config API ===
If older plugins can still use the Core Config API with the new feature, then Config API minor version will be bumped. Otherwise, major version number will be bumped. Newer plugins should check the Core's Config API version and maintain backwards compatibility with older cores if possible.

=== New feature added to Core Debug API ===
If older front-ends can still use the Core Debug API with the new feature, then Debug API minor version number will be bumped. Otherwise, major version number will be bumped. Newer front-end applications should check the Core's Debug API version and maintain backwards compatibility with older cores if possible.

=== New feature added to Video Extension API ===
This is the most complicated interface, because it involves 3 components: the video plugin, the core, and the front-end application. If older video plugins can still use the newer Video Extension API with the core, *and* newer front-end applications can work with older cores, then the Video Extension API minor version number will be bumped. Otherwise, the major version number will be bumped. Newer video plugins can check the Core's Video Extension API version and maintain backwards compatibility with older cores if possible, otherwise they can refuse and give a compatibility error. Front-end applications (such as the default console-ui) which do not hook into the Video Extension do not need to check the Core's Video Extension API version. However, front-end applications which do hook into the Video Extension must check the API version. If the Core and Front-end have different API major version numbers, then they are incompatible. Also if the Core has a *newer* minor version than the front-end, then they are incompatible. This is a unique restriction, and it must be checked and verified by the front-end; the Core has no way to check this.

== Changelog ==
* Version 2.0.0 is the base for all APIs
* '''FRONTEND_API_VERSION''' version 2.0.1:
** added "m64p_command" type "M64CMD_CORE_STATE_SET", handled by CoreDoCommand()
** added "m64p_core_param" type "M64CORE_SPEED_LIMITER", handled by "M64CMD_CORE_STATE_QUERY" and "M64CMD_CORE_STATE_SET" commands
* '''FRONTEND_API_VERSION''' version 2.0.2:
** added "m64p_command" types:
*** M64CMD_GET_SCREEN_WIDTH
*** M64CMD_GET_SCREEN_HEIGHT
*** M64CMD_READ_SCREEN
*** M64CMD_VOLUME_UP
*** M64CMD_VOLUME_DOWN
*** M64CMD_VOLUME_GET_LEVEL
*** M64CMD_VOLUME_SET_LEVEL
*** M64CMD_VOLUME_MUTE
*** M64CMD_RESET
*** M64CMD_ADVANCE_FRAME
** extend command M64CMD_STATE_SAVE to support saving uncompressed PJ64 savestate files as well as zip compressed
* '''FRONTEND_API_VERSION''' version 2.1.0:
** removed "m64p_command" types:
*** M64CMD_GET_SCREEN_WIDTH
*** M64CMD_GET_SCREEN_HEIGHT
*** M64CMD_VOLUME_UP
*** M64CMD_VOLUME_DOWN
*** M64CMD_VOLUME_GET_LEVEL
*** M64CMD_VOLUME_SET_LEVEL
*** M64CMD_VOLUME_MUTE
** added new "m64p_core_param" types:
*** M64CORE_VIDEO_SIZE
*** M64CORE_AUDIO_VOLUME
*** M64CORE_AUDIO_MUTE
*** M64CORE_INPUT_GAMESHARK
*** M64CORE_STATE_LOADCOMPLETE
*** M64CORE_STATE_SAVECOMPLETE
* '''FRONTEND_API_VERSION''' version 2.1.1:
** Core command M64CMD_CORE_STATE_SET will now accept M64CORE_VIDEO_SIZE parameter
*** will call the video plugin function ResizeVideoOutput()
* '''FRONTEND_API_VERSION''' version 2.1.2:
** added "M64CMD_SET_MEDIA_LOADER" command to allow frontend to specify several media files (such as GB cartridge ROM and RAM files).
* '''CONFIG_API_VERSION''' version 2.1.0:
** add new function "ConfigSaveSection()" to save only a single config section to disk
* '''CONFIG_API_VERSION''' version 2.2.0:
** add new function "ConfigHasUnsavedChanges()" to determine if a given Section (or all sections) of the Mupen64Plus Core configuration file has been modified since it was last saved or loaded.
** add new function "ConfigRevertChanges()" to revert changes previously made to one section of the configuration file, so that it will match with the configuration at the last time that it was loaded from or saved to disk.
* '''CONFIG_API_VERSION''' version 2.3.0:
** add new function "ConfigSetParameterHelp()" sets the value of one of the emulator's configuration parameters.
* '''CONFIG_API_VERSION''' version 2.3.1:
** add new functions "ConfigExternalOpen()" "ConfigExternalClose()" "ConfigExternalGetParameter()" that allows plugins to leverage the core INI parser to read config files.
* '''DEBUG_API_VERSION''' version 2.0.1:
** add new function "DebugBreakpointTriggeredBy()" which allows a front-end application to determine which memory address and action (read, write, execute) caused a breakpoint to fire.
** add new function "DebugVirtualToPhysical()" which allows a front-end application to find the physical address which corresponds to a given virtual address.
* '''VIDEO_API_VERSION''' version 2.1.0:
** video render callback function now takes a boolean (int) parameter, which specifies whether the video frame has been re-drawn since the last time the render callback was called. This allows us to take screenshots without the On-Screen-Display text
* '''VIDEO_API_VERSION''' version 2.2.0:
** add (optional) ResizeVideoOutput function in video plugin. If this function is not present in video plugin, then resizing the output video window will not work.
* '''VIDEXT_API_VERSION''' version 3.0.0:
** add VidExt_ResizeWindow() function in video extension. This function is called by the video plugin to notify the window manager (SDL if no video extension is registered by the front-end) that the OpenGL render window size should change.
** add m64p_video_flags parameter to the VidExt_SetVideoMode() function. Currently the flags are only used to notify the window manager that resizing is supported by the video plugin, and it should create a resizable window if possible. This may be extended in the future to support other features.
* '''VIDEXT_API_VERSION''' version 3.1.0:
** add VidExt_GL_GetDefaultFramebuffer() function in video extension. This function should be called to get the name of the default FBO.
* '''INPUT_API_VERSION''' version 2.0.1:
** add (optional) RenderCallback function to input plugin. This function is called by the core after rendering on screen text (OSD) and before the graphics plugin swaps the buffers. The purpose of this function is to enable the input plugin to draw on screen content, for example buttons in a touch input plugin. If this function is not present the core will ignore it and on screen rendering by the input plugin will be disabled.

FileLocations

2018-01-25T06:19:29Z

Richard42: /* Where the heck are the files? */

== Where the heck are the files? ==

Due to the flexibility of Mupen64Plus and its cross-platform design, they could be just about anywhere! The quick-reference tables below gives the most likely locations for some common files. The remainder this wiki page gives the full details of where they could be.

==== OSX/MacOS (Mupen64Plus 2.5.1 and earlier) ====
==== Linux ====
{| class="wikitable"
|-
|'''File Type''' || '''Path'''
|-
|Config file || <code>~/.config/mupen64plus/</code>
|-
|Screenshots || <code>~/.local/share/mupen64plus/screenshot/</code>
|-
|Save states || <code>~/.local/share/mupen64plus/save/</code>
|}

==== OSX/MacOS (Mupen64Plus 2.6 and later) ====
{| class="wikitable"
|-
|'''File Type''' || '''Path'''
|-
|Config file || <code>~/Library/Application Support/Mupen64plus/</code>
|-
|Screenshots || <code>~/Library/Application Support/Mupen64plus/screenshot/</code>
|-
|Save states || <code>~/Library/Application Support/Mupen64plus/save/</code>
|}

==== Windows XP and Earlier ====
{| class="wikitable"
|-
|'''File Type''' || '''Path'''
|-
|Config file || <code>C:\Documents and Settings\your_user_name\Application Data\Mupen64Plus\</code>
|-
|Screenshots || <code>C:\Documents and Settings\your_user_name\Application Data\Mupen64Plus\screenshot\</code>
|-
|Save states || <code>C:\Documents and Settings\your_user_name\Application Data\Mupen64Plus\save\</code>
|}

==== Windows Vista and Newer ====

{| class="wikitable"
|-
|'''File Type''' || '''Path'''
|-
|Config file || <code>C:\Users\your_user_name\AppData\Roaming\Mupen64Plus\</code>
|-
|Screenshots || <code>C:\Users\your_user_name\AppData\Roaming\Mupen64Plus\screenshot\</code>
|-
|Save states || <code>C:\Users\your_user_name\AppData\Roaming\Mupen64Plus\save\</code>
|}

=== Front-End Specific Files ===

The front-end User Interface is responsible for finding the core libraries and plugins for startup. Each front-end may have its own method for finding these libraries. The Mupen64Plus-UI-Console front-end looks for these libraries in the following places, in order:

==== Core Library ====
# Path given by <code>--corelib</code> option
# Path given at compile time with <code>COREDIR</code> macro
# (MacOS-only, Mupen64Plus 2.6 and newer) Frameworks path within the app bundle
# No path at all (allows the Operating System to search for the shared library)
# Current directory

==== Plugin Libraries====
The Mupen64Plus-UI-Console front-end looks through several directories in search of valid Mupen64Plus plugins. When it finds a directory containing plugins, it populates a list with all of the plugins found. Then, when loading plugins it only uses plugins from this list (found in one directory), unless the user specifies full plugin paths on the command line with the <code>--gfx</code>, <code>--audio</code>, <code>--rsp</code>, or <code>--input</code> options. The order in which directories are searched is:

# Path given by <code>--plugindir</code> option
# Path given by '''PluginDir''' parameter in Mupen64Plus config file
# (MacOS-only, Mupen64Plus 2.6 and newer) Frameworks folder within the app bundle
# (Unix-only) Path given at compile-time with <code>PLUGINDIR</code> macro
# (Unix-only) <code>/usr/local/lib/mupen64plus</code>
# (Unix-only) <code>/usr/lib/mupen64plus</code>
# Current Directory

=== Core-specific Files ===

These are files which are read and written by the core emulator.

==== Screenshots ====
# Path given by <code>--sshotdir</code> option (if using Mupen64Plus-UI-Console)
# Path given by '''ScreenshotPath''' parameter in Mupen64Plus config file
# ''User_Data''/screenshot/ (see OS-specific sections below)

==== Save states ====
# ''User_Data''/save/ (see OS-specific sections below)

=== Unix-specific Search Paths ===

The ''Shared_Data'' search paths work in the following way: each time a shared data file needs is requested (such as an .ini file, or font file), the emulator core looks through all of the ''Shared_Data'' paths in order to find the file.

''Shared_Data'':
# Path given by <code>--datadir</code> option (if using Mupen64Plus-UI-Console)
# Path given by '''SharedDataPath''' parameter in Mupen64Plus config file
# (MacOS-only, Mupen64Plus 2.6 and newer) Resources folder within the app bundle
# Path given at compile-time with <code>SHAREDIR</code> macro
# (Linux-only) <code>/usr/local/share/mupen64plus</code>
# (Linux-only) <code>/usr/share/mupen64plus</code>
# <code>./</code>

On MacOS (with Mupen64Plus 2.6 and newer), the User Data and User Config directories are set to <code>~/Library/Application Support/Mupen64Plus/</code>.

Under Linux, the ''User_Data'' and ''User_Config'' search paths work in the following way: at startup time, the emulator core looks through the list of directories to find one that exists. The first one found is used to read/write all ''User_Data'' or ''User_Config'' files, or if none exists, then the last one in the list is created.

''User_Data'':
# <code>$XDG_DATA_HOME/mupen64plus/</code>
# <code>$HOME/.local/share/mupen64plus/</code>

''User_Config'':
# Path given by <code>--configdir</code> option (if using Mupen64Plus-UI-Console)
# <code>$XDG_CONFIG_HOME/mupen64plus/</code>
# <code>$HOME/.config/mupen64plus/</code>

=== Windows-specific Search Paths ===

The ''Shared_Data'' search paths work in the following way: each time a shared data file needs is requested (such as an .ini file, or font file), the emulator core looks through all of the ''Shared_Data'' paths in order to find the file.

On Windows versions prior to Vista, the <code>$CSIDL_APPDATA</code> path is usually: <code>C:\Documents and Settings\your_user_name\Application Data</code>. On later versions of Windows, this path is usually: <code>C:\Users\your_user_name\AppData\Roaming</code>.

''Shared_Data'':
# Path given by <code>--datadir</code> option (if using Mupen64Plus-UI-Console)
# Path given by '''SharedDataPath''' parameter in Mupen64Plus config file
# <code>$CSIDL_APPDATA\Mupen64Plus\</code>

On Windows, the ''User_Data'' and ''User_Config'' directories are the same. These search paths work in the following way: at startup time, the emulator core looks through the list of directories to find one that exists. The first one found is used to read/write all ''User_Data'' or ''User_Config'' files, or if none exists, then the last one in the list is created.

''User_Data'': 
''User_Config'':
# Path given by <code>--configdir</code> option (if using Mupen64Plus-UI-Console)
# <code>$CSIDL_APPDATA\Mupen64Plus\</code>

Mupen64Plus Core Parameters

2015-10-04T22:55:55Z

Richard42:

[[Mupen64Plus v2.0 Core API v1.0|Mupen64Plus v2.0 API]]

= Core Parameters =

These are standard parameters which are used by the Mupen64Plus Core library. They are stored in a configuration section called "Core" and may be altered by the front-end in order to adjust the behaviour of the emulator. These may be adjusted at any time and the effect of the change should occur immediately.

{| border="1"
!Parameter Name!!Type!!Usage
|-
|Version
|M64TYPE_FLOAT
|Mupen64Plus Core config parameter set version number. Please don't change.
|-
|OnScreenDisplay
|M64TYPE_BOOL
|Draw on-screen display if True, otherwise don't draw OSD
|-
|R4300Emulator
|M64TYPE_INT
|Use Pure Interpreter if 0, Cached Interpreter if 1, or Dynamic Recompiler if 2 or more
|-
|NoCompiledJump
|M64TYPE_BOOL
|Disable compiled jump commands in dynamic recompiler (should be set to False)
|-
|DisableExtraMem
|M64TYPE_BOOL
|Disable 4MB expansion RAM pack. May be necessary for some games.
|-
|AutoStateSlotIncrement
|M64TYPE_BOOL
|Increment the save state slot after each save operation.
|-
|EnableDebugger
|M64TYPE_BOOL
|Activate the R4300 debugger when ROM execution begins, if core was built with Debugger support.
|-
|CurrentStateSlot
|M64TYPE_INT
|Save state slot (0-9) to use when saving/loading the emulator state
|-
|ScreenshotPath
|M64TYPE_STRING
|Path to directory where screenshots are saved. If this is blank, the default value of "<tt>GetConfigUserDataPath()</tt>"/screenshot will be used.
|-
|SaveStatePath
|M64TYPE_STRING
|Path to directory where emulator save states (snapshots) are saved. If this is blank, the default value of "<tt>GetConfigUserDataPath()</tt>"/save will be used.
|-
|SaveSRAMPath
|M64TYPE_STRING
|Path to directory where SRAM/EEPROM data (in-game saves) are stored. If this is blank, the default value of "<tt>GetConfigUserDataPath()</tt>"/save will be used.
|-
|SharedDataPath
|M64TYPE_STRING
|Path to a directory to search when looking for shared data files in the <tt>ConfigGetSharedDataFilepath()</tt> function.
|-
|CountPerOp
|M64TYPE_INT
|Force number of cycles per emulated instruction when set greater than 0.
|-
|DelaySI
|M64TYPE_BOOL
|Delay interrupt after DMA SI read/write.
|-
|}

These configuration parameters are used in the Core's event loop to detect keyboard and joystick commands. They are stored in a configuration section called "CoreEvents" and may be altered by the front-end in order to adjust the behaviour of the emulator. These may be adjusted at any time and the effect of the change should occur immediately. The Keysym value stored is actually <tt>(SDLMod << 16) || SDLKey</tt>, so that keypresses with modifiers like shift, control, or alt may be used.

{| border="1"
!Parameter Name!!Type!!Usage
|-
|Kbd Mapping Stop
|M64TYPE_INT
|SDL keysym for stopping the emulator
|-
|Kbd Mapping Fullscreen
|M64TYPE_INT
|SDL keysym for switching between fullscreen/windowed modes
|-
|Kbd Mapping Save State
|M64TYPE_INT
|SDL keysym for saving the emulator state
|-
|Kbd Mapping Load State
|M64TYPE_INT
|SDL keysym for loading the emulator state
|-
|Kbd Mapping Increment Slot
|M64TYPE_INT
|SDL keysym for advancing the save state slot
|-
|Kbd Mapping Reset
|M64TYPE_INT
|SDL keysym for resetting the emulator
|-
|Kbd Mapping Speed Down
|M64TYPE_INT
|SDL keysym for slowing down the emulator
|-
|Kbd Mapping Speed Up
|M64TYPE_INT
|SDL keysym for speeding up the emulator
|-
|Kbd Mapping Screenshot
|M64TYPE_INT
|SDL keysym for taking a screenshot
|-
|Kbd Mapping Pause
|M64TYPE_INT
|SDL keysym for pausing the emulator
|-
|Kbd Mapping Mute
|M64TYPE_INT
|SDL keysym for muting/unmuting the sound
|-
|Kbd Mapping Increase Volume
|M64TYPE_INT
|SDL keysym for increasing the volume
|-
|Kbd Mapping Decrease Volume
|M64TYPE_INT
|SDL keysym for decreasing the volume
|-
|Kbd Mapping Fast Forward
|M64TYPE_INT
|SDL keysym for temporarily going really fast
|-
|Kbd Mapping Frame Advance
|M64TYPE_INT
|SDL keysym for advancing by one frame when paused
|-
|Kbd Mapping Gameshark
|M64TYPE_INT
|SDL keysym for pressing the game shark button
|-
|}

These configuration parameters are used in the Core's event loop to detect joystick commands.

The command strings use a simple format described here. Note that you cannot have any spaces in the command string. For commands activated by pressing a joystick axis, the format is "J'''x'''A'''y'''+" or "J'''x'''A'''y'''-", where '''x''' is the SDL joystick number (must be between 0 and 9) and '''y''' is the axis number. For the last character, '''+''' represents movement in the positive direction, while '''-''' represents movement in the negative direction. For commands activated by pressing a button, the format is "J'''x'''B'''y'''", where '''x''' is the SDL joystick number (must be between 0 and 9) and '''y''' is the button number. For commands activated by pressing a ''hat'' (a directional switch) on the joystick, the format is "J'''x'''H'''y'''V'''z'''", where '''x''' is the SDL joystick number (must be between 0 and 9), '''y''' is the hat number, and '''z''' is the hat value. The hat value corresponds with the SDL_HAT_ enumerated types: Up is 1, Right is 2, Down is 4, and Left is 8. For diagonal directions, these values may be ''or''d together.

After the 2.5 release, several new features were added to these Joystick Mapping command strings. You can now specify more than one joystick action which will activate a given command. To specify several actions, use a comma-separated string containing multiple action phrases as given above ("J'''x'''A'''y'''+" or "J'''x'''B'''y'''" or "J'''x'''H'''y'''V'''z'''"). Make sure there are no spaces in your command string. Another new feature is that the "*" character can be used as a wildcard in the '''x''' joystick number field in order to activate this command for any joystick. Finally, you can also use a hotkey specifier to require that two distinct joystick actions must be pressed simultaneously in order to activate a command. The format for the hoykey feature is like "J'''x'''''Action''/''Action''" where ''Action'' is either "A'''y'''+", "A'''y'''-", "B'''y'''", or "H'''y'''V'''z'''".

Here's an example of a joystick command parameter which uses all three of these new features:

<pre>Joy Mapping Stop = "J0B6,J*B9,J1B5/A0-"</pre>

With this joystick event string, the emulator will shut down when joystick 0 button 6 is pressed, or when button 9 is pressed on any joystick, or when button 5 is pressed on joystick 1 at the same time as axis 0 is moved left.

{| border="1"
!Parameter Name!!Type!!Usage
|-
|Version
|M64TYPE_FLOAT
|Mupen64Plus CoreEvents config parameter set version number. Please don't change.
|-
|Joy Mapping Stop
|M64TYPE_STRING
|Joystick event string for stopping the emulator
|-
|Joy Mapping Fullscreen
|M64TYPE_STRING
|Joystick event string for switching between fullscreen/windowed modes
|-
|Joy Mapping Save State
|M64TYPE_STRING
|Joystick event string for saving the emulator state
|-
|Joy Mapping Load State
|M64TYPE_STRING
|Joystick event string for loading the emulator state
|-
|Joy Mapping Increment Slot
|M64TYPE_STRING
|Joystick event string for advancing the save state slot
|-
|Joy Mapping Screenshot
|M64TYPE_STRING
|Joystick event string for taking a screenshot
|-
|Joy Mapping Pause
|M64TYPE_STRING
|Joystick event string for pausing or resuming the emulator
|-
|Joy Mapping Mute
|M64TYPE_STRING
|Joystick event string for muting/unmuting the sound
|-
|Joy Mapping Increase Volume
|M64TYPE_STRING
|Joystick event string for increasing the volume
|-
|Joy Mapping Decrease Volume
|M64TYPE_STRING
|Joystick event string for decreasing the volume
|-
|Joy Mapping Fast Forward
|M64TYPE_STRING
|Joystick event string for temporarily going really fast
|-
|Joy Mapping Gameshark
|M64TYPE_STRING
|Joystick event string for pressing the game shark button
|-
|}

ThirdPartyPlugins

2015-09-19T15:05:28Z

Richard42: /* Launchers */

This page has been created to list all of the third-party plugins and front-end applications for mupen64plus, in order to facilitate research. It's aim is to be a central place to find the different available plugins.

If you have made a plugin for mupen64plus which is not in this section, please contact dorian.fevrier with a link of the web site, so that it may be added to this list.

== Official Plugins ==

Mupen64Plus has 5 of its own official plugins: mupen64plus-input-sdl, mupen64plus-audio-sdl, mupen64plus-rsp-hle, mupen64plus-video-rice, and mupen64plus-video-glide64mk2. If you have a problem with one of them, you should report it via [http://code.google.com/p/mupen64plus/issues/list the issues list].

== Third-Party Front-end and Launcher Applications ==

Front-ends are applications which use the Mupen64Plus core emulator and compatible plugins, and present a user-interface. The only front-end included with the core Mupen64Plus bundle is a command-line only program. Third-party front-ends are developed and maintained outside of the main Mupen64Plus project but are compatible with Mupen64Plus 2.0. They are supported '''by their authors'''. If you have a problem with one of them, the best thing to do is to contact directly the author, who is the best placed person to answer you.

=== Front-End Applications under active development ===
{| class="wikitable"
|-
|'''Application Name''' || '''Description'''
|-
|[http://m64py.sourceforge.net/ m64py] || Python-based GUI Front-end using PyQt
|-
|[http://openemu.org/ OpenEmu] || OSX application which includes many different emulators. ([https://github.com/OpenEmu/OpenEmu Development Site])
|}

=== Front-end Applications not under active development ===
{| class="wikitable"
|-
|'''Application Name''' || '''Description'''
|-
|[http://www.mudlord.info/emulators/ winmupen] || Windows-specific GUI Front-end
|-
|[http://bitbucket.org/auria/wxmupen64plus/wiki/Home wxMupen64Plus] || A frontend with full support for configuration (mostly tested on OSX at this point)
|-
|[http://www.emutalk.net/showthread.php?t=50438 Gtk64] || GUI Front-end based on the object oriented GTKmm library
|-
|[http://sourceforge.net/userapps/mediawiki/vknecht/index.php?title=CuteMupen CuteMupen] || GUI front-end using Qt
|}

=== Launchers ===
The difference between a full Front-End application and a Launcher application is that a Front-End application links directly with the Mupen64Plus libraries and can integrate very closely with the emulator to provide features like GUI emulator controls, an integrated video window, and graphical debugger. A Launcher application does not link directly with the Mupen64Plus libraries, but uses the "mupen64plus-ui-console" command-line application to run the emulator. This type of application is easier to develop, but cannot provide the more advanced features.

{| class="wikitable"
|-
|'''Name''' || '''Description'''
|-
|[https://github.com/dh4/mupen64plus-qt Mupen64Plus-Qt] || Cross-platform launcher based on CEN64-Qt
|-
|[http://sjtrny.com/mupenlaunch/ MupenLaunch] || Nice-looking Mac OSX Launcher written in Objective C
|-
|[http://mupen64plus.googlecode.com/svn/wiki/Mupen64Loader.bat Mupen64Loader.bat] || Windows batch file (tested on XP) from Supernatendo on 2010-05-11. This script simplifies the use of the Mupen64Plus console UI for Windows XP users.
|-
|[http://speedofmac.com/speedofmac_mp64+_launcher.html SpeedofMac MP64+ GUI] || Launcher application for Mac OSX written with AppleScript and Perl
|-
|[http://forums.ngemu.com/emulation-news-submissions/131998-new-mupen64plus-v1-99-3-release-february-2010-windows-also.html#post1803213 MupenGUI C#] || Windows-only launcher/config application
|}

== Third-Party Plugins ==

Third party plugins are plugins which are not part of the main bundle you can find here. The only way to use these are to download (and sometimes compile) them yourself.

They are supported '''by their authors'''. If you have a problem with one of them, the best thing to do is to contact directly the author, who is the best placed person to answer you.

{| class="wikitable"
|-
|'''Plugin Name''' || '''Description'''
|-
|[https://github.com/mupen64plus/mupen64plus-video-arachnoid/ mupen64plus-video-arachnoid] || Video plugin for Mupen64Plus v2.0, based on the Arachnoid plugin for Project64.
|-
|[https://github.com/mupen64plus/mupen64plus-rsp-z64/ mupen64plus-rsp-z64] || Low-level RSP processor plugin for the Mupen64Plus v2.0 project. This is based on Ziggy's Z64 plugin. ||
|-
|[https://github.com/mupen64plus/mupen64plus-video-z64/ mupen64plus-video-z64] || Low-level RDP plugin for the Mupen64Plus v2.0 project. This is based on Ziggy's Z64 plugin. ||
|-
|[https://github.com/mupen64plus/mupen64plus-video-glide64/ mupen64plus-video-glide64] || Video plugin for Mupen64Plus v2.0, based on the Glide64 plugin from Mupen64Plus 1.5.
|-
|[https://github.com/mupen64plus/mupen64plus-rsp-cxd4/ mupen64plus-rsp-cxd4] || Low-level RSP processor plugin for the Mupen64Plus v2.0 project. This is based on Iconoclast/Batcat/cxd4s's rsp plugin.

MediaWiki:Loginprompt

2015-08-09T15:00:41Z

Richard42: Created page with "To prevent abuse, the Mupen64Plus wiki is only editable by project members. Contact Richard42 if you would like to get an account with permissions to edit this wiki."

To prevent abuse, the Mupen64Plus wiki is only editable by project members. Contact Richard42 if you would like to get an account with permissions to edit this wiki.

MainPage

2015-07-26T23:04:53Z

Richard42: Created page with "http://mupen64plus.googlecode.com/svn/wiki/Mupen64Plus-splash.jpg '''Mupen64Plus''' is a cross-platform plugin-based N64 emulator which is capable of accurately playing many..."

http://mupen64plus.googlecode.com/svn/wiki/Mupen64Plus-splash.jpg

'''Mupen64Plus''' is a cross-platform plugin-based N64 emulator which is capable of accurately playing many games. Included are four ''MIPS R4300'' CPU emulators, with dynamic recompilers for 32-bit x86 and 64-bit amd64 systems, and necessary plugins for audio, graphical rendering (RDP), signal co-processor (RSP), and input. There is 1 included OpenGL video plugin, called RiceVideo. There are 3 other excellent video plugins being maintained by [http://bitbucket.org/wahrhaft/ wahrhaft], called Arachnoid, Glide64, and Z64.

===Features===
* Dynamic recompilers for 32-bit (x86) and 64-bit (amd64) machines
* Two OpenGL video plugins, with [HighResolutionTextures Hi-resolution texture] support
* [LIRC LIRC] Infrared remote control support
* [RumbleSupport Rumble Pak] support (Linux only)
* Cheat system with gameshark code support
* Speed adjustment with smooth sound output
* Shared library interface for integration into other systems (front-ends)
* Command-line Front-end application

=News=

'''April 26, 2015''': I am happy to announce the availability of the latest release of Mupen64Plus! You can download it from GitHub, via the "v2.5 Release Downloads" link on the left. Check out the release message in this [http://www.emutalk.net/threads/55485-Mupen64Plus-v2-5-Mupen-s-Last-Stand-%28on-Google-Code%29 emutalk thread] for more information. 
'''March 12, 2015''': Google has announced the shutdown of the Google Code hosting service. Sadly, we will have to move our Mupen64Plus site off of here to a different host. We'll post our plans here once we decide where to move the site. 
'''February 3, 2015''': I apologize for such a long period with no new releases. There have actually been many many changes since the last release. Development effort has picked up significantly in the past half year or so, and we now have quite a few very smart and dedicated programmers who are improving Mupen64Plus in different areas. I promise there will be a new release this year. 

=Releases=
'''Mupen64Plus v2.5''' is now available for all supported operating systems. You can download it from the "v2.5 Release Downloads" link on the left.

For detailed information about the differences between each release, check out the [[ReleasePage|Release Notes Page]]

=Documentation=

==For Users==
[[KeyboardSetup|Keyboard]] - Default keyboard setup & configuration 
[[ControllerSetup|Joysticks]] - How to set up your joystick if it is not auto-detected 
[[UIConsoleUsage|UI-Console]] - Mupen64Plus command-line UI usage 
[[FileLocations|File Locations]] - Places where Mupen64Plus installs and/or searches for various files 
[[RumbleSupport|Rumble]] - Instructions for setting up force-feedback (Linux only) 
[[HighResolutionTextures|Hi-res textures]] - Instructions for using hi-resolution texture packs with Rice Video 
[[ThirdPartyPlugins|Third Party Front-ends and Plugins]] - List of additional Front-ends (user interfaces) and plugins, compatible with Mupen64Plus 2.0 but not part of the bundle distributed here 
[[GameCompatibility|Games]] - Compatibility and game notes 
[[Screenshots]] 

== For Developers==
[[Mupen64Plus_v2.0_Core_API_v1.0|Mupen64Plus 2.0 API]] - Full documentation of the new API between plugins, the emulator core, and the front-end application 
[https://github.com/mupen64plus Mupen64Plus source code] - Link to Git repository containing the Mupen64plus modules - the emulator core, 10 plugins, command-line user interface program, Win32 build dependencies and test ROM source code. 

You can download, build, and test the latest source code from our Git repository. For Linux users, instructions can be found at the [[CompilingFromGit]] wiki page. For Windows users, instructions can be found at the [[CompilingOnWindows]] wiki page. For Apple OSX users, instructions are at the [[MacOSXInstructions]] page.

=Questions / Problems / Bugs=
If you have questions, you may post them in the [http://groups.google.com/group/mupen64plus Mupen64Plus Google Group]. To report a problem or a bug, you may post a message on the google group, or use the Issue Tracker above to file a bug report.

We also have an IRC channel where many of the developers and fans hang out. If you would like to stop by with a question or to say hi, it's #mupen64plus at irc.freenode.net

=Developers, Developers, Developers!=

For those who are not Mupen64Plus project members but would like to submit a patch, please post it in the [http://groups.google.com/group/mupen64plus Mupen64Plus Google Group]. For those who would like to join the project, please send an email to the project owner, which is given at the top of this page, on the right.

UIConsoleUsage

2015-07-26T22:45:47Z

Richard42: Instructions for using the Mupen64Plus-UI-Console front-end application

ThirdPartyPlugins

2015-07-26T22:44:01Z

Richard42: List of third party plugins and front-end applications for mupen64plus

This page has been created to list all of the third-party plugins and front-end applications for mupen64plus, in order to facilitate research. It's aim is to be a central place to find the different available plugins.

If you have made a plugin for mupen64plus which is not in this section, please contact dorian.fevrier with a link of the web site, so that it may be added to this list.

== Official Plugins ==

Mupen64Plus has 5 of its own official plugins: mupen64plus-input-sdl, mupen64plus-audio-sdl, mupen64plus-rsp-hle, mupen64plus-video-rice, and mupen64plus-video-glide64mk2. If you have a problem with one of them, you should report it via [http://code.google.com/p/mupen64plus/issues/list the issues list].

== Third-Party Front-end and Launcher Applications ==

Front-ends are applications which use the Mupen64Plus core emulator and compatible plugins, and present a user-interface. The only front-end included with the core Mupen64Plus bundle is a command-line only program. Third-party front-ends are developed and maintained outside of the main Mupen64Plus project but are compatible with Mupen64Plus 2.0. They are supported '''by their authors'''. If you have a problem with one of them, the best thing to do is to contact directly the author, who is the best placed person to answer you.

=== Front-End Applications under active development ===
{| class="wikitable"
|-
|'''Application Name''' || '''Description'''
|-
|[http://m64py.sourceforge.net/ m64py] || Python-based GUI Front-end using PyQt
|-
|[http://openemu.org/ OpenEmu] || OSX application which includes many different emulators. ([https://github.com/OpenEmu/OpenEmu Development Site])
|}

=== Front-end Applications not under active development ===
{| class="wikitable"
|-
|'''Application Name''' || '''Description'''
|-
|[http://www.mudlord.info/emulators/ winmupen] || Windows-specific GUI Front-end
|-
|[http://bitbucket.org/auria/wxmupen64plus/wiki/Home wxMupen64Plus] || A frontend with full support for configuration (mostly tested on OSX at this point)
|-
|[http://www.emutalk.net/showthread.php?t=50438 Gtk64] || GUI Front-end based on the object oriented GTKmm library
|-
|[http://sourceforge.net/userapps/mediawiki/vknecht/index.php?title=CuteMupen CuteMupen] || GUI front-end using Qt
|}

=== Launchers ===
The difference between a full Front-End application and a Launcher application is that a Front-End application links directly with the Mupen64Plus libraries and can integrate very closely with the emulator to provide features like GUI emulator controls, an integrated video window, and graphical debugger. A Launcher application does not link directly with the Mupen64Plus libraries, but uses the "mupen64plus-ui-console" command-line application to run the emulator. This type of application is easier to develop, but cannot provide the more advanced features.

{| class="wikitable"
|-
|'''Name''' || '''Description'''
|-
|[http://www.emutalk.net/threads/54976-Mupen64Plus-Qt Mupen64Plus-Qt] || Cross-platform launcher based on CEN64-Qt
|-
|[http://sjtrny.com/mupenlaunch/ MupenLaunch] || Nice-looking Mac OSX Launcher written in Objective C
|-
|[http://mupen64plus.googlecode.com/svn/wiki/Mupen64Loader.bat Mupen64Loader.bat] || Windows batch file (tested on XP) from Supernatendo on 2010-05-11. This script simplifies the use of the Mupen64Plus console UI for Windows XP users.
|-
|[http://speedofmac.com/speedofmac_mp64+_launcher.html SpeedofMac MP64+ GUI] || Launcher application for Mac OSX written with AppleScript and Perl
|-
|[http://forums.ngemu.com/emulation-news-submissions/131998-new-mupen64plus-v1-99-3-release-february-2010-windows-also.html#post1803213 MupenGUI C#] || Windows-only launcher/config application
|}

== Third-Party Plugins ==

Third party plugins are plugins which are not part of the main bundle you can find here. The only way to use these are to download (and sometimes compile) them yourself.

They are supported '''by their authors'''. If you have a problem with one of them, the best thing to do is to contact directly the author, who is the best placed person to answer you.

{| class="wikitable"
|-
|'''Plugin Name''' || '''Description'''
|-
|[https://github.com/mupen64plus/mupen64plus-video-arachnoid/ mupen64plus-video-arachnoid] || Video plugin for Mupen64Plus v2.0, based on the Arachnoid plugin for Project64.
|-
|[https://github.com/mupen64plus/mupen64plus-rsp-z64/ mupen64plus-rsp-z64] || Low-level RSP processor plugin for the Mupen64Plus v2.0 project. This is based on Ziggy's Z64 plugin. ||
|-
|[https://github.com/mupen64plus/mupen64plus-video-z64/ mupen64plus-video-z64] || Low-level RDP plugin for the Mupen64Plus v2.0 project. This is based on Ziggy's Z64 plugin. ||
|-
|[https://github.com/mupen64plus/mupen64plus-video-glide64/ mupen64plus-video-glide64] || Video plugin for Mupen64Plus v2.0, based on the Glide64 plugin from Mupen64Plus 1.5.
|-
|[https://github.com/mupen64plus/mupen64plus-rsp-cxd4/ mupen64plus-rsp-cxd4] || Low-level RSP processor plugin for the Mupen64Plus v2.0 project. This is based on Iconoclast/Batcat/cxd4s's rsp plugin.

SoftResetNotes

2015-07-26T22:39:50Z

Richard42: Developer notes on soft reset feature

=== Details ===

5.2.6 Non Maskable Interrupt (NMI) Exception
A non maskable interrupt exception occurs when the NMI signal is asserted to the processor. Unlike all other interrupts, this exception is not maskable. An NMI occurs only at instruction boundaries, so does not do any reset or other hardware initialization. The state of the cache, memory, and other processor state is consistent and all registers are preserved, with the following exceptions:
* The BEV, TS, SR, NMI, and ERL ﬁelds of theStatus register are initialized to a speciﬁed state.
* TheErrorEPC register is loaded with restart PC, as described inTable 5-5.
* PC is loaded with16#BFC0 0000.
''Cause'' Register ExcCode Value: None
Additional State Saved: None
Entry Vector Used: Reset 16#BFC0 0000

Operation
<nowiki>
StatusBEV <-- 1
StatusTS <-- 0
StatusSR <-- 0
StatusNMI <-- 1
StatusERL <-- 1
if InstructionInBranchDelaySlot then
ErrorEPC <-- restartPC # PC of branch/jump
else
ErrorEPC <-- restartPC # PC of instruction
endif
PC <-- 16#BFC0 0000</nowiki>

=== From assemblergames.com ===

Marshallh [http://www.assemblergames.com/forums/showthread.php?p=477806 wrote]:

On boot, the PIF inside the n64 starts sending a very, very long sequence of random numbers to the CIC. The PIF is always reading the response back (this is a continuous process while the N64 is turned on).

Once the PIF is happy with the values it's getting back, it releases NMI on the R4300. This causes an NMI interrupt on the cpu, and causes it to start executing code from the memory location 0xBFC00000. Because all the memory is accessed through the RCP, this small segment of memory is mapped to a small almost 2k chunk of ROM in the PIF called PIF-rom.

The code in there is r4300 executable code. The actual boot process is pretty convoluted, that's another time. But about halfway through the sequence of boot programs, the R4300 reads from PIF ram (small 64byte area) and this contains values used in the calculation of the CIC seed. (6102 seed is 0x3f)

The way a game determines whether it's running on a PAL or NTSC console is simple - it's hardcoded in the PIF rom.

If you have a logic analyzer and some tools you can put probes on the lines that go from the PIF to the RCP and catch all the contents of the pif ROM as it's read. This is the only way to get access to it, because after the boot process you will read all 0's from where the PIFrom used to be mapped.

Once you have it dumped you can look for the instruction that loads the register s4 (something like li s4, 0x01) and change it to 0x0 for PAL, and 0x1 for NTSC.

You can also use a boot emulator to do all this, but it means you have to have a way of running your own code. The boot emulator basically runs a version of PIFrom that is hacked to skip the security checks, and you patch in whatever values you want (you can fake different CICs and regions this way)

The CIC seed is also used to checksum the bootcode in the first 4k of game ROM, and to also checksum the first 1MB transferred to make sure the cart interface is reliable.

Screenshots

2015-07-26T22:37:47Z

Richard42: Mupen64Plus Screenshots

=== Paper Mario ===

[[File:Screenshot-01-PaperMario.png]]
[[File:Screenshot-02-PaperMario.png]]

=== Hi-res Mario 64 ===

http://i32.tinypic.com/2saldmg.png
http://i30.tinypic.com/t5fw37.png

=== Hi-res Zelda Ocarina of Time ===

This is a cel-shaded pack, by Djipi.

[[File:Zelda-OOT-01.jpg]]
[[File:Zelda-OOT-02.jpg]]
[[File:Zelda-OOT-03.jpg]]

File:Zelda-OOT-03.jpg

2015-07-26T22:31:10Z

Richard42: zelda screenshot

zelda screenshot

File:Zelda-OOT-02.jpg

2015-07-26T22:30:59Z

Richard42: zelda screenshot

zelda screenshot

File:Zelda-OOT-01.jpg

2015-07-26T22:30:47Z

Richard42: zelda screenshot

zelda screenshot

File:Screenshot-02-PaperMario.png

2015-07-26T22:30:26Z

Richard42: paper mario screenshot

paper mario screenshot

File:Screenshot-01-PaperMario.png

2015-07-26T22:30:12Z

Richard42: paper mario screenshot

paper mario screenshot

File:Mupen64Plus-splash.jpg

2015-07-26T22:29:43Z

Richard42: splash pic

splash pic

File:Mupen64Plus-02.jpg

2015-07-26T22:29:15Z

Richard42: Richard42 uploaded a new version of "File:Mupen64Plus-02.jpg"

rom browser screenshot

File:Mupen64Plus-02.jpg

2015-07-26T22:28:49Z

Richard42: rom browser screenshot

rom browser screenshot

RumbleSupport

2015-07-26T22:13:25Z

Richard42: Notes on using Rumble Pak support with Mupen64Plus

== Introduction ==

The first official Mupen64Plus release which includes support for the Rumble Pak feature is v1.4. This feature has been tested and is known to work with Logitech Rumble Pad 2 wireless controllers.

== Prerequisites ==

In order to use the Rumble Pak feature in Mupen64Plus, you must have the HID Force Feedback module enabled in your kernel, and you must have the proper HID force feedback driver for your gamepad also enabled in your kernel. The easiest way to test your system for compatibility is to run the emulator from a console and launch a game to get diagnostic messages from the emulator. Look in the printed information for this line:

<code>[blight's SDL input plugin]: version 0.0.10 initialized.</code>

Just prior to this line, there should be some messages regarding the rumble pak feature. The meanings of the various messages are given below:

* <code>[blight's SDL input plugin]: Couldn't find input event for rumble support.</code>

This suggests that your kernel does not have the required support for the rumble feature

* <code>[blight's SDL input plugin]: Couldn't open device file '/dev/input/eventX' for rumble support.</code> (X is a number)

This is usually caused by restrictive permissions. It is easy to set the correct permissions on this device file. You can do this by entering "sudo chmod 666 /dev/input/eventX" where X is the number given in the error message.

* <code>[blight's SDL input plugin]: Linux kernel communication failed for force feedback (rumble)</code>

This error message can occur when your kernel does not have support for HID Force Feedback built into it or as a module. You must rebuild your kernel to include support for both HID force feedback and the correct driver for your gamepad.

* <code>[blight's SDL input plugin]: No rumble supported on N64 joystick #1</code>

This could be caused by lack of kernel support or by using a joystick which does not support force feedback

* <code>[blight's SDL input plugin]: Rumble activated on N64 joystick #1</code>

Rumble is working and enabled

== Configuration ==

The Blight Input configuration dialog allows the user to configure the default pak to be plugged-in at game start time (this can be either Mem Pak, Rumble Pak, or None). It also allows the user to assign controller buttons to two switches, called "Mempak Switch" and "Rumblepak Switch". When these buttons are pressed, it will swap in a "virtual memory pak" or a "virtual rumble pak" in the selected controller. There will also be tactile feedback given when switching paks - plugging in a memory pak will give a weak rumble, while plugging in a rumble pak will give a strong rumble.

RomCacheSystem

2015-07-26T22:12:13Z

Richard42: Design document for Rom Cache System (RCS)

== Rom Cache System (RCS) Concept ==

=== Overview ===

'''Objective:''' Create a system that passively retrieves/loads information about the Rom Browser, and current ROM being played.

'''Operations:''' Start the RCS when Mupen64Plus is executed. If -–nogui is specified then do not worry about the Rom Browser operations.

''The RCS will be responsible for the following tasks:''
* Caching the MD5, Filename, Good Name (from database), and OS Timestamp (for checking if a file has changed) of each of the entries in the Rom Browser. This file will be external and will be loaded when the GUI version boots up to speed up the Rom Browser creation.
* Reading a ROM database that contains meta information about each ROM. This file will be external and replace mupen64plus.ini
* Sending a notification to the Rom Browser to update the list with new information when the initial caching is going on.
* Storing global information about the current ROM being played.

=== Other Information ===

When creating the Rom List, it would not be proper to display ROMs that have not been initially cached. Once they have been cached with the MD5, Good Name lookup, and Filename they should be displayed onto the Rom Browser.

The process of caching should not be redundant and should only occur if the cache file does not exist, or the Refresh is selected. In the case that Refresh is selected, the files should be checked against the already cached files to speed up performance. Any files that are not existing anymore should be removed from the cache file.

The caching thread should be halted when the user starts a ROM, and should resume caching as if the Rom Browser has been refreshed. It should be continued when the user stops the ROM.

=== File Structure ===

Since there is a bulk list of ROMS, we want our list to be cross referencing itself. Please look at the following flags that will be included:

<nowiki>
[MD5]
CRC=CRC
GoodName=STRING
Compatible=STRING
ExpansionPack=1/0
SoftHack=CODE0001 CODE, CODE0002 CODE
Reference=MD5
</nowiki>

A lot of this should be self explanatory, however just for note... if a reference is used, the ROM will inherit the referenced MD5 properties, and then they can be modified as needed. If you feel like something should be added to the database please feel free to comment in the appropriate discussion so it gets noted.

RomBrowserColumns

2015-07-26T22:11:04Z

Richard42: Useful information about the meaning of each column in the ROM browser

'''Country'''

The release country code for commercial ROMs and N64 tools. Usually this is an indication of the default language and / or target audience for a game. Homebrew programs may use a region code or simply identify as Demos. Additionally, prelease versions of commercial ROMs are flagged as Betas.

'''GoodName'''

GoodN64 is a database of nearly all known N64 ROMs created by Cowering (www.allgoodthings.us). Mupen64Plus uses these names to distinguish ROMs as the file may be misnamed. Each ROM is assigned a unique Good Name on the following criteria:

Release country code for commercial ROMs:
* (JU) USA/Japan
* (G) Germany
* (U) USA
* (F) France
* (I) Italy
* (J) Japan
* (S) Spain
* (A) Australia
* (E) Europe
* or (PD) Public Domain for homebrew.

Additionally, each name has at least one of the following codes:

* <code>[!]</code> - Verified Good Dump - If these ROMs don't work, it is an emulation bug.
* <code>[a#]</code> - Alternative - An alternate working version of a ROM.
* <code>(M#)</code> - Multilanguage - Official support for # of languages.
* <code>[o#]</code> - Overdumped - An overdumped ROM image has more data than is actually in the cart. Besides wasting space, the ROM should be okay.

The following codes indicate that the ROM was modified or hacked in some manner. Mupen64Plus will issue a warning when trying to load one of these ROMs, although many should work fine.

* <code>[T?]</code> - Translation - Unlike multilanguage support from (M#) ROMs, these translations were made by hackers to allow access of games to a broader audience. As performing such a translation involves manipulating large amounts of ROM data, it is possible unintended bugs were introduced. <code>[T+?</code> indicates a newer translation, while <code>[T-?</code> indicates an older release. If a translation doesn't work, you might want to obtain a newer version.
* <code>[t#]</code> - Trained - A trainer is special code which executes before the game is begun. It allows you to access cheats from a menu.
* <code>[h#]</code> - Hacked - A general hacked ROM. Hacks range from changed headers to allow running in different regions, release group intros, or just some kind of cheating or funny hack.
* <code>[b#]</code> - Bad Dump - A released bad dump, either due to a faulty dumping or corruption on upload.
* <code>[f#]</code> - Fixed - A ROM has been altered in some way so that it might run better, usually from the perspective of using a hardware copier.

'''Status'''

Mupen64Plus uses a 0-5 star ranking system to give a rough indication of how well a given ROM works with the emulator. Additionally this can be viewed as the probably the ROM will work for a given system.

0 stars - Unknown / Critical Issues - The ROM doesn't load or crashes the emulator. Definitely won't work.

1 star - Severe Issues - The ROM loads, but is unplayable. This is usually due to one of the following: no input, no audio, or no video with any plugin combination. Probably won't work.

2 stars - Moderate Issues - Playable with one plugin combination on some systems. Might work.

3 stars - Mild Issues - Playable with multiple plugins but sometimes with severe artifacts. Will likely work.

4 stars - Minor Issues - Only minor artifacts with all plugins. Should work.

5 stars - Perfect - No known issues. Will definitely work.

'''User Comments'''

Mupen64Plus gives users the ability to enter short (256 byte) comments to label or classify ROMs without having to rename the files. Some possible uses are to track game progress while playing a number of ROMs, rank ROMs based on preference, or make notes of emulation issues for helping with development.

'''File Name'''

The file name or full path of the ROM.

'''MD5 Hash'''

The md5sum of the ROM data. Used to differentiate ROMs.

'''CRC1'''

The first 4 bytes of the ROM's identifying CRC code, located in the header of the N64 ROM format. This is largely for legacy purposes as ROMs used to be differentiated by CRC. However, as it is possible for the header to be corrupt and / or many different ROMs to share the same CRC, MD5 hashes of the entire ROM file are now used instead. Many cheat codes and video plugins still reference this information, so it is useful for the end user.

'''CRC2'''

The second 4 bytes of the ROM's identifying CRC code, located in the header of the N64 ROM format. This is largely for legacy purposes as ROMs used to be differentiated by CRC. However, as it is possible for the header to be corrupt and / or many different ROMs to share the same CRC, MD5 hashes of the entire ROM file are now used instead. Many cheat codes and video plugins still reference this information, so it is useful for the end user.

'''Internal Name'''

A 20 byte SHIFT_JIS identifying string located in the header of the N64 ROM format. This is largely for informational purposes, though some video plugins may use this name for things like hi-res textures.

'''Save Type'''

The native save format of a given ROM. N64 cartridges had a number of different internal save options. These include 4KB or 16KB of Eeprom, 32KB of battery backed SRAM, or 256KB of Flash RAM. Additionally, many N64 games used an external Controller Pack for game saves. The official version of this was 256KB of battery backed SRAM, although 3rd party models often had much more. This information is used by the emulator in the booting process.

'''Players'''

The number of players 0-4 supported by the ROM. 0 Player ROMs are generally homebrew laminations or other Demos.

'''Size'''

The size of the uncompressed ROM. Useful for debugging.

'''Compression'''

A number of different ROM compression formats are supported including Gzip, Bzip2, LZMA stream, Zip, and 7zip. Zip and 7zip are archive formats, and Mupen64Plus supports having multiple ROMs in a single image.

'''Image Type'''

N64 ROMs come in three types: .z64 (native) images, .v64 (byteswapped) image, and .n64 (wordswapped). The names are mainly historical and refer to original backup units used to dump the ROMs. Mupen64Plus can take any image type, but other emulators might not. Also, all MD5s are of the native .z64 image.

'''CIC Chip'''

The Boot CIC is a security chip that exists in Nintendo64 cartridges that the ROM uses to boot. It is designed for copy protection. Most ROMs only access this information at boot, but others (notably those produced by Rare) access it at other points during gameplay. This is provided largely for informational purposes as Mupen64Plus successfully emulates all known CICs.

'''Rumble'''

Does the ROM support a rumble pack on a real N64? If Yes, it should be possible to get rumble through emulation.

MacOSXInstructions

2015-07-26T22:02:48Z

Richard42:

__NOTOC__
Here are some basic usage instructions to compile Mupen64Plus on Intel Macintosh computers with OSX (this is for developers. If you are a user, please just download the binary from the downloads page or, if you want a front-end, look at http://bitbucket.org/auria/wxmupen64plus/wiki/Home ). As of October, 2011, all of the Mupen64Plus software will compile and run correctly. Please be aware that Mupen64Plus does not currently run on older PowerPC based Macintosh computers.

Please note that these instructions are meant as guidelines for people who know what they're doing. If you don't have much experience building stuff from source, I would recommend that you wait for binary packages instead.

Choose your mupen version :
<div class="toclimit-2">__TOC__</div>

== Mupen64plus 1.99.x and 2.x ==

* Install developer tools (Xcode) from the DVD that came with your Mac.

* Get the code from the various modules using mercurial as on any other platform (or just download a source code archive)
Get the dependencies just like you'd do for mupen64plus 1.x (except maybe GTK/Qt since there is no GUI frontend yet for mupen 2)

* Install pkg-config if you don't already have it

Create this file, called '''zlib.pc''', in /usr/local/lib/pkgconfig
<pre>
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: zlib
Version: 1.1.3
Description: zlib
Requires:
Libs: -L${libdir} -lz
Cflags: -I${includedir}</pre>

Create this file, called '''gl.pc''', in /usr/local/lib/pkgconfig
<pre>
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: gl
Version: 2.0
Description: OpenGL
Requires:
Libs: -framework OpenGL
Cflags: -I${includedir}</pre>

Create this file, called '''glu.pc''', in /usr/local/lib/pkgconfig
<pre>
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: glu
Version: 2.0
Description: glu
Requires:
Libs:
Cflags: -I${includedir}</pre>

A script to build (32 bits, compatible with 10.6/10.5 and maybe 10.4) looks like :

<pre>
PWD = `pwd`
export CC="gcc-4.0"
export CXX="g++-4.0"
export LD="g++-4.0"
APIDIR=$PWD/mupen64plus-core/src/api
export MACOSX_DEPLOYMENT_TARGET=10.4
export SDK_ROOT=/Developer/SDKs/MacOSX10.5.sdk
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig

APP_BUNDLE=./mupen64plus.app/Contents

export CFLAGS="-g"
export CXXFLAGS="-g"

echo "== Core =="
cd mupen64plus-core/projects/unix
make all V=1
cd ../../..
cp -f mupen64plus-core/projects/unix/'''.dylib .'''

echo "== RSP-HLE =="
cd mupen64plus-rsp-hle/projects/unix
make all V=1
cd ../../..
cp -f mupen64plus-rsp-hle/projects/unix/'''.dylib .'''

echo ""
echo "== SDL Audio =="
cd mupen64plus-audio-sdl/projects/unix
make all V=1
cd ../../..
cp -f mupen64plus-audio-sdl/projects/unix/'''.dylib .'''

echo ""
echo "== SDL Input =="
cd mupen64plus-input-sdl/projects/unix
make all V=1
cd ../../..
cp -f mupen64plus-input-sdl/projects/unix/'''.dylib .'''

echo ""
echo "== Rice =="
cd mupen64plus-video-rice/projects/unix
make all CC="g++-4.0" C_INCLUDE_PATH="/usr/local/include" CPLUS_INCLUDE_PATH="/usr/local/include" V=1 BITS=32 PIC=1
cd ../../..
cp -f mupen64plus-video-rice/projects/unix/'''.dylib .'''

echo ""
echo "== Arachnoid =="
cd mupen64plus-video-arachnoid/projects/unix
make all C_INCLUDE_PATH="/usr/local/include" CPLUS_INCLUDE_PATH="/usr/local/include" V=1
cd ../../..
cp -f mupen64plus-video-arachnoid/projects/unix/'''.dylib .'''

echo ""
echo "== Glide =="
cd mupen64plus-video-glide64/projects/unix
make all C_INCLUDE_PATH="/usr/local/include" CPLUS_INCLUDE_PATH="/usr/local/include" V=1
cd ../../..
cp -f mupen64plus-video-glide64/projects/unix/'''.dylib .'''

echo ""
echo "== Glide Napalm =="
cd mupen64plus-video-glide-napalm/Glitch64
make -f Makefile.gcc OSX_ARCH=i386 EXT_INC="../../mupen64plus-core/src/api -I./inc"
cd ../src
make -f Makefile.nowx-gcc all C_INCLUDE_PATH="/usr/local/include:../../mupen64plus-core/src/api" CPLUS_INCLUDE_PATH="/usr/local/include:../../mupen64plus-core/src/api" OSX_ARCH=i386
cd ../..
cp -f mupen64plus-video-glide-napalm/src/lib/'''.dylib .'''
cp -f mupen64plus-video-glide-napalm/src/'''.dylib .'''

echo ""
echo "== Console =="
cd mupen64plus-ui-console/projects/unix
make all V=1
cd ../../..
cp -f mupen64plus-ui-console/projects/unix/mupen64plus .

mkdir -p $APP_BUNDLE/MacOS/
cp -f mupen64plus $APP_BUNDLE/MacOS/mupen64plus
cp -f '''.dylib $APP_BUNDLE/MacOS/.'''
</pre>

To build 64-bits, use something like that instead (tested on 1.6) :
<pre>
#!/bin/sh
PWD = `pwd`

APIDIR=$PWD/mupen64plus-core/src/api
export LD="g++"

APP_BUNDLE=./mupen64plus.app/Contents

echo "== Core =="
cd mupen64plus-core/projects/unix
make all APIDIR=$APIDIR ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-core/projects/unix/*.dylib .

echo "== RSP-HLE =="
cd mupen64plus-rsp-hle/projects/unix
make all APIDIR=$APIDIR ARCH_DETECTED=64BITS LD="g++"
cd ../../..
cp -f mupen64plus-rsp-hle/projects/unix/*.dylib .

echo ""
echo "== SDL Audio =="
cd mupen64plus-audio-sdl/projects/unix
make all APIDIR=$APIDIR ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-audio-sdl/projects/unix/*.dylib .

echo ""
echo "== SDL Input =="
cd mupen64plus-input-sdl/projects/unix
make all APIDIR=$APIDIR ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-input-sdl/projects/unix/*.dylib .

echo ""
echo "== Rice =="
cd mupen64plus-video-rice/projects/unix
make all APIDIR=$APIDIR NO-ASM=1 C_INCLUDE_PATH=/usr/local/include ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-video-rice/projects/unix/*.dylib .

echo ""
echo "== Arachnoid =="
cd mupen64plus-video-arachnoid/projects/unix
make all C_INCLUDE_PATH="/usr/local/include" CPLUS_INCLUDE_PATH="/usr/local/include" ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-video-arachnoid/projects/unix/*.dylib .

echo ""
echo "== Glide =="
cd mupen64plus-video-glide64/projects/unix
make all C_INCLUDE_PATH="/usr/local/include" CPLUS_INCLUDE_PATH="/usr/local/include" ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-video-glide64/projects/unix/*.dylib .

echo ""
echo "== Console =="
cd mupen64plus-ui-console/projects/unix
make all APIDIR=$APIDIR ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-ui-console/projects/unix/mupen64plus .

mkdir -p $APP_BUNDLE/MacOS/
cp -f mupen64plus $APP_BUNDLE/MacOS/mupen64plus
cp -f *.dylib $APP_BUNDLE/MacOS/.
</pre>

''' Macports users, you will need to add flags like this to the end of many of the ''make'' commands above :'''
<nowiki>
LIBRARY_PATH=/opt/local/lib
C_INCLUDE_PATH="/opt/local/include/libpng12"
CPLUS_INCLUDE_PATH="/opt/local/include/libpng12"</nowiki>

And a script to bundle may look like :

<pre>
#!/bin/sh
APP_CONTENTS="./mupen64plus.app/Contents"

FIX_LIST="-x $APP_CONTENTS/MacOS/mupen64plus \
-x $APP_CONTENTS/MacOS/libmupen64plus.dylib \
-x $APP_CONTENTS/MacOS/mupen64plus-audio-sdl.dylib \
-x $APP_CONTENTS/MacOS/mupen64plus-input-sdl.dylib \
-x $APP_CONTENTS/MacOS/mupen64plus-rsp-hle.dylib \
-x $APP_CONTENTS/MacOS/mupen64plus-video-rice.dylib \
-x $APP_CONTENTS/MacOS/mupen64plus-video-arachnoid.dylib \
-x $APP_CONTENTS/MacOS/mupen64plus-video-glide64.dylib"

dylibbundler -od -b $FIX_LIST -d $APP_CONTENTS/libs/

rm -rf $APP_CONTENTS/Resources
mkdir -p $APP_CONTENTS/Resources
cp ./mupen64plus-video-rice/data/* $APP_CONTENTS/Resources
cp ./mupen64plus-video-glide64/data/* $APP_CONTENTS/Resources
cp ./mupen64plus-core/data/* $APP_CONTENTS/Resources
cp ./mupen64plus-input-sdl/data/* $APP_CONTENTS/Resources
</pre>

this script requires [http://macdylibbundler.sourceforge.net/ macdylibbundler] to be installed.

Currently this only runs from the terminal.

== Mupen64plus 1.x ==

===Developer tools===
Install developer tools (Xcode) from the DVD that came with your Mac.

===GETTING MUPEN64PLUS===
You can simply download a source archive from the mupen64plus website; you can also use SVN. SVN example :
<nowiki>
mkdir mupen64plus
cd mupen64plus
svn co svn://fascination.homelinux.net:7684/mupen64plus/trunk --username mupen64 --password Dyson5632-kart</nowiki>

===DEPENDENCIES===
* Mupen can be built with either GTK+ or Qt. It is expected that in the future the Qt version will work better, but until then the GTK+ version is easier to get to run. Install GTK+ from http://www.gtk-osx.org/. (If you like using macports, beware : GTK as installed from macports ''will'' work on your computer, but you won't be able to package a distributable dmg. The installer from the website mentionned is much more handy for this)

* Other dependencies can be installed either from source or from macports.

====(A) THE SOURCE CODE WAY====
You will need SDL, SDL_ttf and its subdependencies (Freetype, fontconfig), and libpng.
Find them with [http://www.google.com Google] and install them with the usual
<nowiki>
./configure
make
sudo make install</nowiki>

====(B) THE MACPORTS WAY====
* Install macports from [http://www.macports.org/install.php macports.org]
* Open terminal (under Hard Drive, Applications, Utilities, Terminal). Type in the following commands.
<nowiki>
sudo port install libsdl_ttf libpng</nowiki>

Since macports installs librairies in a non-standard prefix, you will need to help the makefiles find librairies installed from macports. You can simply export LDFLAGS=-L/opt/local/lib or, more conveniently, change it on a more permanent basis by editing '''pre.mk''' in the mupen source - then locate the lines that read
<nowiki>
OS = OSX
LDFLAGS += -liconv -lpng</nowiki>
and make the second one
<nowiki>
LDFLAGS += -L/opt/local/lib -liconv -lpng</nowiki>

===BUILDING MUPEN64PLUS===
We'll first set some environment variables to help mupen find GTK+. Also make sure sdl-config is in your PATH.
<nowiki>
export PKG_CONFIG_PATH=/Library/Frameworks/Gtk.framework/Resources/dev/lib/pkgconfig
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/Library/Frameworks/GLib.framework/Resources/dev/lib/pkgconfig
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/Library/Frameworks/Cairo.framework/Resources/dev/lib/pkgconfig </nowiki>
Then cross your fingers, it's time to build!
<nowiki>
cd /path/to/mupen/trunk
make all</nowiki>

Or, for a debug build:
<nowiki>
make DBGSYM=1 all</nowiki>

===RUNNING===
<nowiki>
cd mupen64plus/trunk/
./mupen64plus</nowiki>

To run no gui mode :
<nowiki>
# simplest :
./mupen64plus --nogui <rom-path>

# pass some settings
./mupen64plus --nogui --gfx plugins/glN64.so --audio plugins/jttl_audio.so --input plugins/blight_input.so --rsp plugins/mupen64_hle_rsp_azimer.so --emumode 1 <rom-path></nowiki>

Be aware that input may not work if you launch ROMs in GUI mode.

===PACKAGING MUPEN64PLUS===
If all you wanted is to play with Mupen64Plus, this section won't apply to you; but we want to share the fun with others, don't we? From now on, I'll concentrate on how to build a package you can send to others.

Start by installing mupen :
<nowiki>
sudo ./install.sh</nowiki>

You will first need an '''Info.plist''' file, sample here :
<nowiki>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key> <string>English</string>
<key>CFBundleInfoDictionaryVersion</key> <string>6.0</string>
<key>CFBundlePackageType</key> <string>APPL</string>
<key>CSResourcesFileMapped</key> <true/>

<key>CFBundleExecutable</key> <string>launcher</string>
<key>CFBundleName</key> <string>Mupen64Plus</string>
<key>CFBundleIconFile</key> <string>mupen64plus.icns</string>
<key>CFBundleVersion</key> <string>1.5</string>

<key>CFBundleDocumentTypes</key>
<array>
<dict>
<key>CFBundleTypeExtensions</key>
<array>
<string>n64</string>
<string>N64</string>
<string>z64</string>
<string>V64</string>
<string>v64</string>
<string>V64</string>
</array>
<key>CFBundleTypeIconFile</key>
<string>mupen64cart.icns</string>
<key>CFBundleTypeName</key>
<string>N64 Rom</string>
<key>CFBundleTypeRole</key>
<string>Editor</string>
<key>LSIsAppleDefaultForType</key>
<true/>
<key>LSTypeIsPackage</key>
<false/>
</dict>

</array>

</dict>
</plist></nowiki>
(note that the executable name in this Info.plist file is ''launcher'' - I'll explain why below)

You will also need icons for mupen and ROMs : mupen64plus.icns, mupen64cart.icns

Then you can build the application bundle by using a simple shell script :
<nowiki>
INSTALL_PREFIX="/usr/local"
APP_CONTENTS="./Mupen64Plus.app/Contents"

echo "* Removing any existing installation"
rm -rf ./Mupen64Plus.app

echo "* Creating skeleton"
mkdir -p $APP_CONTENTS/Resources
mkdir $APP_CONTENTS/MacOS
cp Info.plist $APP_CONTENTS/Info.plist
cp mupen64plus.icns $APP_CONTENTS/Resources/mupen64plus.icns
cp mupen64cart.icns $APP_CONTENTS/Resources/mupen64cart.icns

echo "* Copying executable"
cp $INSTALL_PREFIX/bin/mupen64plus $APP_CONTENTS/MacOS/mupen64plus
#cp ./launcher $APP_CONTENTS/MacOS/launcher

echo "* Copying data files"
cp -r $INSTALL_PREFIX/share/mupen64plus/ $APP_CONTENTS/Resources/</nowiki>

You can then make this bundle distributable by blessing it with [http://macdylibbundler.sourceforge.net DylibBundler]. First install DylibBundler by following the instructions inside. Then run this small script :

<nowiki>
APP_CONTENTS="./Mupen64Plus.app/Contents"

FIX_LIST="-x $APP_CONTENTS/MacOS/mupen64plus \
-x $APP_CONTENTS/Resources/plugins/blight_input.so \
-x $APP_CONTENTS/Resources/plugins/dummyaudio.so \
-x $APP_CONTENTS/Resources/plugins/dummyvideo.so \
-x $APP_CONTENTS/Resources/plugins/glide64.so \
-x $APP_CONTENTS/Resources/plugins/glN64.so \
-x $APP_CONTENTS/Resources/plugins/jttl_audio.so \
-x $APP_CONTENTS/Resources/plugins/mupen64_hle_rsp_azimer.so \
-x $APP_CONTENTS/Resources/plugins/mupen64_input.so \
-x $APP_CONTENTS/Resources/plugins/ricevideo.so"

dylibbundler -od -b $FIX_LIST -d $APP_CONTENTS/libs/</nowiki>

Voila it's ready! Well actually, it should be in theory... In practice there is a bug on mac : when using both SDL and GTK+ at the same time, both grab the event loop and conflict with each other. The result of this is that ROMs cannot be launched from the GTK GUI, they can only be run in ''nogui'' mode. The GTK interface however still remains necessary to configure mupen. Until this issue gets fixed properly, I work around it by placing a second executable in the bundle called ''launcher'' (see the bundling script above, there is a commented out line that does this). This executable can then act as a bridge to either open the GTK GUI and configure mupen, either launch a ROM in nogui mode.

--> MacLauncher

With this launcher as main executable, you should finally have a distributable executable!

To be continued...

ReleasePage

2015-07-26T22:02:30Z

Richard42: Mupen64Plus Release Notes

<div class="toclimit-2">__TOC__</div>
===Mupen64Plus v2.5 - April 26, 2015===
====All Modules====
* Move from bitbucket (Mercurial) to GitHub
* Travis CI integration with GitHub for continuous automated build regression testing
* New: MS Visual Studio 2013 project files
* Finish integration with SDL2.0, and build against SDL2 by default
====Audio-SDL Plugin====
* Add audioresource support for integration with Linux-based Nemo Mobile OS
====Console-UI Front End Application====
* Update man page document
* Add application desktop file and icons
* New option: load savestate immediately on emulator startup
* Compile-time flag to support building ui-console as a library (used by Android frontend)
====Core Emulator Library====
* Game-specific fixes: Banjo Tooie, Zelda Ocarina of Time, DK64, Hydro Thunder, others
* Game-specific override for # of clock cycles per cpu instruction
* New Dynarec: Speed improvements, accuracy fixes, build support for MSVC
* Cheat fixes for WWF No Mercy, Bomberman Hero, Super Mario 64, and Pokemon Stadium (E)
* Major R4300 CPU core refactoring in many subsystems to improve code organization
* Rewrite speed limiter code to improve performance and audio synchronization
* Separate the logic of the Pure Interpreter from the Cached Interpreter
* Regression test improvements
* Support for building against OpenGL ES
* Build system improvements for ARM / Raspberry Pi
====Input-SDL Plugin====
* SDL2: use SDL1.2 keysyms in the mupen64plus.cfg file Input section for consistency
* SDL2: use prioritization to decide among multiple matching auto-config sections (for XInput)
* New auto-config sections for: Wiimote Classic, Wii U Gamecube / Pro, MS SideWinder GamePad Pro, 17 others
* When Mouse=True but pointer is un-grabbed, fall back to joystick settings for analog x/y
* New feature: prevent mouse/trackpad auto-centering behavior by pressing left-Windows key
====Video-Glide64mk2 Plugin====
* Fix colors in compressed fxt1 textures by importing mesa code
* Replace patented S3TC algorithm with compatible S2TC
* Enable the dump_cache to allow loading of dat files
* Bugfix: work around problem in OSD callback whereby core code doesn't re-activate shader
* Bugfix: Resident Evil II hang
* Allow user override of game-specific settings via mupen64plus.cfg
* New feature: option to enable full-scene antialiasing
* Code cleanup to remove dead section of code
* Add OpenGL ES support (2.0)
* Add config option to force polygon offset values (fixes artifacts on certains games / renderers)
* Fix broken C version of MulMatricesC
* New optional frameskip feature, which drops frames instead of rendering if game is going slow
* Fix texture pack read failure on some 64-bit platforms
* Correct N64 ROM header analysis for PAL/NTSC detection
* Bugfix: use memmove() instead of memcpy() for overlapping buffers
* Win32: don't set gamma table because it breaks monitor calibration
====Video-Rice Plugin====
* Game-specific hack-fix to show last heart and map arrows in Zelda OoT & MM.
* Lots of code cleanup, removal of deprecated code, and simplifications
* Modernize OpenGL interfaces, remove code for supporting old opengl versions
* Graphics fixes for: Fog, RDP InsertMatrix command
* Fix for INI file loading under Windows
* Minor OpenGL ES fixes
* Add config option to force polygon offset values (fixes artifacts on certains games / renderers)
* Bugfix: crash if RiceVideoLinux.ini not found
====RSP-HLE Plugin====
* Game-specific fixes: Bottom of the 9th, IndianaJones, BattleForNaboo, Conkers Bad Fur Day
* Support for MusyX microcodes
* Improve audio microcode identification
* Huge quantity of code cleanups and refactoring to improve organization
* Add support for additional audio commands: #16, POLEF, RESAMPLE_ZOH
* Multiple bugfixes in audio processing code
* Bugfix: microcode detection could sometimes fail after reset

===Mupen64Plus v2.0 - July 4, 2013===
====All Modules====
* New: MS Visual Studio 2012 project files
* Makefiles: support for ARM, PPC, and MINGW architectures
* Makefiles: support for cross-compiling (MXE win32 builds under Unix)
* Support (building from source) for new SDL 2.0 library
====Audio-SDL Plugin====
* Add support for resampling with speexdsp library
* Add more resampling quality options
* Bugfix: Don't assume OSS is installed in all linux systems.
* Make SDL volume handling the default, since OSS is no longer included in the kernel.
* Minor refactoring of volume handling code.
====Console-UI Front End Application====
* Only build system changes
====Core Emulator Library====
* Fixes for various games (DK64, Zelda, Blast Corps)
* Add Ari64's dynamic recompiler for x86 (32-bit) and ARM
* Improved PJ64 savestate loading
* Support video window resizing (with help from video plugin and front-end application)
* Auto-detect savestate type (!Mupen64Plus or PJ64) when loading from a slot
* Many various code cleanups in core from casualjames
* Debugger code cleanup
====Input-SDL Plugin====
* Re-write auto-configuration logic to be more user friendly. Add new 'mode' parameter.
* Support for 6 new joysticks
* Work-around for buggy xboxdrv which results in no rumble
* Bugfix: crash when rumble used with controller #4
====Video-Glide64mk2 Plugin====
* Brand new video plugin which has been ported to Mupen64Plus
====Video-Rice Plugin====
* Support for resizable video window
* Add support to build and run with OpenGL ES 2.0
* Improve hi-resolution texture loading support
* Fix texture CRC calculation for non-x86 (or NO_ASM) platforms
====RSP-HLE Plugin====
* Add support for MusyX ucode detection
* Support JPEG decoding used in Pokemon Stadium Japan
* Lots of refactoring to clean up code

===Mupen64Plus v1.99.5 - March 10, 2012===
====Audio-SDL Plugin====
* added version number to SDL-audio plugin config parameters, to support future changes
* updated audio plugin for new Mupen64plus 2.0 API versioning scheme
* makefile fixes and improvements
====Console-UI Front End Application====
* New option to disable internal core speed limiter (for benchmarking)
* Updated Console-UI front-end for new Mupen64plus 2.0 API versioning
* Added config version number for UI-Console section
* makefile fixes and improvements
====Core Emulator Library====
* New feature: support for N64 internal real-time clock
* use X-Scale's PIF-CIC algorithm instead of the hard-coded challenge-response pairs
* New config parameter for path to save SRAM/EEPROM/MPK files, so they can be separated from emulator snapshots
* updated core for new Mupen64plus 2.0 API versioning scheme
* split core configuration data into 2 sections: Core and CoreEvents. Added version numbers and upgrade handling to both
* Accurately emulate the RSP DMA operation (from Bobby Smiles)
* bugfix: #290 - OnScreenDisplay text is sometimes captured in screenshots
* bugfix: when the front-end specifies an override for the configuration directory, always use this path, so that we don't load the config from there and then save it back to the default user path
* bugfix: #468 - On-screen-display problem under OSX
* bugfix: Use option SaveStatePath from config file
* bugfix: don't call SDL_Quit() until the core library is being unloaded. fixes some front-end use cases
* bugfix: #410 - segfault in dma_pi_write()-->strlen() if /home/username/.local/share/mupen64plus/ owned by root
* bugfix: for Interpreter cores, use proper math functions for ceil/floor/round/trunc instead of x87 rounding modes
* many makefile fixes and improvements
====Input-SDL Plugin====
* Improved input setup behavior (auto-config) to make some use cases more friendly
* Updated input plugin for new Mupen64plus 2.0 API versioning scheme
* Added version number to SDL Input plugin parameters
* Add new parameter for mouse sensitivity, handle mouse movement differently so mouse is easier to use as controller
* New auto-configuration for controllers:
** raphnet technologies GC/N64 usb converter
** Logitech Chillstream Controller
** Jess Tech Colour Rumble
** Xbox 360 linux userspace driver
** Generic X-Box pad
** Saitek P2900 Wireless Pad
** Jess Tech USB 4-Axis 12-Button Gamepad
* bugfix: #392 - when switching between rumble pak and memory pak, simulate removing the pack, waiting 1 second, then inserting the new one
* bugfix: #424 - problem with USB devices supporting multiple controllers per device
* bugfix: #409 - PS3 controller not auto-detected in Gentoo when connected via bluetooth
* bugfix: correctly handle USB devices with multiple game pads, from Peter Helbing
* makefile fixes and improvements
====Rice Video Plugin====
* Hires texture loading: support for 8-bit PNG images
* New config option for forcing vertical sync
* Check OpenGL attributes after creating video window and report any that failed to set
* Updated video plugin for new Mupen64plus 2.0 API versioning scheme
* Update to Video API version 2.1.0.
* Bugfix: hi-res textures: Scale highres textures by precalculated scaleShift exponent
* Bugfix: dont call CoreVideo_Init() inside of the InitializeGFX() function. This will fix some front-end use cases
* Bugfix: Fix z coordinate in 3d line rendering
* Bugfix: double infinite loop in GetValidTmemInfoIndex
* Bugfix: Perfect Dark randomly crashes due to divide-by-zero error
* Bugfix: crash in loading Celda 2009 hi-res texture pack for Zelda Ocarina of Time
* makefile fixes, improvements, and code cleanups
====RSP-HLE Plugin====
* Handle JPEG decompression, used in Ogre Battle 64 and Pokemon Stadium
* updated RSP plugin for new Mupen64plus 2.0 API versioning scheme
* bugfix: #102 - Missing backgrounds in Ogre Battle 64
* many makefile fixes and improvements

===Mupen64Plus v1.99.4 - November 22, 2010===
====Console-UI Front End Application====
* add some parameter checking for --emumode option
* new cheat file format from spinout182
* makefile fixes and improvements
====Core Emulator Library====
* Added some type checking to ConfigGetParameter() function, and a new error type
* Bugfix: avoid segfault in the video extension code if SDL initialization fails (because video plugin fails)
* Added new CoreGetRomSettings() function for front-ends
* Allow to run dynarec in hardware DEP protected windows
* Allow core .cfg parser to accept strings without quotes around them
* API change: use new ReadScreen2() video plugin function
* New re-entrant R4300 disassembler, from tty68k/zzt32, a man who loves MIPS processors
* makefile fixes and improvements, code cleanups
====Audio-SDL Plugin====
* Bugfix: Plugin should write default config values at startup time
* Bugfix: fixed fast-forward for banjo-kazooie and other games which was broken due to limitation in basic resampling algorithm
* makefile fixes and improvements
====Input-SDL Plugin====
* Bugfix: Do configuration during PluginStart(), so GUI will see defaults (auto-configured) the first time it is run
* Move axis value reducers to right shift and right ctrl, to avoid conflict with A/B buttons
* New feature: extra deadzone parameter in axis() config parameter clause when mapping an analog joystick axis to an N64 button
* many new joystick auto-configurations
* makefile fixes and improvements
====Rice Video Plugin====
* new feature: anisotropic filtering
* new feature: trilinear filtering
* new feature: mipmaps
* cleaned up FindScaleFactor function based upon r45 of the 1964 repo
* bugfix: buffer overrun (and crash) when reading vendor string info on some opengl implementations
* API change for reading the video buffer: new interface is more flexible and avoids some potential problems
* support for anti-aliasing (GL_MULTISAMPLE)
* makefile fixes, improvements, and code cleanups
====RSP-HLE Plugin====
* merged all big-endian fixes from mupen64gc project
* makefile fixes and improvements

===Mupen64Plus v1.99.3 - February 13, 2010===
====Console-UI Front End Application====
* New feature: command-line option --set for setting arbitrary configuration variables
* updated MAN page for all the changes made in the 2.0 re-architecture
====Core Emulator Library====
* New feature: configuration function ConfigGetParameterType()
* New feature: up to 1000 screenshots per ROM are allowed
* New feature: support for Gameshark 3.3 patch codes
* Bugfix: Use Dynarec by default when core supports it. If dynarec is selected but unavailable, fall back to cached interpreter
* Bugfix: screenshot directory handling code used unix-specific path separators; now is platform-independent
* Bugfix: #313 - 64-bit inline assembly code in r4300/x86_64/rjump.c needs to have underscores before the symbols names in OSX
* Bugfix: old bug in the core - hang if a ROM '''without''' a 16kb EEPROM type is loaded after a ROM '''with''' a 16kb EEPROM type
* Bugfix: rumble feature caused memory corruption
* Bugfix: Problem with zilmar API: the plugin RomOpen() functions had no way of returning errors to the core, causing crashes
* Replaced api documentation .tar.gz file with the mediawiki text
* Build script improvements:
* new feature: m64p_update.sh script can take an input argument to update to a tag or revision
* new feature: added bash script for building source packages of individual modules
====Audio-SDL Plugin====
* sync with core/plugin API change for RomOpen()
* bugfix: logical error in previous audio refactoring causing slowdown/lockup on loading savestate or re-initializing audio
====Input-SDL Plugin====
* New feature: auto-configuration uses an .ini file instead of hard-coding the controllers in the source code
* New controller auto-configurations:
* Original X-Box (and compatible clones)
* HuiJia USB GamePad
* USB Human(2p) Interface Device
* sync with core/plugin API change for RomOpen()
* Bugfix: controller pak was fixed at startup, switching b/w mempak and rumblepak did not work
* Bugfix: Xbox 360 and PS3 controllers need slightly different names under OSX
====Rice Video Plugin====
* sync with core/plugin API change for RomOpen()
* Changed default ScreenUpdateSetting to 1 for Linux, and 4 for Windows
* use custom opengl extension function pointer typedefs, to avoid compilation errors with some drivers including hosed gl.h headers
* merged some changes from Tillin9 commits in r1142-rice-video-gtk-refactor branch, to be more lenient in hi-res texture loading
* bugfix: hi-res textures did not work in Windows
* bugfix: #329: remove some deprecated types and a function call to prevent build errors with libpng 1.4
* bugfix: fixed mirroring bugs in Rice Video hi-resolution texture loading, based on Tillin9 rev 1337 in r1142-rice-video-gtk-refactor branch
* bugfix: in ConvertImage.cpp none of the 4-bit conversion functions could handle 1-pixel wide textures

===Mupen64Plus v1.99.2 - January 6, 2010===
====Console-UI Front End Application====
* new feature: added MSVC8 project/solution files, minor refactoring for VC compatibility
====Core Emulator Library====
* doc: added tarball of emuwiki api documentation from 2010-01-06 for backup purposes
* clean-up: removed almost all of the ifdef WIN32 statements
* bugfix: stop spamming console with "Core: couldn't open memory pack file '...' for reading" messages
* bugfix: stop spamming console with "Core: couldn't open eeprom file '...' for reading" messages
* new feature: MSVC8 project file for mupen64plus-core, refactored code for VC8 compatibility
====Audio-SDL Plugin====
* new feature: Completely re-wrote buffering/synchronization code:
* Buffer parameters now work as advertised and all use the same units
* Bugfix: previous defaults and algorithm behavior caused audio choppiness on slower PCs
* Bugfix: maximum speed was previously limited to low value by constraints from primary buffer size
* bugfix: SDL volume control will always be used on systems without OSS support
* new feature: added MSVC8 project file, minor code refactoring to build in Windows
====Input-SDL Plugin====
* new feature: added MSVC8 project file, minor code refactoring for VC compatibility
* added auto-configuration for:
* Xbox 360 Wireless Receiver
* PS3 controller
* Jess Tech Dual Analog Pad
====RSP-HLE Plugin====
* New feature: added MSVC8 project file for RSP-HLE plugin, fixed a few minor incompatibilities
====Rice Video Plugin====
* bugfix: fix fragment program combiner for Intel drivers in Win32, by ensuring that program does not allocate unused temp vars or call TEX commands for texture units that are not enabled
* new feature: compile-time option for opengl debugging by calling glGetError after each opengl command (except inside of glBegin/glEnd)
* portability: use ALIGN() for aligned data member declarations in header files as well as the definitions in CPP files
* portability: refactor opengl code to use <code>VidExt_GL_GetProc()</code> for all opengl functions newer than v1.1, so that this will work in Windows
* portability: Abstracted directory-handling code with new <code>osal_files</code> source code
* portability: replaced unix <code>gettimeofday()</code> function calls with <code>SDL_GetTicks()</code>
* new feature: added MSVC8 project file, fixed minor incompatibilities with VC compiler

===Mupen64Plus v1.99.1 - December 14, 2009===
====Console-UI Front End Application====
* Brand new Console-based front-end for Mupen64Plus 2.0
* New feature: R4300 Core Comparison for debugging
* New feature: Cheat code support from command-line
====Core Emulator Library====
New 2.0 architecture advantages:
* Simplified emulator Core, making it much more portable
* Removed all GUI code from plugins, making them simpler and more portable
* User interface development is not tied to Core emulator releases
* All messages from core/plugins can be filtered and shown in GUI instead of only on console
* Video Extension allows Front-end to override some video functions, ie to support embedded render window
* Startup in Fullscreen mode, instead of always starting in windowed mode and switching to FS after few seconds
* video resolution can be given via command-line parameter
* all configuration options for core and plugins are in a single config file, can be configured with a single GUI
* dummy plugins are automatically used if plugin loading fails for any reason
* core and plugins all use the same conventions for where to put data/config files
Mupen64Plus core:
* New feature: cheat code support
* New feature: Keyboard shortcuts for Core commands are now user-configurable
* New feature: can load/save PJ64 state files
* Major code cleanup, refactored build system to separate source and object files
* Removed many dependencies to simplify porting to other platforms
* Moved all of the SDL event-related stuff into a new source file eventloop.c
* Use XDG directory convention for file locations on Unix
* bugfix: frame advance feature should advance every frame, instead of every vertical interrupt (every field)
* bugfix: allow diagonal hat movements for core joystick commands
* bugfix: modified SDL event loop joystick code so that gameshark button press is captured, and joystick commands that are level-triggered instead of edge-triggered (such as fast foward) can be accommodated
* bugfix: fixed the outstanding SDL event issues by re-writing the code which handles the joystick-event-driven core commands. Now the axis-based commands use hysteresis and there is a single global event function for determining if the gameshark button is pressed
* bugfix: OSD crash after pause-stop-start-pause of emulator
* bugfix: Set video width and status, aiDacrate during savestate load
* bugfix: in pure interpreter, Dont allow to override r0 register
* bugfix #52: PJ64 load state patch from olejl77
* bugfix #268: use aligned malloc and mprotect to set executable status for dynarec emitted code
* bugfix #51: Floating Point Register data was not correctly converted when switching between 32-bit (MIPS-I) mode and 64-bit (MIPS III). New code more closely emulates behavior of r4300 hardware. Fixes collision problems in Banjo-Tooie
* bugfix #272: rounding mode for x86 FPU not being set correctly in interpreter and pure interpreter cores
* bugfix: many games need different ScreenUpdateSetting to work properly with Rice Video
====Audio-SDL Plugin====
* Converted to new Mupen64Plus 2.0 API
* Code cleanup to remove non-standard data types
* Refactored build system to separate source and object files
* bugfix #269: jttl_audio segfaults on exit due to incorrectly ordered shutdown code
====Input-SDL Plugin====
* New feature: Joystick/Keyboard auto-configuration
* New feature: deadzone and peak analog joystick values are now configurable
* Converted to new Mupen64Plus 2.0 API
* Refactored build system to separate source and object files
* Major code cleanup: mouse movement and analog axis code was terrible, removed non-standard data types
* Improved debug messages
* bugfix: mapping the X/Y analog sticks to keypresses didnt work
* bugfix: LeftCtrl-!LeftAlt key command when mouse is enabled to now toggles between grabbing and releasing the mouse pointer
====RSP-HLE Plugin====
* Converted to new Mupen64Plus 2.0 API
* Refactored build system to separate source and object files
* Refactored all code to remove win32-specific things, unnecessary functions, and clean up
====Rice Video Plugin====
* Converted to new Mupen64Plus 2.0 API
* Major code cleanup, removed all non-standard data types
* Refactored build system to separate source and object files
* added NO_ASM build option
* removed some unused configuration parameters
* bugfix: handle fullscreen video mode properly: start up in this mode instead of always starting in windowed and needing the core to switch to fullscreen
* bugfix #209: setjmp/longjmp fixes in the BMP writer and PNG reader
* bugfix: eliminated duplicate 'Found ROM ...' messages

===Mupen64Plus v1.5 - January 4th, 2009===
====Major New Features====
* Support for Macintosh OSX platform with Intel CPUs
* Qt4 GUI by slougi, Tillin9, and others
* Rom Cache System (r636, others), by Tillin9, Okaygo, and Hasone.
====Minor New Features====
* r1235: Debugger: memory breakpoint speedup
* r1170-1178,1181: QT GUI: translations for English, Norwegian, German, and Dutch
* r1155: Use configurable key commands for special emulator functions
* r1134: got our own custom test ROM, courtesy of Marshallh
* r1046: debugger: new r4300 disassembler from ZZT32
* r829: jttl_audio: added GTK GUI configuration dialog
* r793: soft reset (hit F9)
* r782: jttl_audio: both SDL-based and OSS-based volume control methods are now supported
* r765: added savestate conversion tool to be able to load pre-v1.5 savestate files
* r711: 7-zip support
* r692: Multi-file Zip support
* r667: GTK GUI: user-configurable columns in ROM browser
* r659: LZMA archive support
* r638: BZip2 archive support
* r629,634: LIRC - added support for speedup, slowdown, pause, and frame advance
====Updates====
* r1007,1032: GTK GUI improvements
* r970, 1019: use SDL threading support instead of pthreads
* r935,938,940: Gtk GUI updates for core and Jttl
* r642,655-657,663,664,747,759,761-763,768-770,774,775,780,781,783,786,787,825,828,931: mupen64plus.ini updates: Good Names, stars, EEPROM types, players, rumble support
====Bugfixes====
* r1247: rsp_hle: memory overwrite bug with Zelda:OOT
* r1234: out of bound array bug in memory access function handlers
* r1222,1223,1228,1229: Debugger fixes
* r1183: Blight Input: sometimes the axis direction would flip
* r1133: Added stop rumble to load savestate, fixes issue 165
* r1077: GTK GUI bugfixes
* r1063: rice video: crash in MMX/SSE checking functions
* r800: logical error in strcpy loop in util.c
* r798: small bugfixes in blight_input: 1. only save config file after running config dialog, not every time DLL is closed. 2. If rumble is not available on a controller, don't allow user to switch between rumble and mempack. 3. If rumble is selected in config file but not available on a controller, select mempack instead.
* r789: 3 glN64 bugfixes (segfaults on a 64-bit system in Perfect Dark): prevent clamp values from being negative, handle TMEM wrap-arounds from wacky height/line values in texture cache load and texture CRC functions
* r788: rice video: add checks for uint32 height/width parameters which can be negative, causing segfault on 64-bit systems
* r784: 64-bit problem causing GUI crashes - gotta save/restore all the callee-saved registers around the dynarec
* r758: fixed some savestate problems
* r748: Fixed 64-bit dynarec crash in genj_idle() and genjal_idle()
* r715: Bugfixes thanks to Valgrind. Two using strcpy with source and destination overlay, i.e. strcpy(p,p+1)
* r700: set ScreenUpdateSetting=1 in rice video ini file for Conkers BFD
* r694: require bash shell scripting for install.sh
* r686: fixed OSD crash bug after running a game, disabling OSD, then running another game
* r684: OGLFT measuring functions were taking a huge chunk of CPU time. Refactored code to measure only once and store the line size and the message sizes instead of re-measuring all the time. This eliminated nearly all of the OSD overhead on my PC
* r681: Refactored OGLFT to do color setting outside of glyph compiling, so the OSD fading doesnt force bitmaps to be continually recreated with calls to renderGlyph. Seems to have cut the excessive cpu usage of the OSD about by half
* r680: removed many unused classes from OGLFT font library code
* r676: bugfix in my BYTESWAP macros
* r674: Removed glide64/Tmem_nasm.asm source file and the project dependency on nasm/yasm assemblers
* r673: removed inline assembly sections in rdp_loadblock and rdp_loadtile, including their dependency on functions in Tmem_nasm.asm. Replaced with new C code. This fixes a segfault on some 64-bit source builds
* r669: string function causing crash on 64-bit linux
* r667: issue #88 - added basic view menu in GTK GUI
* r628,633: Small patch to get glide64.so to compile with O3 optimizations
* r622: Fixed segfault in Glide64 as per issue 113
* r619: fix LIRC build to integrate w/ new screenshot mechanism
* r608: another couple of memory leak fixes from Tub, in main/config.c
* r605: fix from Tub for free() bug in main/util.c/list_delete()
* r587: issue #111: close screenshot file after saving

===Mupen64Plus v1.4 - June 14, 2008===
* New feature: graphical debugger for R4300 core
* New feature: On Screen Display
* New feature: KDE4 GUI (experimental)
* New feature: cheat system with Gameshark codes
* New feature: search/filter box in GTK GUI
* New feature: single frame advance
* New feature: adjust emulator playback speed up or down in 5% increments
* New feature: Rumble Pak support with force feedback
* New feature: Map emulator functions (fullscreen, stop emulation, etc) to joystick buttons or axis movements.
* New feature: Volume up/down
* Blight Input: Individually configure each direction of X and Y axis, which allows inverting the axis
* JTTL_Audio: libsamplerate support for high quality audio resampling
* GTK GUI: Removed second status bar which was not used
* GTK GUI: Implemented accelerator keys
* GTK GUI: Replaced custom directory browser with GTK file chooser
* GTK GUI: numerous small changes and fixes
* Added Mupen64Plus 'man' (manual) page
* Removed mupen64_audio plugin, as it was unnecessary and mostly broken
* Added NoMemoryExpansion parameter to emulate 4MB console; fixes some games
* Overhaul of rom handling functions; numerous small fixes
* Bugfix: Removed NoAudioDelay core option to resolve issue #48
* Bugfix: check for stopped state in dynarec jump function, to fix unresponsive emulator when game gets stuck in loop
* Bugfix: GTK GUI: #6 - if a ROM is selected in the ROM browser and 'play' is pressed, emulation will start
* Bugfix: GTK GUI: #62 - ROM browser column sorting works
* Bugfix: Rice Video: Support hi-res textures with different scale factors for X and Y
* Bugfix: Blight Input: don't use 100% CPU in configuration dialog

----------------------------------------

===Mupen64Plus v1.3 - March 29th, 2008===
* New feature: Glide64 video plugin for 32-bit and 64-bit, renamed project Mupen64Plus
* New feature: Combine mupen64 and mupen64_nogui into a single binary
* New feature: ability to change icon size
* New feature: support different directories for install (plugins, icons, etc) and config (save games, config files)
* New feature: support for creating/using ~/.mupen64plus dir for storing user data
* New feature: support for installation via "make install" or "./install.sh"
* New feature: support for plugins given via command line option in GUI mode
* New feature: config dialog checkbox to toggle "noask" setting
* New feauter: pause/continue functionality with LIRC
* Removed messagebox utility and replaced it with cleaner alert_message/confirm_message calls
* GTK GUI: Set parent window for all popups so WM will center popup windows over the main gui window
* Added README file with information about usage of Mupen64Plus and plugins
* Removed mupen64_soft_gfx, as it didn't work
* Removed Win32 code from RSP HLE plugin,
* Change fullscreen hotkey to Alt+Enter
* Only plugin filenames (not paths) are stored in the mupen64plus.conf file
* Modified pre.mk and glide64 makefile to auto-select yasm or nasm
* Bugfix: Rice Video: Make configuration during gameplay possible again
* Bugfix: many compiler warnings and errors in Glide64
* Bugfix: segfault in Goldeneye and Perfect Dark for 64-bit dynarec
* Bugfix: 64-bit dynarec bug in genld()
* Bugfix: buffer overflow allocating temp strings for basename/dirname
* Bugfix: GTK GUI: Exiting via File -> Exit wasn't writing out config file to disk
* Bugfix: GTK GUI: "About" menu does not pop up while emulation is running
* Bugfix: Glide64: Refactored a bunch of inline asm code with potential bugs
* Bugfix: Added plugin error checking before emulator is started
* Bugfix: Logo not loading in "about" window
* Bugfix: Segfault in plugin_scan_directory()
* Bugfix: ROM pause/continue while playing
* Bugfix: Too many dialog windows when loading a bad dump or hacked rom
* Bugfix: Closing emulation window now stops emulator
* Bugfix: Rice Video: config dialog bug, now it displays proper resolution
* Bugfix: GTK GUI: "Toolbar Style" now works
* Bugfix: Glide64: changed inline asm label syntax, for compatibility with gcc 4.3.0
* Bugfix: Many other minor bug fixes, GTK warnings fixes, translation corrections, etc

----------------------------------------

===Mupen64-amd64 v1.2 - February 10th, 2008===
* New feature: Dynamic Recompiler for 64-bit
* New feature: New ROM Browser for Mupen64 GUI build
* New feature: LIRC remote control integration for NOGUI build
* Added r4300 instruction counting capability to 64-bit Dynarec
* Added r4300 profile data output for 32-bit and 64-bit dynamic recompilers
* TLB Optimization / bugfix
* Revised makefiles to support PPC builds
* Bugfix: memory leaks in mupenIniApi.c
* Bugfix: corrupted filenames being saved to disk for mupen64.ini
* Bugfix: crash in jttl_audio
* Bugfix: crash when running game from gui after first time
* Bugfix: spurious noise blip when running game from gui after first time

----------------------------------------

===Mupen64-amd64 v1.1 - December 9th, 2007===
* New icons for GTK GUI
* Removed GTK 1.2 GUI build; GTK 2.0 is required now
* Added file pointer checking for frwite() calls and error logging
* Added scrolling to the the rom list widget
* Added main/version.h file to store Mupen64-amd64 package version
* Print joystick numbers along with names in blight input to tell multiple devices apart
* Merged okaygo's TLB hack for Goldeneye from Mupen64++
* Rework GTK GUI config dialog; fixed bugs in ROM directory list
* Bugfix: segfault from playing same game twice in a row from GUI
* Bugfix: segfault from fwrite() failure in dma_pi_read in memory/dma.c
* Bugfix: exit properly instead of segfault after dyna_stop is called
* Bugfix: blight input: <code>SDL_PumpEvents</code> must be called from thread which initialized SDL video mode
* Bugfix: blight_input: joystick handling caused glitch in config dialog
* Bugfix: makefile: 32-bit CFLAGS must be used when doing 32-bit build on 64-bit machine
* Bugfix: Added makefile to root folder for building releases

----------------------------------------

===Mupen64-amd64 v1.0 - November 12th, 2007===
* Forked from Mupen64 v0.5
* Ported to 64-bit architecture by NMN/!SirRichard42
* Fixed texture cache problem in glN64
* Print more information during plugin loading process
* Added blight input config file for logitech dual-action style controllers
* Added SDL_GL_SWAP_CONTROL attribute in glN64 to prevent tearing
* Changed glVoids to voids due to strange compilation bug that occurs on certain systems
* Totally refactored makefiles; now plugins are built as sub-modules
* Better logging for r4300 core selection, disallow Dynamic Recompilation for 64-bit builds at compile time
* Set execstack attribute for all mupen64 binaries, to prevent segfault when Dynamic Recompilation is used
* Lots of code cleanup
* Removed 'multi-user' mode of operation
* Removed 'configure' script and config.h file
* Refactored plugin loading code in '''nogui''' build, much more user-friendly now
* Added comments and SDL shutdown code to main.c
* Bugfix: fixed memory leaks in plugin.c
* Bugfix: strcpy in main/gui_gtk/config.c should not copy overlapping strings
* Bugfix: blight audio: only close down audio and timer sub-systems when exiting

MediaWiki:Common.css

2015-07-26T22:00:24Z

Richard42: Created page with "/* CSS placed here will be applied to all skins */ /* * Allow limiting of which header levels are shown in a TOC; * <div class="toclimit-3">, for instance, will limit to *..."

/* CSS placed here will be applied to all skins */
/*
* Allow limiting of which header levels are shown in a TOC;
* <div class="toclimit-3">, for instance, will limit to
* showing ==headings== and ===headings=== but no further.
* Used in [[Template:TOC]]
*/
.toclimit-2 .toclevel-1 ul,
.toclimit-3 .toclevel-2 ul,
.toclimit-4 .toclevel-3 ul,
.toclimit-5 .toclevel-4 ul,
.toclimit-6 .toclevel-5 ul,
.toclimit-7 .toclevel-6 ul {
display: none;
}

README

2015-07-26T21:48:42Z

Richard42: How to build, install, and use Mupen64Plus

This README document reflects the instructions for using the latest Mupen64Plus code, which may be unreleased, so if you are using a released version of Mupen64Plus, the most accurate instructions are in the README file included with your release package.

Mupen64Plus is based off of mupen64, originally created by Hacktarux. The Mupen64Plus package contains the mupen64 emulator program (renamed mupen64plus) plus graphics, sound, input, and RSP plugins.

===Requirements and Pre-requisites===

'''Binary Package Requirements'''
* GTK2 libraries (currently hard plugin dependence even with GUI=NONE)
* SDL 1.2
* SDL_ttf
* libpng
* freetype 2
* zlib

'''Source Build Requirements'''

In addition to the binary libraries, the following packages are required if you build Mupen64Plus from source:

* GNU C and C++ compiler, libraries, and headers
* GNU make
* Development packages for all the libraries above

Most of these pre-requisites are installed by default, but some are more uncommon. Here is an example for adding the 'SDL_ttf' development packages on Fedora systems:
<nowiki>
# yum install SDL_ttf SDL_ttf-devel</nowiki>
And on Debian systems:
<nowiki>
# apt-get install libsdl-ttf2.0-0 libsdl-ttf2.0-dev</nowiki>

There are also a number of packages required for specific options:

* libsamplerate (aka Secret Rabbit Code for higher quality audio)
* binutils-dev (dis-asm.h for debugger)
* Qt4 libraries and headers (for Qt4 GUI)

===Building From Source===

If you downloaded the binary distribution of Mupen64Plus, skip to the Installation section. Otherwise, you will need both the libraries and development packages (header files) for the prerequisites listed above.

Once you have all prerequisites installed, you can build the source distribution by unzipping and cd'ing into the source directory, then build using make:

<nowiki>
$ unzip Mupen64Plus-x-y-z-src.zip
$ cd Mupen64Plus-x-y-z-src
$ make all</nowiki>
Type 'make' by itself to view all available build options:
<nowiki>
$ make
Mupen64Plus makefile.
Targets:
all == Build Mupen64Plus and all plugins
clean == remove object files
rebuild == clean and re-build all
install == Install Mupen64Plus and all plugins
uninstall == Uninstall Mupen64Plus and all plugins
Options:
BITS=32 == build 32-bit binaries on 64-bit machine
VCR=1 == enable video recording
LIRC=1 == enable LIRC support
NO_RESAMP=1 == disable libsamplerate support in jttl_audio
NO_ASM=1 == build without assembly (no dynamic recompiler or MMX/SSE code)
GUI=NONE == build without GUI support
GUI=GTK2 == build with GTK2 GUI support (default)
GUI=QT4 == build with QT4 GUI support
Install Options:
PREFIX=path == install/uninstall prefix (default: /usr/local/)
SHAREDIR=path == path to install shared data (default: PREFIX/share/mupen64plus/)
BINDIR=path == path to install mupen64plus binary (default: PREFIX/bin/)
LIBDIR=path == path to install plugin libs (default: SHAREDIR/plugins/)
MANDIR=path == path to install manual files (default: PREFIX/man/man1/)
Debugging Options:
PROFILE=1 == build gprof instrumentation into binaries for profiling
DBGSYM=1 == add debugging symbols to binaries
DBG=1 == build graphical debugger
DBG_CORE=1 == print debugging info in r4300 core
DBG_COUNT=1 == print R4300 instruction count totals (64-bit dynarec only)
DBG_COMPARE=1 == enable core-synchronized r4300 debugging
DBG_PROFILE=1 == dump profiling data for r4300 dynarec to data file</nowiki>

NOTE: If you want to build a nogui-only version of the Mupen64Plus core (without gtk+ dependencies), pass the GUI=NONE option to make, like this:
<nowiki>
$ make GUI=NONE all</nowiki>

===Installation===

'''Binary Distribution'''

To install the binary distribution of Mupen64Plus, su to root and run the provided install.sh script:
<nowiki>
$ su
# ./install.sh
# exit
$</nowiki>
The install script will copy the executable to /usr/local/bin and a directory called /usr/local/share/mupen64plus will be created to hold plugins and other files used by mupen64plus.

'''Source Distribution'''

After building mupen64plus and all plugins, su to root and type 'make install' to install Mupen64Plus. The install process will copy the executable to $PREFIX/bin and a directory called $PREFIX/share/mupen64plus will be created to hold plugins and other files used by mupen64plus. By default, PREFIX is set to /usr/local. This can be changed by passing the PREFIX option to 'make' during the installation. For example, to install mupen64plus to /usr, do this:
<nowiki>
$ make all
$ su
# make PREFIX=/usr install
# exit
$</nowiki>

'''Custom Installation Paths'''

You may customize the installation of the Mupen64Plus program by using the options for the install.sh script:

<nowiki>
usage: install.sh [PREFIX] [SHAREDIR] [BINDIR] [LIBDIR] [MANDIR]
PREFIX - installation directories prefix (default: /usr/local)
SHAREDIR - path to Mupen64Plus shared data files (default: $PREFIX/share/mupen64plus)
BINDIR - path to Mupen64Plus binary program files (default: $PREFIX/bin)
LIBDIR - path to Mupen64Plus plugin files (default: $SHAREDIR/plugins)
MANDIR - path to manual files (default: $PREFIX/man/man1)</nowiki>

You must pass the same options to the uninstall.sh script when uninstalling in order to remove all of the Mupen64Plus files.

You should install the Mupen64Plus plugins (libraries) in their own folder. If you install them in a common directory such as /usr/lib and then later uninstall them with "sudo uninstall.sh LIBDIR=/usr/lib", it will delete all system libraries.

If you install with SHAREDIR in a place other than /usr/local/share/mupen64plus or /usr/share/mupen64plus, and BINDIR is not the same as SHAREDIR, then users will have to run Mupen64Plus with the --installdir= option, otherwise they will get an error. The mupen64plus executable looks in up to 5 different directories in order to find the Shared Data Directory. The order in which the directories are searched is:

# directory specified on command line with --installdir
# same directory as the mupen64plus binary
# /usr/local/share/mupen64plus
# /usr/share/mupen64plus
# current working directory

If you choose to install the plugins in a non-standard location (someplace other than $SHAREDIR/plugins), then you must set the PluginDirectory parameter in the mupen64plus.conf config file to the directory path in which the plugins have been installed.

===Multi-user Support===

As of version 1.3, Mupen64Plus now has support for multi-user environments.

The mupen64plus program will look for user configuration files in a .mupen64plus directory in the user's home directory. If the directory does not exist, it will be created and a default mupen64plus.conf file will be written to that directory. If desired, an alternate config directory can be specified using the --configdir commandline option.

By default, the mupen64plus program will look for plugins, icons, and language translation files in the install directory $PREFIX/share/mupen64plus (see Installation section for details). If this directory does not exist, mupen64plus will try to use the current working directory. An alternate installation directory can be specified using the --installdir commandline option.

Run 'mupen64plus --help' for a complete list of commandline options:
<nowiki>
$ mupen64plus --help
Usage: mupen64plus [parameter(s)] rom

Parameters:
--nogui : do not display GUI
--fullscreen : turn fullscreen mode on
--noosd : disable onscreen display.
--gfx (path) : use gfx plugin given by (path)
--audio (path) : use audio plugin given by (path)
--input (path) : use input plugin given by (path)
--rsp (path) : use rsp plugin given by (path)
--emumode (number) : set emu mode to: 0=Interpreter 1=DynaRec 2=Pure Interpreter
--sshotdir (dir) : set screenshot directory to (dir)
--configdir (dir) : force config dir (must contain mupen64plus.conf)
--installdir (dir) : force install dir (place to look for plugins, icons, lang, etc)
--noask : dont ask to force load on bad dumps
--testshots (list) : take screenshots at frames given in comma-separated list, then quit
-h, --help : see this help message</nowiki>

===Key Commands In Emulator===

The keys or joystick/mouse inputs which will be mapped to the N64 controller for playing the games are determined by the input plugin. The emulator core also supports several key commands, which are fixed and cannot be changed. They are:

{| class="wikitable"
|-
|'''Key''' || '''Description'''
|-
|Escape || Quit the emulator
|-
|0-9 || Select virtual 'slot' for save/load state (F5 and F7) commands
|-
|F5 || Save emulator state
|-
|F7 || Load emulator state
|-
|F9 || Reset emulator
|-
|F10 || slow down emulator by 5%
|-
|F11 || speed up emulator by 5%
|-
|F12 || take screenshot
|-
|Alt-Enter || Toggle between windowed and fullscreen
|-
|p or P || Pause on/off
|-
|m or M || Mute/unmute sound
|-
|g or G || Press "Game Shark" button (only if cheats are enabled)
|-
|/ or ? || single frame advance while paused
|-
|F || Fast Forward (playback at 250% normal speed while F key is pressed)
|-
|[ || Decrease volume
|-
|] || Increase volume
|}

===Default Key Mappings for SDL-Input Plugin===

The keys or joystick/mouse inputs which will be mapped to the N64 controller for playing the games are determined by the input plugin. The SDL-Input plugin contains an auto-configuration function which will provide default joystick mappings for any recognized joystick. If there is no supported joystick connected, the input plugin will enable a default keyboard control mapping, as given below:

{| class="wikitable"
|-
|'''N64 Controller Action''' || '''Keys'''
|-
|Analog Pad || Arrow Keys (left, right, down, up)
|-
|C Up/Left/Down/Right || "I", "J", "K", "L"
|-
|DPad Up/Left/Down/Right || "W", "A", "S", "D"
|-
|Z trigger || "z"
|-
|Left trigger || "x"
|-
|Right trigger || "c"
|-
|Start || "Enter" ("Return")
|-
|A button || "left shift"
|-
|B button || "left control"
|-
|Select Mempack || ","
|-
|Select Rumblepack || "."
|}

===Known Issues===

As of March 2008, the RiceVideoLinux plugin causes artifacts when fog is enabled in most games with the open source drivers for ATI Radeon graphics adapters. If you are using the open source Radeon driver, you should set the "!EnableFog" value in RiceVideo.cfg to 0.

When using RiceVideoLinux, there are quite a few games which show an artifact whereby some or all of the polygons on the screen will disappear every few frames, revealing the underlying background color. This problem is usually caused by the wrong screen update setting. If you edit the ini file at: ~/.mupen64plus/RiceVideoLinux.ini, search for the section with the game's name, and add "ScreenUpdateSetting=1" to the bottom. This usually fixes the flashing artifacts. Please file an issue report here with the game's name and MD5 hash value if you find a game which exhibits this problem and works correctly after the .ini file update.

Mupen64Plus

2015-07-26T21:44:11Z

Richard42: Background Information About Mupen64Plus

== Introduction ==

'''Mupen64Plus''', Originally '''Mupen64-64bit''', created by Richard42, is a fork of '''Mupen64''', An N64 emulator created by Hacktarux. '''Mupen64-64bit''' was started sometime after the first release of a quick attempt to port '''Mupen64''' to x86_64/AMD64/EM64T was released.

'''Mupen64Plus''' is Open Source, as it is required as a derivative of the GPLv2 software, '''Mupen64''' . All source code to all plug-ins are redistributed under the license they were originally redistributed under. The latest snapshot of source is publicly available via offsite SVN under a special user (Who's information is listed on the Project Homepage.)

== History ==

On October 10th, 2007, A branch off of '''Mupen64''' was presented to the public as '''Mupen 64bit''' [[http://emutalk.net/showthread.php?t=42243 Go→]]. First released by nmn, it contained a buggy version of glN64, JTTL's Audio Plug-in, A broken release of Blight's SDL Input plug-in, And the original ''''r4300'''' emulation minus dynamic recompiling. (No attempt to port it was made as of the original release) On October 14th, 2007, Richard42 had decided to help on the project. On October 21st, 2007, the original port was finally dumped and the project gained a new name, '''Mupen64-64bit'''. Essentially, It was a new project, being started from the vanilla Mupen64 0.5 source code.

'''Mupen64-64bit''' was soon renamed '''Mupen64-amd64'''. During this next period many of the fork's most important achievements were made. A Dynamic Recompiler was developed, Many of the largest bugs were fixed, and the emulator's GUI was renovated.

After a while, it became clear that the name '''Mupen64-amd64''' was giving the impression that the emulator did not support 32-bit Intel x86 processors. Finally, It was decided to rename the project to '''Mupen64Plus''', and the project gained a homepage at Google Code, where it sits today.

== Progress ==

Although the original goals of the initial project were only to port the emulator to 64-bit Intel and fix bugs, not long after Richard42 arrived, it was decided that the project should also aim to improve the quality of '''Mupen64'''. Currently, the project has deviated off of the original '''Mupen64''' quite much. The main differences are:

* New Makefile, supporting PPC (broken as of now) and x86 targets for 64-bit and 32-bit.
* New GTK code, with much less deprecated GTK functions and widgets
* A Qt4 GUI
* A port of Rice Video, with countless fixes and renovations
* A port of Glide64 Wonder Plus
* Improvements to glN64
* 64-bit Dynamic Recompiler
* A brand new Windows port using GTK

== Usage ==

Currently, '''Mupen64Plus''' only compiles under Intel processors on the Linux platform (Other UNIX like Operating Systems should work as long as you have GNU Make and GCC for compilation). Simply use "make all" to compile the emulator, provided all prerequisites are properly installed and working.

An effort to port '''Mupen64Plus''' to Microsoft Windows is under way. Fixes to the build system that will allow users of PowerPC Linux to run '''Mupen64Plus''' should be released soon.

== Plugins ==

Currently, '''Mupen64Plus''' has 10 Plug-ins. 4 Video plug-ins, 3 audio plug-ins, 2 input plug-ins and 1 RSP plug-in.

'''Video:'''
* glN64
* No Video
* Glide64 Wonder Plus
* Rice's Video Plugin (With mudlord's extensions)

'''Audio:'''
* Mupen64 Audio Plugin (May become obsolete)
* No Audio
* JttL's SDL Audio

'''Input:'''
* Mupen64 Basic Input Plugin
* Blight's SDL Input Plugin

'''RSP:'''
* Hacktarux/Azimer HLE RSP Plugin

MacOSXInstructions

2015-07-26T21:36:31Z

Richard42: How to install and run Mupen64Plus on Intel Macintosh computers with OSX

__NOTOC__
Here are some basic usage instructions to compile Mupen64Plus on Intel Macintosh computers with OSX (this is for developers. If you are a user, please just download the binary from the downloads page or, if you want a front-end, look at http://bitbucket.org/auria/wxmupen64plus/wiki/Home ). As of October, 2011, all of the Mupen64Plus software will compile and run correctly. Please be aware that Mupen64Plus does not currently run on older PowerPC based Macintosh computers.

Please note that these instructions are meant as guidelines for people who know what they're doing. If you don't have much experience building stuff from source, I would recommend that you wait for binary packages instead.

Choose your mupen version :
<div class="toclimit-1">__TOC__</div>

== Mupen64plus 1.99.x and 2.x ==

* Install developer tools (Xcode) from the DVD that came with your Mac.

* Get the code from the various modules using mercurial as on any other platform (or just download a source code archive)
Get the dependencies just like you'd do for mupen64plus 1.x (except maybe GTK/Qt since there is no GUI frontend yet for mupen 2)

* Install pkg-config if you don't already have it

Create this file, called '''zlib.pc''', in /usr/local/lib/pkgconfig
<pre>
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: zlib
Version: 1.1.3
Description: zlib
Requires:
Libs: -L${libdir} -lz
Cflags: -I${includedir}</pre>

Create this file, called '''gl.pc''', in /usr/local/lib/pkgconfig
<pre>
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: gl
Version: 2.0
Description: OpenGL
Requires:
Libs: -framework OpenGL
Cflags: -I${includedir}</pre>

Create this file, called '''glu.pc''', in /usr/local/lib/pkgconfig
<pre>
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: glu
Version: 2.0
Description: glu
Requires:
Libs:
Cflags: -I${includedir}</pre>

A script to build (32 bits, compatible with 10.6/10.5 and maybe 10.4) looks like :

<pre>
PWD = `pwd`
export CC="gcc-4.0"
export CXX="g++-4.0"
export LD="g++-4.0"
APIDIR=$PWD/mupen64plus-core/src/api
export MACOSX_DEPLOYMENT_TARGET=10.4
export SDK_ROOT=/Developer/SDKs/MacOSX10.5.sdk
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig

APP_BUNDLE=./mupen64plus.app/Contents

export CFLAGS="-g"
export CXXFLAGS="-g"

echo "== Core =="
cd mupen64plus-core/projects/unix
make all V=1
cd ../../..
cp -f mupen64plus-core/projects/unix/'''.dylib .'''

echo "== RSP-HLE =="
cd mupen64plus-rsp-hle/projects/unix
make all V=1
cd ../../..
cp -f mupen64plus-rsp-hle/projects/unix/'''.dylib .'''

echo ""
echo "== SDL Audio =="
cd mupen64plus-audio-sdl/projects/unix
make all V=1
cd ../../..
cp -f mupen64plus-audio-sdl/projects/unix/'''.dylib .'''

echo ""
echo "== SDL Input =="
cd mupen64plus-input-sdl/projects/unix
make all V=1
cd ../../..
cp -f mupen64plus-input-sdl/projects/unix/'''.dylib .'''

echo ""
echo "== Rice =="
cd mupen64plus-video-rice/projects/unix
make all CC="g++-4.0" C_INCLUDE_PATH="/usr/local/include" CPLUS_INCLUDE_PATH="/usr/local/include" V=1 BITS=32 PIC=1
cd ../../..
cp -f mupen64plus-video-rice/projects/unix/'''.dylib .'''

echo ""
echo "== Arachnoid =="
cd mupen64plus-video-arachnoid/projects/unix
make all C_INCLUDE_PATH="/usr/local/include" CPLUS_INCLUDE_PATH="/usr/local/include" V=1
cd ../../..
cp -f mupen64plus-video-arachnoid/projects/unix/'''.dylib .'''

echo ""
echo "== Glide =="
cd mupen64plus-video-glide64/projects/unix
make all C_INCLUDE_PATH="/usr/local/include" CPLUS_INCLUDE_PATH="/usr/local/include" V=1
cd ../../..
cp -f mupen64plus-video-glide64/projects/unix/'''.dylib .'''

echo ""
echo "== Glide Napalm =="
cd mupen64plus-video-glide-napalm/Glitch64
make -f Makefile.gcc OSX_ARCH=i386 EXT_INC="../../mupen64plus-core/src/api -I./inc"
cd ../src
make -f Makefile.nowx-gcc all C_INCLUDE_PATH="/usr/local/include:../../mupen64plus-core/src/api" CPLUS_INCLUDE_PATH="/usr/local/include:../../mupen64plus-core/src/api" OSX_ARCH=i386
cd ../..
cp -f mupen64plus-video-glide-napalm/src/lib/'''.dylib .'''
cp -f mupen64plus-video-glide-napalm/src/'''.dylib .'''

echo ""
echo "== Console =="
cd mupen64plus-ui-console/projects/unix
make all V=1
cd ../../..
cp -f mupen64plus-ui-console/projects/unix/mupen64plus .

mkdir -p $APP_BUNDLE/MacOS/
cp -f mupen64plus $APP_BUNDLE/MacOS/mupen64plus
cp -f '''.dylib $APP_BUNDLE/MacOS/.'''
</pre>

To build 64-bits, use something like that instead (tested on 1.6) :
<pre>
#!/bin/sh
PWD = `pwd`

APIDIR=$PWD/mupen64plus-core/src/api
export LD="g++"

APP_BUNDLE=./mupen64plus.app/Contents

echo "== Core =="
cd mupen64plus-core/projects/unix
make all APIDIR=$APIDIR ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-core/projects/unix/*.dylib .

echo "== RSP-HLE =="
cd mupen64plus-rsp-hle/projects/unix
make all APIDIR=$APIDIR ARCH_DETECTED=64BITS LD="g++"
cd ../../..
cp -f mupen64plus-rsp-hle/projects/unix/*.dylib .

echo ""
echo "== SDL Audio =="
cd mupen64plus-audio-sdl/projects/unix
make all APIDIR=$APIDIR ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-audio-sdl/projects/unix/*.dylib .

echo ""
echo "== SDL Input =="
cd mupen64plus-input-sdl/projects/unix
make all APIDIR=$APIDIR ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-input-sdl/projects/unix/*.dylib .

echo ""
echo "== Rice =="
cd mupen64plus-video-rice/projects/unix
make all APIDIR=$APIDIR NO-ASM=1 C_INCLUDE_PATH=/usr/local/include ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-video-rice/projects/unix/*.dylib .

echo ""
echo "== Arachnoid =="
cd mupen64plus-video-arachnoid/projects/unix
make all C_INCLUDE_PATH="/usr/local/include" CPLUS_INCLUDE_PATH="/usr/local/include" ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-video-arachnoid/projects/unix/*.dylib .

echo ""
echo "== Glide =="
cd mupen64plus-video-glide64/projects/unix
make all C_INCLUDE_PATH="/usr/local/include" CPLUS_INCLUDE_PATH="/usr/local/include" ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-video-glide64/projects/unix/*.dylib .

echo ""
echo "== Console =="
cd mupen64plus-ui-console/projects/unix
make all APIDIR=$APIDIR ARCH_DETECTED=64BITS
cd ../../..
cp -f mupen64plus-ui-console/projects/unix/mupen64plus .

mkdir -p $APP_BUNDLE/MacOS/
cp -f mupen64plus $APP_BUNDLE/MacOS/mupen64plus
cp -f *.dylib $APP_BUNDLE/MacOS/.
</pre>

''' Macports users, you will need to add flags like this to the end of many of the ''make'' commands above :'''
<nowiki>
LIBRARY_PATH=/opt/local/lib
C_INCLUDE_PATH="/opt/local/include/libpng12"
CPLUS_INCLUDE_PATH="/opt/local/include/libpng12"</nowiki>

And a script to bundle may look like :

<pre>
#!/bin/sh
APP_CONTENTS="./mupen64plus.app/Contents"

FIX_LIST="-x $APP_CONTENTS/MacOS/mupen64plus \
-x $APP_CONTENTS/MacOS/libmupen64plus.dylib \
-x $APP_CONTENTS/MacOS/mupen64plus-audio-sdl.dylib \
-x $APP_CONTENTS/MacOS/mupen64plus-input-sdl.dylib \
-x $APP_CONTENTS/MacOS/mupen64plus-rsp-hle.dylib \
-x $APP_CONTENTS/MacOS/mupen64plus-video-rice.dylib \
-x $APP_CONTENTS/MacOS/mupen64plus-video-arachnoid.dylib \
-x $APP_CONTENTS/MacOS/mupen64plus-video-glide64.dylib"

dylibbundler -od -b $FIX_LIST -d $APP_CONTENTS/libs/

rm -rf $APP_CONTENTS/Resources
mkdir -p $APP_CONTENTS/Resources
cp ./mupen64plus-video-rice/data/* $APP_CONTENTS/Resources
cp ./mupen64plus-video-glide64/data/* $APP_CONTENTS/Resources
cp ./mupen64plus-core/data/* $APP_CONTENTS/Resources
cp ./mupen64plus-input-sdl/data/* $APP_CONTENTS/Resources
</pre>

this script requires [http://macdylibbundler.sourceforge.net/ macdylibbundler] to be installed.

Currently this only runs from the terminal.

== Mupen64plus 1.x ==

===Developer tools===
Install developer tools (Xcode) from the DVD that came with your Mac.

===GETTING MUPEN64PLUS===
You can simply download a source archive from the mupen64plus website; you can also use SVN. SVN example :
<nowiki>
mkdir mupen64plus
cd mupen64plus
svn co svn://fascination.homelinux.net:7684/mupen64plus/trunk --username mupen64 --password Dyson5632-kart</nowiki>

===DEPENDENCIES===
* Mupen can be built with either GTK+ or Qt. It is expected that in the future the Qt version will work better, but until then the GTK+ version is easier to get to run. Install GTK+ from http://www.gtk-osx.org/. (If you like using macports, beware : GTK as installed from macports ''will'' work on your computer, but you won't be able to package a distributable dmg. The installer from the website mentionned is much more handy for this)

* Other dependencies can be installed either from source or from macports.

====(A) THE SOURCE CODE WAY====
You will need SDL, SDL_ttf and its subdependencies (Freetype, fontconfig), and libpng.
Find them with [http://www.google.com Google] and install them with the usual
<nowiki>
./configure
make
sudo make install</nowiki>

====(B) THE MACPORTS WAY====
* Install macports from [http://www.macports.org/install.php macports.org]
* Open terminal (under Hard Drive, Applications, Utilities, Terminal). Type in the following commands.
<nowiki>
sudo port install libsdl_ttf libpng</nowiki>

Since macports installs librairies in a non-standard prefix, you will need to help the makefiles find librairies installed from macports. You can simply export LDFLAGS=-L/opt/local/lib or, more conveniently, change it on a more permanent basis by editing '''pre.mk''' in the mupen source - then locate the lines that read
<nowiki>
OS = OSX
LDFLAGS += -liconv -lpng</nowiki>
and make the second one
<nowiki>
LDFLAGS += -L/opt/local/lib -liconv -lpng</nowiki>

===BUILDING MUPEN64PLUS===
We'll first set some environment variables to help mupen find GTK+. Also make sure sdl-config is in your PATH.
<nowiki>
export PKG_CONFIG_PATH=/Library/Frameworks/Gtk.framework/Resources/dev/lib/pkgconfig
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/Library/Frameworks/GLib.framework/Resources/dev/lib/pkgconfig
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/Library/Frameworks/Cairo.framework/Resources/dev/lib/pkgconfig </nowiki>
Then cross your fingers, it's time to build!
<nowiki>
cd /path/to/mupen/trunk
make all</nowiki>

Or, for a debug build:
<nowiki>
make DBGSYM=1 all</nowiki>

===RUNNING===
<nowiki>
cd mupen64plus/trunk/
./mupen64plus</nowiki>

To run no gui mode :
<nowiki>
# simplest :
./mupen64plus --nogui <rom-path>

# pass some settings
./mupen64plus --nogui --gfx plugins/glN64.so --audio plugins/jttl_audio.so --input plugins/blight_input.so --rsp plugins/mupen64_hle_rsp_azimer.so --emumode 1 <rom-path></nowiki>

Be aware that input may not work if you launch ROMs in GUI mode.

===PACKAGING MUPEN64PLUS===
If all you wanted is to play with Mupen64Plus, this section won't apply to you; but we want to share the fun with others, don't we? From now on, I'll concentrate on how to build a package you can send to others.

Start by installing mupen :
<nowiki>
sudo ./install.sh</nowiki>

You will first need an '''Info.plist''' file, sample here :
<nowiki>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key> <string>English</string>
<key>CFBundleInfoDictionaryVersion</key> <string>6.0</string>
<key>CFBundlePackageType</key> <string>APPL</string>
<key>CSResourcesFileMapped</key> <true/>

<key>CFBundleExecutable</key> <string>launcher</string>
<key>CFBundleName</key> <string>Mupen64Plus</string>
<key>CFBundleIconFile</key> <string>mupen64plus.icns</string>
<key>CFBundleVersion</key> <string>1.5</string>

<key>CFBundleDocumentTypes</key>
<array>
<dict>
<key>CFBundleTypeExtensions</key>
<array>
<string>n64</string>
<string>N64</string>
<string>z64</string>
<string>V64</string>
<string>v64</string>
<string>V64</string>
</array>
<key>CFBundleTypeIconFile</key>
<string>mupen64cart.icns</string>
<key>CFBundleTypeName</key>
<string>N64 Rom</string>
<key>CFBundleTypeRole</key>
<string>Editor</string>
<key>LSIsAppleDefaultForType</key>
<true/>
<key>LSTypeIsPackage</key>
<false/>
</dict>

</array>

</dict>
</plist></nowiki>
(note that the executable name in this Info.plist file is ''launcher'' - I'll explain why below)

You will also need icons for mupen and ROMs : mupen64plus.icns, mupen64cart.icns

Then you can build the application bundle by using a simple shell script :
<nowiki>
INSTALL_PREFIX="/usr/local"
APP_CONTENTS="./Mupen64Plus.app/Contents"

echo "* Removing any existing installation"
rm -rf ./Mupen64Plus.app

echo "* Creating skeleton"
mkdir -p $APP_CONTENTS/Resources
mkdir $APP_CONTENTS/MacOS
cp Info.plist $APP_CONTENTS/Info.plist
cp mupen64plus.icns $APP_CONTENTS/Resources/mupen64plus.icns
cp mupen64cart.icns $APP_CONTENTS/Resources/mupen64cart.icns

echo "* Copying executable"
cp $INSTALL_PREFIX/bin/mupen64plus $APP_CONTENTS/MacOS/mupen64plus
#cp ./launcher $APP_CONTENTS/MacOS/launcher

echo "* Copying data files"
cp -r $INSTALL_PREFIX/share/mupen64plus/ $APP_CONTENTS/Resources/</nowiki>

You can then make this bundle distributable by blessing it with [http://macdylibbundler.sourceforge.net DylibBundler]. First install DylibBundler by following the instructions inside. Then run this small script :

<nowiki>
APP_CONTENTS="./Mupen64Plus.app/Contents"

FIX_LIST="-x $APP_CONTENTS/MacOS/mupen64plus \
-x $APP_CONTENTS/Resources/plugins/blight_input.so \
-x $APP_CONTENTS/Resources/plugins/dummyaudio.so \
-x $APP_CONTENTS/Resources/plugins/dummyvideo.so \
-x $APP_CONTENTS/Resources/plugins/glide64.so \
-x $APP_CONTENTS/Resources/plugins/glN64.so \
-x $APP_CONTENTS/Resources/plugins/jttl_audio.so \
-x $APP_CONTENTS/Resources/plugins/mupen64_hle_rsp_azimer.so \
-x $APP_CONTENTS/Resources/plugins/mupen64_input.so \
-x $APP_CONTENTS/Resources/plugins/ricevideo.so"

dylibbundler -od -b $FIX_LIST -d $APP_CONTENTS/libs/</nowiki>

Voila it's ready! Well actually, it should be in theory... In practice there is a bug on mac : when using both SDL and GTK+ at the same time, both grab the event loop and conflict with each other. The result of this is that ROMs cannot be launched from the GTK GUI, they can only be run in ''nogui'' mode. The GTK interface however still remains necessary to configure mupen. Until this issue gets fixed properly, I work around it by placing a second executable in the bundle called ''launcher'' (see the bundling script above, there is a commented out line that does this). This executable can then act as a bridge to either open the GTK GUI and configure mupen, either launch a ROM in nogui mode.

--> MacLauncher

With this launcher as main executable, you should finally have a distributable executable!

To be continued...

LIRC

2015-07-26T21:07:37Z

Richard42: Enabling LIRC support in Mupen64Plus

== Introduction ==

Mupen64Plus includes support for [http://www.lirc.org Linux Infrared Remote Control] (LIRC). This can be used to send commands to Mupen64Plus using a remote control.

== Building with LIRC support ==

To build Mupen64Plus with LIRC support, download and unzip the source code, and pass "LIRC=1" to make. See the [[README]] for full details on build/installation of Mupen64Plus.

<nowiki>
$ make LIRC=1 all</nowiki>

== Configuring LIRC Commands ==

LIRC uses a config file to define mappings between buttons on your remote control (as defined in lircd.conf) and the commands you want to send to Mupen64Plus. Mupen64Plus expects the LIRC config to be in a file called .lircrc in the user's home directory.

The LIRC config file contains a block for each button mapping. Here is an example block:

<nowiki>
begin
prog = mupen64plus
button = Back/Exit
config = quit
end</nowiki>

This maps the "Back/Exit" button on the remote control to the "quit" mupen64plus command.

You can also use the "repeat" keyword to have LIRC repeatedly send a command while you're holding down a button on the remote control. Here is an example block:

<nowiki>
begin
prog = mupen64plus
button = Vol+
repeat = 1
config = vol+
end</nowiki>

This maps the "Vol+" button on the remote control to the "vol+" mupen64plus command. The repeat line means that LIRC will repeatedly send the "vol+" command as long as the remote control button is held down. Increasing the repeat number decreases how often the command will be sent to mupen64plus.

=== Supported Commands ===

The following table lists the Mupen64Plus commands that can be mapped to remote control buttons in your LIRC config file:

{| class="wikitable"
|-
|'''Config String''' || '''Description'''
|-
|0-9 || Set current statesave slot to given slot number.
|-
|save || Save game state to currently selected statesave slot.
|-
|load || Load game statesave from currently selected statesave slot.
|-
|pause || Pause/continue emulation.
|-
|quit || Stop Emulation.
|-
|fullscreen || Toggle fullscreen mode.
|-
|screenshot || Take a screenshot.
|-
|vol+ || Increase volume by 2%. '''Note:''' svn only, not available in v1.3
|-
|vol- || Decrease volume by 2% '''Note:''' svn only, not available in v1.3
|-
|mute || Mute/unmute volume '''Note:''' svn only, not available in v1.3

KeyboardSetup

2015-07-26T21:05:02Z

Richard42: Default key bindings for Mupen64Plus emulator

File:KeyboardMupen64Plus.png

2015-07-26T20:14:18Z

Richard42: keyboard layout image

keyboard layout image

InputPluginUsage

2015-07-26T17:45:34Z

Richard42: Supported use cases for Autoconfiguration with Mupen64Plus-Input-SDL plugin

=== Use Cases ===

* '''Use case #1 scenario''': First-time user of Mupen64Plus, has no configuration file.
** '''Desired Behavior''':
*** Automatically detect and configure any supported joysticks, assigning them in sequence to controllers.
*** Skip any unsupported joysticks without leaving unconfigured controllers.
*** If no SDL joysticks are found, configure the keyboard/mouse.
*** Fill in (blank) settings for all 4 controllers (for GUI front-ends)
** '''How to configure''': Automatic.
*** If no configuration is found for a controller (or version is out of date), it will automatically be set to mode 2 (fully automatic), and saved.
 
* '''Use case #2 scenario''': User changes controllers often (configuration file is present)
** '''Desired Behavior''':'''
*** Automatically detect and configure any joysticks plugged in
*** Skip any unsupported joysticks without leaving unconfigured controllers.
*** If no SDL joysticks are found, configure the keyboard/mouse.
*** Don't stick to old input settings in configuration file when a different joystick is used
*** User should be able to modify the auto-configured settings (edit InputAutoConfig.ini)
** '''How to configure''': Automatic
*** User should set all controllers to mode 2 (fully auto) in this scenario, and edit his controller preferences in the InputAutoConfig.ini file.
 
* '''Use case #3 scenario''': User switches between keyboard and joystick
** '''Desired Behavior''':
*** If joystick is plugged in, then set up according to configuration file (if it matches), or auto-config
*** If no SDL joysticks are found, configure the keyboard/mouse.
** '''How to configure''':
*** User should set all controllers to mode 2 (fully auto) in this scenario, and edit his controller preferences in the InputAutoConfig.ini file.
 
* '''Use case #4 scenario''': Developer wants to create a specific input configuration for testing purposes: no controllers, only a controller in port 2, etc.
** '''How to configure''': Set all controller '''<code>mode</code>''' parameters to 0, set other configuration parameters as necessary.
 
* '''Use case #5 scenario''': A user wants has several different controllers plugged in, and wants to set a specific one (which may not be SDL joystick 0) to be N64 controller 0. The user also wants the configuration to be automatic (doesn't want to have to set up the joystick manually).
** '''How to configure''': Set controller #1 '''<code>mode</code>''' parameter to 1, and set the SDL joystick name of your desired main controller in to the '''<code>name</code>''' parameter.

=== Design Changes ===
* changes relative to Hg rev 173:725bc6d288ae
* Changes to <code>[Input-SDL-Control*]</code> sections
** '''<code>version</code>''' changes from 1 to 2
*** Add parameter '''<code>mode</code>''': 0 = Fully Manual, 1 = Automatic with named SDL device, 2 = Fully Automatic. GUI front-ends should make all of the controller's other parameters read-only when the mode is set to 2, and should make all parameters except '''<code>name</code>''' read-only when the mode is set to 1.
*** For the '''<code>device</code>''' parameter, remove the <code>-2</code> option (keyboard input should automatically work for any N64 controller which maps keys), and change the semantic of the <code>-1</code> option to mean "No SDL joystick" instead of "Auto-config". For modes 1 and 2, this parameter will be set by the input plugin. The user can only set this parameter for mode 0.
*** For the '''<code>name</code>''' parameter: Similar to previous usage, but mode-dependent: For mode 0, name of joystick/keyboard which was last used (set by plugin). For mode 1, name of desired joystick/keyboard to use for this controller (set by user). For mode 2, ignored.

HighResolutionTextures

2015-07-26T06:32:29Z

Richard42:

== Introduction ==

Mupen64Plus's Rice Video plugin supports a very nice feature which allows the user to replace all of the original textures used for 3D rendering in a game with high-resolution replacement textures drawn by graphic artists.

== Setup ==

=== Enable Hi-Res Texture Loading in Rice Video ===

In order to begin using the hi-resolution texture feature, you must enable it by editing the Mupen64Plus config file. One option is to find the file and edit it directly with a text editor. On Linux or OSX, this is located at <code>~/.config/mupen64plus/</code>, and on Windows it is in the "Application Data" sub-folder of your user folder. On Windows XP and prior, this is <code>C:\Documents and Settings\<username>\Application Data\Mupen64Plus\</code>, while on Windows Vista and newer this is <code>C:\Users\<username>\AppData\Mupen64Plus</code>. You should find a section in this file labeled <code>[Video-Rice]</code>, and within this section is a parameter called <code>LoadHiResTextures</code>. Set this to True to enable searching for and loading high-resolution textures.

Another option to enable this feature is to use the <code>--set</code> option with the Mupen64Plus command-line user interface. To do this, run a game with a command similar to this: <code>./mupen64plus --set Video-Rice[LoadHiResTextures]=True --saveoptions m64p_test_rom.v64</code>

=== Installing Hi-Res Texture Files ===

To install a high-resolution texture pack for a game, all that you need to do is unzip the archive and put the extracted directory full of images into the right place. On Linux and OSX, this is usually <code>/home/<username>/.local/share/mupen64plus/hires_texture</code>. On Windows it is in the "Application Data" sub-folder of your user folder. On Windows XP and prior, this is <code>C:\Documents and Settings\<username>\Application Data\Mupen64Plus\hires_texture</code>, while on Windows Vista and newer this is <code>C:\Users\<username>\AppData\Mupen64Plus\hires_texture</code>. If this directory doesn't exist, create it and copy the hi-res texture directory inside.

The folder containing hi-res textures must be named exactly the same as the ROM's name in the header of the ROM file. Usually this name is short with all capital letters, like "MARIOKART64" or "SMASH BROTHERS". The command-line UI prints out this ROM name when running a game, right after the Goodname and before the MD5.

=== Running ===

After setup, just run the game as usual. If using the command-line UI, you should see a line printed out which says:

<nowiki>
Video: Texture loading option is enabled. Finding all hires textures</nowiki>