mupen never starts running a rom - or maybe it does

[Flying Mouse]

I just installed Slackware 9.0 today ( this isn't the good part yet ) on my fixed 20gb drive (YAY!) . I got it all configured right i think ( i have the tdfx Voodoo 5 drivers on, and i have a good moniter setting ), but mupen64 never runs a rom. I'm trying out Super Mario 64, if it matters. Rice's Daedulus 5.2.0 ( or is it 5.1.0? ) with the FPS being shown, reports 0.200 VI/s. I dunno what i am doing wrong. Nothing apears on the screen. Same goes for TR64 OpenGL and glNintendo64 0.3.1 ( yeah, i need to update that one )
Also, when i hit the stop button, it crashes mupen ( a side effect of my problem? )
i also got my joypad installed, if THAT matters ( i went to sbin, su - then modprobe joydev and it works )
BTW, Mupen64 rocks ( when I used it on windows, like i'll be booting back to that tonight )

EDIT: I sorta fixed it. I changed the sound plugin ( jttl's SDL sound ) and it works! But in super mario 64, it runs about 20 VI/s.. which is too slow for me. Is there a way too speed it up? Am i missing something? Do i need to enable something? Do i need to install something else? Am I asking way too many questions at one time?

 

[Doomulation]

Might be a side effect of your processor. Mupen is *very* requiring.
Try out the fastest plugins and make sure you're using mupen's rsp.

 

[JttL]

EDIT: I sorta fixed it. I changed the sound plugin ( jttl's SDL sound ) and it works! But in super mario 64, it runs about 20 VI/s.. which is too slow for me. Is there a way too speed it up? Am i missing something? Do i need to enable something? Do i need to install something else? Am I asking way too many questions at one time?

Mupen uses sound plugin to slow down the emulator to the correct speed. Sound is good for that because we know the sample rate so we know how long it takes to play audio chunks. In mupen's original sound plugin (and in ALSA plugin, if I'm right) the syncronization is done by waiting until previous buffer is played and then continuing but if there is problem with /dev/dsp the buffer never gets played and plugin keeps waiting for it forever and emulation is stuck.

In SDL plugin the SDL itself takes care of low level stuff like selecting and opening audio device, and because of SDL's way to handle audio the syncronization is done very differently. It's based on time and calculations how long it should take to play the audio buffer. These calculations and time checks requires much more CPU power than other plugin's simple waits for playing thread to exit. In SDL plugin we pay of compatibility with CPU requirements.

The SDL plugin is still at beta stage and there is much things that can be optimazed so stand by for next release (which might hapen before end of this week).

 

[Hacktarux]

nicedude455: maybe it's a problem with your video card drivers.... i don't know how good linux voodoo drivers are with openGL. Do you have tried any other 3d intensive application on your computer ?

 

[Flying Mouse]

Unless you count screensavers ( if they run 60fps, it runs about 45ishfps ), no. I could try PCSX or ePSXe... i bet it is a problem with the video card drivers. but i have the lastest from www.falconfly.de/vsa100.htm ( or so i think.. RPM.. yuck! )
BTW Hacktarux, i want to say that Mupen64 rocks.

EDIT: I think i found the problem. I ran gdb mupen64 and..
Initializing OpenGL Device Context
(II) Initializing SDL video subsystem...
(II) Getting video info...
(II) Setting video mode 320x240...
Xlib: extension "XFree86-DRI" missing on display ":0.0".
Mesa project: www.mesa3d.org - Mesa GLX Indirect : 1.3 Mesa 4.0.4
As you see.. what i bolded is what i think is wrong? WTH is this "XFree86-DRI" thing? Sorry i'm braindead when it comes to linux and OGL terms

 

[Flying Mouse]

sry for double posting, but an edit doesn't just fit this.
I think i have got it fixed. By myself. Me, dri.sourceforge.net, windows, and my moniter mans. helped me fixed it. I ran glxinfo again and tada: Direct rendering is enabled. I'm guessing that is what Windows calls "hardware rendering." I ran glxgears and WOW - it ran ( instead of around 100FPS ) a whopping 1000 FPS! And i was moving around the window just to make it go slower.
Konsole never lies:

 Andrew Hruska@darkstar:~$ glxgears
6158 frames in 5.0 seconds = 1231.600 FPS
Broken pipe

Please don't ask me what the darkstar is for, slackware named it that :getlost:
and in mupen64, damn, Super mario 64 flys! ! :shifty: But now the sound is all crackly and skipping. But i'm sure another thread around here can help me fix that
/me looks suspicously at the threads at the Mupen64 forum.
Thank you Hacktarux for giving me a nudge in the right direction

 

[JttL]

and in mupen64, damn, Super mario 64 flys! ! :shifty: But now the sound is all crackly and skipping. But i'm sure another thread around here can help me fix that
/me looks suspicously at the threads at the Mupen64 forum.
Thank you Hacktarux for giving me a nudge in the right direction

If you're using SDL plugin, there is a bug in syncronization code which causes it to run too fast some times, I haven't been able to track it down yet. There is two possible reasons for sound to be crackly and skipping. Either buffer underruns or overflows. Underrun is caused by too slow processor and overflow is caused by a bug in syncronization.

You can find out which one it it is by uncommenting two printfs from source. One that says "Buffer underrun." and another "Buffer overflow. Sound dropped." or something similar. Then just look at console window for which message is repeated. If it's caused by underrun you can try to adjust primary and secondary buffer size. If it is caused by overflow you can only hope I'm able to track that bug down or use some other plugin.

If buffer underruns all the time you could try to set primary buffer to 131 072 and secondary buffer to 512 or 1024. Those values are defined in the beginning of main.c.