What's new

February 2008 release: Mupen64-amd64 v1.2

TwistedWhizz

New member
Nobody else has reported this bug. I am also using the proprietary NVidia drivers with a 6600 card on my desktop PC and I haven't noticed any shaking. Does this happen with both graphics plugins and multiple games?

Hi there. Thanks for your reply.

It seems to only happen with the ricevideo plugin. The other one - glN64 - doesn't shake about when full screen, but it has other glitches (such as Mario's red eye in Mario 64) so I tend to use the alternatives. On the older Mupen64, I used to get a flashing blue screen with ricevideo, and now it's this shaking. Like I say, I'm fine with it when windowed. It's just strange to me that no one else has this problem. It's got to be something I've not set properly....

I can't seem to take a screenshot of it on the desktop, but if you'd like it's easy enough for me to do a digital photo of it and post it up. Let me know, anyway.

Thanks again. :)

EDIT: Just thought I ought to add, I think it might be the rom. It only seems to be happening on Mario 64. A quick test of other favourites and all seems to be OK, though Mario is still shaking around for some reason. Sorry for any fuss.
 
Last edited:
OP
R

Richard42

Emulator Developer
I have a known good SM64 ROM, it gives the following info on the console:

CRC: 635a2bff 8b022326
name: SUPER MARIO 64
Manufacturer: Nintendo
Cartridge_ID: 4d53
Country : United States
size: 4096
PC= 80246000
md5 code:20B854B239203BAF6C961B850A4A51A2
eeprom type:0
Goodname:Super Mario 64 (U) [!]

If the CRC and MD5 do not match for your ROM, that could be the problem.
 

dionysianfunk

New member
Goldeneye/Perfect Dark

First off, great work with the AMD64 port and all the general improvements.

I am running into a problem with version 1.2 and Goldeneye. Whenever I actually begin a mission the music switches over to the mission music then mupen closes. Perfect Dark closes right after the credits page (and apparently does so in a more abrupt manner than Goldeneye as the screen size does not return to the pre-game resolution). Other games work great. I am using mupen64_nogui under AMD64 and running the latest nVidia proprietary driver (169.07) on my GeForce 6150. I have tried various different combinations of graphics plugins, windowed/fullscreen mode and recompiler mode. Through these tests I have narrowed the problem down to the dynamic recompiler mode (which, of course, is the mode I really want to run in). Additionally, I tried getting the latest svn trunk (revision 214) and compiling. The compiled program behaved in the exact same way. Has anyone else had this problem? Any help would be greatly appreciated.
 
OP
R

Richard42

Emulator Developer
I am running into a problem with version 1.2 and Goldeneye. Whenever I actually begin a mission the music switches over to the mission music then mupen closes. Perfect Dark closes right after the credits page (and apparently does so in a more abrupt manner than Goldeneye as the screen size does not return to the pre-game resolution).

Thanks for reporting the problem. I'll take a look at it this weekend.
 
OP
R

Richard42

Emulator Developer
Thanks for the quick reply.
Also, I just tested this on my other computer using the 32 bit version and everything works fine. So I guess this has something to do with the 64-bit version.

Thanks for the bug report - that's just the kind of information I need. I found and fixed the problem, and committed the change to SVN. Now both these games run, but unfortunately there's still a problem with the dynamic recompiler in Goldeneye. The display is pretty messed up; with any luck I might be able to fix it today. I've also noticed that almost none of the games run with Glide64 (at least in the 64-bit mode), so I plan to hunt and fix bugs in this plugin as well.
 
OP
R

Richard42

Emulator Developer
I just committed another bugfix for the 64-bit dynarec; Goldeneye seems to play correctly now.
 

dionysianfunk

New member
I just committed another bugfix for the 64-bit dynarec; Goldeneye seems to play correctly now.

Wow. Thanks to your diligent coding and incredibly quick debugging response, Goldeneye plays (and looks) better than ever before with the new branch. Thanks so much for all your hard work.

Also, if anyone is interested, I have created a patch of my own for the jttl_audio plugin. I work with digital video and, as such, am incredibly in tune to mismatched audio sampling rates (and/or brute force resampling - characteristically a kind of digital roughness to the sound). The current jttl plugin seems to (by design) resample everything to relatively standard but very limited frequencies. Unfortunately, it does so in such a way that creates the digital nastiness associated with low quality resampling. The enclosed patch simply makes the plugin set the audio card frequency to whatever the game sampling rate is. This works great for me as I have a high quality audio card that can handle most any sampling frequency. As this would probably not work for cards that don't have such flexibility it certainly isn't something that, as-is, should be committed to svn. Perhaps if someone with actual programming ability (ie not me) thinks this is worthwhile, they could add some sort of gui option in the plugin setup (or just in the conf file) that would enable this sort of straight across game frequency to sound card frequency option. If not, this is the patch for anyone else out there that has a flexible sound card and can't stand low quality resampling (it may not be good or pretty... I'm certainly not a programmer by trade):

Code:
--- trunk/mupen64-64bit/jttl_audio/main.c	2008-02-12 19:26:20.000000000 -0800
+++ trunk.audio/mupen64-64bit/jttl_audio/main.c	2008-02-12 22:15:44.000000000 -0800
@@ -560,9 +560,7 @@
         obtained = malloc(sizeof(SDL_AudioSpec));
         /* 22050Hz - FM Radio quality */
         //desired->freq=freq;
-        if(freq < 11025) realFreq = 11025;
-        else if(freq < 22050) realFreq = 22050;
-        else realFreq = 44100;
+        realFreq = freq;
         desired->freq = realFreq;
 #ifdef DEBUG
         printf("(DD) Requesting frequency: %iHz.\n", desired->freq);

I can't seem to get the attachment function to work...
 

thatmariolover

New member
Well, just an update. I've been trying to compile Mupen64 1.2 for OS X without much understanding of what I'm doing. I'm having trouble getting GTK+ installed properly for OS X at the moment, which is what's really slowing my progress. The guide is very poorly written with some big gaps in it. But most of the libraries are installing like a charm. I'm not sure what the next hurdle will be after getting GTK+ installed, but I'll keep trying.
 

augustob

New member
Great, great work in this project, Richard42, thanks for all your time, I'm sure everyone here appreciates it, I sure do. Between this version of Mupen and getting my X360 wireless controller receiver to work in linux I'm not sure I'll be getting much work done in the next few weeks..

I'm having some trouble with audio, though. I'm running on a 2.2GHz Core2Duo and CPU utilization never seems to go over 60%, but sound still stutters (music on the "press start" screen in Mario 64, for example). Is anyone else experiencing this?

I'm using the 1.2 GUI version compiled for with "make all BITS=32".

Thanks in advance for any help, and congratulations again for all the great work!
 

ebenblues

Mupen64Plus Dev.
So the _nogui build gave you an error message and quit, but the gui build just didn't load a plugin and crashed. That's a bug in the GUI build. The failure to load the blight_input plugin isn't a problem with the plugin - it's impossible to dynamically load it if the dependencies are not found. We'll have to make sure that this is fixed in the upcoming gui/nogui consolidation that Ebenblues is doing.
FYI, the bug where mupen64 crashes if no plugins are specified has been fixed in the gui/nogui merge branch.
 
OP
R

Richard42

Emulator Developer
I'm having some trouble with audio, though. I'm running on a 2.2GHz Core2Duo and CPU utilization never seems to go over 60%, but sound still stutters (music on the "press start" screen in Mario 64, for example). Is anyone else experiencing this?

It may be CPU-bound, because 50% CPU usage means that one core is 100% pegged. Are you sure that the Dynamic Recompiler is being used? I have noticed that glN64 and Glide64 seem to stutter when loading new textures, but RiceVideo does better.
 

okaygo

Mupen64Plus Dev.
Reading this thread, downloading the source, and having a fun time playing on linux makes me want to continue development on Mupen64.

I had a problem with pausing/unpausing the emulator on Ubuntu Desktop 7.10, so I wrote a modification. Instead of pausing the threads and resuming them, we force it into a while loop, which simulates the same effect.

File r4300.h
Code:
This Line: extern int stop, llbit;
To: extern int stop, llbit, rompause;

File r4300.c
Code:
Change:  int stop, llbit;
To:  extern int stop, llbit, rompause;

After these Lines:   delay_slot=0;
   stop = 0;

Add:
   rompause = 0;

File interupt.c
Code:
After these Lines:
void gen_interupt()
{
 
Add: while(rompause) { sleep(1); }

In main_gtk.c
Code:
replace these two functions with the following

// pause/continue emulation
static void
		callback_pauseContinueEmulation( GtkWidget *widget, gpointer data )
{
	
	if( !g_EmulationThread )
		return;
	statusbar_message( "status", tr("Emulation thread (PID: %d)"), g_EmulationThread );
	if( g_EmulationRunning )
	{
		statusbar_message( "status", tr("Pausing emulator.") );
		rompause = 1;
		g_EmulationRunning = 0;
		statusbar_message( "status", tr("Emulation paused.") );
	}
	else
	{
		statusbar_message( "status", tr("Unpausing emulator.") );
		rompause = 0;
		g_EmulationRunning = 1;
		statusbar_message( "status", tr("Emulation continued.") );
	}
}

// stop emulation
static void callback_stopEmulation( GtkWidget *widget, gpointer data )
{
	if( g_EmulationThread )
	{
		statusbar_message( "status", tr("Stopping emulation.") );
		rompause = 0;
		if( !g_EmulationRunning )
			pthread_kill( g_EmulationThread, SIGCONT );
		stop_it();
		while( g_EmulationThread )
			if( gtk_main_iteration() )
				break;
		statusbar_message( "status", tr("Emulation stopped.") );
	}
}

==== then
				case SDLK_ESCAPE:
					rompause=0;
					stop_it();
					break;

Compile :3
 
Last edited:

ebenblues

Mupen64Plus Dev.
Reading this thread, downloading the source, and having a fun time playing on linux makes me want to continue development on Mupen64.

I had a problem with pausing/unpausing the emulator on Ubuntu Desktop 7.10, so I wrote a modification. Instead of pausing the threads and resuming them, we force it into a while loop, which simulates the same effect.
You're correct. Pause/unpause was broken for me too. I'll try out your changes tonight. Thanks for the contribution!

Btw, if you checked out the code using svn and then made your modifications, running "svn diff" will output a patchfile which you can paste between code tags in this forum. This will give us all of the same information and you won't have to manually type "after this line, change this line to this..."
 

okaygo

Mupen64Plus Dev.
You're correct. Pause/unpause was broken for me too. I'll try out your changes tonight. Thanks for the contribution!

Btw, if you checked out the code using svn and then made your modifications, running "svn diff" will output a patchfile which you can paste between code tags in this forum. This will give us all of the same information and you won't have to manually type "after this line, change this line to this..."

I dont have SVN access, also is it me or does Mupen run a lot slower on Linux compared to Windows? I get full speed in the games I enjoy, however while writing the speed modifiers I couldn't push past 60VI/s.
 
OP
R

Richard42

Emulator Developer
I dont have SVN access, also is it me or does Mupen run a lot slower on Linux compared to Windows? I get full speed in the games I enjoy, however while writing the speed modifiers I couldn't push past 60VI/s.

Everybody has read access to SVN; the url and login info are given here. I don't think anyone has done any Win32 vs. Linux benchmarking with Mupen64 but I don't think there's any reason why there would be a significant speed difference.
 

ebenblues

Mupen64Plus Dev.
FYI, I just committed changes to fix emulation pause/continue. Thanks to okaygo for the code contribution! Instead of using the sleep function, I used a call to SDL_PumpEvents. Otherwise hot keys (escape, F1, etc) stopped working while the emulation was paused.

I also added a new hotkey, 'p', to pause/continue emulation.
 

okaygo

Mupen64Plus Dev.
FYI, I just committed changes to fix emulation pause/continue. Thanks to okaygo for the code contribution! Instead of using the sleep function, I used a call to SDL_PumpEvents. Otherwise hot keys (escape, F1, etc) stopped working while the emulation was paused.

I also added a new hotkey, 'p', to pause/continue emulation.

Neat. :)
 

DarkJezter

New member
I haven't tried the new release of the app yet, but I suspect that the while loop may need to include checking for the Lirc commands as well, for those of use who aren't using the keyboard to control the emulator ;)

I'll probably be feeling ambitious enough to give it a test spin in a couple days, and if I notice any issues, I'll submit a patch.

That is, if no one beats me to it :)



P.S. First post to the forums for a while, glad to see all the activity that mupen's enjoying. I'm really looking forward to looking at the new nogui/gui version.
 

ebenblues

Mupen64Plus Dev.
I haven't tried the new release of the app yet, but I suspect that the while loop may need to include checking for the Lirc commands as well, for those of use who aren't using the keyboard to control the emulator ;)

I'll probably be feeling ambitious enough to give it a test spin in a couple days, and if I notice any issues, I'll submit a patch.

That is, if no one beats me to it :)
Thanks for pointing that out. I haven't messed around with lirc support yet, but I do have a lirc setup, so I'll have to try that out soon.
 

Top