What's new

Mupen64 0.4 & Zelda Majora Mask probs / crashs

kabalak

New member
Hi,

we are happily using mupen64 0.4 from the precompiled packages from the official mupen64 homepage on a Debian linux machine (Athlon 2800+, 512 MB RAM, GeForce 440MX). For playing Zelda Ocarina of Time everything - except the unnice multiple suns problem with the glN64 video plugin (glN64 v0.4.1-rc2) and smaller graphix probs... - went quite good.

But currently we try to play Majora`s Mask (ROM name: "Legend of Zelda, The - Majora's Mask (E) (M4) [!]" - Ini Code E97955C6-BC338D38-C50) and it crashes / freezes quite often: mostly after 1-2 minutes, sometimes even immediately after an action.

The screen keeps gray and nothing further happens - CPU usage also goes down to almost 0 %, so I guess the emu goes down :-/

We're using the "no audio delay" and "Interpreter" core functions & the glN64 video plugin with fog, 2xSAI, HW framebuffer textures enabled for a 800x600 resolution. Super Mario 64 plays well and without any errors, Zelda OoT had some slight problems but nothing more important.

Are we missing something? With "dynamic recompiler" core option it crashes even more often. Is there any solution to this? Or should we just forget Majoras Mask for mupen64 & linux...
 

aminalshmu

linux gaming enthusiast
i had issues with majora's mask as well on gentoo linux with mupen64 0.4. i made it a little ways into the game with dynamic recompiler and the glN64 plugin but just gave up, with too many crashes. maybe in the next version... maybe with another sound or gfx plugin... it just doesn't seem like a lot of development is going on with n64 emulation for linux. :(

aminalshmu
 

Hacktarux

Emulator Developer
Moderator
Hmm... i'm starting to feel ashamed to answer this to most questions lately but... it's a problem that will likely be fixed in the next version. I just hope i'll find the time to release it.
 
OP
kabalak

kabalak

New member
Hacktarux said:
Hmm... i'm starting to feel ashamed to answer this to most questions lately but... it's a problem that will likely be fixed in the next version. I just hope i'll find the time to release it.

Any timeline for the new release 0.5? Or can we test a beta version somewhere (download, CVS repository etc.)?! :whistling
 
OP
kabalak

kabalak

New member
So, now I started mupen with the same ROM but the Glide video plugin - it worked a bit longer, but hangs now with following messages on the console:

Code:
(II) Initializing SDL video subsystem...
(II) Getting video info...
(II) Setting video mode 800x600...
demarrage r4300
interpreter
Signal number 11 caught:
        errno = 0 (Success)
Xlib: unexpected async reply (sequence 0x4f87d)!
 

juwb

New member
kabalak said:
Any timeline for the new release 0.5? Or can we test a beta version somewhere (download, CVS repository etc.)?! :whistling

SVN or CVS would be really nice. I wouldn't mind betatesting bleeding edge development versions. And it would probably be easier to follow the development or even contribute...

Anyway, about Majoras Masks, it runs quite well on my linux machine. I use glN64 for the most part. This plugin has problems in some situations (for example, when you see the great fairy the first time, or for sequences in general), the screen goes gray. In that case, I switch to another graphics plugin (tr64gl), that looks crappy, but at least does not crash. When the part is over, I switch back to glN64. Of course, you have to use the save state feature (hotkeys, 0-9 to select slot, F5 to save, F7 to restore) regularily, so that you can go back where you left off after it crashed.

This way, the game is very playable (you actually don't have to switch graphics plugins that often, it's just in the beginning it crashes the most); that said, I haven't actually played very far. I got my ocarina back and can walk around on the fields as a boy, but that's about it.
 
OP
kabalak

kabalak

New member
juwb said:
...This way, the game is very playable (you actually don't have to switch graphics plugins that often, it's just in the beginning it crashes the most); that said, I haven't actually played very far. I got my ocarina back and can walk around on the fields as a boy, but that's about it.

Well, I'm currently also that far that I can run around the fields as a boy but well, it crashes there and I have to start within the long sequence with the mask selling man :-/

Is the tr64 plugin somehow useful? I once tried it and it didn't perform very well in contrast to glN64...
 

juwb

New member
kabalak said:
Is the tr64 plugin somehow useful? I once tried it and it didn't perform very well in contrast to glN64...

No, I just use it as an ersatz plugin for the passages that make glN64 crash. Although it does not crash (at least not at the same passages where glN64 crashes), it has to many graphical errors to be useful for general play.

It's only sequences and stuff that make Mupen+glN64 crash on my system; the crashes are not random. I can run around in the town and on the fields for ages without crashing in glN64. Until I do something very special like collecting the great fairy fairies and getting a sequence as crashing reward.
 
OP
kabalak

kabalak

New member
juwb said:
No, I just use it as an ersatz plugin for the passages that make glN64 crash. Although it does not crash (at least not at the same passages where glN64 crashes), it has to many graphical errors to be useful for general play.

It's only sequences and stuff that make Mupen+glN64 crash on my system; the crashes are not random. I can run around in the town and on the fields for ages without crashing in glN64. Until I do something very special like collecting the great fairy fairies and getting a sequence as crashing reward.

Well, well, we are now using Glide64 & all selfcompiled mupen stuff and it works much faster - but the crashes are still persisting. With the F5/F7 state save/restore function we got a good tool against the crashes :)

The tr64 video plugin did not protect me against any crashes unfortunately :-( And saving state did crash mupen while changing a mask so I would suggest not to use F5 while doing any active game action; so I have got to do the 1st dungeon again now :-/
 
Hi.

Same problem here, except that I've found another game implicated. Wetrix (european) also crashes the same way, apparently randomly, I think no matter the plugins/core mode being used -tried almost all combinations. Here is the message Zelda MoM spits:

Code:
Signal number 11 caught:
        errno = 0 (Success)
Xlib: unexpected async reply (sequence 0x4f87d)!

Unfortunately, I don't know -and i can't tell you now- if Wetrix also crashes with the message kabalak put up there, but at least Zelda MoM does to me too.

Sorry by my crappy almostEnglish - Spanish speaker.

But currently we try to play Majora`s Mask (ROM name: "Legend of Zelda, The - Majora's Mask (E) (M4) [!]" - Ini Code E97955C6-BC338D38-C50) and it crashes / freezes quite often: mostly after 1-2 minutes, sometimes even immediately after an action.

Well... 2-10 minutes to me really.

Since the error seems to have something to do with xlibs... well... i'm installing x.org 6.8.2 from an unnofficial repo, so i could try recompiling and testing again.

--
Debian GNU/Linux testing/unstable
Built from sources (emu & plugins)
Zelda MoM European
 
OP
kabalak

kabalak

New member
Another problem - lens of truth (or: how to find the gfx plugin of truth...)

After getting to the Goron Village and getting the lens of truth I now need to use the lens of truth - but with all the gfx plugins I do not get a good result. With Glide64 we do get no lens of truth at all --> it takes magic from the magicometer but there is no lens in action. With rice plugin we can see the Goron ghost in the lens but everything another is white / blue. gI64 makes just rubbish...
 
Same here (or not?)

Lens of truth didn't work for me the first time I tried, but since I upgraded nvidia drivers to 7667 it always worked for me with Glide64. I don't know if this is a direct relation. If you have the lastest drivers, try to restart the computer.
 
OP
kabalak

kabalak

New member
ySS said:
Lens of truth didn't work for me the first time I tried, but since I upgraded nvidia drivers to 7667 it always worked for me with Glide64. I don't know if this is a direct relation. If you have the lastest drivers, try to restart the computer.

I did compile the latest 7667 driver, installed the package and restarted my comp - now I can't still use it normally :(

If I toggle off the "Zelda Corona Fix" in Glide64 conf, then I can see the red circle of the lens of truth but cannot see the ladder in Goron City...

Lens of truth in action:

WithoutCoronaWithoutLadder.jpg


Glide64 config:

GlideConfig.jpg


Any help from anyone? Seems quite weird... It's Debian unstable, kernel 2.4.25 on AMD Athlon, self compiled newest nvidia driver; mupen + plugins also self compiled.

I tried to recompile the glide64 plugin now, but even with gcc-3.3 I get these errors with current libs from Debian unstable:
Code:
g++-3.3  -DUSE_GTK `sdl-config --cflags` `gtk-config --cflags` -Iwrapper/ -O3 -mcpu=athlon -ffast-math -funroll-loops -fomit-frame-pointer -msse -mmmx  -c -o wrapper/main.o wrapper/main.cpp
In file included from wrapper/main.cpp:17:
wrapper/main.h:19: error: `void (*glActiveTextureARB)(unsigned int)' redeclared
   as different kind of symbol
/usr/include/GL/gl.h:2056: error: previous declaration of `void
   glActiveTextureARB(unsigned int)'
wrapper/main.h:20: error: `void (*glMultiTexCoord2fARB)(unsigned int, float,
   float)' redeclared as different kind of symbol
/usr/include/GL/gl.h:2068: error: previous declaration of `void
   glMultiTexCoord2fARB(unsigned int, float, float)'
make: *** [wrapper/main.o] Fehler 1
 
Last edited:
Same here... again. Lens of Truth stopped working one more time. I can't try it just now, but... can you try it on several hours (in the game)? Perhaps, snow effect changes slightly at certain hours or something, and it has something to do with this. I have not really advanced too far in the game to use it again in a place without the snow effect.
 
OP
kabalak

kabalak

New member
ySS said:
Same here... again. Lens of Truth stopped working one more time. I can't try it just now, but... can you try it on several hours (in the game)? Perhaps, snow effect changes slightly at certain hours or something, and it has something to do with this. I have not really advanced too far in the game to use it again in a place without the snow effect.

Well, I have tried it in the 3 days with no difference, the lense does not work :-/ I'm currently in the SnowTemple and to find fairies without a working lense is not soo easy... Within Zelda OoT the lens worked perfectly with the Glide plugin, hhrmr...
 

juwb

New member
Lens of Truth worked flawlessly for me in Zelda: OoT and glN64 plugin. In Zelda: MM, I haven't gotten that far yet, so I can't test it. It'd be sad if they used a different technique there for the same thing...
 
OP
kabalak

kabalak

New member
Finally....

Well, I managed to get the game over with mupen64, that's great :) But unfortunately I needed to do 3x,4x severe plugin changing and extensive save state feature using.

Thanks to F5/F7, the # of crashes was not worrying me too much ;)

If someone wants to do it also: use normal Glide64 plugin with Autodetect microcode, Zelda corona fix on. In need of the lens of truth, save via F5, switch to pure Rice Daedalus plugin with just "Normal Blender" and Texture Scaling to 2xSaI on; this works to see the lens stuff (you may not be able to see the rest, but well you always need a bit of luck :))).

Afterworks you can use F5/F7 to restore the state in the good-looking Glide64 plugin.

The number of crashes within the game was aberrantly high - 5x the # crashes in Zelda OoT.
 

Top