February 2008 release: Mupen64-amd64 v1.2

[Richard42]

We've been really busy the past few months on Mupen64 development - I've put many hours into a fully-native 64-bit dynamic recompiler, NMN has written a new ROM browser, and DarkJezter added LIRC support for the NOGUI build. There are also a bunch of bug fixes from DarkJezter, Ebenblues, Günther, and myself. Thanks to the whole team for your effort!

As usual, there are links for both 32-bit and 64-bit binaries and individual source packages for RiceVideoLinux and Mupen64-amd64.

The major changes are:

Mupen64-amd64:
- New feature: Dynamic Recompiler for 64-bit
- New feature: New ROM Browser for Mupen64 GUI build
- New feature: LIRC remote control integration for NOGUI build
- Added R4300 profiling features
- TLB Optimization / bugfix
- Bugfix: memory leaks in mupenIniApi.c
- Bugfix: corrupted filenames being saved to disk for mupen64.ini
- Bugfix: crash in jttl_audio
- Bugfix: crash when running game from gui after first time
- Bugfix: spurious noise blip when running game from gui after first time

RiceVideoLinux:
- Bugfix: Texture dumping now works

Mupen64amd64-RiceVideoLinux-1-2-bin-32.zip
Mupen64amd64-RiceVideoLinux-1-2-bin-64.zip
Mupen64-amd64-1-2-src.zip
RiceVideoLinux-1-2-src.zip

Note: The emutalk forum is broken right now - uploads don't work, so these are links to an external web server that hosts one of my domains.

 

[Danny]

Awesome Keep up the amazing work guys

 

[DarkJezter]

I've noticed that Gentoo's portage tree has a package for version 0.5, I'm wondering if it wouldn't be worthwhile to have some packages done up for major distros. If we make an in-house package for at least Ubuntu, Gentoo and RPM based distributions it might generate some extra buzz/interest in the branch.

The only thing though, I suspect calling the packages mupen64-amd64 may prevent a lot of people from trying it. (particularly people with 32 bit cores )

Anyone else have any thoughts on doing this?

Richard. I realize the only source for this stuff at the moment is the SVN tree that you're hosting. Is it safe to assume that we shouldn't be taxing the bandwidth your server offers for source based distributions?

Ciao
Jes

 

[JKKDARK]

Excellent, a new version. Thanks for the emulator, Richard42 and company

 

[Richard42]

I've noticed that Gentoo's portage tree has a package for version 0.5, I'm wondering if it wouldn't be worthwhile to have some packages done up for major distros. If we make an in-house package for at least Ubuntu, Gentoo and RPM based distributions it might generate some extra buzz/interest in the branch.

That would be a very nice thing. Personally I would prefer if we could recruit one or more people to take the source/binary packages that I make for the releases and get them into the right package format for the various distributions. I love Gentoo, my main PC is Gentoo, but I have no experience in making ebuilds. Same with RPMs. We need volunteers to help with this.

The only thing though, I suspect calling the packages mupen64-amd64 may prevent a lot of people from trying it. (particularly people with 32 bit cores )

I agree - I started another thread soliciting ideas for a new project name.

Richard. I realize the only source for this stuff at the moment is the SVN tree that you're hosting. Is it safe to assume that we shouldn't be taxing the bandwidth your server offers for source based distributions?

I believe that Gentoo (I don't know of any other source-based distros) uses mirrors for the ebuilds. My SVN server is running on my home PC with a Comcast connection and about 512kbps upload bandwidth. It's more than adequate for development, but if it got hammered by downloaders it wouldn't be pleasant.

 

[X-Fi6]

Nice!!

 

[olivieryuyu]

would it be possible to get a windows 32 bits binary pls ? I am not programmer and i don t use linux.

 

[CrispyXUK]

Great news, will this get an OSX port?

 

[Richard42]

Great news, will this get an OSX port?

It will if somebody either gives me a Mac, or owns one and volunteers to help with testing and development.

would it be possible to get a windows 32 bits binary pls ? I am not programmer and i don t use linux.

That's an interesting request. I thought PJ64 was the favored emulator for Win32 and people weren't that interested in the other N64 emulators. Unfortunately I don't have any Windows development machines at home any more. Are there any devs who could take some time to update the VC project files in Mupen64-amd64 and put together a package for the Windows users? I don't think it would take too much time.

 

[smcd]

I've never tried compiling mupen on Windows but might give it a go - keyword might

 

[MasterPhW]

That's an interesting request. I thought PJ64 was the favored emulator for Win32 and people weren't that interested in the other N64 emulators. Unfortunately I don't have any Windows development machines at home any more. Are there any devs who could take some time to update the VC project files in Mupen64-amd64 and put together a package for the Windows users? I don't think it would take too much time.

I asked the same question some months ago, with the first release, I don't like only having a specific emulator, because no emulator is perfect and always great to have different possibilities to chose from.
It would be great to see a windows build (for example a X64-86 executable would kick ass) with all your improvements!
Looking forward that someone in your team would build a working binary.

 

[CrispyXUK]

It will if somebody either gives me a Mac, or owns one and volunteers to help with testing and development.



That's an interesting request. I thought PJ64 was the favored emulator for Win32 and people weren't that interested in the other N64 emulators. Unfortunately I don't have any Windows development machines at home any more. Are there any devs who could take some time to update the VC project files in Mupen64-amd64 and put together a package for the Windows users? I don't think it would take too much time.

Well I have one, but am no programmer, didn't lamer0 do the last mupen port?

 

[smcd]

I tried compiling on Windows with the makefile for Windows... no go lots of redefinition errors, conflicting types etc. Ah well, maybe sometime when I'm bored I'll give it another go

 

[Richard42]

Well I have one, but am no programmer, didn't lamer0 do the last mupen port?

That's correct, and you can still get that port from his website and try it out. But it won't have any of the changes/fixes that we've been making. I wouldn't mind merging in the porting changes that he did to get it running on the Mac if they're not too extensive, but it's not feasible for me to do it without having the hardware to test/debug.

 

[Richard42]

I tried compiling on Windows with the makefile for Windows... no go lots of redefinition errors, conflicting types etc. Ah well, maybe sometime when I'm bored I'll give it another go

Oh I just looked at it more closely and realized that there are no project files after all. Apparently the original Mupen64 developers were using a toolkit called Dev C++ for the Win32 platform, so that would be required to build it as is. If I were gonna go down that route I'd just make visual studio solution/project files and build it from there. I think MS have no-cost versions available these days, so at least you wouldn't have to pay for the compiler.

 

[X-Fi6]

Oh I just looked at it more closely and realized that there are no project files after all. Apparently the original Mupen64 developers were using a toolkit called Dev C++ for the Win32 platform, so that would be required to build it as is. If I were gonna go down that route I'd just make visual studio solution/project files and build it from there. I think MS have no-cost versions available these days, so at least you wouldn't have to pay for the compiler.

I'm still getting compilation errors with Dev-C++.

In the makefile it points to /config.h rather than /main/win/config.h (I could fix that). The ASM gives me "too many memory references" errors. (can't fix that)

So when I remove the ASM it compiles but when I load a ROM it just stays blank.

And I just can't seem to make my own VS project.

It's a shame, really, because I really wanted to test this new Mupen out.

 

[Richard42]

In the makefile it points to /config.h rather than /main/win/config.h (I could fix that). The ASM gives me "too many memory references" errors. (can't fix that)

If you post the exact error info that is dumped by the compiler for the ASM I should be able to fix it. That sounds like an unusual error message.

 

[X-Fi6]

If you post the exact error info that is dumped by the compiler for the ASM I should be able to fix it. That sounds like an unusual error message.

Woah, it actually compiled successfully for me now. I'm not getting the error anymore--it just all of a sudden works after re-downloading it for like the 5th time in total lol.

Just could you make one change to \winproject\mupen64.dev? At the very end, for Unit 96, it says:

FileName=..\config.h

It should be:

FileName=..\main\win\config.h

That way I don't have to do it myself every time I download it. :bouncy:

EDIT: I'm still getting that glitch.

 

[Richard42]

Just could you make one change to \winproject\mupen64.dev? At the very end, for Unit 96, it says:

Actually the '..\main\win\Config.h' file is already included, at about #79. This is referencing the old config.h file which I removed a long time ago. If it compiles without it, then it doesn't need it.

Which graphics plugin are you using for this?

 

[X-Fi6]

Actually the '..\main\win\Config.h' file is already included, at about #79. This is referencing the old config.h file which I removed a long time ago. If it compiles without it, then it doesn't need it.

Which graphics plugin are you using for this?

glN64, but it doesn't work with Glide64 or any other plugins, either.