What's new

February 2008 release: Mupen64-amd64 v1.2

smcd

Active member
Just a FYI I was using MinGW 3.4.5 not through Dev-C++ but using mingw32-make against winproject\Makefile.win
 

zeldaman55069

New member
So yea, just thought I'd submit an idea. In your changes to RiceVideo you should include a debug version, unless you already have one that I'm missing. RiceVideo runs, but if I enable loading of hi-rez textures it runs for about 3 seconds then crashes(and i know it's working cause it's loading the textures perfectly, and the video is displayed)... otherwise this is an amazing update/branch of mupen(much needed for the linux emu scene if u ask me)...
 

X-Fi6

New member
Nobody to compile a windows 32 bit version :( ?

I really wanted to test this version
I compiled it for Windows 32-bit (Dynamic Recompiler doesn't work however). You can download it here:

www.phppoll.org/Mupen64-amd64_x86_1-2.zip

But really, most of the changes have only been made to the Linux version of it (like a ROM browser, Rice Video Linux, changes to the Blight input plugin, etc)

In this build there's Kaillera and some *minor* minor minor improvements.
 
OP
R

Richard42

Emulator Developer
So yea, just thought I'd submit an idea. In your changes to RiceVideo you should include a debug version, unless you already have one that I'm missing.

Rice Video does have an integrated debugger but the GUI was not ported when the plugin was brought over to Linux, so it's really broken. I kind of hacked it up and used it a little when I was fixing bugs in rice video earlier, but fixing it right would require adding a full GTK debug window with all the controls. I'm not really motivated to do that because I don't have much experience with GTK and I prefer to debug with properly placed printf statements, asserts, and gdb anyways. You can run 'make DBGSYM=1' to generate a build with debug symbols, which is helpful when using GDB. If someone with GTK experience wants to make a proper debug window it would be nice.

I compiled it for Windows 32-bit (Dynamic Recompiler doesn't work however). You can download it here:

Congratulations X-fi6, you're our new Win32 builder. :) You're right - most of the big improvements (other than 64-bit dynarec) were not in the core Mupen64 code, because that part of it works pretty well already.
 

snexs

New member
hello, nice work.
but it seems to be that jabos graphic plugin doesnt work.
i have tested many games and everytime the same result.
if i use jabo i get a black screen, the sound works.
Mupen Jabo:
mupen64jabo16hy2.jpg

Mupen Rice:
mupen64riceiv5.jpg

Mupen64++ with Jabo:
mupen64ppjabomc4.jpg
 
Last edited:

Tillin9

Mupen64Plus Dev.
Just a heads up, 1.1 worked for me (though some icons didn't appear), but 1.2 crashes when I start emulation. Does this regardless of video plugin.

[email protected]:~/Mupen64amd64-RiceVideoLinux-1-2-bin-32$ ./mupen64
Couldn't load plugin '/home/templarapheonix/Mupen64amd64-RiceVideoLinux-1-2-bin-32/./plugins/blight_input.so': libSDL_ttf-2.0.so.0: cannot open shared object file: No such file or directory
rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:1449
CRC: ec7011b7 7616d72b
name: THE LEGEND OF ZELDA
Manufacturer: 43000000
Cartridge_ID: 4c5a
Country : United States
size: 4096
PC= 80000400
md5 code:5BD1FE107BF8106B2AB6650ABECD54D6
eeprom type:0
init timer!
memory initialized
[glN64]: (WW) Couldn't open config file '/home/templarapheonix/Mupen64amd64-RiceVideoLinux-1-2-bin-32/./plugins/glN64.conf' for reading: No such file or directory
Signal number 11 caught:
errno = 0 (Success)

Any ideas? Thanks in advance and for all the hard work.
 
OP
R

Richard42

Emulator Developer
Just a heads up, 1.1 worked for me (though some icons didn't appear), but 1.2 crashes when I start emulation. Does this regardless of video plugin.

Can you try different input plugins and different emulator cores (interpreter, dynamic recompiler, etc) to see if you can narrow it down to one of these components?
 

Tillin9

Mupen64Plus Dev.
Thanks for the quick reply. I should have been more verbose in my previous post. My first instinct was to try various options. Regardless of video plugin, Rice, glN64, (even software gfx) or CPU option - dynamic recompiler, interpreter, pure interpreter, the same thing happens. As soon as I start emulation, Mupen exits. I tried restarting X inbetween tests, same issue. All crashes give the same error message at the console.

Some other info:
Distro: Debian Testing (Lenny)
Kernel: 2.6.23-1-686
Xorg: 7.3-10

Let me know if any other info. would be helpful in tracking down this regression.
 
Last edited:
OP
R

Richard42

Emulator Developer
Let me know if any other info. would be helpful in tracking down this regression.

A couple more questions: What's the output of 'cat /proc/cpuinfo'? Does the v1.1 console output also have the error message 'libSDL_ttf-2.0.so.0: cannot open shared object file:'?

I also ran this game as a test - Zelda Majora's Mask. My console output gave the same CRC as yours, but a different MD5. Do all the games crash? I wonder if this is a bad ROM or there's a bug causing the ROM data to be incorrect. Can you try the _nogui build?
 

remmy

reenignE
I just spent a few hours or so hacking away at the 0.5 source to get it running smoothly in my 64 bit flavor of choice before stumbling on this Incredible work. It's really nice to see ANY active emulation development in Linux.

A couple of questions:

Is there anything like a roadmap set for the project?

For people looking to lend a hand, would you prefer submissions in the form of patches or by some other means?

Are there certain areas you'd like people to concentrate on before contributing to new features?


Once again, great work.
 

Tillin9

Mupen64Plus Dev.
I think I found a bug!

[email protected]:~/Mupen64amd64-RiceVideoLinux-1-2-bin-32$ ./mupen64_nogui /Legend_of_Zelda\,_The_-_Ocarina_of_Time_\(U\)_\(V1.0\)_\[\!\].v64 --./input=plugins/blight_input.so

Mupen64-amd64 version : 1.2
Couldn't load plugin './plugins/blight_input.so': libSDL_ttf-2.0.so.0: cannot open shared object file: No such file or directory
***Warning: Input Plugin './plugins/blight_input.so' couldn't be loaded!
***Error: No Input plugin loaded.

The exact same line works flawlessly with 1.1. Actually, I don't even need to specify an input plugin as it can find it just fine. The nogui 1.2 fails (same error) without the --plugin line.

Just in case this isn't it, as requested:

[email protected]:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 6
cpu MHz : 751.738
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat p
se36 mmx fxsr sse up
bogomips : 1504.78
clflush size : 32

Yes, I know my CPU is probably too slow to run Mupen, but unless you compiled with sse2/3 no fallback or something I doubt there is an issue.

V1.1 also gives the libSDL_ttf-2.0.so.0 error. (Should also note that after recently upgrading GTK I no longer have the icon issues in 1.1)

As far as ROMs:

[email protected]:~/Mupen64amd64-RiceVideoLinux-1-1-bin-32$ ./mupen64
Couldn't load plugin '/home/templarapheonix/Mupen64amd64-RiceVideoLinux-1-1-bin-32/./plugins/blight_input.so': libSDL_ttf-2.0.so.0: cannot open shared object file: No such file or directory

(mupen64:10505): Gtk-CRITICAL **: gtk_box_pack_start: assertion `child->parent == NULL' failed
rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:1449
CRC: ec7011b7 7616d72b
name: THE LEGEND OF ZELDA
Manufacturer: 43000000
Cartridge_ID: 4c5a
Country : United States
size: 4096
PC= 80000400
md5 code:5BD1FE107BF8106B2AB6650ABECD54D6
eeprom type:0
init timer!
memory initialized
[glN64]: (II) Initializing SDL video subsystem...
[glN64]: (II) Getting video info...
[glN64]: (II) Setting video mode 1600x1200...

As my Zelda64 ROM works with 1.1, and has with every other emulator I've tried, I doubt its the ROM. However, I did try with some other ROMs I had handy. Trying Mario64, and Zelda64 Master Quest, 1.2 gave the same issues:

[email protected]:~/Mupen64amd64-RiceVideoLinux-1-2-bin-32$ ./mupen64
Couldn't load plugin '/home/templarapheonix/Mupen64amd64-RiceVideoLinux-1-2-bin-32/./plugins/blight_input.so': libSDL_ttf-2.0.so.0: cannot open shared object file: No such file or directory
rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:1446
CRC: a03cf036 bcc1c5d2
name: SUPER MARIO 64
Manufacturer: Nintendo
Cartridge_ID: 4d53
European cartridge
size: 4096
PC= 80241800
md5 code:45676429EF6B90E65B517129B700308E
eeprom type:0
init timer!
memory initialized
Signal number 11 caught:
errno = 0 (Success)

[email protected]:~/Mupen64amd64-RiceVideoLinux-1-2-bin-32$ ./mupen64
Couldn't load plugin '/home/templarapheonix/Mupen64amd64-RiceVideoLinux-1-2-bin-32/./plugins/blight_input.so': libSDL_ttf-2.0.so.0: cannot open shared object file: No such file or directory
rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
byteswaping rom...
rom byteswaped
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:144c
CRC: 1d4136f3 af63eea9
name: ZELDA MASTER QUEST
Manufacturer: Nintendo
Cartridge_ID: 4c5a
Country Code : f45
size: 4096
PC= 80000400
md5 code:2DE4D0F0788871CC4BB6D30B60F72184
eeprom type:0
init timer!
memory initialized
Signal number 11 caught:
errno = 0 (Success)

Both ROMs work fine with 1.1 and a variety of other emulators.
Anyway... hope all this helps.
 

Tillin9

Mupen64Plus Dev.
Okay... that was it. For some reason the Mupen64 basic input plugin wasn't being selected in the config or giving any kind of error when I started emulation without an input plugin. Forcing it to basic lets the ROM start just fine.

Blight input doesn't seem to want to show up in the GUI (neither 1.1 or 1.2). Not sure what is the actual cause of that error (i.e. the plugin doesn't work on my system) or the GUI just has issue loading it / telling me its loaded.

EDIT: On Debian you need to install libsdl-ttf2.0-0 a 15KB package with the font. With that installed I can now see Blight input in the GUI and the libSDL_ttf-2.0.so.0 error doesn't appear.

Thus the bug is the inability to fallback to Mupen basic input. Blight's plugin ideally should be recoded to not get so upset over a font, but this is a minor problem, and really a line in the documentation should be fine.

Looks like I solved my own problem. :) Is there any work so far on the Qt GUI? Sadly I don't know GTK so I won't be much help, but I have made KDE/ Qt GUIs via KDevelop / QT Designer and won't mind helping with that.
 
Last edited:
OP
R

Richard42

Emulator Developer
Thus the bug is the inability to fallback to Mupen basic input. Blight's plugin ideally should be recoded to not get so upset over a font, but this is a minor problem, and really a line in the documentation should be fine.

So the _nogui build gave you an error message and quit, but the gui build just didn't load a plugin and crashed. That's a bug in the GUI build. The failure to load the blight_input plugin isn't a problem with the plugin - it's impossible to dynamically load it if the dependencies are not found. We'll have to make sure that this is fixed in the upcoming gui/nogui consolidation that Ebenblues is doing.
 
OP
R

Richard42

Emulator Developer
Is there anything like a roadmap set for the project?

There is no official roadmap for this project as of right now. To give you a little history - the current work started about 6 months ago. NMN did some 64-bit porting work on Mupen64 itself, and Hacktarux ported RiceVideo from Win32 to Linux. I decided to start development from these two by merging them into a larger project and setting up an SVN server. I ported RiceVideo to run natively as a 64-bit app and started fixing bugs.

Since then several other developers have joined the effort and contributed code. We welcome submissions of good code from anyone wanting to help. I have been thinking lately about the direction of the project as more people have been joining, and my overall vision for our work is that I want this to become one of the finest and most used emulators available for 32-bit and 64-bit Linux platforms. I really believe that Linux is becoming a great development platform, and with all the new users coming on board with popular distros like Ubuntu and Fedora, I want people to have access to an accurate N64 emulator to expand the possibilities of Linux gaming. Developers are welcome to work on whatever they are most motivated to do, but personally I see a need for improvement in the following areas:

1. Compatibility with games - fixing graphical glitches and bugs to make as many games as possible work flawlessly.
2. Bug fixing and code quality: I don't want to see any compiler warnings, GTK warnings, etc. When I first picked up this project there were quite a few obvious and annoying bugs - I've been working to get everything 'in shape' and working as smoothly as possible, and this needs to continue. We need to be very focused on quality and testing, and ensure that the code is really 'done right'.
3. Integration with distributions. We need people who can take the binary and source release packages that I post here and make distro packages (rpm, deb, ebuild) for the major Linux distributions to attract a wider audience for testing and playing.

For people looking to lend a hand, would you prefer submissions in the form of patches or by some other means?

I will accept patches here, but if someone is serious and making a contribution I would prefer that he/she send me a PM with username/password and email address, and I will set up a developer account on the SVN server. I have commit email notification setup and look over the new code to maintain quality.

Are there certain areas you'd like people to concentrate on before contributing to new features?

I am maintaining TODO files in the root directory of each sub-project - these contain known bugs which need to be fixed and feature requests from people here on the forum. With more developers coming on board, I would like to ask that developers wishing to contribute drop me a PM/email and let me know what you want to work on; I'll maintain a list and loosely coordinate so that people aren't working on the same things.
 
Last edited:

thatmariolover

New member
I have XCode (Apple development kit for OS X) and can open Lamer0's source project. But I don't know the first thing about swapping in the various changes without breaking it.

I'm gonna pick up a few books tomorrow I think.
 
Last edited:

TwistedWhizz

New member
Anyone else here getting shaky screen on the 32-bit version? It's great if I leave it windowed, but as soon as I make it full-screen, the whole thing shakes about and you can't really play it.

I think I remember having this issue on the last release you guys did too. Could it be the graphics card drivers I'm using? I have an Nvidia FX5600XT, which isn't great I know but has been good for N64 emu in the past. I'm using the proprietary drivers from Ubuntu's repository for 7.10.

Thanks all. :)
 
OP
R

Richard42

Emulator Developer
Anyone else here getting shaky screen on the 32-bit version? It's great if I leave it windowed, but as soon as I make it full-screen, the whole thing shakes about and you can't really play it.

Nobody else has reported this bug. I am also using the proprietary NVidia drivers with a 6600 card on my desktop PC and I haven't noticed any shaking. Does this happen with both graphics plugins and multiple games?
 

Top