[mupen64plus-core] 232/310: Imported Upstream version 2.0
Sven Eckelmann
ecsv-guest at moszumanska.debian.org
Thu Nov 26 05:58:06 UTC 2015
This is an automated email from the git hooks/post-receive script.
ecsv-guest pushed a commit to branch armhf_test
in repository mupen64plus-core.
commit e7c891d8366002783b63b312d310065d99ec9b56
Author: Sven Eckelmann <sven at narfation.org>
Date: Fri Jul 5 09:38:05 2013 +0200
Imported Upstream version 2.0
---
LICENSES | 3 +-
README | 17 +-
RELEASE | 15 ++
.../Mupen64Plus_v2.0_API_Versioning.txt | 109 ++++++++++++
.../Mupen64Plus_v2.0_Core_API_v1.0.txt | 4 +
doc/module-api-versions.txt | 192 ---------------------
src/api/config.c | 3 +
src/main/eventloop.c | 22 ++-
src/main/rom.c | 2 +-
src/main/version.h | 2 +-
src/memory/dma.c | 7 -
src/r4300/interupt.c | 1 -
tools/build_bundle_bin.sh | 2 +-
tools/osx_build_bundle.sh | 36 ++++
tools/osx_build_instructions.txt | 52 ++++++
15 files changed, 254 insertions(+), 213 deletions(-)
diff --git a/LICENSES b/LICENSES
index 4e9f0af..d1bdbe3 100644
--- a/LICENSES
+++ b/LICENSES
@@ -3,8 +3,9 @@ Mupen64Plus-Core LICENSES
Mupen64Plus-Core is licensed under the GNU General Public License version 2. Please see the
included doc/gpl-license file for the terms and conditions of the GNU General Public License.
-The authors of Mupen64Plus are:
+The authors of Mupen64Plus-Core are:
* Richard Goedeken (Richard42)
+ * Sven Eckelmann (ecsv)
* John Chadwick (NMN)
* James Hood (Ebenblues)
* Scott Gorman (okaygo)
diff --git a/README b/README
index 6679b46..45c53c9 100644
--- a/README
+++ b/README
@@ -63,6 +63,9 @@ Type 'make' by itself to view all available build options:
SHAREDIR=path == extra path to search for shared data files
OPTFLAGS=flag == compiler optimization (default: -O3)
PIC=(1|0) == Force enable/disable of position independent code
+ OSD=(1|0) == Enable/disable build of OpenGL On-screen display
+ NEW_DYNAREC=1 == Replace dynamic recompiler with Ari64's experimental dynarec
+ POSTFIX=name == String added to the name of the the build (default: '')
Install Options:
PREFIX=path == install/uninstall prefix (default: /usr/local/)
SHAREDIR=path == path to install shared data (default: PREFIX/share/mupen64plus/)
@@ -76,6 +79,7 @@ Type 'make' by itself to view all available build options:
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_TIMING=1 == print timing data
DBG_PROFILE=1 == dump profiling data for r4300 dynarec to data file
V=1 == show verbose compiler output
@@ -99,10 +103,13 @@ files used by mupen64plus.
NOTE: By default, install.sh uses /usr/local for the install prefix. Although
the user can specify an alternate prefix to install.sh at the commandline, the
mupen64plus binary was compiled to look for the install directory in /usr/local,
-so specifying an alternate prefix to install.sh will cause problems (mupen64plus
-will not find the install directory). If you want to use a prefix other than
-/usr/local, you will have to download the source package and build with the
-PREFIX option (see below).
+so specifying an alternate prefix to install.sh will cause problems (the
+mupen64plus front-end application will not find the directory containing the
+core library) unless the directory to which you install it is known by your
+dynamic library loader (ie, included in /etc/ld.conf.so)
+
+If you want to use a prefix other than /usr/local, you may also download the
+source code package and build with the PREFIX option (see below).
*Source Distribution*
@@ -114,7 +121,7 @@ to /usr/local. This can be changed by passing the PREFIX option to make. NOTE:
you must pass the prefix, when building AND installing. For example, to install
mupen64plus to /usr, do this:
- $ make all
+ $ make PREFIX=/usr all
$ sudo make PREFIX=/usr install
$
diff --git a/RELEASE b/RELEASE
index 6ecd337..3184290 100644
--- a/RELEASE
+++ b/RELEASE
@@ -1,6 +1,21 @@
Mupen64Plus-Core Emulator Library RELEASE
-----------------------------------------
+Mupen64Plus v2.0 - July 4th, 2013
+---------------------------------
+ - 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
+ - support to build against SDL2
+ - debugger code cleanup
+ - Project files for Visual Studio 2012
+ - Makefile changes
+ - add support for PowerPC and MinGW32 builds
+ - add cross-compiling support to build Win32 executables (MXE) under Linux
+
Mupen64Plus v1.99.5 - March 10, 2012
------------------------------------
- New feature: support for N64 internal real-time clock
diff --git a/doc/emuwiki-api-doc/Mupen64Plus_v2.0_API_Versioning.txt b/doc/emuwiki-api-doc/Mupen64Plus_v2.0_API_Versioning.txt
new file mode 100644
index 0000000..38bb5de
--- /dev/null
+++ b/doc/emuwiki-api-doc/Mupen64Plus_v2.0_API_Versioning.txt
@@ -0,0 +1,109 @@
+[[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 [...]
+
+# 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 [...]
+# 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() [...]
+# 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 com [...]
+
+== 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()
+* '''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.
+* '''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.
+
diff --git a/doc/emuwiki-api-doc/Mupen64Plus_v2.0_Core_API_v1.0.txt b/doc/emuwiki-api-doc/Mupen64Plus_v2.0_Core_API_v1.0.txt
index 3ca5872..43cf890 100644
--- a/doc/emuwiki-api-doc/Mupen64Plus_v2.0_Core_API_v1.0.txt
+++ b/doc/emuwiki-api-doc/Mupen64Plus_v2.0_Core_API_v1.0.txt
@@ -30,6 +30,10 @@ The expected sequence of operations which will be taken by the front-end applica
#* 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 a [...]
+
== Core API ==
=== [[Mupen64Plus v2.0 Core Basic|Basic Core Functions]] ===
diff --git a/doc/module-api-versions.txt b/doc/module-api-versions.txt
deleted file mode 100644
index bc9884c..0000000
--- a/doc/module-api-versions.txt
+++ /dev/null
@@ -1,192 +0,0 @@
-Mupen64Plus API versions
-
----------------------------------------------------------------------------------------------------
-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:
-
-1. The Front-end UI application
-2. The Core emulator library
-3. The Video plugin
-4. The Audio plugin
-5. The Input plugin
-6. 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:
-
-1. 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.
-2. 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
-
-1. When the front-end application calls the CoreStartup(), 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 return from this function with a failure code of M64ERR_INCOMPATIBLE.
-
-2. 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.
-
-3. 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.
-
-4. 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.
-
-5. All front-ends and plugins should verify API version compatibility for the Config API.
-
----------------------------------------------------------------------------------------------------
-Handling Future Changes:
-
-1. 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.
-
-2. 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.
-
-3. 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.
-
-4. 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.
-
-5. 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()
-
- - 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.
-
- - 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.
-
-
diff --git a/src/api/config.c b/src/api/config.c
index b259ca4..8095a89 100644
--- a/src/api/config.c
+++ b/src/api/config.c
@@ -1413,7 +1413,10 @@ EXPORT const char * CALL ConfigGetSharedDataFilepath(const char *filename)
EXPORT const char * CALL ConfigGetUserConfigPath(void)
{
if (l_ConfigDirOverride != NULL)
+ {
+ osal_mkdirp(l_ConfigDirOverride, 0700);
return l_ConfigDirOverride;
+ }
else
return osal_get_user_configpath();
}
diff --git a/src/main/eventloop.c b/src/main/eventloop.c
index 633a697..85a06d7 100644
--- a/src/main/eventloop.c
+++ b/src/main/eventloop.c
@@ -246,6 +246,9 @@ static int SDLCALL event_sdl_filter(void *userdata, SDL_Event *event)
case SDL_KEYDOWN:
#if SDL_VERSION_ATLEAST(1,3,0)
+ if (event->key.repeat)
+ return 0;
+
event_sdl_keydown(event->key.keysym.scancode, event->key.keysym.mod);
#else
event_sdl_keydown(event->key.keysym.sym, event->key.keysym.mod);
@@ -259,12 +262,25 @@ static int SDLCALL event_sdl_filter(void *userdata, SDL_Event *event)
#endif
return 0;
+#if SDL_VERSION_ATLEAST(2,0,0)
+ case SDL_WINDOWEVENT:
+ switch (event->window.event) {
+ case SDL_WINDOWEVENT_RESIZED:
+ // call the video plugin. if the video plugin supports resizing, it will resize its viewport and call
+ // VidExt_ResizeWindow to update the window manager handling our opengl output window
+ gfx.resizeVideoOutput(event->window.data1, event->window.data2);
+ return 0; // consumed the event
+ break;
+ }
+ break;
+#else
case SDL_VIDEORESIZE:
// call the video plugin. if the video plugin supports resizing, it will resize its viewport and call
// VidExt_ResizeWindow to update the window manager handling our opengl output window
gfx.resizeVideoOutput(event->resize.w, event->resize.h);
return 0; // consumed the event
break;
+#endif
// if joystick action is detected, check if it's mapped to a special function
case SDL_JOYAXISMOTION:
@@ -340,7 +356,7 @@ void event_initialize(void)
if (!SDL_WasInit(SDL_INIT_JOYSTICK))
SDL_InitSubSystem(SDL_INIT_JOYSTICK);
#if SDL_VERSION_ATLEAST(2,0,0)
-#warning SDL_JoystickOpened unsupported
+ SDL_JoystickOpen(device);
#else
if (!SDL_JoystickOpened(device))
SDL_JoystickOpen(device);
@@ -349,9 +365,7 @@ void event_initialize(void)
}
/* set up SDL event filter and disable key repeat */
-#if SDL_VERSION_ATLEAST(2,0,0)
-#warning SDL_EnableKeyRepeat unsupported
-#else
+#if !SDL_VERSION_ATLEAST(2,0,0)
SDL_EnableKeyRepeat(0, 0);
#endif
SDL_SetEventFilter(event_sdl_filter, NULL);
diff --git a/src/main/rom.c b/src/main/rom.c
index be26b0c..5cd1b3e 100644
--- a/src/main/rom.c
+++ b/src/main/rom.c
@@ -238,7 +238,7 @@ m64p_error close_rom(void)
// Get the system type associated to a ROM country code.
static m64p_system_type rom_country_code_to_system_type(unsigned short country_code)
{
- switch (country_code)
+ switch (country_code & 0xFF)
{
// PAL codes
case 0x44:
diff --git a/src/main/version.h b/src/main/version.h
index 1f13032..81ce92c 100644
--- a/src/main/version.h
+++ b/src/main/version.h
@@ -25,7 +25,7 @@
#define __VERSION_H__
#define MUPEN_CORE_NAME "Mupen64Plus Core"
-#define MUPEN_CORE_VERSION 0x016305
+#define MUPEN_CORE_VERSION 0x020000
#define FRONTEND_API_VERSION 0x020101
#define CONFIG_API_VERSION 0x020200
diff --git a/src/memory/dma.c b/src/memory/dma.c
index 7d23b00..8d606d4 100644
--- a/src/memory/dma.c
+++ b/src/memory/dma.c
@@ -353,10 +353,6 @@ void dma_si_write(void)
}
update_pif_write();
-
- // TODO: under what circumstances should bits 1 or 3 be set?
- si_register.si_stat |= 1;
-
update_count();
add_interupt_event(SI_INT, /*0x100*/0x900);
}
@@ -378,9 +374,6 @@ void dma_si_read(void)
rdram[si_register.si_dram_addr/4+i] = sl(PIF_RAM[i]);
}
- // TODO: under what circumstances should bits 1 or 3 be set?
- si_register.si_stat |= 1;
-
update_count();
add_interupt_event(SI_INT, /*0x100*/0x900);
}
diff --git a/src/r4300/interupt.c b/src/r4300/interupt.c
index f44da5b..3225559 100644
--- a/src/r4300/interupt.c
+++ b/src/r4300/interupt.c
@@ -445,7 +445,6 @@ void gen_interupt(void)
remove_interupt_event();
MI_register.mi_intr_reg |= 0x02;
si_register.si_stat |= 0x1000;
- si_register.si_stat &= ~0x1;
if (MI_register.mi_intr_reg & MI_register.mi_intr_mask_reg)
Cause = (Cause | 0x400) & 0xFFFFFF83;
else
diff --git a/tools/build_bundle_bin.sh b/tools/build_bundle_bin.sh
index 5646622..f69f60e 100755
--- a/tools/build_bundle_bin.sh
+++ b/tools/build_bundle_bin.sh
@@ -53,7 +53,7 @@ echo "************************************ Building Mupen64Plus modules"
cd ..
tar xzvf source/mupen64plus-core/tools/m64p_helper_scripts.tar.gz
-./m64p_build.sh $@
+./m64p_build.sh COREDIR=/usr/local/lib/ $@
mv "test" "${OUTPUTDIR}"
echo "************************************ Creating archive"
diff --git a/tools/osx_build_bundle.sh b/tools/osx_build_bundle.sh
new file mode 100755
index 0000000..e6de384
--- /dev/null
+++ b/tools/osx_build_bundle.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+
+./m64p_build.sh
+
+mkdir -p mupen64plus.app/Contents/MacOS/
+
+mv test/mupen64plus test/*.dylib mupen64plus.app/Contents/MacOS/
+
+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-glide64mk2.dylib"
+
+dylibbundler -od -b $FIX_LIST -d $APP_CONTENTS/libs/
+
+rm -rf $APP_CONTENTS/Resources
+rm -rf $APP_CONTENTS/SharedSupport
+mkdir -p $APP_CONTENTS/Resources
+mkdir -p $APP_CONTENTS/Frameworks
+mv test/*.ini test/*.ttf $APP_CONTENTS/Resources
+mv test/mupen* $APP_CONTENTS/Resources
+mv test $APP_CONTENTS/SharedSupport
+cp -r /Library/Frameworks/SDL.framework $APP_CONTENTS/Frameworks
+
+mv $APP_CONTENTS/SharedSupport/m64p_test_rom.v64 ./example.v64
+echo './mupen64plus.app/Contents/MacOS/mupen64plus --corelib ./mupen64plus.app/Contents/MacOS/libmupen64plus.dylib --plugindir ./mupen64plus.app/Contents/MacOS --gfx mupen64plus-video-rice "$@"' > run_rice.sh
+echo './mupen64plus.app/Contents/MacOS/mupen64plus --corelib ./mupen64plus.app/Contents/MacOS/libmupen64plus.dylib --plugindir ./mupen64plus.app/Contents/MacOS --gfx mupen64plus-video-glide64mk2 "$@"' > run_glide.sh
+echo -e "Note that Mupen64Plus requires an Intel mac and will not run on PPC macs.\nIt is known to run on OS X 10.8; and most likely also runs on 10.7.\n\nThis application can NOT be opened in the Finder by double-clicking.\n To use, launch the terminal, then cd into the directory that contains mupen64plus.app and use a command like :\n\n $ ./run_rice.sh example.v64 # for the Rice video plugin\n $ ./run_glide.sh example.v64 # for the Glide64mk2 video plugin\n\n N [...]
+chmod +x run_rice.sh run_glide.sh
+zip -r mupen64plus-bundle-osx-2.0rc4.zip mupen64plus.app Readme.txt run_rice.sh run_glide.sh example.v64
+
diff --git a/tools/osx_build_instructions.txt b/tools/osx_build_instructions.txt
new file mode 100644
index 0000000..61f953c
--- /dev/null
+++ b/tools/osx_build_instructions.txt
@@ -0,0 +1,52 @@
+OSX build instructions (using OSX 10.8.3 and Xcode 4.6.2):
+
+1. Install SDL framework
+ - go to http://www.libsdl.org/download-1.2.php
+ - download SDL-1.2.15.dmg
+ - Open the DMG and copy SDL.framework to /Library/Frameworks
+ - also, copy devel-lite to your desktop
+ - Build SDLMain.m_o:
+ - open terminal, cd ~/Desktop/devel-lite
+ - run: gcc -c -O3 -I./ -I/Library/Frameworks/SDL.framework/Headers -o SDLMain.m_o SDLMain.m
+2. Install macports
+3. Install the following ports (sudo port install <name>):
+ - bzip2
+ - freetype
+ - libpng
+ - libsamplerate
+ - speex
+ - zlib
+4. Boost requires some special stuff. We must compile with clang and libc++.
+ - edit your /opt/local/etc/macports/macports.conf
+ - add to end: default_compiler clang
+ - sudo port edit boost
+ - change this line:
+ write_jam "using darwin : : ${configure.cxx} : <cxxflags>\"${configure.cxxflags}\" ${compileflags} <linkflags>\"${configure.ldflags}\" : ;"
+ - to this:
+ write_jam "using darwin : : ${configure.cxx} : <cxxflags>\"${configure.cxxflags} -std=c++11 -stdlib=libc++\" ${compileflags} <linkflags>\"${configure.ldflags} -stdlib=libc++\" : ;"
+ - if you have boost already installed in macports, remove it:
+ - sudo port uninstall boost
+ - reinstall boost from source:
+ - sudo port -s install boost
+5. Download the Mupen64Plus source code:
+ - Open terminal window, create build directory for Mupen64Plus
+ - Download and unpack the latest m64p_helper_scripts.tar.gz from: https://code.google.com/p/mupen64plus/wiki/CompilingFromHg
+ - run ./m64p_get.sh
+6. Hack your ui-console makefile to build against SDLMain.m_o:
+ - edit source/mupen64plus-ui-console/projects/unix/Makefile
+ - change line:
+ CFLAGS += $(SDL_CFLAGS)
+ - to:
+ CFLAGS += $(SDL_CFLAGS) ~/devel-lite/SDLMain.m_o -framework Cocoa
+7. Hack your m64p_build.sh script to build under OSX:
+ - change line:
+ "$MAKE" -C source/mupen64plus-${component}/projects/unix all $@
+ - to:
+ if [ "${component}" = "ui-console" ]; then
+ "$MAKE" -C source/mupen64plus-${component}/projects/unix all -j4 V=1 CC=clang CXX=clang++ OSX_SDK=10.7 SDL_CFLAGS="-I/opt/local/include -D__APPLE__ -I/Library/Frameworks/SDL.framework/Headers" SDL_LDLIBS="-F/Library/Frameworks -framework SDL -framework Foundation" OPTFLAGS="-O3" LDFLAGS="-Wl,-rpath -Wl, at executable_path/../Frameworks"
+ else
+ "$MAKE" -C source/mupen64plus-${component}/projects/unix all -j4 V=1 CC=clang CXX=clang++ OSX_SDK=10.7 SDL_CFLAGS="-I/opt/local/include -D__APPLE__ -I/Library/Frameworks/SDL.framework/Headers" SDL_LDLIBS="-F/Library/Frameworks -framework SDL -framework Foundation" OPTFLAGS="-O3"
+ fi
+8. Build it
+ - copy osx_build_bundle.sh from source/mupen64plus-core/tools to current directory
+ - run ./osx_build_bundle.sh
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-games/mupen64plus-core.git
More information about the Pkg-games-commits
mailing list