Mupen64 wishlist

[Trillian]

Hi,
just tried 0.3 and I noticed installation is a bit broken

1.) The source tarball ships with a FIFO in the root directory, which can't be copied => install.sh fails.
2.) What's the "install" target for? If you don't want to set up "real" install targets, I suggest you put the code from install.sh into the Makefile (you prolly want to use "install" of "cp", too).
3.) The mupen64 binary isn't copied to /usr/games/bin/mupen64
4.) /usr/games/lib/mupen64 is a script which creates some directories in ~/.mupen64 and then spawns itself. Uh.
5.) Installation should take care of DESTDIR
6.) The Makefile shouldn't call "strip" manually, IMHO. If you want to strip your binaries, put "-s" in CFLAGS (at least on UNIX/gcc).
7.) Build binaries with debug-symbols by default to make debugging easier

FYI, mupen64 crashes hard when I try to run Zelda OOT with the TR64 and glN64 plugins. Probably some debugging messages would be helpful here for those who don't/can't run mupen in a debugger.

I'll try to deliver backtraces etc later today.

 

[blight]

maybe you should tell us which settings you have chosen to run Zelda: OOT and we can tell you what the problem is...
The collective of your 7 wishes would be a new build system (like automake)

 

[Trillian]

blight: Yeah, I'd whip up a autotools-based system as well. Shouldn't be too hard anyway.

In general: you guys shouldn't set CC = ... in the Makefile, you should override CFLAGS/CXXFLAGS only

1.) Segfault on exit.

Program received signal SIGSEGV, Segmentation fault.
0x4044e644 in fputs () from /lib/libc.so.6
(gdb) bt
#0 0x4044e644 in fputs () from /lib/libc.so.6
#1 0x0807ede7 in ini_updateFile (compress=0) at main/mupenIniApi.c:244
#2 0x08090a29 in main ()
(gdb) f 1
#1 0x0807ede7 in ini_updateFile (compress=0) at main/mupenIniApi.c:244
244 fprintf(f, "%s", ini.comment);
(gdb) p f
$1 = (FILE *) 0x0

2.) Running OOT using Linux 2.6.0-test9, XFree86 4.3, Matrox g450, Via AGPGART, Hacktarux' input plugin, ALSA sound plugin.

glN64: disabled fog. When started as a user, mupen crashes after the spinning Nintendo symbol has been shown for a second.
As root: works, speed okay, but the colors are fscked up

Cannot track down the crash; it fucks up gdb as well.

Tried to quit the game (when "playing" as root), and I got this:

reg[ 0]:       0       0        reg[16]:       0       0
reg[ 1]:       03f800000        reg[17]:       0       0
reg[ 2]:       0       0        reg[18]:       0       0
reg[ 3]:ffffffff80006944        reg[19]:       0       0
reg[ 4]:       0       1        reg[20]:       0       0
reg[ 5]:ffffffff8000a550        reg[21]:       0       0
reg[ 6]:ffffffff800067d0        reg[22]:       0       0
reg[ 7]:       0       0        reg[23]:       0       0
reg[ 8]:       02000ff01        reg[24]:ffffffff80006d70
reg[ 9]:ffffffff8000a550        reg[25]:ffffffff80006d70
reg[10]:       0      fe        reg[26]:ffffffffa430000c
reg[11]:ffffffff8000a550        reg[27]:       0     aaa
reg[12]:ffffffff80006940        reg[28]:       0       0
reg[13]:ffffffffa4400000        reg[29]:ffffffff800072f0
reg[14]:ffffffffffffffff        reg[30]:       0       0
reg[15]:       0      fe        reg[31]:ffffffff800007c0
hi:       0       0        lo:       0       0
après 1717298626 instructions soit 665be5c2

No idea if that's helpful ;D

Graphics are okay, but slow (~17 fps) with the TR64 plugin.

 

[Hacktarux]

That's because you need write permission for save/ folder and mupen64.ini file. I should change it in the futur....

 

[Trillian]

That's because you need write permission for save/ folder and mupen64.ini file. I should change it in the futur....

Yeah, mupen should just put the savegames, config files to ~/.mupen64... the config files in $prefix/games/... should be read-only for the mupen64 process.

 

[Lillymon]

My Mupen64 wishlist:

Dynamic recompiler core.

That's it. I know it'll be ready soon enough, so I'm gonna relax and wait for it along with 1964 0.9.9 public beta.

 

[Doomulation]

My Mupen64 wishlist:

Dynamic recompiler core.

There is already one. But it is far from as optimized as 1964's.

 

[blight]

the current dynarec core is broken afaik
trillian: which version of glN64 do you use? binary or compiled it yourself?

 

[Trillian]

the current dynarec core is broken afaik
trillian: which version of glN64 do you use? binary or compiled it yourself?

Got the latest source tarball from your site; compiled it using:

-finline-functions -funroll-loops -ffast-math -mcpu=i686 -O2

 

[blight]

without X86_ASM defined? weird... sorry... i dunno what the problem could be... maybe a driver issue? no idea... sorry
or does the binary work? or maybe 0.3.1 works?