What's new

Mupen64Plus Release Candidates now out - please test!

Richard42

Emulator Developer
Hello N64 fans!

It's been over a year since the last Mupen64Plus release, and we're gearing up to finally get v2.0 out of the door. Everything that I really wanted to be in this major milestone release is there, and all that's left is the testing. That's where I'm hoping that you can help us. I have put up some release candidate packages on our Google Code download page, and we need testers to play with these to find any last-minute bugs before we tag version 2.0.

Some of the particular features of Mupen64Plus that have changed and deserve some attention are:

  • saving and loading PJ64 state files (including both compressed and uncompressed pj64 states)
  • native mupen64plus save/load state files
  • all 3 core modes: dynarec, cached interpreter, and pure interpreter
  • all 3 major OS platforms: win32, linux, osx. I think most of our users are on Linux, so it would be good to get feedback from more Windows and OSX users.
  • saving, loading, and sharing state files between big-endian (ARM, PPC) and little-endian (Intel/AMD) machines
  • Input auto-detection use cases (joystick and keyboard configurations)
  • window resizing (currently only supported with the Rice video plugin and ui-console front-end application)

Developers: I will not accept pull requests or patches for new features (only bug fixes) until after the 2.0 release.

Some platform-specific notes:
  • win32: I built this package with Visual Studio 2012, and I think it will only run under Vista or newer version of Windows. Making it run under older Win32 platforms would be a little tricky. I could use an older compiler to build everything except the new Glide64MK2 plugin pretty easily. But this plugin uses the new multi-threading features of C++11, which is not supported in older versions of MSVC. If some enterprising developer would like to lend a hand, I would accept a patch to replace the C++ threading implementation with something that uses SDL threads, since SDL is already required for this video plugin. The other option that I have is to cross-compile the Win32 build with something like cygwin or mingw, but I'm afraid that this will be complicated and require many additional run-time dependencies. Please let me know if you really need this emulator under Windows XP or older, and if enough people speak up I will make sure to support this OS for the final 2.0 release.
  • linux: the binary packages require libpng15, which may not be present on older distros. Please report if you can't run the binaries due to missing libpng libraries; I can make a special build which links against an older version of libpng.
  • osx: the binary package was built with the OSX 10.7 SDK, so it requires 10.7 or newer. The glide64mk2 video plugin is not present because there is no Apple compiler (either gcc or clang under OSX 10.8) which supports c++11 threads. Again, if some enterprising developer would like to remove the C++ threading and replace it with SDL threads, then I could make an OSX build of Glide64mk2, and I'm sure lots of Mac owners would be happy. You would also get bonus points for removing the dependency on boost::filesystem, because this is major extra dependency which causes much heartache and trouble for little benefit.

Please report bugs in this emutalk thread or come to our IRC channel (#mupen64plus on irc.freenode.net) for help.
 

Cheogh

New member
Archlinux 64bit - After running install.sh then typing mupen64plus in a terminal I get "UI-Console Error: dlopen('./libmupen64plus.so.2') failed: ./libmupen64plus.so.2: cannot open shared object file: No such file or directory
UI-Console Error: AttachCoreLib() Error: failed to find Mupen64Plus Core library"

Windows 7 64bit - I get a error about missing msvcr110.dll, I even downloaded the file and put it in the folder, but it still gave the same message.

Also uninstall.sh gives "rmdir: failed to remove ‘/usr/local/share/man’: Not a directory"
 
Last edited:

Zuzma

New member
Works fine on my windows 7 64bit system. Even got it working with my real n64 pad. Though I did notice a weird problem with glide64mk2 when playing mario64. The ground geometry will warp and wobble if you're looking at it from a certain angle. I thought it was my video drivers at first, but it has the same problem with the android port of the plugin.

http://www.youtube.com/watch?v=BmqE7jKX2Xo
 
Last edited:
OP
R

Richard42

Emulator Developer
Archlinux 64bit - After running install.sh then typing mupen64plus in a terminal I get "UI-Console Error: dlopen('./libmupen64plus.so.2') failed: ./libmupen64plus.so.2: cannot open shared object file: No such file or directory
UI-Console Error: AttachCoreLib() Error: failed to find Mupen64Plus Core library"

Windows 7 64bit - I get a error about missing msvcr110.dll, I even downloaded the file and put it in the folder, but it still gave the same message.

Also uninstall.sh gives "rmdir: failed to remove ‘/usr/local/share/man’: Not a directory"

Thanks for reporting your results. I'm running Gentoo, which is quite similar to Arch, and I was able to install using the script and run it. Did you run the install.sh script as root? Did it tell you "Installation successful."? If not, the install won't work. I will add something to this script to check for root access level before trying to install.

I was able to replicate a similar problem in the uninstall script. Some distros use symbolic links for directories like /usr/local/lib, and this screws up our directory removal code.

For the windows 7 thing, it sounds like you're missing the visual studio 2012 redistribution libraries. I'll have to dig into this a bit more.
 

Zuzma

New member
Hmm did i post a false bug? I'm sorry if I did. Mario64 is pretty much the only game I ever really play on the n64. I was pretty impressed how good this emulator was since I never used it before.
 

tony971

New member
I can confirm that the Windows 7 issue is caused by not having Visual Studio 2012. You can fix it by downloading Visual C++ Redistributable for Visual Studio 2012 (x86 version) from the Microsoft website. If it's possible, it could make sense to have that be a dependent package.
 

V1del

New member
Thanks for reporting your results. I'm running Gentoo, which is quite similar to Arch, and I was able to install using the script and run it. Did you run the install.sh script as root? Did it tell you "Installation successful."? If not, the install won't work. I will add something to this script to check for root access level before trying to install.

Pretty sure its not the install that went wrong per se, but you have to give the location of the corelib each time you want to start, because the default search value seems to be nowhere near where the corelib
is put (/usr/local/lib), while by default it only checks for the lib in the same directory as the runtime (which would have to be \usr\local\bin)

Played around with it some time, here are my first moment findings, with Arch Linux 64bit and nvidia 319.23 :

- Glide64mk2 still doesn't stretch properly, which may be because 1920x1080 isn't really a "standard" n64 resolution.
- Resizing with Rice works fine, except if you resize your window to something arbitrary and then try to fullscreen, there will be following error and video output will be lost

Code:
  Core Error: VidExt_ResizeWindow() called in fullscreen mode.
  Core Error: VidExt_ResizeWindow() called in fullscreen mode. 
  Video Error: Failed to set 32-bit video mode: 373x269

In addition to that, if you resize to something that can be fullscreened, the screen will stay at the size of the original window. Can't say much about the new input possibilities, as i use a keyboard and just switched the mode to 0 so i can configure my keys. Didn't have time to really check any specific game, quick cycles through dynarec and the two interpreters didn't show any major problems and savestating/loading was no problem, at least on mario64 and kirby64
 
Last edited:
OP
R

Richard42

Emulator Developer
V1del, thanks for the testing. The ui-console application actually looks in 3 or 4 places to find the core library. The code is starts at line 120 of core_interface.c. I think the problem is that your distro does not have our default library install location (/usr/local/lib) in your /etc/ld.so.conf file. I will make a change to the bundle build script which will hard-code this path for checking during the core attach process. That should solve this problem. I think I tested the fullscreen-after-arbitrary-res-resize case on my PC and it worked, but I have an AMD graphics card. I'll try to reproduce this on a laptop with nvidia hardware.
 

V1del

New member
Ah good to know, can confirm that the path is missing in the ld.so.conf and adding it there loads the lib without having to add the corelib argument each time, thanks for looking into the other issues as well, you guys are doing an awesome job !
 

stag019

New member
  • linux: the binary packages require libpng15, which may not be present on older distros. Please report if you can't run the binaries due to missing libpng libraries; I can make a special build which links against an older version of libpng.
I had exactly this problem. I tried installing it last night, and tried installing libpng15 alongside the version already there, but then I needed zlib, and then I needed to get some sleep.

Could you make the special build so I can give it a try?
 
OP
R

Richard42

Emulator Developer
I am interested in seeing a Windows XP compatible build.

Okay, I have uploaded a new Windows build here which should be compatible with XP. Please give it a try and post your results.

I had exactly this problem. I tried installing it last night, and tried installing libpng15 alongside the version already there, but then I needed zlib, and then I needed to get some sleep.

Could you make the special build so I can give it a try?

I have also uploaded a 64-bit "ubuntu friendly" build here, which I compiled on an Ubuntu 12.04 laptop. This should fix your libpng15 dependency problem, though it is likely that you'll still have to install zlib. Once the official 2.0 release is made and this works its way into the distro package managers, these dependency problems will be handled automatically.
 

V1del

New member
Some Windows Testing, can't entirely confirm those issues to be only present on Windows yet.
Code:
Core Warning: two events of type 0x80 in interrupt queue
Core Warning: two events of type 0x100 in interrupt queue

What Perfect Dark (E) spits out before dying minutes into the game (with any core).

Also there seems to be some weird osd behaviour and it doesn't fade out properly and just stacks outside of the rendered area on changing/saving states (noticable in Kirby, other games worked fine)
 
OP
R

Richard42

Emulator Developer
Some Windows Testing, can't entirely confirm those issues to be only present on Windows yet.
Code:
Core Warning: two events of type 0x80 in interrupt queue
Core Warning: two events of type 0x100 in interrupt queue

What Perfect Dark (E) spits out before dying minutes into the game (with any core).

Also there seems to be some weird osd behaviour and it doesn't fade out properly and just stacks outside of the rendered area on changing/saving states (noticable in Kirby, other games worked fine)

I also get the lockup in Perfect Dark (Linux, AMD video card); can you file an issue report for this in our google code issue tracker?

The unfortunate OSD behavior in Kirby is actually an artifact of the way that the games (ROM) work. They don't always tell the emulated N64 graphics hardware to blank or redraw all of the screen, so the fragments of the OSD text stay there. It's not an easy thing to fix, and since it only affects a few games it hasn't been a high priority.
 

V1del

New member
I also get the lockup in Perfect Dark (Linux, AMD video card); can you file an issue report for this in our google code issue tracker?

Done. Yeah osd issue isn't really that much of a problem and kirby does indeed have some weird screen redraws had to manually change the redraw method in earlier rice versions to prevent flashes. Also Glide64mk2 doesn't want to stretch on Windows either, I'm guessing there's some nvidia driver behaviour which doesn't want to play along with it :/. Will try it out on an intel laptop when i get to it.
 
OP
R

Richard42

Emulator Developer
Done. Yeah osd issue isn't really that much of a problem and kirby does indeed have some weird screen redraws had to manually change the redraw method in earlier rice versions to prevent flashes. Also Glide64mk2 doesn't want to stretch on Windows either, I'm guessing there's some nvidia driver behaviour which doesn't want to play along with it :/. Will try it out on an intel laptop when i get to it.

Great; thanks for posting the issue report. The Glide64mk2 plugin currently does not support window resizing. The resizing thing was kind of complicated: it requires support in the core, the front-end application (if the video extension is used), and the video plugin. I only added support and tested with Rice; I expect that support for this feature in glide64mk2 won't happen until after the 2.0 release. When SDL resizes the window it destroys the opengl context and creates a new one, so the video plugin will lose all of its textures, arrays, shaders, etc. So it must re-create them all after the resize, and this can be a bit tricky.
 

V1del

New member
I'm not talking about resizing, but actually making the image fit to the resolution being passed with the --resolution option, in my case 1920x1080, on startup. This works fine for all other plugins except glide64mk2 where it just keeps a small 4:3 in the center of the screen. I remember reading a post of yours on GoogleGroup where you said it works for you, but it seems like the nvidia driver somehow doesn't want to play along.
 

Moshroum

New member
The core doesn't build anymore against SDL 2.0-rc1

Code:
../../src/main/eventloop.c: In function ‘event_sdl_filter’:
../../src/main/eventloop.c:262:14: error: ‘SDL_VIDEORESIZE’ undeclared (first use in this function)
../../src/main/eventloop.c:262:14: note: each undeclared identifier is reported only once for each function it appears in
../../src/main/eventloop.c:265:40: error: ‘SDL_Event’ has no member named ‘resize’
../../src/main/eventloop.c:265:57: error: ‘SDL_Event’ has no member named ‘resize’
 

Top