[$threadinfo[title]]

[Richard42]

Only a month and a half after v1.2, and it's time to release Mupen64Plus v1.3. We have more new features and bug fixes in here than you can shake a stick at! Ebenblues did most of the work for this release, but okaygo, nmn, and myself have also contributed. The RELEASE file gives most of the changes, but the highlights are:

- New feature: Glide64 video plugin for 32-bit and 64-bit systems
- New feature: Combine mupen64 and mupen64_nogui into a single binary
- New feature: ability to change icon size in GTK GUI
- New feature: support different directories for install (plugins, icons, etc) and config (save games, config files)
- New feature: support for creating and using ~/.mupen64plus dir for storing user data
- New feature: support for multi-user installation via "make install" or "./install.sh"
- New feature: support for plugins given via command line option in GUI mode
- New feature: pause/continue functionality with LIRC
- Change fullscreen hotkey to Alt+Enter
- Bugfix: segfault in Goldeneye and Perfect Dark for 64-bit dynarec
- Bugfix: 64-bit dynarec bug in genld()
- Bugfix: GTK GUI: Exiting via File -> Exit wasn't writing out config file to disk
- Bugfix: GTK GUI: "About" menu does not pop up while emulation is running
- Bugfix: Added plugin error checking before emulator is started
- Bugfix: Segfault in plugin_scan_directory()
- Bugfix: Closing emulation window now stops emulator
- Bugfix: GTK GUI: "Toolbar Style" now works
- Bugfix: Many other minor bug fixes, GTK warnings fixes, translation corrections, etc

Mupen64Plus has a new Home Page (http://code.google.com/p/mupen64plus/) over at Google Code, with lots of useful information, screenshots, a bug tracker, a discussion forum, etc.

To download Mupen64Plus v1.3, just grab the package that you want:

Mupen64Plus-1-3-bin-32.zip (http://mupen64plus.googlecode.com/files/Mupen64Plus-1-3-bin-32.zip)
Mupen64Plus-1-3-bin-64.zip (http://mupen64plus.googlecode.com/files/Mupen64Plus-1-3-bin-64.zip)
Mupen64Plus-1-3-src.zip (http://mupen64plus.googlecode.com/files/Mupen64Plus-1-3-src.zip)

[Tillin9]

Great job! You can add fixed the Konqueror path issue and emulation window controls now work as well.

Only one possible issue, Rice seems to not work as well as before. I'm not sure if this is just me though, since glN64 works fine. I'd have to run more detailed tests with previous and svn versions to see if it was changes in mupen or my video driver.

[gen2brain]

Great work. Keep going :)
I made an ebuild for gentoo, if anyone is interested.
Link to bugzilla -> http://bugs.gentoo.org/show_bug.cgi?id=215426

[kosmi]

Just to say, i compile this verion of mupen64plus with no problem with yasm by default for 32-bit. Glide64 and resolution changes now also work. Many thanks to developers for that:).

For the fog problem with radeon driver, just for you to know that this is only r300 DRI driver problem because GL_EXT_fog_coord extension not included in it (precisely it's disabled in Mesa source due weird bugs in some cases). Radeon drivers like r200 and r100 has it and of course plugins works with fog enabled without problem.

[Richard42]

Great work. Keep going :)
I made an ebuild for gentoo, if anyone is interested.
Link to bugzilla -> http://bugs.gentoo.org/show_bug.cgi?id=215426

That's great, thanks for making the Gentoo ebuild. We really appreciate people making packages for Linux distros because nobody on the Mupen64Plus development team has much experience with making rpms, debs, ebuilds, etc, and getting them into the distributions.

There are more features and fixes planned for the next release as well - it's being tracked in the Issue Tracker on the Google Code site.

[ebenblues]

Great work. Keep going :)
I made an ebuild for gentoo, if anyone is interested.
Link to bugzilla -> http://bugs.gentoo.org/show_bug.cgi?id=215426
I'm really happy to see this. One of our big goals with this release was to make Mupen64Plus more distro-friendly.

src_compile() {
make PREFIX=${GAMES_DATADIR} ${LIRC} ${NOGUI} all || die "make failed"
}

src_install() {
./install.sh ${D} || or die "install.sh failed"
newicon icons/logo.png "${PN}.png"
make_desktop_entry "${GAMES_BINDIR}/${PN}" Mupen64Plus
dodoc README RELEASE TODO
prepgamesdirs
}
I don't know much about gentoo ebuild files, but I was looking through the source and noticed that in the first line in src_install, you pass ${D} to install.sh. I couldn't find where that variable is defined, but I wanted to make sure you know that ${D} needs to resolve to the same location as ${GAMES_DATADIR}, otherwise mupen64plus will not be able to find the install dir.

Thanks for your contribution!

[gen2brain]

I am glad you like this, I first made svn ebuild, since I follow your work for last two months, with this release I thought it's time to post it to bugzilla. I would really like to see it in portage but I have no influence on this, the developers will decide, I just wrote ebuild, but I think there is a good chance to see it soon in the tree because mupen64 is discontinued and hard to maintain with all those patches they have now. ;)
btw. ${D} is something like virtual / . No wories, ebuild works just fine, I had to patch install.sh because gentoo keeps data in /usr/share/games and binaries in /usr/games/bin. This is usual practice, they just might not like those ffast-math and funroll-loops but they are fixable with sed.

Cheers :)

[nmn]

By the way, I didn't realize this just got released, The VCR is definitally broken, because it relied on a non-existant header and had function definitions wrong in the header file. I fixed this in SVN, but it may be a little heavy on headers (It was missing some before but I think I may have added some unnecessary ones) but I'm going to go fix that right now.

[sl1pkn07]

hello:

Tmem_nasm.asm:3: label or instruction expected at start of line
make[1]: *** [Tmem_nasm.o] Error 1
make[1]: se sale del directorio `/home/sl1pkn07/aplicaciones/mupen64plus-svn/glide64'
make: *** [plugins/glide64.so] Error 2
sl1pkn07@SpinFlo:~/aplicaciones/mupen64plus-svn$

i'm using rev 78 of SVN repository on kbuntu 64bits Gutsy Gibbon

greetings

[Richard42]

hello:
Tmem_nasm.asm:3: label or instruction expected at start of line


Can you give us the line just before this, the one in which the assembler is called? It looks like whatever assembler you're using has a problem with the code.

[sl1pkn07]

yasm -f elf -m amd64 -DBITS=64 Tmem_nasm.asm -o Tmem_nasm.o

sl1pkn07@SpinFlo:~/aplicaciones/mupen64plus-svn$ yasm --version
yasm 0.5.0.1591

[Richard42]

yasm -f elf -m amd64 -DBITS=64 Tmem_nasm.asm -o Tmem_nasm.o

sl1pkn07@SpinFlo:~/aplicaciones/mupen64plus-svn$ yasm --version
yasm 0.5.0.1591

I see. The Tmem_nasm.asm uses a keyword which was not introduced into yasm until ver 0.6.2. Which version of 'nasm' do you have? Maybe you can use that instead.

[Eck]

Gotta say, "Thank you, thank you, thank you," to you guys for all the work that went into this release.

Actually, make all, su - , make install failed for me the first time. You know why? I had the previous zips in the same folder when I extracted them and did a right click, extract here to the wrong, older package! :)

You guys must have fixed the "ginstall not found" thing in make install, eh?

Anyway, I looked and saw that nothing was in the /usr/local folders and did a make uninstall just in case before deleting that and extracting the right zip! Then it built and installed perfectly.

The GUI looks wonderful. I've only had time to configure it and test two games. I used the Glide64 with SuperMario64 and MarioKart64 along with my N64 pad and Adaptoid.

As always with Glide64, sometimes the fonts in the talk bubbles in Mario aren't bright and clear like they are normally (and are with glN64), but it played fine as did MarioKart64. I unchecked the disabled stuff regarding GLSL and such, checked the read frame buffer info and show frame buffer stuff and, as usual for me always on Linux, that screen in MarioKart just doesn't show the video. Hmm, maybe I have to turn on something else or it just doesn't work in the Linux versions?

The full screen alt-tab switch will leave new users less confused (assuming that not everyone reads that wiki page or included readme). I know that I hadn't known until recently that F1 used to be used for that and always wondered why I couldn't switch back and forth! Once I clicked the full screen button in the GUI I could never get back until I hit Esc. And I read the pdf for Mupen64! Must have missed something.

I expect I might be pleasantly surprised by the Rice plugin when I try games with it. The older released version (before you guys) seemed to always have some annoying bug or another and I rarely used it. But since your work concentrated a great deal on the Rice video plugin I'll surely check it out now. I never used 1964, where it came from I think. The plugin must be something special to garner all this work. :)

Just to mention, I installed this on a Debian Lenny system with the NVidia 169.09 driver currently in Sid installed the Debian way. Since it isn't in Debian repos yet, I felt it best to compile it rather than using the binary. Best way to ensure it's built based upon what I have here.

Mupen64Plus v1.3 really is a polished release. No errors noticed during compiling and installing and everything looks (and is) easily understandable to configure and use. It seems like a normal rpm, deb, whatever package could easily be built by distro maintainers. Maybe this will finally be a version of Mupen64 that isn't hidden away for only devotees to use, and will finally make it into official distributions.

Great work!

[sl1pkn07]

i'm now compile Yasm 0.6.2. now works!

thanks ^^

greetings

[ebenblues]

Gotta say, "Thank you, thank you, thank you," to you guys for all the work that went into this release.
Your welcome, glad you like it. :)

You guys must have fixed the "ginstall not found" thing in make install, eh?
Yes, this should be fixed.

The full screen alt-tab switch will leave new users less confused (assuming that not everyone reads that wiki page or included readme).
I'm guessing you mean alt-enter. For 1.4, I'm working on adding a new tab to the configuration dialog to allow the user to map emulation actions like "toggle fullscreen" to controller buttons. The dialog also displays the keyboard shortcut for each action (although for now, the keyboard shortcuts will not be configurable). I'm also planning to add the hotkey next to the menu item for each action in the gtk gui. Hopefully these changes will help people learn the hotkeys.

Mupen64Plus v1.3 really is a polished release. No errors noticed during compiling and installing and everything looks (and is) easily understandable to configure and use. It seems like a normal rpm, deb, whatever package could easily be built by distro maintainers. Maybe this will finally be a version of Mupen64 that isn't hidden away for only devotees to use, and will finally make it into official distributions.

Great work!
That's my hope. We worked hard on making this release more distro-friendly. Thanks for the feedback!

[Eck]

Okay here's some more.

Namco Museum, which was unusable for like, forever until Glide64 v12 got it going, does not start with Glide64 or RiceVideo on Mupen64plus, but works fine with mupen64-0.5 and the Glide64 v12 plugin. On Plus, it only offers a black screen.

I still have both mupen's installed, the new one built and make install, and the original just extracted to a folder in my home folder, and the Glide64 v12 built and substituted for the original. I use the ini file from the Windows version of Glide64 Wonder++. That's not on your's, now, for which I haven't changed any of the plugins besides configuring them. I just update the mupen64-0.5 Glide64 to that v12 one.

I tried a few tinkerings in the configuration for Glide64 on Mupen64Plus but no go. It's strange since it's essentially the same as version 12 except for some fixes, or so I've read.

Since it seems that the 3 plugins, glN64, Glide64, and well I guess Rice is improved but the others behave about the same in both mupen64-0.5 and mupen64plus, from a user standpoint (and this user has not really tested a large amount of games) the old one would be favored still since that game runs fine and the others run about the same. Your GUI looks better and it builds, which are both improvements since mupen64-0.5 does not build on any distro I've tried it on. I never learned how to apply patches so that my contribute to that. I just run it from the binary.

The DrMario64 pills that can be seen with mupen64-0.5 and the Glide64-v12 plugin cannot be seen dropping with mupen64plus and the Glide64 plugin. Since it's never worked with glN64 I haven't tried that or Rice yet with it.

Nothing shows the video screen on MarioKart64, except on Windows Vista with Project 64 1.7 beta with the Glide64-wonder++ Windows version. I was shocked about a month ago when I started that game in there and the video showed up. Isn't that supposed to work somehow on Linux too?

[Günther]

Okay here's some more.

Namco Museum, which was unusable for like, forever until Glide64 v12 got it going, does not start with Glide64 or RiceVideo on Mupen64plus, but works fine with mupen64-0.5 and the Glide64 v12 plugin. On Plus, it only offers a black screen.

Well, the Glide64 plugin got severily broken during the port to 64 Bit. The assembler code is horrible brittle. I fixed all issues I found, but I only tested with Zelda Majoras Mask. If you can use git, a bisect would help a lot - the history is available at http://repo.or.cz/w/Glide64.git.

[Eric89GXL]

First of all, excellent work on the emulator. It runs really well. Thanks. Two quick questions:

1) Should the 64-bit version run slower than the 32-bit version? It does on my (64-bit AMD/Ubuntu) system.

2) Where do I put hi-res textures to get the rice plugin to recognize them? I tried putting them in the the plugins folder under hires_textures/[Game Name] but that didn't work.

I was also thinking it would be nice to have the option to force 4:3 aspect ratio in the graphics plugins---I run a 16:9 screen, and I'd prefer my graphics be pillarboxed instead of stretched.

[nmn]

1) Should the 64-bit version run slower than the 32-bit version? It does on my (64-bit AMD/Ubuntu) system.

At the moment, there are no optimizations to the 64-bit Dynamic Recompilation core and it is expected to run slower. Sorry.


2) Where do I put hi-res textures to get the rice plugin to recognize them? I tried putting them in the the plugins folder under hires_textures/[Game Name] but that didn't work.

You can put them into ~/.mupen64plus/hires_texture/ and it will work. Remember to enable it though. It only works in Rice's Video Plugin as we do not have GlideHQ support.

[Eric89GXL]

At the moment, there are no optimizations to the 64-bit Dynamic Recompilation core and it is expected to run slower. Sorry.


You can put them into ~/.mupen64plus/hires_texture/ and it will work. Remember to enable it though. It only works in Rice's Video Plugin as we do not have GlideHQ support.

That's kind of what I expected with the 64-bit version, just wanted to make sure I wasn't missing out.

That's strange about the hi-res. I put them in "/home/mediator/.mupen64plus/hires_texture/The Legend of Zelda" and it still doesn't work. I have mupen64plus 32-bit version installed. This texture pack works with Project64 under windows, so it shouldn't be the problem. No big deal if it doesn't work.

The relevant output if I run mupen64plus from the command line is:

[RiceVideo] SSE processing enabled.
[RiceVideo] Found ROM 'THE LEGEND OF ZELDA', CRC b71170ec2bd71676-45
[RiceVideo] Enabled hacks for game: 'THE LEGEND OF ZELDA'
InitExternalTextures
Texture loading option is enabledFinding all hires texturesInitializing OpenGL Device Context

And that's it.

[Eck]

Okay, I downloaded the snapshot of Glide64 from the top (latest) listing on the Summary page.

So, I do make, hope it makes the Glide64.so, and in File Manager-Super User Mode place that and the Glide64.ini into the mupen64plus plugins folder (after renaming the originals so I can go back to them just in case) right?

Then what? What's a bisect? Heh, do you just want me to run it and see if I get the same problem? Any special settings you'd like me to set in the Glide64 configuration panel?

[nmn]

That's kind of what I expected with the 64-bit version, just wanted to make sure I wasn't missing out.

That's strange about the hi-res. I put them in "/home/mediator/.mupen64plus/hires_texture/The Legend of Zelda" and it still doesn't work. I have mupen64plus 32-bit version installed. This texture pack works with Project64 under windows, so it shouldn't be the problem. No big deal if it doesn't work.

The relevant output if I run mupen64plus from the command line is:

[RiceVideo] SSE processing enabled.
[RiceVideo] Found ROM 'THE LEGEND OF ZELDA', CRC b71170ec2bd71676-45
[RiceVideo] Enabled hacks for game: 'THE LEGEND OF ZELDA'
InitExternalTextures
Texture loading option is enabledFinding all hires texturesInitializing OpenGL Device Context

And that's it.
I know there is something wrong. The folder must be "THE LEGEND OF ZELDA" since that's the internal ROM name. Caps matters in Linux, so if that IS the right folder, with a crapload of PNGs directly inside, rename it and enjoy :)

Plus, I forgot to mention. Some texture packs will only work in the latest SVN because they require support for the 16x texture size and 32bit textures on 24bit game textures.

[lifning]

Hello, I use Fedora Linux and have found this emulator very useful, solving many of the problems I had with the old Mupen64. =) Thanks!

If anyone might find it useful, I've made some RPMs for this version of Mupen64Plus. The source RPM can be found here: http://lightning.h4xopolis.net/repo/src/mupen64plus-1.3-1.fc8.src.rpm

[ebenblues]

I know there is something wrong. The folder must be "THE LEGEND OF ZELDA" since that's the internal ROM name. Caps matters in Linux, so if that IS the right folder, with a crapload of PNGs directly inside, rename it and enjoy :)
I haven't played with hires textures yet, but is there a way we could make loading them simpler for users? For example, after loading a rom, you could have an option to "load hires textures" or something like that, then a file chooser could pop up and you could select the downloaded texture files (do they come in a zipped file?) and mupen64plus would automatically create the directory (with the correct case) and copy the files in there. Thoughts?

[ebenblues]

If anyone might find it useful, I've made some RPMs for this version of Mupen64Plus. The source RPM can be found here: http://lightning.h4xopolis.net/repo/src/mupen64plus-1.3-1.fc8.src.rpm
Thank you for doing this. One of our goals for this release was to make mupen64plus more distro-friendly. If you can, submit your rpm to the fedora developers for inclusion in their repositories.

[nmn]

I haven't played with hires textures yet, but is there a way we could make loading them simpler for users? For example, after loading a rom, you could have an option to "load hires textures" or something like that, then a file chooser could pop up and you could select the downloaded texture files (do they come in a zipped file?) and mupen64plus would automatically create the directory (with the correct case) and copy the files in there. Thoughts?

Obviously, this is possible. I have not yet done this, though, because I'm not focusing on features nor Rice Video at this point (more trying to figure out a way to port Mupen64Plus to Windows and a reliable way to build a GCC 4 MinGW)

If anyone else wants to do it, the obvious way would be to use the compression libraries, read all of the file list and grab the directory with the most images and copy it over. This requires a little more work, of course, considering you'll have to extract the archive to a temporary location to do the copy AFAIK.

[Richard42]

Okay here's some more.

Namco Museum, which was unusable for like, forever until Glide64 v12 got it going, does not start with Glide64 or RiceVideo on Mupen64plus, but works fine with mupen64-0.5 and the Glide64 v12 plugin. On Plus, it only offers a black screen.


Last night I played Namco museum with an older version of Mupen64-amd64 and it ran fine under Rice Video, and worked but was slow under Glide64. This morning I tried with the latest Mupen64plus and got the problem you described. I'll try to find the cause of the problem. I wish we had a regression test.

Edit: it looks like this was broken during the GUI/NOGUI merge. It worked in rev 241 of the Mupen64-amd64 repo (right before the merge), and it is broken in rev 244.

[Eck]

Just another part of growing pains. :) No way for every game to be retested with every change so it's to be expected. It's great that we have this forum available for feedback and throwing ideas around.

Gotta have my NamcoMuseum so I don't need to boot into Windows to play Return Of Arcade. Just for your info, NamcoMuseum has never run on Project64 with their default plugins either. But I think I recall sticking the Windows Glide64-wonder++ in there and getting it to run. But without the Linux version improvements, Glide64 has several bugs such as sticking around, not closing, crashing Windows, etc. And similar happens running it with the Windows version of Mupen64 (which is a bugfest in itself, Project64 is much better if using Windows but I do try to avoid using Windows).

Until the Glide64-wonder++-v12 on Linux, it ran at unacceptably slow speeds. And at times the GUI would lose parts of the screen so it was unplayable even if running. But of late it's been working with the last updates to v12. If Rice can run it more like the speedy Return Of Arcade does it would be great! Don't care what plugin (no loyalties) as long as it gets playing correctly.

I just booted into Vista yesterday to uninstall the u3 stuff on a new Sandisk Cruzer 8GB stick I bought. It took me about 5 hours before I could get to plugging in the drive, checking out the cool u3 stuff and then uninstalling it. Updates, scans to make Vista happy, system restore logging, blah blah blah, waiting waiting waiting, rebooting rebooting rebooting, yecch!

Gonna experiment and put the new Knoppix 5.3.1 on the USB stick. It'll be nice to have a customized system in a pocket! And unlike using the DVD I'll be able to both read and write like an installed system so won't run out of room. Things will really get uninstalled and replaced like a real Debian system. Or so I've read in a great guide posting in the wiki. Great if I can get it working that is. Too bad I don't have room for my 18GB of mp3 files in my music folder so I only get my music if I'm using it on my computer. Now I see why people like iPods. Too pricey for my budget though.

[lifning]

Thank you for doing this. One of our goals for this release was to make mupen64plus more distro-friendly. If you can, submit your rpm to the fedora developers for inclusion in their repositories.
The official Fedora repositories don't accept console emulators. I will submit it to http://dribble.org.uk/ though, which is a third-party repository mainly for emulation-related packages.

[ebenblues]

Edit: it looks like this was broken during the GUI/NOGUI merge. It worked in rev 241 of the Mupen64-amd64 repo (right before the merge), and it is broken in rev 244.
D'oh, yeah, the gui/nogui merge was a major change, but I still think it was the right direction to go. Looking at the r241 and r244 code, with respect to graphics, the only thing that stands out to me is that before the merge, we had this line:


SDL_SetVideoMode(10, 10, 16, 0);
and after the merge, we had this:


SDL_SetVideoMode( 10, 10, 0, 0 );
According to the man page, "If bpp is 0, it is treated as the current display bits per pixel."

But later, okaygo removed the SDL_SetVideoMode call completely because he said it was removing the window bars in his distro. I don't know, seems like a shot in the dark, but you could try adding SDL_SetVideoMode(10, 10, 16, 0); to emulationThread in main/main.c and see if that changes anything. Other than that, I don't see how the merge would affect how the graphics plugins work...

[Richard42]

D'oh, yeah, the gui/nogui merge was a major change, but I still think it was the right direction to go. Looking at the r241 and r244 code, with respect to graphics, the only thing that stands out to me is that before the merge, we had this line:


A agree the GUI/NOGUI merge was the right thing to do; having two separate but similar code bases is a recipe for trouble. Adding new features always causes bugs, so in the development cycle you have to take time to slow down or stop on the new features and fix the bugs and bring back the stability.

I had an idea that this bug may have been related to the 2 different 'main' files that were present in the old system. Maybe it worked in the _nogui build but not the gui build, and the correct _nogui code got lost during the merge. I doubt that the SDL_SetVideoMode caused this bug, but it would be easy to test.

[infinitycircuit]

I just downloaded Mupen 64 on a Debian sid install. I had to install libglu1-mesa and libsdl-ttf2.0-0 to get it to run. However, when I try to start SSB, I get the following error message:

rom loaded successfully
80 37 12 40
ClockRate=f
Version:1449
CRC: 916b8b5b 780b85a4
name: SMASH BROTHERS
Manufacturer: Nintendo
Cartridge_ID: 4c41
Country : United States
size: 4096
PC= 80100400
md5 code:F7C52568A31AADF26E14DC2B6416B2ED
eeprom type:0
init timer!
memory initialized
[RiceVideo] SSE processing enabled.
[blight's SDL input plugin]: version 0.0.10 initialized.
[RiceVideo] SSE processing enabled.
[RiceVideo] Found ROM 'SMASH BROTHERS', CRC 5b8b6b91a4850b78-45
InitExternalTextures
Initializing OpenGL Device Context
(II) Initializing SDL video subsystem...
(II) Getting video info...
(II) Setting video mode 640x480...
(EE) Error setting video mode 640x480: Couldn't find matching GLX visual
Signal number 11 caught:
errno = 0 (Success)


EDIT: I fixed it I need to switch video plugins

[doorknob60]

Cool, I just found out about Mupen64plus and I've been playing N64 games all night now. It runs way more games than normal Mupen64 does. Nice job :)

[gen2brain]

During compile I get warnings No libsamplerate development libraries found! in pre.mk line62, it doesn't matter if I have libsamplerate on system or not (I am on gentoo so there are no -dev package to install, either I have them or I don't). Are those libraries even used? I didn't notice that it affects anything.

[ebenblues]

During compile I get warnings No libsamplerate development libraries found! in pre.mk line62, it doesn't matter if I have libsamplerate on system or not (I am on gentoo so there are no -dev package to install, either I have them or I don't). Are those libraries even used? I didn't notice that it affects anything.
nmn recently added changes so the jttl audio plugin can use libsamplerate. See this thread:

http://www.emutalk.net/showthread.php?t=43854

The presence of libsamplerate is checked via this command: "pkg-config libsamplerate --exists". The Makefile only gives a warning because jttl will still compile without it. If you have libsamplerate installed, but the pkg-config command says it's not, it could be a path issue. Here's what pkg-config has to say about it:


Package samplerate was not found in the pkg-config search path.
Perhaps you should add the directory containing `samplerate.pc'
to the PKG_CONFIG_PATH environment variable
No package 'samplerate' found

[gen2brain]

Well, I just tried, pkg-config libsamplerate --exists return false but pkg-config samplerate --exists returns true, 0 in fact... So, what is the right way?

[gen2brain]

I just checked pre.mk, in fact there is a line
ifneq ($(shell pkg-config samplerate --exists), 0)
but should it be
ifneq ("$(shell pkg-config samplerate --exists)", 0)
just like gtk+, a couple of lines above?

[nmn]

When I put it up it was working except it errored out when there was no library. I copied the GTK code and slightly modified it. I have no idea why it would be any different.

[ebenblues]

When I put it up it was working except it errored out when there was no library. I copied the GTK code and slightly modified it. I have no idea why it would be any different.
Oops, that was my fault. I just committed a fix to svn.

[Günther]

Then what? What's a bisect? Heh, do you just want me to run it and see if I get the same problem? Any special settings you'd like me to set in the Glide64 configuration panel?

With a bisect, you basically test enough different versions until you find the two closest ones where one does work and the other does not. For efficiency, git offers automation of a binary search.

I'd use this method: You need two terminals, one in the mupen64 directory, one in a spare directory. (Hm, I only know the layout for building from source, I think you'll get the idea anyway, though) In the first, you do

ln -s /path/to/spare/Glide64/Glide64.so plugins/Glide64.so

so you do not have to copy Glide64.so after each build.

in /path/to/spare, you get a copy of the Glide64 history and build it:

git clone git://repo.or.cz/Glide64.git
cd Glide64
git bisect start
make

Now you start mupen64 in the other terminal and confirm that the bug exists.
After that, you tell git that it does exist, and that the v12 version was good (hopefully that's still true for this copy):
git bisect bad
git bisect good 9c1b7d5a7eac291cf2e0335405b98744f45fd413

Now git has switched to a version in the middle. Build it with another "make", test wether it's broken, and either run "git bisect good" if it works or "git bisect bad" if it does not, make, test, etc. Eventually, git will tell you what the last good commit was.

[nmn]

Oops, that was my fault. I just committed a fix to svn.
Ahh, I didn't think about that. Well, nice that its fixed now, because I have a feeling that explains why my resampling changes aren't working XD (Just have to revert a little I'm guessing and everything should go fine.)

Speaking of which I'll be working on a JttL Audio GUI, but also, Mupen64Plus for Windows. I haven't mentioned this often enough I guess, But yes, I am working on it, My main issue is creating a reliable MinGW with GCC 4. Right now It's having an issue with compiling binutils because it complains about makeinfo (but WTF?! Its installed, along with bison and friends...)

[vision]

I'm running Mupen64plus on AMD64 X2 in Arch Linux. It works great! You guys are the best, I remember a while back trying to run the original Mupen64, and it wasn't pretty. Really great job guys.

Now, I'm getting a little spoiled and I'm trying to load the hires texture pack for OOT in Mupen.. it actually loads and the title screen starts but then locks up as the moon starts to lower, right before Link and Epona come into view.. any ideas? Should I pull from SVN instead?

PS: Here's the halt output.

Non-integral hi-res texture scale. Orig = (32,32) Hi-res = (64,128)
*** glibc detected *** mupen64plus: malloc(): memory corruption: 0x00002aaabbb71820 ***
======= Backtrace: =========
/lib/libc.so.6[0x2b42a68f8808]
/lib/libc.so.6[0x2b42a68fb03c]
/lib/libc.so.6(__libc_calloc+0x108)[0x2b42a68fc648]
/usr/lib/libGLcore.so.1[0x2b42a706b548]
======= Memory map: ========
00400000-00493000 r-xp 00000000 08:13 5447765 /usr/bin/mupen64plus
00692000-00696000 rwxp 00092000 08:13 5447765 /usr/bin/mupen64plus
00696000-02da9000 rwxp 00696000 00:00 0 [heap]
40002000-40004000 rwxp 00000000 00:0d 1593 /dev/zero
40004000-40005000 ---p 40004000 00:00 0
40005000-40805000 rwxp 40005000 00:00 0
40805000-4088a000 rwxp 00000000 00:0d 1593 /dev/zero
4088a000-4088b000 ---p 4088a000 00:00 0
4088b000-4108b000 rwxp 4088b000 00:00 0
4108b000-4108c000 ---p 4108b000 00:00 0
4108c000-4188c000 rwxp 4108c000 00:00 0

[Tillin9]

If your pack is using 32-bit PNGs, using svn as opposed to 1.3 will help.

However, this begs the question what video driver and texture pack? I have Kman/Federelli's for OOT, and using the open source radeo r300 driver it seems to work fine for me with 1.3 or the latest svn. I have to manually set Rice to use OpenGL 1.3 (as my driver doesn't support anything better) in the svn build likely because of the OpenGL 1.4 combiner changes.

Might also be this issue: http://www.emutalk.net/showthread.php?t=43906

[Richard42]

]Non-integral hi-res texture scale. Orig = (32,32) Hi-res = (64,128)

That's the problem. Rice does not currently allow using textures which are not integral multiples of the original resolution. I can remove this check quickly if you can pull from SVN and test it and let us know how it works.

[vision]

I can remove this check quickly if you can pull from SVN and test it and let us know how it works.

If you could do this, I will gladly test it. Just let me know and I'll pull an SVN copy.

However, this begs the question what video driver and texture pack?

I use the one from DGEmu.. I can't remember what it's called. The link is here.

http://www.dgemu.com/forums/index.php?showtopic=327734

Though it seems to be down for the moment. Hmm. I'm also using Rice's plugin.

EDIT: My bad, it appears that pack is also located on EmuTalk. Sorry guys, I'm new here. :) http://www.emutalk.net/showthread.php?t=34361

[Richard42]

If you could do this, I will gladly test it. Just let me know and I'll pull an SVN copy.


I just committed a tentative fix in rev 185. It still prints a warning but I added the necessary calculations to correctly load an unevenly scaled texture. Let me know how it works.

[vision]

I've checked out 185 and am testing now. Earlier I was playing around in Project64 on XP and loaded both the cel-shaded pack and the high-res pack to make sure they work okay; confirmed. I'll post back here with test results.

[vision]

Alright, so that worked. As you mentioned, instead of simply crashing, Mupen printed a warning to console every time a non-integral scale was performed. Overall though, it really didn't look too bad. I would say that the hi-res pack looks almost identical to PJ64 on Windows, save for a couple of very minor glitches that you'll see below.

The cel-shaded pack suffered slightly. I think that this might be related to the bizarre folder names it uses, some have french accents on the letters and I don't believe they conform to Linux/UTF-8 standards.. i.e. when you unpack the cel-shaded .RAR in Linux, Nautilus shows the directories like this:

http://i84.photobucket.com/albums/k23/shiftedesign/Screenshot.png

So maybe that explains something. Or, I could just be an idiot.

Keep in mind that the HiRes pack by Federelli is only listed as being 21% complete. I don't have the Kman pack. I wish I did. The cel-shaded pack, by Djipi, is listed as being 100% complete. Also keep in mind that both of these packs look near-perfect on XP with PJ64 - at least in the 20 minutes I spent, nothing jumped out at me.

Anyway. Here are the shots from the cel-shaded pack and the hi-res pack, respectively.

Cel-shaded
http://i84.photobucket.com/albums/k23/shiftedesign/cel-1.png
http://i84.photobucket.com/albums/k23/shiftedesign/cel-2.png
http://i84.photobucket.com/albums/k23/shiftedesign/cel-3.png

Hi-res
http://i84.photobucket.com/albums/k23/shiftedesign/hires-1.png
http://i84.photobucket.com/albums/k23/shiftedesign/hires-2.png
http://i84.photobucket.com/albums/k23/shiftedesign/hires-3.png

So as you can see there are a few issues.. but.. at least it loads. :)

Btw Richard, I'm keeping this SVN commit, you can't have it back ;)

Also.. sorry for the weird size differences.. gotta love photobucket I guess :S

[vision]

UPDATE: Having played through the game a bit more, I really haven't spotted any other problems in the cel-shaded pack. Mostly just the black half of Link's Kokiri outfit and some menu issues. It looks and runs great.

[Richard42]

Btw Richard, I'm keeping this SVN commit, you can't have it back ;)


You're welcome; keep it. Of course it will also be in the next release as well. :) We're going to have some nice new features.

Do you mind if we post some of these screenshots in our gallery on the google code site?

[vision]

Sure. Check your PM for some more.

[Richard42]

Namco Museum, which was unusable for like, forever until Glide64 v12 got it going, does not start with Glide64 or RiceVideo on Mupen64plus, but works fine with mupen64-0.5 and the Glide64 v12 plugin. On Plus, it only offers a black screen.
....
The DrMario64 pills that can be seen with mupen64-0.5 and the Glide64-v12 plugin cannot be seen dropping with mupen64plus and the Glide64 plugin. Since it's never worked with glN64 I haven't tried that or Rice yet with it.


I tried DrMario with a 32-bit build of Mupen64Plus from SVN and the 32-bit Glide64-v12 plugin. I couldn't see the pills drop with this combination, so I don't know what could be wrong.

I found the problem with Namco Museum - it hangs when the NoAudioDelay is set to true in mupen64plus.conf. If you set it to false, it will work. I'm going to fix this shortly.

[Eck]

Nice! It's always good to hear of the fixes coming. That Dr. Mario pill dropping without seeing the pills was a long standing issue until Glide64-wonder++-v12. I think I remember it's the same with Project64 and their official plugins. Still works on the mupen64-0.5 with that plugin, but not on Plus with its Glide64, which I haven't tinkered with besides setting the resolution and trying that read frame buffer thing that doesn't appear to do anything.

Namco Museum also is tricky. It used to instantly crash like now (mupen64 or Project64), but then with new versions of Glide64 it started to work but would not show all the visual in the game so couldn't be played, and then worked fully with Glide64-wonder++-v12 on the mupen64-0.5. It'll be interesting to see if it's playable once that audio setting is made and the game starts.

[okaygo]

6 Pages... wow

[vision]

6 Pages... wow

You have no idea how happy some of us are to have playable N64 emulation on our 64-bit Linux boxes.. :)

[olivieryuyu]

Very good version:

Well as i don't see any new version of Mupen coming soon, i have 2 requests:

1) support of PJ64 savestate
2) possibility to disable the memory expansion

:)

[ebenblues]

1) support of PJ64 savestate

You can use our issue tracker to make these kinds of requests. I added an issue for PJ64 statesave support:

http://code.google.com/p/mupen64plus/issues/detail?id=52

[okaygo]

Guys the latest SVN has a lot of bug fixes, so people who are still interested in this project (and DEVELOPERS) can come check out our home page, try out the latest SVN and continue to report bugs. Also join the google groups.

[T3mporal]

Hi, everyone who is developing this new Mupen! I think that if I say my feelings about, you can, maybe, have any insight... don't know... well, here i go:

1->With Mupen64, every time I ask for pausing (from the pause button on its interface), the program freezes. With Mupen64plus this is fixed!

but...

(WITHOUT COMPIZ AND NVIDIA DRIVERS WORKING):
2->With Mupen64, the first 10 minutes sounds really "heavy" for Xorg, that keeps loading up to 100% every X seconds, BUT, after these 10 minutes, Xorg comes back to load at normal rate (something about 30%~40% ALL the time) and Mupen64 with 45%~55%.
BUT, with Mupen64plus Xorg keeps loading 100% of the processor every 5~6 seconds all the time, no matter how many time I let the program running.

I use ubuntu 7.10, running on:
Asus A7V400-MX;
AMD Sempron 2300;
1GB ram;
NVIDIA GeForce 4000 MX (With proprietary drivers - I mean thats the latest stable one for my Video Card);

I hope this helps!

And sorry my english, I'm not a native speaker.

[ebenblues]

Guys the latest SVN has a lot of bug fixes, so people who are still interested in this project (and DEVELOPERS) can come check out our home page, try out the latest SVN and continue to report bugs. Also join the google groups.
Yeah, I wouldn't be surprised to see a 1.4 release candidate in the next week or two... :)

[DarkJezter]

with Mupen64plus Xorg keeps loading 100% of the processor every 5~6 seconds all the time, no matter how many time I let the program running.


There are a few things I would want to suggest trying here.

1)As always if possible use the latest version available from SVN
2) Try running mupen64plus using the --nogui option and see if that makes any difference
3) When trying to tweak performance, make sure you're using the dynamic recompiler, and try turning off some of the features in the video plugin. Lately, the big push is for video settings that work for more games instead of on more computers, so you may need to change the video settings to get things running smoothly
4) And... which video plugin do you see the issue with? Do you know what happens if you try using the old plugin from mupen64 with mupen64plus?


An old AMD Sempron is likely going to have a hard time doing N64 emulation but you should be able to get it running at least as well if not better than previous versions of mupen64

[HyperHacker]

I'm getting an error trying to build the SVN version with "make DBG=1 all" on Xubuntu 8.04 x86:
main/gui_gtk/main_gtk.c: In function ‘callback_debuggerEnableToggled’:
main/gui_gtk/main_gtk.c:932: error: ‘g_DebuggerEnabled’ undeclared (first use in this function)
main/gui_gtk/main_gtk.c:932: error: (Each undeclared identifier is reported only once
main/gui_gtk/main_gtk.c:932: error: for each function it appears in.)

And with just "make all":
r4300/r4300.o: In function `go':
r4300.c:(.text+0x42fa): undefined reference to `update_debugger'
r4300.c:(.text+0x4540): undefined reference to `update_debugger'
r4300.c:(.text+0x454f): undefined reference to `update_debugger'
r4300/r4300.o: In function `BEQL_OUT':
r4300.c:(.text+0x4609): undefined reference to `update_debugger'
r4300.c:(.text+0x46cf): undefined reference to `update_debugger'
r4300/r4300.o:r4300.c:(.text+0x47ae): more undefined references to `update_debugger' follow
Is there a binary release with the debugger?

[edit] Nevermind, make all worked after doing make clean (and installing SDL_ttf and yasm <_<). But no debugger... :(

[more edit] Been tinkering with getting the debugger to work. So far I've fixed the above error by adding a line to debugger/debugger.h:
int g_DebuggerEnabled; // wether the debugger is enabled or not

Then I got errors about lines 931 and 933 of main/gui_gtk/main_gtk.c (functions not defined, grep confirmed no other instance of them), so I took a chance and commented them:
//callback_emulationStop( NULL, NULL );
g_DebuggerEnabled = GTK_CHECK_MENU_ITEM(widget)->active;
//callback_emulationStart( NULL, NULL );

Finally I had to correct a rule on line 242 of the makefile:
-mupen64plus_dbg: $(OBJECTS) main/main_gtk.o
+mupen64plus_dbg: $(OBJECTS) main/gui_gtk/main_gtk.o

That got it to compile, but all it did was add a "Debugger" menu with an "Enable" option that doesn't do anything, and print a crapload of messages to the console making it run at a snail's pace. It also takes ages to compile. I did make clean and built it again and nothing changed.

[MIO0]

HH: Did you:
1. check out the debugger branch? The trunk does not have a working debugger(I think).
2. enable the debugger option before starting the ROM?

[HyperHacker]

Nice username. :-p
I doubt I did get the debugger branch because I have no idea how to use SVN and just copied the instructions on the page. I tried it both before and after loading the ROM. I was able to fix a few more things to get the menu option to do something:

main_gtk.c:1278 - wrong widget type, so the callback was not executing
#ifdef DBG
debuggerMenu = gtk_menu_new();
debuggerMenuItem = gtk_menu_item_new_with_mnemonic(tr("_Debugger"));
gtk_menu_item_set_submenu( GTK_MENU_ITEM(debuggerMenuItem), debuggerMenu );
debuggerEnableItem = gtk_check_menu_item_new_with_mnemonic(tr ("_Enable"));
gtk_menu_append( GTK_MENU(debuggerMenu), debuggerEnableItem );

gtk_signal_connect_object( GTK_OBJECT(debuggerEnableItem), "toggled", GTK_SIGNAL_FUNC(callback_debuggerEnableT oggled), debuggerEnableItem );
#endif // DBG

main_gtk.c:932 - wrong function names, found the right ones:
callback_stopEmulation(NULL, NULL); //callback_emulationStop( NULL, NULL );
g_DebuggerEnabled = GTK_CHECK_MENU_ITEM(widget)->active;
callback_startEmulation(NULL, NULL); //callback_emulationStart( NULL, NULL );
With that, the Enable option is checkable and displays the warning message as expected, but I still don't see any debugging options.

I'm checking out the r0286-debugger build now, hopefully that's the right one. :P

...unzip.c is taking forever to download... or not, svn just locked up. Let's see if this one builds.

Yep, it works, woo! Only one problem, during install: "/usr/bin/install: cannot stat `doc/readme.pdf': No such file or directory". I just made an empty file there and it worked fine. Looks like it doesn't do a whole lot yet though, just PC breakpoints and register/ASM viewing? Maybe I need to learn to work GTK and hack some features in. ;)

Thanks for the tip BTW.

[ebenblues]

Yep, it works, woo! Only one problem, during install: "/usr/bin/install: cannot stat `doc/readme.pdf': No such file or directory". I just made an empty file there and it worked fine.
That problem's been fixed in trunk, but the fix isn't in the branch.

[Felipe]

hi,i'm the translator of the original mupen to brazilian portuguese and here is my translation based on the spanish language file that you EbenBlues posted in the forum ;) it's in the address down here and i have a few things to report and suggest about the windows version of mupen64plus:

1 - mupen64plus needs to have an icon in its .exe file that could serve as its shortcut icon too

2 - it would be cool if it had an installer like pj64 based on nsis, with the installer the ability to add or not shortcuts in the desktop, quick bar launch and start menu :)

3 - the spanish file you posted contains several errors of translation, i hope someone post another file here to replace the other one :P

4 - i couldnt put my translation to see in mupen64, why are there 4 translation's files in mupen's locale folders? Just the .po file wouldnt be enough to add translation support?

5 - the gui of mupen is a bit weird, i saw mupen64 uses qt but its interface doesnt look like the interface of linguist from trolltech (look at the address below for reference) look at how the colors of the interface has a nice tone of color, in mupen64 is kinda that color mixed with white (maybe because mupen64 came from linux but i can be wrong) and the menus that come when you click for example in help menu on mupen64 are extremely short unlike we see in the qt linguist pic or in any other app.

the address is: felipefpl.4shared.com

That's all, thanks to all the devs for continue the work of Hacktarux (i hope he is well) and for all the new stuff/bugs fixed you added to it. ;)

NOTE FOR THOSE WHO KEEP THIS FORUM: WHY ATTACHMENTS DONT WORK? AND REPLY BUTTON DOESNT WORK FOR ME

[okaygo]

Please use the following link (http://emutalk.net/showthread.php?t=44669) to continue discussion about our newest version.