New release: Mupen64-amd64 and RiceVideoLinux versions 1.0

[nmn]

Well, its in your plugins folder, its 32bit... uhh... hmm... Maybe we did something to brake the ABIs?

If you could just, use the console once to start Mupen, and exit, and feed the output to us, that would be pretty helpful.

 

[TwistedWhizz]

Well, its in your plugins folder, its 32bit... uhh... hmm... Maybe we did something to brake the ABIs?

If you could just, use the console once to start Mupen, and exit, and feed the output to us, that would be pretty helpful.

OK, I'm a numpty. How do I do that with executable launchers like Mupen's? I'm very new to terminal use.....sorry.

:blush:

 

[Richard42]

OK, I'm a numpty. How do I do that with executable launchers like Mupen's? I'm very new to terminal use.....sorry.

:blush:

No problem, we all gotta start somewhere. The thing that you're calling a lancher is actually the mupen64 program binary. You need to run this from the console and send us the information that it prints out. There should be a 'location:' bar in your file browser/explorer when you're looking at the mupen64 binary, and this should have the directory path to the binary. The path probably looks something like /home/your-username/Desktop/Mupen64-amd/....

You need to open up the console and type:

cd <mupen_path>

where <mupen_path> is the path that's in the location bar of your file browser. Then type:

./mupen64

The emulator will run and dump out a bunch of information. Select and copy this from your terminal window and paste it here. Additionally, you should type:

ldd ./plugins/ricevideo.so

and paste that here as well - that will tell us why it is not loading Rice video for you.

 

[TwistedWhizz]

Many thanks for your reply and your patience. I've followed your instructions and got this when typing ./mupen64:

Couldn't load plugin '/home/twistedwhizz/Emulators/Mupen64New/Mupen64amd64-RiceVideoLinux-1-0-bin-32/./plugins/ricevideo.so': libgtk-1.2.so.0: cannot open shared object file: No such file or directory

I also typed in ldd ./plugins/ricevideo.so as you said, and got this:

twistedwhizz@twistedwhizz-desktop:~/Emulators/Mupen64New/Mupen64amd64-RiceVideoLinux-1-0-bin-32$ ldd ./plugins/ricevideo.so
        linux-gate.so.1 =>  (0xffffe000)
        libgtk-1.2.so.0 => not found
        libgdk-1.2.so.0 => not found
        libgmodule-1.2.so.0 => not found
        libglib-1.2.so.0 => not found
        libXi.so.6 => /usr/lib/libXi.so.6 (0xb7dee000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb7ddf000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb7cee000)
        libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7c5e000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7c46000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0xb7bb0000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7abd000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7a97000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7a8c000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7942000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb793f000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb793a000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7936000)
        libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb78de000)
        libfusion-0.9.so.25 => /usr/lib/libfusion-0.9.so.25 (0xb78d8000)
        libdirect-0.9.so.25 => /usr/lib/libdirect-0.9.so.25 (0xb78c9000)
        /lib/ld-linux.so.2 (0x80000000)
        libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0xb6f31000)
        libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0xb6f2f000)

Hope this is of some use to you. I'd be very grateful if you could let me know if I've done something wrong! Many thanks again.

 

[Richard42]

Hope this is of some use to you. I'd be very grateful if you could let me know if I've done something wrong! Many thanks again.

Good job - that tells me exactly what went wrong. I made a mistake when I built the binary builds for the 1.0 release, and I built RiceVideo with GTK1.2 support instead of GTK2.0 support. This also caused problems with the RiceVideo config and about dialogs for other people. Your system doesn't even have GTK 1.2 installed, so it won't load the plugin. I've attached the latest 32-bit RiceVideo build to this message, and it was built for GTK 2.0. You should be able to extract the 'ricevideo.so' file from the zip and put it in your plugin folder, and this one should work.

 

[TwistedWhizz]

Thanks very much for replying. I've done as you suggest and downloaded the new plugin. I've extracted it, and replaced the old ricevideo.so with the new one, but now it won't start at all. When I type ./mupen64 as before, I now get -

Illegal instruction (core dumped)

I know noobs are a pain! What would you suggest here?

 

[Richard42]

Illegal instruction (core dumped)

That's very interesting. Did it do this as soon as you started the program, or after you tried to run a game?

Last night I ran a test, with the original 32-bit binary package that I posted on this thread, and the updated RiceVideo binary which I posted yesterday, and it ran perfectly for me. This should be the exact same configuration which you used to get this error, but I didn't get the error. I have an idea what may have caused this and how to fix it, but I need a little bit more information first. What CPU does your computer have? If you're not sure, you can run "cat /proc/cpuinfo" from the console and paste the output here.

 

[TwistedWhizz]

Hiya, yeah I get that message simply trying to run Mupen64 from a terminal. It won't open, and that's the readout.

I've got a fairly dated CPU I believe by most modern standards! It's an AMD Sempron 2200+, which I believe is clocked at 1.5 Ghz. This is the output from the terminal -

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : AMD Sempron(tm) 2200+
stepping        : 1
cpu MHz         : 1512.005
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow up ts
bogomips        : 3025.85
clflush size    : 32

I also have 768Mb of RAM, in case that's of any use to you.

 

[Richard42]

Yep I found a small problem in the makefiles. When doing a 32-bit build on a 64-bit machine, the wrong CFLAGS list was being used, and it was getting compiled with '-march=athlon64'. The compiler probably used some instruction which isn't available on your CPU. I fixed this and re-built all of the binaries, which are in the attached zip file. You should unzip this and copy the mupen64 and mupen64_nogui binaries over your old ones, then copy all of the plugins (*.so) over the old ones in your 'plugins' folder. It's good that you found this problem because I bet it affected a lot of users with older CPUs.

 

[Richard42]

-I seg fault if I put a nonstandard resolution into the .cfg file. Would be fine but there are not widescreen choices.

Kdubya,

I'm trying to reproduce this bug to fix it, and it works for me. I put some weird resolutions into the rice video config file and they all work. Can you please give me some more info on this:
1. Did you build from source or use one of the binary packages? Which architecture are you using (32 or 64-bit)?
2. Which config file did you modify? What are the exact parameter names and values you used in the config file to cause the crash?
3. Were you using the GTK or NOGUI version? Was it in fullscreen or windowed mode?

Thanks.

 

[nmn]

More on the GUI fixes. In the latest SVN:

- The directory list was completely reworked in everyway to move from GtkList to GtkTreeView. If you liked Gtk 1.2 support... well, that brakes it. Sorry, but the GtkList is ugly, buggy, old and depricated On the plus side, i massively cleaned the code and made some slight other adjustments in dialog. Hope they work out

- The ROM list itself has not been reworked. This will probably take *ALOT* more work. I will try to get that done soon.

edit: To elaborate on what i mean by the last thing, the ROM list has not been *changed* yet. It shall be as it was, without the country flag showing up... (will be fixed soon)

And the QT GUI has frozen since i lost all of the code in a crash (which explains my absense of commits. I should've fixed the directory list problem the same night it was found but my partition table did not agree with Windows which i was installing for dualboot purposes and... yeah... long story short, it nuked my tables, and i'm too lazy to try to find the exact locations of the filesystems on it.. >_>)

 

[TwistedWhizz]

Yep I found a small problem in the makefiles. When doing a 32-bit build on a 64-bit machine, the wrong CFLAGS list was being used, and it was getting compiled with '-march=athlon64'. The compiler probably used some instruction which isn't available on your CPU. I fixed this and re-built all of the binaries, which are in the attached zip file. You should unzip this and copy the mupen64 and mupen64_nogui binaries over your old ones, then copy all of the plugins (*.so) over the old ones in your 'plugins' folder. It's good that you found this problem because I bet it affected a lot of users with older CPUs.

Thanks for all your time. I've done as you said, and it seems to work now. The GUI looks a bit different to the old Mupen (I dunno if this was intentional - the boxes at the top of the screen for open rom, start emulation, full screen etc, are now just little boxes with an X on them) but it starts OK.

However, I'm having exactly the same problem with rice video that I had with old Mupen. It still flickers blue when you enter a level. I've attached an image that I managed to capture to give you an idea. I won't bother you any more, since you've already done loads for us owners of older PC's, but I thought you may be interested in this.

Mario Rice Video Glitch

Thanks very much again for your time.

 

[Richard42]

However, I'm having exactly the same problem with rice video that I had with old Mupen. It still flickers blue when you enter a level. I've attached an image that I managed to capture to give you an idea. I won't bother you any more, since you've already done loads for us owners of older PC's, but I thought you may be interested in this.

I spent about a week diagnosing that flashing problem that you illustrated with that screenshot. I was looking at Mario Kart 64 but it affects many other games as well. In the end I found that it was due to an incorrect screen update behavior. I don't know why the emulator has multiple settings for when to update the screen, but it does. If you add this line: "ScreenUpdateSetting=1" to the "SUPER MARIO 64" rom section of the RiceVideoLinux.ini file, this problem will go away. I've updated the ini file in my SVN repository, so this will also be fixed with the next release.

 

[nmn]

The icons are alot better now, but unfortanatally, the method to load them has changed. Soon enough it will be fixed, but for now, the current working directory must be the application directory. (This would mean, for example, on a KDE desktop, the shortcuts "work path" must be the directory mupen64 is in. On a GNOME desktop, its hard to set the work path because GNOME doesn't directly support it.) Really the working directory belongs at the directory of the application if nothing else, but KDE and Gnome both set it to ~ i believe, when its not specified. (This is what makes double clicking applications directly in Linux usually not work )

 

[Danny]

Nice stuff, you guys are really hunting down those bugs

Btw, would you mind removing me from the svn mailing list Richard? My inbox is getting too flooded

Cheers, and keep up the great work guys

 

[nmn]

Richard42, do you think we should try to... *force* the global screen update setting to 1? It shouldn't do much harm considering it seems to work with pretty much any rom.

 

[sl1pkn07]

Thanks

 

[Richard42]

Richard42, do you think we should try to... *force* the global screen update setting to 1? It shouldn't do much harm considering it seems to work with pretty much any rom.

The thought had occurred to me. There is a value for the default setting of the ScreenUpdateSetting parameter - currently the default is 0. It is possible to change this default to 1 instead. I am a little reluctant to do this because I don't really understand why there is a setting for the screen update time. It seems like there should be 1 method or mechanism to handle this (ie, whatever the N64 hardware itself uses) and this should work with all the games. Since I don't understand why this setting exists (what problem it was intended to solve), I have no idea about what problems could be caused by changing the default. Probably the best thing to do would be to test a large number of games (maybe 50 or so) with both settings, and if there are fewer problems or artifacts with the new setting, then it would be safe to change the default.

I know that's a lot of work but in a relatively mature project it makes sense to spend effort to avoid a regression.

 

[Eck]

Hey again!

I noticed a mupen64-1.0-1.1 in the OpenSUSE Build Service. That's this project, isn't it? I think it's terrific that we have an easily installable rpm through our package manager available. Thanks!

But, some questions since I'm wondering what I want to do with this.

The comments state to use the GUI sparingly, if at all since it's buggy at the moment. Well, I've only used Mupen64 with the GUI. Most recently with the Mupen64 version 0.5-6.1 from the wberrier OpenSUSE Build Service repo with the only change being my using the version 12 Glide64 plugin and adding that since the package doesn't come with it.

Since the other emulators I use, fceu and zsnes, are not packaged with openGL support in the Build Service I compile them myself and just added PicoPico's repo to get kfceu for a gui to my built fceu. Back on Debian when the kfceu didn't install properly when I tried building it I went back to GFCEU, which still works great but kfceu is better with more resolution control.

If I add that additional emulator repo to get your Mupen64, it will have the higher version number and so remove the version I have that works just great for most things and replace it with your new version.

Although I do want to try the new version as you have related having fixed a lot of bugs in games with it, the one I have works just great for most of what I play. Not ever having much success with the Rice Video plugin, using your version centered upon that plugin really makes me committed to switching over to Rice. Especially since I will no longer have the older Mupen64 available. The packaged Mupen64 on the wberrier site, which installs to the system and not just the home folder extraction that the official 0.5 version did, is working much better than the official 0.5. It is handling full-screen switching and correct resolution and refresh rate and seems to be giving me higher fps scores all better than the original.

So you see I have reasons, including using the GUI and the various alternative video plugins, for wanting to stay with what I've got here.

Is there no way of simply taking your improved Rice Video plugin and replacing the one I now have on my Mupen64-0.5-6.1 version? Is it so radically changed now that a simple drop-in replacement just isn't possible? If it were, I could keep the working GUI, control the plugin with the GUI configuration control, and also still have the rest of the package with the improved performance I have been noticing with it.

Any shot of something like that working for a not so terminal oriented GUI lover?

 

[Richard42]

I noticed a mupen64-1.0-1.1 in the OpenSUSE Build Service. That's this project, isn't it? I think it's terrific that we have an easily installable rpm through our package manager available. Thanks!

That's cool - I have no idea who added this release to the emulator repo for OpenSUSE; I haven't heard anything about it. But I'm glad to hear that it's getting out. We're going to make another one soon because there have been a lot of fixes.

So you see I have reasons, including using the GUI and the various alternative video plugins, for wanting to stay with what I've got here.

Is there no way of simply taking your improved Rice Video plugin and replacing the one I now have on my Mupen64-0.5-6.1 version? Is it so radically changed now that a simple drop-in replacement just isn't possible? If it were, I could keep the working GUI, control the plugin with the GUI configuration control, and also still have the rest of the package with the improved performance I have been noticing with it.

Any shot of something like that working for a not so terminal oriented GUI lover?

Well you could always give it a try and see what happens. I assume that you are running a 32-bit system; if so take the last untagged 32-bit rice video binary which I posted in this thread (post #69 on page 7), extract the ricevideo.so plugin file, and drop it into the plugin directory wherever your Mupen0.5 was installed.

We've actually fixed quite a few GUI bugs in the last week or so - the blight input config dialog had issues as well as the directory browser. Maybe after we make the next release whoever added the last one to your repo will also add this one; hopefully this will be the best of both worlds.