Here it is: Mupen64Plus v1.3!

[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ünther1]

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.