What's new

New release: Mupen64-amd64 and RiceVideoLinux versions 1.0

Eck

New member
I'm glad you're happy about it. I just hope it's all done right by whatever rules apply to open source/free software. I was surprised when I read that you hadn't been informed about it, especially since it appears not in someones personal directory under the /home:/ section, but in the semi-official emulator repository.

Heh, maybe a SUSE engineer really liked your work and decided upon it. Interestingly, the 0.5 version which works fine is relegated to a lower version number now and in that wberrier home directory. And that's the official one! Many more users will come across your version than the official one this way. It's nice to have it available all nice and automatically installable like this, however, like you said. But it does seem a bit backwards even to you I bet, no?

Nice about just needing to use the Rice plugin you already made to get some of your fixes into the Mupen64 0.5 I'm already using here. It's another advancement in the available video plugins which is always a good thing. As I explained, I hadn't had much luck with the included one and perhaps this will improve even more of the games.

The more contributions to the Mupen64 technology the better. The other night I tried turning on the frame buffer part in the Glide64 and running MarioKart64 to see if the video screen there would show up. It did not! Hmm. Other than that the game ran fine, but didn't appear to be any different from having that setting unchecked. If I recall correctly even though it's been some time since I used it, I believe the videos do show up when MarioKart64 is played on Project64 1.7 beta on Windows XP.

I guessing that, although slowed recently, development on Project64 was simply more active during the last couple of years since the last official Mupen64 came out and simply saw more improvements and games working better because of that activity, and of course I am talking about the beta version 7. During the same period the Mupen64 just stayed as it is, which is pretty darned good of course! However it is really nice to see all parties working on it again.
 
OP
R

Richard42

Emulator Developer
I'm glad you're happy about it. I just hope it's all done right by whatever rules apply to open source/free software. I was surprised when I read that you hadn't been informed about it, especially since it appears not in someones personal directory under the /home:/ section, but in the semi-official emulator repository.

As long as they are in compliance with the GPL, it's all good and legal. The gist of the GPL is that if they are distributing binaries, they must also distribute the source or make an offer regarding where to download the source or purchase for a limited fee.

Heh, maybe a SUSE engineer really liked your work and decided upon it. Interestingly, the 0.5 version which works fine is relegated to a lower version number now and in that wberrier home directory. And that's the official one! Many more users will come across your version than the official one this way. It's nice to have it available all nice and automatically installable like this, however, like you said. But it does seem a bit backwards even to you I bet, no?

That's not good. I'm trying not to step on anyone's toes, and Mupen64 is Hacktarux's baby. What I've created is a branch of his work, and I try to emphasize this by always calling it by a different name: mupen64-amd64. Same with RV - I always call it RiceVideoLinux. I hope whoever created the SUSE repository entry reads this and puts it under a different name for the next release.

Nice about just needing to use the Rice plugin you already made to get some of your fixes into the Mupen64 0.5 I'm already using here. It's another advancement in the available video plugins which is always a good thing. As I explained, I hadn't had much luck with the included one and perhaps this will improve even more of the games.

Yeah the original N64 emulator designers who decided to use the plugin approach did a great service to the community, because that really improves the user experience. This is a very interesting project to work on.
 

Eck

New member
Thinking here. You know what might sort this? A while back when OpenSUSE 10.3 was first released I had posted in CyberOrg's thread in the Compiz Fusion forum where he describes how to get the OpenSUSE packages. It was just to offer my experiences with using his repo, but I happened to mention how weird it was (actually I think this was during the RC1 period) that some of the game emulators I used happened to be in the Build Services Debian based repositories. I mentioned how I thought it strange when doing system upgrades that one of them (not an emulator) came from one of these Debian/SUSE hybrid repos and had installed Debconf and related dpkg stuff into my OpenSUSE installation. And I said that since one of those claimed that it made it so future package installs would honor the user configuration files, not replacing them with new ones from an upgrade, I hoped that this wouldn't interfere with normal OpenSUSE YaST package upgrades.

A couple of days later all those emulators had been moved into the normal OpenSUSE Build Service Emulators repo, no longer needed a user to activate any of those Debian based repos. So the problem, if it was a problem, had been fixed within a couple of days and was not present by the time 10.3 was released.

I know CyberOrg (can never remember his actual name although he's a major developer. I bookmark both his CyberOrg blog and personal blog whenever I come across them. Good OpenSUSE and Linux info there) tries to keep that thread clean of discussions not related to his Compiz Fusion repo and often moves conflicting stuff out of there. However it does appear that if he sees something funky being reported he manages to get action taken on it faster than a speeding bullet!

The most legit way would be for me to post a bugzilla bug somewhere. Bugzilla is one of the things about Linux I've never quite gotten a handle on. There's just so many of them! And what to post and fill in the blocks is also unclear. I've done it, but most often my bug sits there, with perhaps a reply and perhaps not, but the status never changes until I close the bug myself. It's just a weird place to me, although sometimes I browse through it, reading some other bugs to find something that has been happening to me and might clear up something.

I'll go complain somewhere. You're right that although terrific that the package is available, Hacktarux's official version should be like Mupen64 and any fork or 3rd party work should be named a bit (but not completely) differently, like you mentioned.
 

nmn

Mupen64Plus Dev.
Even though i disagree with their decision to degrade the official builds, similar things have happened before. Its probably only because Mupen64s official builds are starting to get old, but i still see no reason to do what they did. Hope its all sorted out soon.
 

Eck

New member
I don't think it was intentional. It's possible that it was simply thought to be a new official release and since it's the choice for N64 emulation on Linux, they just put it up. They didn't change anything about the official version on the other repo, only posted up this one. It's just the effect of the version numbering, the same file name, and the sort of hidden from the average user nature of the official version's repo that causes the trouble.

That search function they have is rather new and many users will likely just look in the top directory, see Mupen64 there, and just add that Emulators repo and wind up with this one.

But I think the official one with its fully functioning GUI, shortcut icons, full package of plugins (well, except for Glide64 for some reason. I just installed that myself afterwards), would be the one chosen by most users who want a stable released version. This new one would be more for those who want to see progress and experiment with things. With things as they are, they might not find out they have that choice.

With the bug report posted I would think someone will be looking into this. I have no idea how effective bug reports are or how fast appropriate action can be taken. I hope they arrange things so that somehow both packages are kept around in a more appropriate format so to avoid confusion. It is quite nice to have a choice and also would be nice if they could possibly be installed at the same time.

We'll see what happens, if anything, when the smoke clears! :)
 

mudlord

Banned
The other night I tried turning on the frame buffer part in the Glide64 and running MarioKart64 to see if the video screen there would show up. It did not! Hmm. Other than that the game ran fine, but didn't appear to be any different from having that setting unchecked. If I recall correctly even though it's been some time since I used it, I believe the videos do show up when MarioKart64 is played on Project64 1.7 beta on Windows XP.

You need to tick "read every frame" in Glide64 for the billboards to show correctly.
 

Eck

New member
Thank you. I'll check for that in there in a bit and see how it goes. Read every frame kind of seems that it might slow things down, but maybe not. Everything plays smoothly so as long as that doesn't cause any hesitation it'll be a nice addition to see the billboards like we're supposed to.

If it does have some bad effect on things though, we really only see the billboard for a few moments while speeding through there so it isn't absolutely necessary for gameplay. But I'm actually expecting the best, since everyone's been saying this works, and I am using the last one available before that HQ series started.
 

mudlord

Banned
Read every frame kind of seems that it might slow things down, but maybe not. Everything plays smoothly so as long as that doesn't cause any hesitation it'll be a nice addition to see the billboards like we're supposed to.

It depends on the game & your video card bandwidth whether it slows down or not. I know that the newest PCI-E based video cards can handle "read every frame" perfectly fine, whereas older cards can have major issues with speed. I noticed simplistic games like Mario Kart 64 have less slowdown or no slowdown at all when using "read every frame" than games such as Donkey Kong 64.

But I'm actually expecting the best, since everyone's been saying this works, and I am using the last one available before that HQ series started.

Yeah this plugin works quite well for what it supports. Though, the HQ series will continue on with the next official Glide64 release, which will support hi-res textures, through the GlideHQ DLL.
 

Top