sudden hangs with black screen

[juwb]

Hi,

first of all, great work on this emulator. I had a lot of stability issues at first, but after fiddling a bit with the configuration settings most of them were solved.

I was finally able to play Zelda:OoT as far as Hyrule castle town, to the first room where you can get a lot of money by smashing all these pots. But when I left the room, the screen turned black and mupen64 hang.

This happened extremely often before when I had the 'no audio delay' option unchecked. Screen suddenly gets stuck or turns black while memory comsumption rises from 20-40% to over 90%... and the only way to get out of it is kill -9.

Is there some debug option I could turn on to see what the hell is happening? And, more important - how can I save/restore states in a fullscreen running game? If I had a hotkey for that, I wouldn't have to remember to save the game all the time ;-)

EDIT: Just found out that it can be done with the F-keys... F5 seems to be save and F7 restore... is this documented anywhere?

Great work with the emulator. :-) I'm so happy I can finally play this game in linux. :bouncy: :bunny: :icecream:

[Piko]

I also have been playing Zelda: OoT, and I also hang at parts!

Though I can only get as far as into the great Deku Tree, then anytime after that, crashing occures.

Though for me it hangs, whatever music that was playing, is still playing, with a frozen image.

Also to get into the menu, there is a long delay while it makes that background image, or at least that's what I think is doing it.

[juwb]

Yes, at first I had hangs like you describe in the scene where Navi flies from the tree to the boy for the first time (Image froze, music continued playing), and later when the Deku tree opened.

But it doesn't happen anymore. I think the "no audio delay" was responsible, but I changed a lot of configuration options, so it might be just as well something else. In any case, that option improved sound a lot, it was rather sluggish before.

Here's the plugins I'm using:
video: glN64 v0.4.1-r2 (800x600, 16 and 32 bit, everything else unchecked)
audio: JttL's (latest version from the forum, but I don't get no config dialogue...)
EDIT: Whoopsie, just found out the one on the Plugins-Forum is actually quite old ^_^ so version 1.2 it is...
input: blight's
rsp: hacktarux

As for the waiting time for the menu:
I think that's the game's fault. Every emulator I tried so far took a very long time to display that menu (one even took 5 minutes until it showed up... made equipment switching quite a pain). Mupen64 is quite okay there, takes about 5 seconds.

But as for speed in general, there's a lot of room for improvement. With UltraHLE, I played this game on a PII-233 with a 3dfx Banshee card. Of course, it was without sound and I only had about 10-15 fps, but still, it was playable. Mupen64 taking 90% CPU to display 20-30 fps on my XP2000+ / GF4Ti sounds like a bad joke in comparison. (But I guess the sound playback actually eats a hell of a lot of CPU, since the game runs way too fast when I switch to a broken sound plugin)

[juwb]

Oh yeah, and state save+restore using F5/F7 doesn't seem to work reliably... sometimes it works, sometimes F7 loads a different extremely deprecated state and when that happens, I can't seem to find the previously saved one...

So now I'm using F1 (which switches fullscreen I found out) and then save the state a few times to be sure using the GUI. :)

EDIT:
Found out what the problem was... I use the numpad to play, but the number keys also select which save slot is being used...

Oh well, I guess things work out in the end *g*

[ciruZ]

Well, I had that problem with Mupen 0.3 in the past, too. But Mupen 0.4 fixed that for me? No problems anymore with Zelda: OoT. Hasn't crashed for a long time now.

[juwb]

Well, it's the settings. Mainly the two checkboxes on the interpreter/dynamic recompiler page are dangerous. With the right configuration, it's pretty stable. It still hangs, but only in extreme rare cases.

For example, earlier in OoT after getting the ocarina from Zelda [sequence with gray / foggy background], the screen was stuck (everything gray). Loaded a save state from earlier and on the second try it went through normally...

From time to time, something like this happens, so I have to save often and go back one step and retry... it usually works the second time.

[juwb]

Another problem I'm having now with OoT... when using the bow to shoot, literally half the screen goes black (or grey, or other single-color polygon). It's really annoying because this way you have a hard time seeing your target. The effect is especially bad in the shooting game of Kakariko village, where you have to aim fast... I'm using glN64 plugin for video output.

I'd post a screen shot here but I don't know how to make one... the record avi function gives me the sound, but a completely black screen... ;-)

Oh yeah, the sling shot had a similar issue, but there the polygon had a kind of flickering effect, which allowed you to see.

[juwb]

Attached a screenshot made with gimp :) in this case with the Slingshot. Happens all the time using the bow...

[Hacktarux]

It can very possibly be a problem with gln64...

Btw, most of your problems with the core in zelda will probably be fixed in next release.

[ciruZ]

Well, it's the settings. Mainly the two checkboxes on the interpreter/dynamic recompiler page are dangerous. With the right configuration, it's pretty stable. It still hangs, but only in extreme rare cases.

For example, earlier in OoT after getting the ocarina from Zelda [sequence with gray / foggy background], the screen was stuck (everything gray). Loaded a save state from earlier and on the second try it went through normally...

From time to time, something like this happens, so I have to save often and go back one step and retry... it usually works the second time.
I had no problems at this part of the game? The GFX was ok for me, too.
Just use Glide64, it's the best for Zelda IMO. It even renders the ingame menus correctly which all other plugin don't do.

[juwb]

I don't have a 3dfx card so I can't use Glide. Yeah, I know there are glide wrappers, which are fine for old games which support nothing but Glide, but I don't think it's a good idea to use them when there's native OpenGL support available...

Anyhow, glN64 looks :term: awesome :term: in Linux with my GF4Ti card, and all ingame menus are displayed correctly as far as I can tell. Except for the left half of the equipment menu, but that's the same for every other emulator I've tried so far (and it's not important). Even exotic stuff (enhanced textures, fog, ...) works flawlessly.

In fact, these weird single-color polygons that turn up now and then hiding half the screen are the only flaw I could find as far as display goes.

EDIT: Oh yeah, another minor flaw I noticed... the sun looks weird, it actually displays three and a half suns... moon etc. looks okay though, don't know what's the problem with the damn sun. But that's just as unimportant as anything else ;-)

[Hacktarux]

Well... the glide64 linux port is using the glide64 code but it's not a glide plugin... it only supports opengl. So it's supported by your video card without a wrapper...

The reason i've bothered porting it like this and writing the wrapper on windows is that glide64 is supporting some games and some effects that no other opengl plugins support. It was the only easy way for me to get these games working on linux without writing a whole new plugin.

[juwb]

The glide64 plugin gives me a black screen followed by an error "uCode crc not found in INI, using currently selected uCode". Then it hangs indefinitely until I "killall -9 mupen64". TR64 makes X11 freeze until I go to text console and killall -9 again. The only other plugin actually producing video output for me is Rice's port, but it looks bad and has many many errors especially in the menus.

So in the end glN64 is the only plugin that is usable for me. Same with sound, JttL's SDL plugin is the only one that produces sound output other than noise... the Alsa plugin which I'd usually prefer doesn't give me any sound, although it shows my soundcard and everything in the configuration dialogue.

[juwb]

all ingame menus are displayed correctly as far as I can tell. Except for the left half of the equipment menu

Correction: This part is displayed correctly when I enable "Hardware Framebuffer Textures (experimental)" :canadian: I think I'll keep this activated until I notice some bad side effects...

[ciruZ]

hm, I always had problems in the ingame menu with glN64? For example where you chose link's equipment, there were only gfx bugs. With Glide64 it's just like it has to be. Or the background in the ingame menu was missing to with glN64.
The 4 suns (and somtimes strange trees) are normal with glN64 - Glide64 does that correct, too ;).

[juwb]

That equipment graphic works with glN64 when you enable the HW framebuffer option (well, for some reason it does not always show up, but who needs that anyway...). That's the only problem with the menu I could find. Trees and stuff are okay (with a different plugin, they look like pyramids, maybe that's what you meant).

GFX would be flawless if only this polygon problem thing was gone (it isn't as bad as described before... turns out it happens all the time only in certain areas), except for these two minor glitches (equipment menu gfx, sun).

As for Glide64, it doesn't work for me at all, just a weird error message :alien2:

EDIT: Question, are any of these linux gfx plugins actually maintained by anyone? If I understand this right, there was no change to glN64 since 2003...

[ciruZ]

Well, are you sure that the menu background is ok for you? I always had a picture of the last 2D room I visited (for example Link's home) as background image. With Glide64, I have the room I'm currently in as background (it renders the 3D room to a 2D Picture).
Anyway, what's the error message Glide64 gives you? Have you tried deleting it's config file?

[juwb]

Screenshot of glN64 attached... can't complain about quality at all. Except for the glitches mentioned earlier.

As for the Glide64 error message, I already posted it, see earlier message. Didn't work with a fresh install either, and I've also tried fiddling with the configuration settings to no avail...

[ciruZ]

Hm, strange that it works for you with glN64 but not for me. Which version do you use?
To your Glide64 Problem: I can't see where you posted a log of what Mupen64/Glide64 says?! Hm, seems that I'm too blind ;).
Have you compiled Mupen64/Glide64 yourself or did you use the precompiled ones?

[juwb]

The glide64 plugin gives me a black screen followed by an error "uCode crc not found in INI, using currently selected uCode". Then it hangs indefinitely until I "killall -9 mupen64".

As for glN64 version, it's supposed to be the newest one (the version number is shown in the screenshot above - 0.4.1-rc2 or something). I compiled mupen64 and all plugins myself (or rather, Gentoo compiled it for me). Don't even know where to look for precompiled binaries.

[ciruZ]

You can find the precompiled binaries in this forum as well. Maybe you should try them, this might reduce the problems ;).

[juwb]

You can find the precompiled binaries in this forum as well. Maybe you should try them, this might reduce the problems ;).

Okay, tested with binary plugins downloaded from this forum:

tr64: is newer version than I had installed, looks better than before, but not nearly as nice as glN64.
glN64: same version I had, looks the same
glide64: couldn't find a linux binary in the forum. Point me?

any other plugins available for linux?

[Hacktarux]

donwload the precompiled binary of mupen64 on mupen64 web site : http://mupen64.emulation64.com

Uncompress it in a user folder and run it from there (i know that it could be better, but i'm working on that for the next release). The archive contains most available plugins.

[juwb]

Glide64 worked with the binary version. Now it also works with the version Gentoo compiled for me. I copied the configuration from them binary version... don't know which setting actually caused the error message described earlier. Anyway, Glide64 works now, thanks.

First the good stuff: With Glide64, the sun's showing up the way it should :bouncy:, and there seem to be no weird polygons blocking the view when using the bow. So that's very good.

Now the bad stuff: Glide64 seems to have problems elsewhere. There are disappearing roads and stuff (see screenshot), the GUI map looks weird, and in general, it looks more pixelish than glN64. It's hard to catch in a screenshot, don't know if you can see the difference (look at sky in the first shot or the floor and walls in the second shot). Both Glide64 and glN64 use 2xSAI, I also tried Bilinear and Point filtering with Glide64.

Also, Glide64 freezes extremely often (image gets stuck while sound continues playing). glN64 had that at first too until I fiddled a bit with the settings... maybe something similar will work for Glide64 as well, I don't know.

I'll use glN64 now for everyday use, and switch to Glide64 when I have to use the bow a lot :) Thanks for helping me out so far.

[ciruZ]

Your screenshots look good. That with the way is normal, but it's only on Hyrule Field and I think it doesn't hurt that much ;).
The map looks strange? Can you please try to screenshot this or discribe it more in detail?

[juwb]

That with the way is normal, but it's only on Hyrule Field and I think it doesn't hurt that much ;).

Of course, we are talking about minor details here. It doesn't hurt when the sun looks a little weird, the equipment menu doesn't work or even when a road goes missing. :happy: The very fact that we're going all nitpicky over these minor details is proof that GFX is already extremely close to perfection.

Another flaw I found in Glide64: Lightning is bad in general. Shadows tend to flicker on and off. In the first shot above, the kid doesn't even have a shadow. And the second shot shows how the map is different in Glide64 (it doesn't have the bluish shape). Plus there is a weird grey triangular spot in it that won't go away.

I guess I'll have to go read an OpenGL book and see if I can do anything about the glN64 flaws. But I guess it's hard to find out where these weird sight blockers come from, huh? :paperbag:

[ciruZ]

The map looks normal for me? Maybe because I always play with Glide64 and I don't notice it anymore ;).
I don't think an OpenGL book will help you out here. It are issues with the GFX emulation, not with OpenGL usage ;).
// Edit:
I just tested the new glN64 and I'm amazed. The ingame menu even looks better than with Glide64. Glide64 took a snapshot of the screen in the real N64 resolution and took that as background. That's why it's that unsharp. And it even does that with the link in the menu. glN64 renders it 3D and that looks much better on a resolution of 1280x1024 ;).
// Edit: But sometimes the ingame link is simply not there. :(

[juwb]

// Edit: But sometimes the ingame link is simply not there. :(

Yeah, sometimes it also breaks completely (weird black&white background instead of rendered image). This feature is still flagged experimental after all.

It seems that the glN64 plugin is pretty much dead... it was a port from windows in the first place and the original author seems to have moved to Microsoft DirectX.

It's a shame because glN64 really works best for me in Linux. I hope that someone will pick it up someday to straighten out some of the glitches.

[Illissius]

Any idea how to get rid of the freezes? Usually some minutes into a game it just randomly locks up (image stops where it was) -- sound sometimes keeps playing, sometimes not, sometimes goes berserk. It makes actually getting anywhere in the games quite impossible. I have the 'no audio delay' option checked.
Also... does the ALSA2 sound plugin work for anyone? It segfaults as soon as any sound would be needed (ie, it shows only the very first bit of mario 64, before the 'bling').

[juwb]

Any idea how to get rid of the freezes? Usually some minutes into a game it just randomly locks up (image stops where it was) -- sound sometimes keeps playing, sometimes not, sometimes goes berserk.

I had that at first with glN64, but after some changes it went away. Unfortunately, I'm not sure which change was responsible. I thought it was the audio delay / compiled jump options, but if changing these doesn't help, then it's probably something else. I can send you my config files if you like, PM me...

Oh yeah, and I'm using the Gentoo version... Gentoo seems to apply several patches to the mupen64 stuff, don't know if any of these are responsible for (in)stabilities.


Also... does the ALSA2 sound plugin work for anyone? It segfaults as soon as any sound would be needed (ie, it shows only the very first bit of mario 64, before the 'bling').

No. The only sound plugin that works for me is the SDL plugin. Others will either crash, not play sound at all, or let the game run way too fast. There is another plugin with ALSA support included with the binary version (forgot the name though, it was an abbreviation with three letters). This plugin worked, but not very well (it was stuttering). The sound output produced by the SDL plugin is flawless, except for half a second of noise when restarting the emulation, which sounds like an uninitialized buffer somewhere in the emulator or in the plugin.

[juwb]

Oookay, doesn't really belong into this thread, but because I gave a lot of praise to glN64 already, I have to add another downside: The plugin seems to be old and unmaintained, so while it works nearly flawlessly in Zelda: OoT, there are a lot of errors to be seen in Zelda: MM. (For example, Zelda flashback can't be watched at all, you just get a black screen). It's really a pity that the original author switched to DirectX...

Now I'm using glN64 and switching to Glide64 and back whenever there are errors.