@twinaphex discussed about making make_run function reentrant here. Here are his words:

One of the big things that still separates Mupen64plus libretro from Mupen64plus upstream is that for Mupen64plus libretro, I took the effort of making sure main_run is nonblocking and can be called in a reentrant fashion. I need this not only for the purpose of being able to one-shot per frame in the main loop, but also so that I can do realtime rewind (since the savestate code also had to be made reentrant).

In that regard, things are still not really satisfactory right now in the Libretro fork since I still need libco to be able to skip between threads cooperatively (the main thread is for libretro, the other thread is for Mupen64plus). I'd like that to not be needed so that instead we will have a model for the Mupen64plus emulation core that is much more like a conventional emulator like SNES9x or FCEU, one where there are separate global functions for initing, deiniting, and iterating for one frame run.

@Nebuleon's answer:

@twinaphex: What you describe is neither reentrant nor non-blocking, unless one frame of emulation can be requested in the middle of running another, e.g. in two separate threads (reentrancy), or one frame of emulation can be requested and it immediately returns (i.e. doesn't block) before it's actually done (non-blocking).

Please create separate issues as appropriate to describe in detail the main differences between libretro mupen64plus and this repository and what could be done to minimise the differences, and another one for the PIC patches, for wider discussion.

This ticket has been created to discuss about if this system need to be put in the core and how it would be efficiently integrated.

Please continue this discussion here. :)

The SDL_SetVideoMode reimplementation sets the profile mask attribute, with no care whether it has already been set.

#ifndef USE_GLES
    SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_COMPATIBILITY);
#else // !USE_GLES

Part of the purpose of this function is to open the GL context, so reordering calls on the video plugin side of things can't work around this.

if (flags & SDL_OPENGL) {
    SDL_VideoContext = SDL_GL_CreateContext(SDL_VideoWindow);

This makes opening a 3.2 or higher context on Mesa impossible because Mesa does not allow versions higher than 3.1 to be opened in compatibility profile. Leaving the profile mask unset causes it to default to CORE for 3.2 and higher.

[...] If the requested OpenGL version is less than 3.2,
GLX_CONTEXT_PROFILE_MASK_ARB is ignored and the functionality of the
context is determined solely by the requested version.
[...]
The default value for GLX_CONTEXT_PROFILE_MASK_ARB is
GLX_CONTEXT_CORE_PROFILE_BIT_ARB. All OpenGL 3.2 implementations are
required to implement the core profile, but implementation of the
compatibility profile is optional.

This prevents GLideN64 from working correctly on Mesa, because it requires GL 3.3 for shaders. I still only get a black screen with sound after patching both the core and the plugin, but at least it doesn't segfault or take down my system just trying to boot anymore.

I have been having this issue, where even on a fresh install (fresh Linux Mint 17.3 Cinnamon) with both mupen64plus, and m64py

Attempting to open any rom results in the following term output

| / |_ _ _ __ ___ _ __ / /_ | || | | _ | |_ _ ___
| |/| | | | | '_ \ / _ \ '_ | '_ | || || |) | | | | / |
| | | | || | |) | __/ | | | (_) | | __/| | || __ \
|| ||,| ./ _|| ||**/ || || ||**,|/
|| http://code.google.com/p/mupen64plus/
Mupen64Plus Console User-Interface Version 2.5.0

UI-Console: attached to core library 'Mupen64Plus Core' version 2.5.0
UI-Console: Includes support for Dynamic Recompiler.
Core: Couldn't open configuration file '/home/alex/.config/mupen64plus/mupen64plus.cfg'. Using defaults.
Core Warning: No version number in 'Core' config section. Setting defaults.
Core Warning: No version number in 'CoreEvents' config section. Setting defaults.
UI-Console Warning: No version number in 'UI-Console' config section. Setting defaults.
Core: Goodname: Super Smash Bros. (U) [!]
Core: Name: SMASH BROTHERS
Core: MD5: F7C52568A31AADF26E14DC2B6416B2ED
Core: CRC: 916B8B5B 780B85A4
Core: Imagetype: .z64 (native)
Core: Rom size: 16777216 bytes (or 16 Mb or 128 Megabits)
Core: Version: 1449
Core: Manufacturer: Nintendo
Core: Country: USA
UI-Console Status: Cheat codes disabled.
Video Warning: No version number in 'Rice-Video' config section. Setting defaults.
Video Warning: Old parameter config version detected : 0, updating to 1;
UI-Console: using Video plugin: 'Mupen64Plus OpenGL Video Plugin by Rice' v2.5.0
Audio Warning: No version number in 'Audio-SDL' config section. Setting defaults.
UI-Console: using Audio plugin: 'Mupen64Plus SDL Audio Plugin' v2.5.0
Input Warning: Missing or incompatible config section 'Input-SDL-Control1'. Clearing.
Input Warning: Missing or incompatible config section 'Input-SDL-Control2'. Clearing.
Input Warning: Missing or incompatible config section 'Input-SDL-Control3'. Clearing.
Input Warning: Missing or incompatible config section 'Input-SDL-Control4'. Clearing.
UI-Console: using Input plugin: 'Mupen64Plus SDL Input Plugin' v2.5.0
UI-Console: using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v2.5.0
Input: 1 SDL joysticks were found.
Input: N64 Controller #1: Using auto-config with SDL joystick 0 ('Logitech Logitech Dual Action')
Input: 1 controller(s) found, 1 plugged in and usable in the emulator
Input Warning: No rumble supported on N64 joystick #1
Input: Mupen64Plus SDL Input Plugin version 2.5.0 initialized.
Video: SSE processing enabled.
Video: Found ROM 'SMASH BROTHERS', CRC 5b8b6b91a4850b78-45
Video: Initializing OpenGL Device Context.
Core: Setting 32-bit video mode: 640x480
Video Warning: Failed to set GL_BUFFER_SIZE to 32. (it's 24)
Video Warning: Failed to set GL_DEPTH_SIZE to 16. (it's 24)
Video: Using OpenGL: NVIDIA Corporation - GeForce GTX 660 Ti/PCIe/SSE2 : 4.5.0 NVIDIA 352.63
Audio: Initializing SDL audio subsystem...
Input Warning: No rumble supported on N64 joystick #1
Core: Starting R4300 emulator: Dynamic Recompiler
Core: R4300: starting 64-bit dynamic recompiler at: 0x7eff37504bc0

Once it reaches the line to start the recompiler (or dynamic interpreter, or pure interpreter) the game window will open, but will remain black indefinitely. No sound is played, and while the game window can be exitted, nothing short of closing the terminal window exits the program.

@richard42 mentioned that he wanted to do release very soon (maybe April or May ?). So I'd like to discuss the agenda about that.

• What needs to be done before the release (code, wiki, documentation ...) ?
• What should be postponed until after that release (which PR) ?

Not really to pressure anybody with a schedule, just to allow sharing and organizing the work between interested developers.

Using latest mupen64plus-core(2.5.0) bundled with M64py (0.2.3).

Once in the game if I try to save my progress via the traditional game save method it simply creates a blank eep (At least this is what I believe).

To test,
I downloaded this eep file,
http://www.emutalk.net/attachment.php?attachmentid=35912

Replaced it and went to the main menu of the game and seen if the data showed up, it did indeed there for the loading of saved games was working properly.

I went back to my own saved state attempted to save a game got the "OK" confirmation and then proceeded to exit level, then exit game, came back to the load screen only to see that there were no saved games.

It's safe to note that the original save from the downloaded eep file also seemed to disappear I'm not sure if this was because I loaded a different state?

Save State/EEP
https://www.sendspace.com/file/1nyygt

I've seen this discussion on IRC a couple times.

Might as well bring it here.

Mar 23 23:01:20 Richard42: well there has been talk of basically getting rid of the audio plugin, and even possibly the input plugin
Mar 23 23:02:11 Richard42: I'm open to these kind of changes. the plugin architecture isn't the greatest thing in the world

Apr 08 20:59:14 rlabrecque: The biggest concern of mine with that is what do projects like libretro and bizhawk do with input?
Apr 08 21:00:22 Nebuleon: rlabrecque: every end of frame, pull events, compute the pressed button mask, send it over (or use it in the input plugin for the next frame)
Apr 08 21:01:07 Nebuleon: libretro uses logic like [while (!stop) { r4300_execute(); get_inputs(); }]
Apr 08 21:01:50 rlabrecque: Okay cool, yeah we could totally expose an API for that
Apr 08 21:03:00 Nebuleon: see issue 100: #100
Apr 08 21:03:02 rlabrecque: I'd love to use the SDL2 GameController API too, but I'm not sure how well it works with all the weird controllers we see with N64 Emulation (Like well... N64 controllers)

This would be post 2.5 of course.

Pull request #140 caused this when building with mingw64 for windows:

 ../../src/main/eventloop.c: In function 'event_sdl_filter':
 ../../src/main/eventloop.c:345:38: error: invalid operands to binary == (have 'union <anonymous>' and 'int')
              if(event->syswm.msg->msg == WM_MOVE)

On raspberry pi we have to use GL_RGBA with glReadPixels(). This means the buffer must be 4x the pixel count. However the core is expecting on 3x as GL_RGB is currently used.

Increasing the buffer size will stop mupen64plus from locking up the GPU but changing SaveRGBBufferToFile() to use 'width * 4', to get good screenshots, would require a change in all video plugins or an API change to get the expected pixel width from the video plugin.

Does anyone have any suggestions for the way forward?

Every single time I try to play "Coin Block Bash (Mario Party 1)" while playing a regular game (doesn't matter what map), mupen64plus crashes, this is the error I get:

mupen64plus: ../../src/r4300/new_dynarec/new_dynarec.c:9777: new_recompile_block: Assertion `(branch_regs[i].is32&(1LL<<f_regmap[hr]))== (regs[i+2].was32&(1LL<<f_regmap[hr]))' failed.

This is on a Raspberry Pi 3 using the latest git source.

I'm trying to get my PS3 controller to work with the run_rice command on my mac os x 10.11.2 system. I think I know the right button setup, but after I edit the configuration file at ~/.config/mupen64plus/mupen64plus.cfg and try to run the program the buttons revert to the defaults. If I change the mode to 0 then the file is not overwritten, but regardless my preferences don't seem to take effect. I also tried using the M64py front end and had the same behavior occur after setting up the controller in the UI. I feel like I must being doing something obviously wrong, but I can't figure it out.

My config file is attached in case it helps (renamed to .txt so the attachment is accepted).
mupen64plus.txt

Error "dyld: Symbol not found: ___strlcpy_chk" from within SDL2 lib used. A quick Google search of the exact text reveals command line git has the same issue, and reveals it's because they're being compiled for Mavericks and up now (10.9). I switch between OSX versions on my HDD for various reasons and noticed mupen64plus doesn't like Mountain Lion.

The reason this is an issue is because the readme says it works on 10.8 and maybe 10.7.

In Android, at least, Disney's Tarzan freezes after going in game. The core seems to continue running but the game seems to be stuck in a frozen state.

It doesn't matter if interpreter or dynarec is chosen. Also graphics plugin seems to have no effect either.

Just tested on armhf with build script from https://launchpad.net/~random-stuff/+archive/ubuntu/ppa

The build contains TEXTREL (aka - which makes the .so a broken/not PIC shared object)

CFLAGS="-g3 -O0" make -C projects/unix/ NEON=1 USE_GLES=1 OPTFLAGS=""  all -j4
readelf -d projects/unix/libmupen64plus.so.2.0.0|grep -i TEXTREL
 0x00000016 (TEXTREL)                    0x0
scanelf -qT projects/unix/libmupen64plus.so.2.0.0
  libmupen64plus.so.2.0.0: (memory/data?) [0xD6600] in (optimized out: previous .B8) [0xD65CC]
  libmupen64plus.so.2.0.0: (memory/data?) [0xD6604] in (optimized out: previous .jiptr) [0xD6600]
  libmupen64plus.so.2.0.0: (memory/data?) [0xD6608] in (optimized out: previous .jdptr) [0xD6604]
  libmupen64plus.so.2.0.0: (memory/data?) [0xD660C] in (optimized out: previous .tlbptr) [0xD6608]
  libmupen64plus.so.2.0.0: (memory/data?) [0xD696C] in (optimized out: previous new_dyna_start) [0xD6938]
  libmupen64plus.so.2.0.0: (memory/data?) [0xD6970] in (optimized out: previous .dlptr) [0xD696C]
  projects/unix/libmupen64plus.so.2.0.0

A valid PIC build is created when compiling without NEW_DYNAREC:

CFLAGS="-g3 -O0" make -C projects/unix/ NEON=1 USE_GLES=1 OPTFLAGS="" DYNAREC="" -j4 all
readelf -d projects/unix/libmupen64plus.so.2.0.0|grep -i TEXTREL
scanelf -qT projects/unix/libmupen64plus.so.2.0.0

All broken instruction/definitions which require a relocation can be found in src/r4300/new_dynarec/arm/linkage_arm.S

Hi all. As you maybe know, Google Code will be shutdown. Roughly:

• March 12, 2015 - New project creation disabled.
• August 24, 2015 - The site goes read-only. You can still checkout/view project source, issues, and wikis.
• January 25, 2016 - The project hosting service is closed. You will be able to download a tarball of project source, issues, and wikis. These tarballs will be available throughout the rest of 2016.

Technically, we have until August 24 to find where users could help each others. For now, a lot of help is provided under the google code issue page

I think it's important to keep github for dev related discussions, but we need to find a place for mupen64plus users to communicate, help each other, share, have fun, etc. :)

mupen64plus.github.io would be an interesting place to have a forum. But we definitely need a web dev for this.

But more important: Do we want this? I mean: Do we want mupen64plus to be more than an emulator? With a community of users/players/etc... Or do we want to let this to downstream projects?

IMHO, this is what make the difference between living projects or dying ones. Living projects can gather new contributors easily, have better/faster feedback, making work motivating. I was a mupen64plus user before jump into the code. You don't simply jump on the first dead project you found and if we don't fight a little, mupen64plus will look dead from the exterior.

I would also love to gather downstream projects into this forum, making a common place for devs to communicate with users. :)

@richard42 @bsmiles32 @gen2brain @Nebuleon @littleguy77 @twinaphex @cxd4 @conchurnavid and certainly others (don't hesitate to add them).

Samples are fed to the audio plugin indiscriminately during CPU emulation. When the audio plugin receives samples, it can sleep. This is very bad for input latency. Delays must not happen anywhere except immediately before input is sampled. The audio plugin should not feed samples to the driver except immediately before input is sampled.

I think new_vi() might also have an input/delay ordering problem but I can't test it since this is in the way.

write_aiX/??? -> X/gen_interupt -> write_ai_regs/ai_end_of_dma_event -> fifo_push/pop -> do_dma -> push_audio_samples -> push_audio_samples_via_audio_plugin -> aiLenChanged -> SDL_Delay

No mupen64plus installed on the system

$ wget https://github.com/mupen64plus/mupen64plus-core/raw/master/tools/m64p_helper_scripts.tar.gz
$ tar xvf m64p_helper_scripts.tar.gz
$ ./m64p_get.sh
$ CFLAGS="-g3 -fsanitize=undefined -fsanitize=address" ./m64p_build.sh OPTFLAGS="" INSTALL_STRIP_FLAG="" -j5
$ cd test
$ rm ~/.config/mupen64plus/mupen64plus.cfg
$ ./mupen64plus m64p_test_rom.v64
 __  __                         __   _  _   ____  _             
|  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ ___ 
| |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __|  
| |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__ \  
|_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|___/  
             |_|         http://code.google.com/p/mupen64plus/  
Mupen64Plus Console User-Interface Version 2.0.0

UI-Console: attached to core library 'Mupen64Plus Core' version 2.0.0
UI-Console:             Includes support for Dynamic Recompiler.
Core: Couldn't open configuration file '/home/conchur/.config/mupen64plus/mupen64plus.cfg'.  Using defaults.
Core Warning: No version number in 'Core' config section. Setting defaults.
Core Warning: No version number in 'CoreEvents' config section. Setting defaults.
=================================================================
==19508==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f22b28fde3f at pc 0x7f22b2550f33 bp 0x7fff98ca37f0 sp 0x7fff98ca37e8
READ of size 1 at 0x7f22b28fde3f thread T0
    #0 0x7f22b2550f32 in search_dir_file ../../src/osal/files_unix.c:124
    #1 0x7f22b2551515 in osal_get_shared_filepath ../../src/osal/files_unix.c:188
    #2 0x7f22b246a22b in ConfigGetSharedDataFilepath ../../src/api/config.c:1453
    #3 0x7f22b248333c in romdatabase_open ../../src/main/rom.c:420
    #4 0x7f22b246aade in CoreStartup ../../src/api/frontend.c:95
    #5 0x40a867 in main ../../src/main.c:654
    #6 0x7f22bd2cdb44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
    #7 0x4016db (/home/conchur/testzelda/test/mupen64plus+0x4016db)

0x7f22b28fde3f is located 1 bytes to the left of global variable 'retpath' from '../../src/osal/files_unix.c' (0x7f22b28fde40) of size 4096
0x7f22b28fde3f is located 59 bytes to the right of global variable 'reset_hard_job' from '../../src/r4300/reset.c' (0x7f22b28fde00) of size 4
SUMMARY: AddressSanitizer: global-buffer-overflow ../../src/osal/files_unix.c:124 search_dir_file
Shadow bytes around the buggy address:
  0x0fe4d6517b70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe4d6517b80: 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
  0x0fe4d6517b90: 04 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x0fe4d6517ba0: 00 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
  0x0fe4d6517bb0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
=>0x0fe4d6517bc0: 04 f9 f9 f9 f9 f9 f9[f9]00 00 00 00 00 00 00 00
  0x0fe4d6517bd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe4d6517be0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe4d6517bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe4d6517c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe4d6517c10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Contiguous container OOB:fc
  ASan internal:           fe
==19508==ABORTING

I'm reporting this long standing issue on behalf of the DK64 RTA & TAS communities.

I have completed a thorough technical analysis of the symptoms here
Savestates to reproduce the issue are available here

Let's squish this bug!

Signed integer overflow/underflow aren't well defined by the C standard and should be avoided. Problem can be seen when compiling like explained below and testing the save file attached to the thread "Ocarina of Time - Crash with Glide64mk2 (Bug Tracking) https://groups.google.com/forum/#!topic/mupen64plus/7tgGftNKNEA"

$ wget https://github.com/mupen64plus/mupen64plus-core/raw/master/tools/m64p_helper_scripts.tar.gz
$ tar xvf m64p_helper_scripts.tar.gz
$ ./m64p_get.sh
$ CFLAGS="-g3 -fsanitize=undefined -fsanitize=address" ./m64p_build.sh OPTFLAGS="" INSTALL_STRIP_FLAG="" -j5
$ cd test
$ rm ~/.config/mupen64plus/mupen64plus.cfg
$ (cd ./test/ && ./mupen64plus --gfx ./mupen64plus-video-glide64mk2.so --datadir `pwd` ../zeldaoot.v64  ) 

../../src/r4300/interpreter_special.def:275:18: runtime error: signed integer overflow: -1860206572 + -551095242 cannot be represented in type 'int'
../../src/r4300/interpreter_special.def:289:18: runtime error: signed integer overflow: -2147463642 - 2147360282 cannot be represented in type 'int'

This is especially interesting because the calculation ADDU and SUBU (275 and 289) are for unsigned and not for signed calculations. Misusing signed integers with underflows can lead to misoptimizations in newer GCC versions. For example endless loops. I think @cxd4 can enlighten us more because he already experienced it himself when he wrote some benchmarks for his rsp plugin

Hello,

Mupen64 does not emulate rightly Bomberman64: transition effect are not correct.
It is not easy to describe this, look at the video:
https://www.youtube.com/watch?v=mE1DaVMN6pE

and now try this game with Mupen64: at start the transition are not right.

@gizmo98

I am having difficulty with this line when I try to compile for Android. In our makefile, we set the following CFLAGS for ARM-v7a:

    LOCAL_CFLAGS += -mfloat-abi=softfp
    LOCAL_CFLAGS += -mfpu=vfp

The GCC 4.8 linker throws an error ... new_dynarec/linkage_arm.o uses VFP register arguments, output does not.

If I comment out the line marked here, everything builds again, so it seems to me that either

• __VFP_FP__ or __SOFTFP__ is not being set properly in Android NDK 10d, or
• the #ifdefs here need to be tweaked, or
• we need to tweak something in the Android makefile

Any thoughts?

@Gillou68310, @paulscode, @xperia64 Here is the commit on my branch where you can test, if you have any ideas: littleguy77/mupen64plus-ae@f75c70e

Mainly a question but when I compile the core I have this:

_obj/si/eeprom.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters

I never notice it before.

When building mupen64plus-core with the New_Dynarec_Release or New_Dynarec_Release configurations, Visual Studio reports the following errors:

..\..\src\r4300\new_dynarec\new_dynarec.c(484): error C2275: 'u_int' : illegal use of this type as an expression
          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\include\winsock.h(46) : see declaration of 'u_int'
..\..\src\r4300\new_dynarec\new_dynarec.c(484): error C2146: syntax error : missing ';' before identifier 'page'
..\..\src\r4300\new_dynarec\new_dynarec.c(484): error C2065: 'page' : undeclared identifier
..\..\src\r4300\new_dynarec\new_dynarec.c(485): error C2065: 'page' : undeclared identifier
..\..\src\r4300\new_dynarec\new_dynarec.c(486): error C2065: 'page' : undeclared identifier
..\..\src\r4300\new_dynarec\new_dynarec.c(487): error C2065: 'page' : undeclared identifier
..\..\src\r4300\new_dynarec\new_dynarec.c(491): error C2065: 'page' : undeclared identifier
..\..\src\r4300\new_dynarec\new_dynarec.c(530): error C2065: 'page' : undeclared identifier

Strangely, it succeeds if unsigned int is used instead of u_int on line 484 in new_dynarec.c

Help my RSP settings have vanished and cant find them i redownloaded it several times and still no RSP settings

Commit bdb8a88 brakes new_dynarec arm target.
../../src/r4300/new_dynarec/arm/assem_arm.c:22:28: fatal error: ../cp0_private.h: No such file or directory
compilation terminated.
Makefile:666: recipe for target '_obj/r4300/new_dynarec/new_dynarec.o' failed
make: *** [_obj/r4300/new_dynarec/new_dynarec.o] Error 1

Line 22 should be something like: #include "../../cp0_private.h"
https://github.com/mupen64plus/mupen64plus-core/blob/master/src/r4300/new_dynarec/arm/assem_arm.c#L22

--configdir doesn't change the highres_texture dir

A few people on paulscode.com are asking about a configurable VI refresh rate option (like PJ64).
The main motivation is when using a lag remover cheat code (which typically disable ingame framelimiter), but such a cheat code should be reversed compensated by lowering VI Refresh Rate value in order to get back initial framerate.

Using this combo sometimes help fixing framerate issues in some games.

@richard42 @Narann do you mind if I add such an option?

Copied and pasted from: http://www.paulscode.com/forum/index.php?topic=1818.915

Army Men: Sarge's Heroes-- The game's sound completely cuts out in the beginning of the second level. Restarting the game brings the sound back, but it just quickly cuts out again after you reload the second level and play it for about 30 seconds to a minute. I decided to keep playing until I made it to the third level. I then restarted the game again and loaded up the third level where I left off. The sound was there for about 30 seconds and then quickly cut out again. Changing the graphic and audio plugin didn't fix it.

This was fixed by switching to cached interpreter.

The libretro guys observed this issue a good two years ago: libretro/mupen64plus-libretro#63 Seeing the same symptoms in M64Py 2.3; from a quick skim of the commit log I didn't see any attempt to directly address it.

By all appearances ingame: when game-save data is written, a copy is written in all subsequent slots i.e. saving in slot 2 replicates the data to 3 and 4. The errant duplicates appear after returning to the title screen and reopening the load menu. Trying to copy saves has the same effect, starting from the slot copied to. Bizarrely, deleting a save doesn't behave the same way.

Seen claims that Project64 shows the same issue. Makes me wonder if the game had an unusual flash RAM setup that nobody noticed.

Been working on 64DD emulation for a while, implemented code on 64DD ports like I did with Project64, and then with the actual emulation, using MAME 64DD disk format as it is closer to physical (makes it easier).

Except it's quite hard to implement, and every disk reads makes mupen64plus freeze (the debugger still says it works, even though the window clearly froze).
And I don't know why.

https://github.com/LuigiBlood/mupen64plus-core/tree/64dd/src/dd

Glover is crashing with the new arm dynarec. It crashes within a few seconds of starting the game. The core crashes and produces this core dump:

Build fingerprint: 'motorola/quark_verizon/quark:5.1/SU4TL-49/5:user/release-keys'
pid: 14559, tid: 30188, name: CoreThread  >>> org.mupen64plusae.v3.alpha <<<
signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x8f5e5560
Stack frame 07-29 02:10:07.638 400-400/? I/DEBUG:     #00 pc 001f2560  <unknown>: Unable to open symbol file .\Mupen64Plus-AE-Studio\mobile\src\main\obj\local\armeabi-v7a/<unknown>. Error (22): Invalid argument
Stack frame 07-29 02:10:07.638 400-400/? I/DEBUG:     #01 pc fffffffd  <unknown>: Unable to open symbol file .\Mupen64Plus-AE-Studio\mobile\src\main\obj\local\armeabi-v7a/<unknown>. Error (22): Invalid argument

This is probably the relevant portion:

signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x8f5e5560

Hi,

I am referencing this commit: 14bf40b

Using mupen64plus 2.5-4 on Arch Linux, I try to stop the emulator using two simultaneous button presses as stated by this documentation: http://www.mupen64plus.org/wiki/index.php?title=Mupen64Plus_Core_Parameters

The problem is, it just won't work. This is the relevant part of my configuration:

[CoreEvents]
Joy Mapping Stop = "J0B6/B7"

The button after the slash just gets ignored. The emulator stops by just pressing B7. If I change the statement to "J0B7/B6", the emulator stops by just pressing B6.

I tried different controllers and different button combinations with the same result.

Bliss-Box developers have offered support for the VRU, we need to get the interface working for them though.
See here:
http://www.emutalk.net/threads/55279-Hey-You!-Pikachu-Possible-HLE-Implementation/page4

If we can get the VRU working through BlissBox, an HLE implementation through any mic shouldn't be far behind. Issue is that I don't think the controller plugin currently has support for the VRU, I believe the Mupen plugin doesn't have any Adaptoid-style support for RAW input, correct?

Hey there,

I was having the hardest time figuring out why I was unable to load the glide64mk2 plugin from the 2.5 release, but it seems that was due to a missing dependency, libboost-system-1.46.1 and libboost-filesystem-1.46.1. I'm on Linux Mint 17 and that was not available from the repos. I was, however, able to get it working by manually downloading a deb from and older Ubuntu repo.

I wasn't sure if this should go in the repository for the plugin or here, but I figure it'd be of interest to anyone using the official release.

Any chance things could be updated to use a newer version of libboost? I have no idea if this is trivial or difficult.

This ticket is to engage a discussion started on the IRC about removing SDL1.2 dependency for Windows bins in favor of SDL2.

So:

• Remove SDL1.2 from win32dep repo.
• Put SDL2 in win32dep repo.
• Clean VS projects (the hardest part).

Pros? Cons?

Hey,
thank you for this wonderful emulator!
But I have an issue with Mario Kart 64:
When playing Mario Kart 64 in multiplayer, only Player 1 is visible. All other players have a black screen.

Any suggestions?

Greetings

Platform: Windows 7 64-bit
Emulator build: Mupen64Plus 2.5 64-bit

This issue deals with four games specifically: Banjo-Kazooie, Banjo-Tooie, Donkey Kong 64, and Perfect Dark. These games all lock up during their intros at some point or another while using any LLE video plugin. I've tested this using both z64 and GLideN64, with both the CXD4 and z64 RSP plugins. The same thing also happens in the libretro fork, which uses Angrylion's plugin as its LLE plugin. Happens using both the dynarec and interpreter cores.

For what it's worth, these games do not have this problem on Mupen64Plus 1.5, nor on the original Mupen64, with the exception of Donkey Kong 64.

It was working great. I beat mario 64 on it. Had it for 2 weeks. Suddenly out of no where, any game I open with N64, i get an error message saying "Couldn't communicate with a helper application" Can I get help? All other roms works fine. Its just the n64 emulator. I play open emu on a Macbook Air. Thanks!

Use joystick device name section (for example Playstation3Controller) of InputAutoConfig.ini instead of joystick device (/dev/input/js*) mapping of mupen64plus.cfg to store hotkeys for controller. If controllers changes the right hotkey will be applied.
https://github.com/mupen64plus/mupen64plus-input-sdl/blob/master/data/InputAutoCfg.ini

Hi,

To begin, thanks everyone for your great work on Mupen64plus, it's awesome.

I'm working to make the netplay for mupen64plus and I posted a message in google code few days ago.
https://code.google.com/p/mupen64plus/issues/detail?id=16&colspec=ID%20Type%20Component%20Status%20Priority%20Stars%20Milestone%20Owner%20Summary
It's my bad, you moved on github :)

I'm aiming to have the netplay for maximum 4 network players with all combinations available. (Multiple locals vs network etc...)

This morning I pushed a version with the support of 2 players (One by computer)
ymartel06@6fe81b9

To test it, get my console https://github.com/ymartel06/mupen64plus-ui-console and my core https://github.com/ymartel06/mupen64plus-core/.
Then you can launch the server with:
mupen64plus-ui-console.exe --server your-rom
For the client:
mupen64plus-ui-console.exe --client IP your-rom

Currently, it's only TCP (UDP will come really later) and the default is 6464 (you can change it using --server-port).

Before to work on the 4 players, I will work on:

• Fix the clock to take care of CLOCKS_PER_SEC for the client. I use a clock sync to be able to launch the emulator at around the same time.
• Don't allow to press pause, forward, backyard and more, when the emulator is in network
• Try to build it on Linux / MacOS and fix what is needed (I try to make everything cross platform but I can have a bad surprise)
• Add an option to force the frame sync between players (good to have the same simulation but can be laggy, looks like this concept http://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php)

Known issue:

• When you move the render window, you can have some disconnection.

Of course feedbacks are welcome. If you want some explanations of what I made (like flow or technical), I will try my best to answer.

Note: It seems I can't open a discussion.

Following the installation instructions found here

https://github.com/mupen64plus/mupen64plus-core/blob/master/tools/osx_build_instructions.txt

I got this error when I installed:

../../src/GlideHQ/TxHiResCache.h:37:10: fatal error: 'boost/filesystem.hpp' file not found
#include <boost/filesystem.hpp>
         ^
1 error generated.
make: *** [_obj/GlideHQ/TxFilterExport.o] Error 1

I'm not sure why this boost library can't be found. First I installed boost with brew install boost which installed version 1.57.0. After that I tried installing boost manually by following the instructions on boost.org. I when installing manually I installed without the --with-libraries option, so I believe all of the libraries, including filesystem have been installed.

Is there more information that could be provided in the osx_build_instructions.txt that could help with the configuration problem I'm having?

Some internal controller names differ only in spaces from each other. As it subdivides the words between spaces, the spaces are not being taken into account. The name has to do with the firmware of the controllers, and cannot always be changed if the firmware isn't upgradable. As a consequence, many controllers can't be used together.

Sometimes, when entering the in-game subscreen in the LoZ: Ocarine of Time Master Quest (Debug), the core will lock up taking 100% of the CPU and the app has to be killed. This is using the arm dynarec. With interpreter the issue doesn't happen.

There are three defects in the coverity report which are about switch "case" without break and also no /* fall through */ comment.

There are 38098, 38099 and 38100.Does anyone know if the break is actually missing or just the comment is missing to point out that this is intentionally?

@Gillou68310

I'm seeing this crash reported on the ARM version of the new dynarec:

"oops, branch at end of block with no delay slot"

I'm seeing this happen in Banjo-Tooie. Here is a save state:
Banjo-Tooie-crash.zip

Face the big digging machine and throw an egg at it by holding Z and C-UP

This is happening in new_dynarec.c at line 8553.

Mario Story freezes during the intro while moving through Toad Town.

Steps to reproduce

1. Load Mario Story Rom on mupen64plus 2.5
2. Create file
3. Open file
4. Play through and when you leave Mario Bros house it freezes on the way to Princess Peach's Castle.

I realize processDList() function is totally useless and should be remove both from core and API.

@Guillou68310 point it would be great Travis CI to test both old and new dynarec build.

Im sure I shouldnt be posting here, but im at a loss. Ive posted to the mupen64+ forum, with no responses.
Im using Mupen64+ 2.2.4 (version 36) on android 4.0.4. and using Sixaxis (no version. download from playstore 7-2-15)
I can map buttons on the controller, I can go through the menu, but when I start to play a game, nothing on the controller registers.
Ive got the controller setting set in android. Ive set the controller (non-touchscreen) set on Mupen64+, but it just wont play.
Its a generic Gasia controller, but SixAxis recognizes it, and found a 'work around', and every other emulator I have works without issue.
Any ideas?

Using the latest core bundle on Windows.

Issue: When I alt-tab out, I can not move the mouse. It is stuck in the top left corner. ctrl alt in the emulator does not release the mouse.

Expected behavior: ctrl alt should show and release the mouse cursor

Steps to reproduce: With mouse = False set on every controller, launch a ROM and alt-tab out.

The Win32 subsystem version for generated binaries is set to "6.0", which does not allow the emulator to work on Windows NT 5.x series (2000, XP and 2k3).

If patched to "4.0", the emulator works with no problem. Since the emulator does not appear to use any NT 6.x-specific functions, it's meaningless to set subsystem version to "6.0".