What's new

February 2008 release: Mupen64-amd64 v1.2

Richard42

Emulator Developer
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.
 

DarkJezter

New member
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
 
OP
R

Richard42

Emulator Developer
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.
 
OP
R

Richard42

Emulator Developer
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.
 

MasterPhW

Master of the Emulation Flame
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.
 
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

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

Richard42

Emulator Developer
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.
 
OP
R

Richard42

Emulator Developer
I tried compiling on Windows with the makefile for Windows... no go :p 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

New member
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. :(
 
Last edited:
OP
R

Richard42

Emulator Developer
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

New member
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. :(

glitch335.png
 
Last edited:
OP
R

Richard42

Emulator Developer
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

New member
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.
 

Top