your games are hanging every seconds or so on linux while sound is still smooth ?

[Hacktarux]

if it happens edit main/gui_gtk/main_gtk.c and uncomment content of new_frame() and new_vi(). Then compile mupen64 and try it to see if it solved your problem. If it did, please tell me what's your computer, what plugins you were using and what linux kernel you're using.

[conguito]

if it happens edit main/gui_gtk/main_gtk.c and uncomment content of new_frame() and new_vi(). Then compile mupen64 and try it to see if it solved your problem. If it did, please tell me what's your computer, what plugins you were using and what linux kernel you're using.

Hi, I had the problem you described (with all GFX plugins, sound, etc...), when I uncommented new_vi() the problem was gone (apparently there's no need to uncomment new_frame()). If I change new_vi() to:

void new_vi() {
usleep(1);
}

it will also work, with the only difference that the sound will shutter on some instances (e.g Mario 64 when Mario's head is shown on the start screen). I guess there's a timing problem somewhere.

My distro is Mandrake 9.1 with the 2.4.21-0.13mdk kernel, and an Athlon 1800, KDE3.1, I'm mainly using rice's and the mupen audio.

Hope this helps.

[mafiosnik]

same problem here... emulator hangs every second but sound is pretty good... games are totally unplayable! after uncommenting new_frame() and new_vi() mupen is now VERY slow (3-5FPS). same problem with conguitos solution. i was really happy when i seen that u released a new version of mupen yesterday but i was very frustrated while testing some games. i hope u fix this problem in next release! maybe u release mupen64-0.3b for linux users in the next time? :) *hope*

ah... rices plugin does NOT work for me.. here is the error output.

Initializing OpenGL Device Context
(II) Initializing SDL video subsystem...
(II) Getting video info...
(II) Setting video mode 640x480...
NVIDIA Corporation - GeForce2 GTS/AGP/3DNOW! : 1.4.0 NVIDIA 43.63
demarrage r4300
interprétation
Signal number 4 caught:
errno = 0 (Success)
Xlib: unexpected async reply (sequence 0xc147)!


hope a fixed release will be out soon :)

My System:
Gentoo Linux 1.4
CPU: AthlonXP 1700+
GPU: GeForce2 GTS 32MB
RAM: 256DDR 333MHz
Kernel: gaming-sources-2.4.20-r3
XFree: xfree-4.3.0-r2
Plugins: glN64-0.4.1 & mupens audio


hope this information is enough.

[Hacktarux]

ouch
mafiosnik, i've never heard about such problem.... with your computer, many games should run almost full speed...
such error with rice's plugin make me thinking it can be an X11 problem (opengl states not cleanly cleared by an application or something) do u have tried to restart xwindow ? also check you have the RiceDaedalus ini file in your plugins folder.

[mafiosnik]

ouch
mafiosnik, i've never heard about such problem.... with your computer, many games should run almost full speed...
such error with rice's plugin make me thinking it can be an X11 problem (opengl states not cleanly cleared by an application or something) do u have tried to restart xwindow ? also check you have the RiceDaedalus ini file in your plugins folder.


yes the ini is there but it still does not work.. dont know why .. i tryed even to reboot and some other things but nothing helped. with mupen0.2 i have 90-100%.

[Hacktarux]

do u have the possibility to connect to irc (#mupen64 on efnet) ?
I'd like to understand what's the problem...

[Soggie]

If it did, please tell me what's your computer, what plugins you were using and what linux kernel you're using.

This issue occurs on my system, and is solved by uncommenting new_frame() and new_vi().

Computer: 2.4GHz Pentium4, 1GB RAM, Matrox G400 (Mesa-DRI 4.0.4, OpenGL1.2)
Distro: RedHat 9 (XFree86-4.3.0, glibc-2.3.2, gcc-3.2.2)
Kernel: kernel-2.4.20-19.9 (RH9 updates)

Plugins used: tr64 / ricedaedalus + mupen64_audio + blight_input

[Gaenya]

Im getting the same error that mafiosnik with rice plugin, other than that mupen is running just fine.

[Hacktarux]

hmm just got an idea... please check if you're not missing any library to get rice's plugin working: "ldd -r the_plugin_you_want_to_check.so"

You need glibc 2.3 to use the precompiled binaries... otherwise you'll have to compile yourself...

[Gaenya]

ive compiled the plugin miself, so thats not the problem and ive checked the library and there isnt any missing library

[Sri Narayan]

i have a problem:

to the compile the plugin i add the following include files in CNvTntCombiner.cpp:

#include "glext.h"
#include "glh_genext.h"

because of GL_SUBTRACT_ARB first use of this function

then I had linking problems:

/usr/bin/ld: Warning: type of symbol `glMultiTexCoord1dARB' changed from 2 to 1 in OGLGraphicsContext.o
/usr/bin/ld: Warning: type of symbol `glMultiTexCoord1dvARB' changed from 2 to 1 in OGLGraphicsContext.o
/usr/bin/ld: Warning: type of symbol `glMultiTexCoord1fARB' changed from 2 to 1 in OGLGraphicsContext.o
/usr/bin/ld: Warning: type of symbol `glMultiTexCoord1fvARB' changed from 2 to 1 in OGLGraphicsContext.o
/usr/bin/ld: Warning: type of symbol `glMultiTexCoord1iARB' changed from 2 to 1 in OGLGraphicsContext.o

don't know why.

mupen didn't recognise this plugin because of my specific

stuff

I have to do it manually

but no rom is starting



Another thing is the sound
I can hear the sound two time.
One second before and then in the right timing


But through all what I've written

nice work (these little problems will solve easyily by you hacktarux)


see you



gcc version 3.2
Debian Linuxtag edition
nvidia 4496
kernel 2.4.21

[Hacktarux]

I have those warning too, and from what i've read on the internet it should be a gcc bug but the plugin should still perfectly work ;)

Also, it would be cool if someone who's having rice's plugin crash symptom could compile everything with debugging symbols (-g option) and run it through gdb to see at which line it's crashing.

You can also try to enable/disable SSE optimizations and see what happen.

[Sri Narayan]

i do have the same prom with xlib

is there a solution

see ya

[Hacktarux]

i haven't used the -fPIC option in the makefile.... on gentoo it isn't a problem at all but i'm wondering if it's a problem on other ditros.... unfortunately you can't simply compile the plugin with this option, i have to change source code too

[linemu]

On banjo kazooie it freezes up every second. ssb, mariokart, mario64, diddy kong racing, OOT, MM, and kirby64 are exempt from this problem. However in oot, and kirby64, after playing them for a couple minutes they freeze up. COMPLETELY (although the sound goes on). WIERD. Needless to say I continue to use .2 (with gl64 4.1 ported by blight).

[Hacktarux]

can you send me a save state of oot just before it freezes ?

[Hacktarux]

People who can't run rice's plugin:
Can you try the attached plugin and tell me if it changes something ?

[linemu]

can you send me a save state of oot just before it freezes ?

I can't really predict the freeze ups... they're in different spots every time.
Although I could probably time how long it takes for it to freeze. And as Its an issue with the emu itself.. I don't think it would do the same thing for you. If it doesn't do it with your computer right now it won't do it if I give you a savestate.

[Hacktarux]

if it's a core problem it'll happen on all computers... but i never play games really deep, can you tell me at least in which area is it crashing ? intro, begining of game, first level....

[linemu]

if it's a core problem it'll happen on all computers... but i never play games really deep, can you tell me at least in which area is it crashing ? intro, begining of game, first level....

well...
Its happened while battling ganondorf, and while in the sacred forest meadow as an adult. Those are the only two places I've tested it at.

[Hacktarux]

are u using savestates or native saves ? I'd really like to have the save file you're using a few minutes before it happens.... otherwise i don't see how i can try to fix it :/

[linemu]

are u using savestates or native saves ? I'd really like to have the save file you're using a few minutes before it happens.... otherwise i don't see how i can try to fix it :/

Just tested something. You don't need a special savestate. Just start a new game and play around for a while. After about 5 minutes or more it should freeze up. Actually it was strange this time... first the sound plugin died (sound shut off) and the game started going at HHIIIGHH speed. Then the sound re-initialized and the game froze. WEIRD. It froze up in the little area where the kokiri sword is.

[Hacktarux]

Concerning the main topic of this thread... i need some people to test this audio plugin (by leaving the new_frame and new_vi functions commented).....

And if you didn't see, there's also a gfx plugin to test posted in the middle of the zelda bug discussion in this thread.

[linemu]

Concerning the main topic of this thread... i need some people to test this audio plugin (by leaving the new_frame and new_vi functions commented).....

And if you didn't see, there's also a gfx plugin to test posted in the middle of the zelda bug discussion in this thread.

Seems more like a NO SOUND plugin. When I enable this, sound fails to initialize many games are incompatible, and things run at outragous speeds.

[mafiosnik]

YES! u did it hack! games run at fullspeed without any problems and this ist great. :)

sound is pretty bad and some games which worked before do not work now. hope i could help u a bit.

ricedeadalus still does not work :(

Initializing OpenGL Device Context
(II) Initializing SDL video subsystem...
(II) Getting video info...
(II) Setting video mode 800x600...
NVIDIA Corporation - GeForce2 GTS/AGP/3DNOW! : 1.4.0 NVIDIA 44.96
demarrage r4300
interprétation
Signal number 4 caught:
errno = 0 (Success)
Xlib: unexpected async reply (sequence 0x7b50)!
gentoo mupen64-0.3 #

[Gaenya]

YES! u did it hack! games run at fullspeed without any problems and this ist great. :)

sound is pretty bad and some games which worked before do not work now. hope i could help u a bit.

ricedeadalus still does not work :(

Initializing OpenGL Device Context
(II) Initializing SDL video subsystem...
(II) Getting video info...
(II) Setting video mode 800x600...
NVIDIA Corporation - GeForce2 GTS/AGP/3DNOW! : 1.4.0 NVIDIA 44.96
demarrage r4300
interprétation
Signal number 4 caught:
errno = 0 (Success)
Xlib: unexpected async reply (sequence 0x7b50)!
gentoo mupen64-0.3 #
Same here ....
:cry:

[Soggie]

test this audio plugin (by leaving the new_frame and new_vi functions commented).....


Tested with mupen-0.3 binary (as released), with tr64 and/or mupen64_gfx, with the binary mupen64_audio.so, I get:

rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
file found
rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
byteswaping rom...
rom byteswaped
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:1444
CRC: 635a2bff 8b022326
name: SUPER MARIO 64
Manufacturer: Nintendo
Cartridge_ID: 4d53
Country : United States
size: 4096
PC= 80246000
md5 code:20B854B239203BAF6C961B850A4A51A2
init timer!
memory initialized
[blight's SDL input plugin]: version 0.0.8 initialized.
demarrage r4300
interpréation
error getting sample count
error getting sample count
error getting sample count
error getting sample count
[...]
(ad infinitum..)

The output window is open, but stays black.

Starting mupen with './mupen64 &> /dev/null' fixes this (all those (f)printfs take too much time on an anti-aliased gnome-terminal, I guess)

The sound works, and gameplay is smooth (no more halting every second). The Mario64 intro screen (with the light reflections on Mario's head) now runs at 22fps, as opposed to 12fps with new_vi and new_frame. (The other parts of Mario64 run at about 30fps, both with new_vi+new_frame+old-mupen64_audio and binary-mupen64-0.3+test-mupen64_audio)

The sound in the other parts of Mario64 (ie, not the intro) sounds more 'crackled' with the new mupen64_audio plugin you posted than with new_vi + new_frame + old mupen64_audio plugin.

(version numbers for mupen64_audio test releases might clear up confusion)

[Hacktarux]

hope i could help u a bit.


You can and i've already said what i need... someone who can test the plugin without SSE option and someone who can compile mupen64 and the plugins with -g option (don't forget to comment strip command line in the makefile when you compile) and try it using gdb... then gdb will tell what's the line in the source code that's making things crashing, finally type "where" and give me the gdb output.

[Hacktarux]

Here is another audio plugin to test... let's call it mupen64 0.1b to understand what we're talking about but don't consider it as a stable release.... it's only there for testing purpose ;)

I've slightly improved sync and i've added an option to configure the buffer size, try it and tell me the best value on your system.

[Gaenya]

You can and i've already said what i need... someone who can test the plugin without SSE option and someone who can compile mupen64 and the plugins with -g option (don't forget to comment strip command line in the makefile when you compile) and try it using gdb... then gdb will tell what's the line in the source code that's making things crashing, finally type "where" and give me the gdb output.
Hacktarux, if you post a step by step of how to do the debug maybe i could help, i havent used gdb so i dont know how to use it, but i want to help.

[Hacktarux]

Gaenya: you have to recompile every plugins and the core with debug options : edit the Makefile, add -g option in gcc options line and remove the that's calling strip command.

After everything is compiled and ready, go in mupen64 folder and type:
"gdb mupen64"

run the application by typing:
"run"

when it crashes gdb will tell at which line it's crashing
after that type
"where"
it'll give some additionnal informations that will help me hopefully.
Finally give me everything that has been outputed by gdb :)

[Gaenya]

Gaenya: you have to recompile every plugins and the core with debug options : edit the Makefile, add -g option in gcc options line and remove the that's calling strip command.

After everything is compiled and ready, go in mupen64 folder and type:
"gdb mupen64"

run the application by typing:
"run"

when it crashes gdb will tell at which line it's crashing
after that type
"where"
it'll give some additionnal informations that will help me hopefully.
Finally give me everything that has been outputed by gdb :)

Im getting this when compiling the rice plugin


g++ -DUSE_GTK `sdl-config --cflags` `gtk-config --cflags` -O3 -mcpu=athlon -ffast-math -funroll-loops -fomit-frame-pointer -msse -mmmx -c -o DaedalusGraphics.o DaedalusGraphics.cpp
unique.h: In static member function `static T* CUnique<T>::Get() [with T =
CProfiler]':
DaedalusGraphics.cpp:308: instantiated from here
unique.h:80: error: `assert' undeclared (first use this function)
unique.h:80: error: (Each undeclared identifier is reported only once for each
function it appears in.)
unique.h: In static member function `static void CUnique<T>::Destroy() [with T
= CProfiler]':
DaedalusGraphics.cpp:769: instantiated from here
unique.h:72: error: `assert' undeclared (first use this function)
make: *** [DaedalusGraphics.o] Error 1

Keep in mind that gentoo upgraded gcc to 3.3.1, so maybe thats the problem.

So far this is the info i could give you


rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
file found
rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
byteswaping rom...
rom byteswaped
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:1444
CRC: 635a2bff 8b022326
name: SUPER MARIO 64
Manufacturer: Nintendo
Cartridge_ID: 4d53
Country : United States
size: 4096
PC= 80246000

md5 code:20B854B239203BAF6C961B850A4A51A2
init timer!
[New Thread 32769 (LWP 4449)]
[New Thread 16386 (LWP 4450)]
memory initialized
Initializing OpenGL Device Context
(II) Initializing SDL video subsystem...
(II) Getting video info...
(II) Setting video mode 640x480...
NVIDIA Corporation - GeForce4 MX 420/AGP/3DNOW! : 1.4.0 NVIDIA 44.96
[New Thread 32771 (LWP 4451)]
demarrage r4300
interprétation
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 16386 (LWP 4450)]
0x40d998e9 in SetVIScales() ()
from /mnt/datos/downloads/emu64/plugins/ricedaedalus.so
(gdb) where
#0 0x40d998e9 in SetVIScales() ()
from /mnt/datos/downloads/emu64/plugins/ricedaedalus.so
#1 0xc3a00000 in ?? ()

[blight]

Program received signal SIGILL, Illegal instruction.
maybe you have enabled SSE altough your processor doesn't support it

[mafiosnik]

compiled all plugins without problems including ricedeadalus! (gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice))

after emulator crashes and typing "where":

Initializing OpenGL Device Context
(II) Initializing SDL video subsystem...
(II) Getting video info...
(II) Setting video mode 640x480...
NVIDIA Corporation - GeForce2 GTS/AGP/3DNOW! : 1.4.0 NVIDIA 44.96
[New Thread 32771 (LWP 22952)]
demarrage r4300
interprétation

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 16386 (LWP 22951)]
0x40d828a7 in SetVIScales () at DaedalusGraphics.cpp:472
472 if( abs((int)(windowSetting.fViWidth - width) ) < 8 )
Current language: auto; currently c++
(gdb) where
#0 0x40d828a7 in SetVIScales () at DaedalusGraphics.cpp:472
(gdb)


where are the outputfiles of gdb? could not find anything.

[blight]

the output is right in front of your eyes :P gdb doesn't creaty any files unless you tell it to ;)
maybe you can disassemble the function?
(gdb) disassemble 0x40d828a7

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 16386 (LWP 22951)]
0x40d828a7 in SetVIScales () at DaedalusGraphics.cpp:472
the red number is the address to disassemble - it might change every time you run it

[mafiosnik]

oh.. good to know blight ;) ok.. here comes the disassembe output.

have fun :P

EDIT:
hmm.. seems to be too long ... i can send u an e-mail if u want.

[blight]

or just paste the part at address 0x40d828a7 or whatever (plus some lines above and below of course ;))

hmm... what if it happens in another thread and we're looking at the wrong place? i have seen GDB do weird things ;)

[mafiosnik]

ah.. the new audio plugin is cool! best configuration for me is to set the sample rate to 12-13! much better then the previous one! :) at 16 the sound is great but mupen still hangs.