Mupen64Plus release candidate!

[Richard42]

Emulator fans, come and test our release candidate of the upcoming Mupen64Plus version 1.3. The major features of this emulator are:

- runs on 32-bit or 64-bit Linux systems with optimized code
- includes 3 great OpenGL video plugins: glN64, RiceVideoLinux, and glide64
- massively cleaned-up interface code; GTK GUI build and "nogui" build are unified
- install/uninstall scripts to properly handle a multi-user environment
- bugfixes in the 64-bit dynamic recompiler, GTK GUI, and plugins

I would like to acknowledge Ebenblues, who put a lot of work into the enhancements and changes, and Günther, who made a backwards-compatible 64-bit port of Glide64 included here.

You can download the packages here:

Mupen64Plus-1-3-RC1-bin-32.zip
Mupen64Plus-1-3-RC1-bin-64.zip
Mupen64Plus-1-3-RC1-src.zip

Or you can get the latest SVN snapshot and build your own with this repository:
svn://fascination.homelinux.net:7684/mupen64plus/trunk/
There is read-only access for the username "mupen64" with password "Dyson5632-kart".

So please test it out and report bugs in this thread. We'll make an official release in a couple of weeks after addressing the issues reported here. We would also be interested to talk with distro packagers to get it included with upcoming Linux distributions.

 

[mudlord]

Yay!

I'm happy I set up my dual boot with Linux, so I can try out this. I tried out your previous compiles, and they work just fine. My only concern is the input plugins and how to set keys, though I'll try this compile set and see how it works.

Nice job btw.

 

[Richard42]

I'm happy I set up my dual boot with Linux, so I can try out this. I tried out your previous compiles, and they work just fine. My only concern is the input plugins and how to set keys, though I'll try this compile set and see how it works.

Nice job btw.

Let us know how it goes. BTW thanks to you also mudlord. I was using VisualBoyAdvance 1.7.2 in my downstream project and I noticed some sound glitches in Metroid Fusion. So on Sunday I grabbed a VBA-M snapshot from SVN and built it for my HTPC box. It runs perfectly with the HQ3X filter with no sound glitches and really nice visuals on my TV. I love it; I played a bunch of Crash Bandicoot and Metroid Fusion tonight and it was great!

 

[kosmi]

Hi, just to mention two small problems with compilation (Ubuntu Gutsy 32-bit) that i have with this RC release. I'm will testing some games later

1. glide64 plugin: stops for me because of yasm (v0.5) again, for me that works with:

yasm -f elf -DBITS=$(BITS) $< -o $@

2. install: tipo in install.sh:

INSTALL=ginstall

Also i have one proposal: If this will to be emulator for linux only, 'mupen64plus-1.3' is proper name for src package, also use of tar.gz or tar.bz2 for compression. I think, every distribution packagers will agree with this.

 

[ebenblues]

2. install: tipo in install.sh:

INSTALL=ginstall

Thanks for the feedback. I actually have a ginstall program on my system, but looking closer I see it's a symlink to /bin/install. I updated install.sh to look for install executables in the following order: /usr/bin/ginstall, /bin/ginstall, /usr/bin/install, /bin/install. Hopefully that should address your concern.

 

[kosmi]

I never heard of this ginstall program, but OK maybe that solution will helps both of us. I'm will try this with some following RC release.

I'm using glide64 because this is good for me in most cases, but not with this included in RC. Games now goes stright in fullscreen (rice and glN64 don't), F1 not work like in previous versions and custom fulscreen resolution in glide64 configuration gtk dialog not working, it now start always with 640x480 and use 'window resolution' for fullscreen.

edit: to be more clear, F1 in v12 is used to change fulscreen mode or window, now not leave fullscreen and just goes to the smallest 320x200 plus another hit on it now not working

I think that all plugins must functioning in the same fashion on its default values.

 

[Richard42]

I never heard of this ginstall program, but OK maybe that solution will helps both of us. I'm will try this with some following RC release.

I'm using glide64 because this is good for me in most cases, but not with this included in RC. Games now goes stright in fullscreen (rice and glN64 don't), F1 not work like in previous versions and custom fulscreen resolution in glide64 configuration gtk dialog not working, it now start always with 640x480 and use 'window resolution' for fullscreen.

edit: to be more clear, F1 in v12 is used to change fulscreen mode or window, now not leave fullscreen and just goes to the smallest 320x200 plus another hit on it now not working

I think that all plugins must functioning in the same fashion on its default values.

I'm aware of the fullscreen compatibility issue in Glide64. I think it was broken during the Linux porting process. Originally it refused to go into fullscreen at all, so I hacked it to properly use one of the config file parameters to select window/FS. I need to make it work with the command-line option and the F1 key.

The reason I've been using zips instead of .tar.bz2 for the packages is that ZIP removes the user info from the files, which is what I want. When I used .tar.bz2, it saves the UID with the files and when they're extracted they end up being owned by either root or a UID which may be invalid for your system. There should be some way around this, I just haven't taken the time to find it.

 

[phorsyon]

Hello everybody, I've just registered to this forum to post my first bug report.
I used the 64bit binary and discovered the following bugs:

1. The "--noask" switch stopped working

2. To many useless confirmations
2.1 Load a rom which is a "bad dump" or a "hack"
2.2 You get asked if you want to load the rom anyway. Choose "No"
At this point no more popups should appear, but it goes on.
2.3 Confirm: "There is no Rom loaded. Do you want to load one?". Choose "No"
2.4 Error: "Couldn't load Rom!" --> OK

I also have (still) graphical issues in with some roms like objects rendered invisible or black and heavy screen flickering especially with split screen. Would it help you out if i report those too?

BTW: Thanks to all the developers for making a great N64 emulator for unix. :-D

 

[csi]

Great work, respect for those improvements to mupen64.

I noticed:
1. Starting the configuration panel does not show any default plugin enabled.
2. Starting RiceVideoLinux config panel resets resolution to 320x240.

I recently started to play with hi-resolution packs (http://www.emutalk.net/showthread.php?t=42231), and RiceVideoLinux doesn't seem to cope with them yet. It did work for some packs with RiceVideoLinux v1.1, but often crashed cause of color depth issues. I suppose this is a known request. (BTW Is the right place to ask about RiceVideoLinux plugin?)

 

[ebenblues]

I used the 64bit binary and discovered the following bugs:

1. The "--noask" switch stopped working

2. To many useless confirmations
2.1 Load a rom which is a "bad dump" or a "hack"
2.2 You get asked if you want to load the rom anyway. Choose "No"
At this point no more popups should appear, but it goes on.
2.3 Confirm: "There is no Rom loaded. Do you want to load one?". Choose "No"
2.4 Error: "Couldn't load Rom!" --> OK

Cool, thanks for the feedback. You're right, --noask functionality was accidentally lost during the gui/nogui merge. I'll look into both of these issues.

 

[ebenblues]

I noticed:
1. Starting the configuration panel does not show any default plugin enabled.
2. Starting RiceVideoLinux config panel resets resolution to 320x240.

Thanks for pointing these out. I'm wondering if you may be experiencing these issues due to the new multi-user support code. In this version, the first time you run mupen64plus, a .mupen64plus dir is created in your home directory and default config files for the emu and the plugins are copied to it.

Problem #1 you pointed out should only happen the first time you run mupen64plus. Once you select plugins in the configuration window and click Ok, they will be selected the next time you run the program. If that's not the case, let me know. Otherwise, I'm working on a fix so plugins are selected the first time you run it.

Along the same lines, did problem #2 only happen the first time you ran mupen64plus? What I mean is, if you change the resolution in the config panel, exit mupen64plus and start it again, does the resolution setting you changed still get reset to 320x240? If so, then that's a bug. If not, then it's just a side effect of getting the default config the first time you run mupen64plus.

 

[csi]

Thanks for pointing these out. I'm wondering if you may be experiencing these issues due to the new multi-user support code.

I just compiled the source with make all, but I did not run install.sh.
This is not an issue for .mupen64plus which is created in my home directory at binary launch.

Problem #1 you pointed out should only happen the first time you run mupen64plus. Once you select plugins in the configuration window and click Ok, they will be selected the next time you run the program. If that's not the case, let me know. Otherwise, I'm working on a fix so plugins are selected the first time you run it.

Yes, this only happens the first time, but it is kind of annoying for newcomers.

Along the same lines, did problem #2 only happen the first time you ran mupen64plus? What I mean is, if you change the resolution in the config panel, exit mupen64plus and start it again, does the resolution setting you changed still get reset to 320x240? If so, then that's a bug. If not, then it's just a side effect of getting the default config the first time you run mupen64plus.

This is a bug. Resolution setting from RiceVideoLinux is reset to 320x240 every time I launch its configuration panel.

I recently started to play with hi-resolution packs (http://www.emutalk.net/showthread.php?t=42231), and RiceVideoLinux doesn't seem to cope with them yet. It did work for some packs with RiceVideoLinux v1.1, but often crashed cause of color depth issues.

Fixed, I was not aware of ~/.mupen64plus/plugins/hires_texture/ folder.

 

[piccolo17486]

sounds like a intresting version, but i dont have linux installed right now. is a os-x port possible?

 

[Richard42]

I also have (still) graphical issues in with some roms like objects rendered invisible or black and heavy screen flickering especially with split screen. Would it help you out if i report those too?

Please do report graphical issues here. Give us the following information:
1. machine type (32-bit or 64-bit)
2. version of Mupen64Plus
3. which video plugin was being used
4. game name and CRC/MD5 hash (printed on console)
5. description of the artifact (missing polygons, flashing, wrong colors, etc)

(BTW Is the right place to ask about RiceVideoLinux plugin?)

Yep, we're working on the plugins as well.

 

[Richard42]

sounds like a intresting version, but i dont have linux installed right now. is a os-x port possible?

It's possible but it will take quite a bit of work. There have been numerous requests for Win32 and OSX ports of our work, but right now the current development team is focusing on 32-bit and 64-bit Linux systems only. We don't have the hardware, the software, or the time to maintain compatibility with other platforms. We welcome Win32 or OSX developers to work with us and put the "Mup" back in "Mupen64Plus", but we need developers to step forward and take the responsibility for these, and so far no-one has done it.

On an unrelated note, I'm tracking the issues reported here via the TODO file in the root of the SVN trunk. This will be the official list of things to fix before the release, and after they're all taken care of we can tag the project and release.

 

[kosmi]

I'm aware of the fullscreen compatibility issue in Glide64. I think it was broken during the Linux porting process. Originally it refused to go into fullscreen at all, so I hacked it to properly use one of the config file parameters to select window/FS. I need to make it work with the command-line option and the F1 key.

No, no, v12 was allways work exellent for me, fullscreen/window was allways work properly and configuraton GUI and F1 also. Maybe this regression is introduced somewhere with porting on 64-bit Linux, because now it has problems that i never see in v12 (which is of course 32-bit only).

 

[thatmariolover]

I'll just keep requesting a new Mac version since I've got nothing else to gripe about. And by requesting a Mac version, I mean requesting a Mac developer.

 

[Danny]

It's possible but it will take quite a bit of work. There have been numerous requests for Win32 and OSX ports of our work, but right now the current development team is focusing on 32-bit and 64-bit Linux systems only. We don't have the hardware, the software, or the time to maintain compatibility with other platforms. We welcome Win32 or OSX developers to work with us and put the "Mup" back in "Mupen64Plus", but we need developers to step forward and take the responsibility for these, and so far no-one has done it.

On an unrelated note, I'm tracking the issues reported here via the TODO file in the root of the SVN trunk. This will be the official list of things to fix before the release, and after they're all taken care of we can tag the project and release.

How high would the skill level have to be to be able to merge the current changes to the windows build?

I know C well and have ported a chip8 emulator amongst countless private projects. (So I would class myself as average).

I would be more than willing to help/maintain a windows version if you believe the task is in my skill level. (I don't want to promise something If I cannot deliver you see )

 

[ebenblues]

How high would the skill level have to be to be able to merge the current changes to the windows build?

The windows gui code would have to be refactored to account for the major changes that went into place in the gui/nogui merge. Honestly, in my opinion, the changes actually make it easier to write the gui code, because there's a lot of common function now that's available to all gui's, but some of the common code relies on GNU functions which are not available in windows. I'd be willing to work with you to abstract some of the platform-dependent code out so our code doesn't become riddled with #ifdef __WIN32__ lines.

Also, the plugins we offer might not be especially windows friendly, but others can comment on that better than I can. So far, it seems the aim of Mupen64Plus is to be a complete package including plugins, so this might be an issue.

 

[Tillin9]

My comments:

I like the GUI no plugin selected error as opposed to the crash, but think we should select default plugins, (Rice, mupen64audio, Blights, the RSP plugin - we only have one). Maybe the first time mupen starts we should send a message along the line of:

"Mupen64Plus uses a plugin framework to handle various aspects of N64 emulation. While the default plugins should work for most users, you may have better luck on by choosing another plugin. You can see the available plugins and options on the Plugins tab in Options->Configuration."

Also:

- I can confirm the Rice 320x240 issue.
- The mupen executable (either self compiled from svn or from the linked binary) won't execute from Konqueror, but works fine from the commandline.
- Wonder Plus starts fullscreen, it should start windowed or have an option, and "F1" doesn't work to toggle fullscreen. ideally "Alt-Enter" should be the standardize key for this since "F1" is usually the hotkey for help and used in multiple other emulators and programs. This should be standardize across plugins.
- Our GTK accelerators don't work (I know I brought this up before but we might want to fix this before the release).
- The X for windowed plugins should close the window (by ending emulation).
- Might I suggest Rice should have fog disabled by default, this lets the open source Radeon 3D drivers work by default.