mupen64-amd64 praise, questions

[shiny]

Hi,

First of all let me thank you for reactivating mupen64 and giving all of us linux users a hope for the better n64 emulation! I use the new version and find it faster and more compatible than the v0.5. Finaly the nogui version works as expected, so I can run it from within freevo, which I use on my dedicated gaming box.

Anyway, although I can run some games with very acceptable results (Super Smash Bros, Paper Mario, Extreme G, Rampage), others run a bit too slow and the sound likes to stutter quite a lot - or just plain don't work at all (the game, not the sound ). So, my question is: in the light of recent developments and improvements, can we (the users ) expect more performace from our old i386 machines in the future, or should we just upgrade to 64bit? I for one would love to see my Celeron 2100 with 512 MB of RAM and nvidia 5200 to run more n64 games.

Anyway, keep up the good work, and in the meantime I'll stick with Super Smash Bros ;D

 

[Richard42]

...others run a bit too slow and the sound likes to stutter quite a lot - or just plain don't work at all (the game, not the sound ). So, my question is: in the light of recent developments and improvements, can we (the users ) expect more performace from our old i386 machines in the future, or should we just upgrade to 64bit?

Shiny,

Glad to hear that you like our improvements. As you probably realize, the sound stuttering is caused by not enough processing/graphics power to run the emulator at real-time speed. I don't really plan on optimizing the 32-bit dynamic recompiler, which eats most of the CPU time if you have a fairly modern video card. The 64-bit dynarec is actually slower than the 32-bit one right now. I would like to optimize this to achieve better performance but I don't know if I'll have the time to do this anytime soon. In short, moving from the 32-bit build to the 64-bit build (on the same machine) will actually result in slightly worse performance. I'm afraid if you want better performance you'll probably have to buy a newer machine. One thing to point out is that the r4300 emulator (the interpreter and especially the dynarec) eat up a large amount of RAM. The whole process can consume 500MB-1GB while running, so if you have less than 1GB-2GB of RAM, you might be able to get better perfomance by adding more memory. The way to determine if it's impacting performance is to watch your hard drive light while running - it should only be accessing the disk very little or none at all. If it's hitting the disk very hard then you need more RAM.

 

[shiny]

Hi Richard!

Thank you for your quick reply! I will test it later today with with more ram from my other machine. Do you have any suggestions about the video/audio settings which have the most impact on performance? Which is the preferred audio plugin in combination with RiceVideo 1.1?

 

[Richard42]

Hi Richard!

Thank you for your quick reply! I will test it later today with with more ram from my other machine. Do you have any suggestions about the video/audio settings which have the most impact on performance? Which is the preferred audio plugin in combination with RiceVideo 1.1?

The only audio plugin that works for me is jttl_audio, and the only input plugin that works is blight_input. I did some profiling on my desktop PC with a GeForce 6600 silencer, and the video plugin only took about 10% of the execution time. So choosing a different plugin or tweaking settings will probably have a small effect. Probably the most import setting is the resolution - there's not much point in having it higher than 640x480, since that it the maximum practical res with NTSC anyway.

Just make sure that you are using the dynamic recompiler (--emumode 2) because the interpreter takes about 2x more CPU time.

 

[Zarniwoop]

Just make sure that you are using the dynamic recompiler (--emumode 2) because the interpreter takes about 2x more CPU time.

This might sound odd, but even though when I set mine up in the GUI I chose the dynamic recompiler, when I run mupen64_nogui with --emumode 2, it runs faster then if I don't pass an emumode argument at all. I don't see an entry for it in mupen64.conf (even if I change it to something else), is the setting hiding somewhere else? Thanks for the excellent program by the way Richard42.

Anyone else have any performance tricks? I'm running a first gen P4 1.4 with 1.1GB RDRam and a GForce2 MX/MX 400 with 32mbs of RAM (I know...) so I could use any you can throw my way. Is there a way to disable the audio? That might help a bit...

 

[Richard42]

This might sound odd, but even though when I set mine up in the GUI I chose the dynamic recompiler, when I run mupen64_nogui with --emumode 2, it runs faster then if I don't pass an emumode argument at all.

There actually is a setting for the r4300 core in the mupen64.conf file - I think it's something like "Core=x". It doesn't have the same numbering scheme as the command-line option though (this is a bug, which has been reported and fixed). I think if you set it to 1 it should use the dynamic recompiler. You can always see what was used after running the emulator by looking at the output to the console. The r4300 mode is printed there.

You can disable the audio with "--audio ./plugins/dummyaudio.so".

 

[Zarniwoop]

There actually is a setting for the r4300 core in the mupen64.conf file - I think it's something like "Core=x". It doesn't have the same numbering scheme as the command-line option though (this is a bug, which has been reported and fixed). I think if you set it to 1 it should use the dynamic recompiler. You can always see what was used after running the emulator by looking at the output to the console. The r4300 mode is printed there.

ko... so I looked into it, and there's a bug of sorts.

If you go in and set it to the use the dynamic recompiler in the GUI, it sets Core = 1 in mupen64.conf. When you run the emulator from the GUI, you get the dynamic recompiler. All is well. BUT if you then run the same conf file with mupen64_nogui, you get the Interpreter....

If you change the the conf to Core = 2 and run mupen64_nogui, you get the dynamic recompiler, but if you open up the GUI and check, it now thinks you're using the Pure Interpreter and when you run the emulator from the GUI, that's what you'll get.

So... It looks like mupen64_nogui actually does use the same numbering scheme for --emumode and the .conf, it's just that it's offset by 1 from mupen64's! I hope I made sense, can someone confirm? Hope this helped.

[edit]
I'm using 1.2 by the way.

 

[Richard42]

ko... so I looked into it, and there's a bug of sorts.

Yep, you accurately described that bug. I think that came about when I re-worked a whole bunch of code in the _nogui build before I made the first release. Ebenblues also found that and fixed it in SVN, so it will be corrected in the next release.

 

[Zarniwoop]

Oh, it's the bug you mentioned earlier? Sorry, I guess I misunderstood. (I thought you meant that mupen64_nogui uses a different numbering in the .conf than at the CLI). Damn, here I thought I was helping.

 

[Richard42]

Oh, it's the bug you mentioned earlier? Sorry, I guess I misunderstood. (I thought you meant that mupen64_nogui uses a different numbering in the .conf than at the CLI). Damn, here I thought I was helping.

Yep, that's the bug. I explained it incorrectly because I wrote that message without looking at the code and I mixed up the details. I looked at the code last night, and as it turns out, the patched code has the property you mentioned. The --emumode CLI option takes a range of 1-3. But the value which is used in a global variable inside the program, and the value which is written into the mupen64.conf file, has a range of 0-2. The _nogui build was modified to store the value as a 0-based index because that's how the GUI build also saves it. I don't really like that very much (having different ranges for the same parameter), but the internal variable really needs to stay 0-based, because it's used in hundreds of places and would be a pain to change them all without breaking something. We could change the code that reads and stores this value in mupen64.conf, but it's not worth the effort right now.

So unfortunately we already knew about this bug that you found, but you did a very good job explaining it. If you find any more, be sure to report them.

 

[TD-Linux]

I just tried this emulator out (as my first n64 emulator) and it is great! glN64 is virtually bug-free! RiceVideoLinux, on the other hand, has problems with textures flashing white or black (the alpha stays consistent though). This is visible even on the rotating-N splash screen.

Also, I never seem to get more that 20 fps on my 2.2ghz core 2 duo, which seems a bit low, but it's playable.

 

[Richard42]

I just tried this emulator out (as my first n64 emulator) and it is great! glN64 is virtually bug-free! RiceVideoLinux, on the other hand, has problems with textures flashing white or black (the alpha stays consistent though). This is visible even on the rotating-N splash screen.

Also, I never seem to get more that 20 fps on my 2.2ghz core 2 duo, which seems a bit low, but it's playable.

We have 3 decent video plugins now (I just added Glide64 to SVN a few days ago), and they all have bugs. I fixed numerous bugs to get Rice Video working nearly perfectly in Super Mario 64, Mario Kart 64, and Kirby 64. We'll keep improving them in the future. You should be able to get real-time performance with a 2.2 ghz core 2 duo CPU. Make sure that you have the Dynamic Recompiler in use for the r4300 core.

 

[TD-Linux]

Hmm OK, it might be a problem with my video driver (169.something nVidia on Linux). Where is this SVN server? I'd like to pull the source and compile it myself (with optimizations)... maybe I can find it somewhere on the forums.

 

[Richard42]

Hmm OK, it might be a problem with my video driver (169.something nVidia on Linux). Where is this SVN server? I'd like to pull the source and compile it myself (with optimizations)... maybe I can find it somewhere on the forums.

svn://fascination.homelinux.net:7684/mupen64-amd64/trunk/

The svn login is 'mupen64', and the password is 'Dyson5632-kart'.

 

[shiny]

Yep, that's the bug. (...)

Does it mean we should go with --emumode=1 when using nogui?

 

[ebenblues]

Does it mean we should go with --emumode=1 when using nogui?

If you want the Dynamic Recompiler, you should go with --emumode 2. The numbers passed to --emumode are off by one from the numbers in the mupen64.conf file. This is something I intend to fix soon. For now, use --help to see which emumode number to use and check the output of the nogui program to see which mode it's actually using.