[$threadinfo[title]]

[Richard42]

A month after 1.0, we've accumulated enough fixes to make another release, so here is v1.1. I've attached zips for both 32-bit and 64-bit binaries and individual source packages for RiceVideoLinux and Mupen64-amd64.

Some of the more notable fixes are:

Mupen64-amd64:
- GTK GUI: new icons, reworked config dialog, fixed bugs in ROM directory list
- Blight input config dialog: many bugfixes
- Bugfix: segfaults from failed fwrite() calls, added more error logging
- Bugfix: segfault from playing same game twice in a row from GUI
- Bugfix: exit properly instead of segfault after stopping game

RiceVideoLinux:
- Hi-res textures now work!
- Added capability to load 24-bit PNG files into 32-bit texture buffer
- Added more error logging to hi-res texture code
- Bugfix: SSE vertex lighting inline ASM code was incorrect
- Bugfix: Eliminate gaps between textures in Puyo Puyo 4 and other games
- Bugfix: opengl error in ApplyTextureFilter
- Bugfix: fix texturing problem with some Intel graphics adapters

Try it out and report problems here in this thread.

[sultanoswing]

Brilliant! Just as I'm starting to play around with N64 and PSX emulation again (this time on linux instead of windows), these lovely releases start appearing!

Thanks again & keep up the good work!

(feedback +/- bug reports to follow)

EDIT: Yay! The exit -> crash bug is fixed & I haven't had a full screen lockup so far! One small issues, the Blight input plugin didn't work for me out of the box, and only worked when I copied blight and its .ini from my 0.5 install.

[mudlord]

Nice job! When my new dev system is up and running (should be a couple of days), I'll see about adding your fixes to the Windows Rice Video OpenGL renderer so that Windows folks can enjoy your OpenGL fixes. :)

[Richard42]

Yay! The exit -> crash bug is fixed & I haven't had a full screen lockup so far! One small issues, the Blight input plugin didn't work for me out of the box, and only worked when I copied blight and its .ini from my 0.5 install.

What kind of problems did you have with the Blight input plugin? Probably the default setup doesn't match your own, so you would have needed to either configure your input through the config dialog or copy your previous .ini file. If you had problems configuring the plugin to your devices with the config dialog, then please give details about the specific problems that you had, because this should be working much better now than before.

[TwistedWhizz]

Excellent! Thanks to all for your continued hard work on this. I'll make sure I pass this among my friends.

OK, so far the only problem I've encountered is with RiceVideo. When selecting full screen mode it shakes and flickers and is generally unplayable. However it seems to be OK when leaving it windowed. I'm using the 32bit version with a simple GeForce FX5600XT, and I'm selecting the same settings as I would if I used the older Mupen64. I have an AMD Sempron 2200+ processor. I've listed my specs before but thought it worth stating them again to assist. There doesn't seem to be any error readout when using the terminal to start Mupen64.

Hope this is helpful. If I've done something wrong please let me know. Many thanks.

:mupen64:

EDIT: Sorry, should have mentioned this is when playing Super Mario 64.

[sultanoswing]

What kind of problems did you have with the Blight input plugin? Probably the default setup doesn't match your own, so you would have needed to either configure your input through the config dialog or copy your previous .ini file. If you had problems configuring the plugin to your devices with the config dialog, then please give details about the specific problems that you had, because this should be working much better now than before.

Oh, sorry, should have been more specific.

Despite the presence of blight_input.so in the plugins folder and the blight_input.ini as they came directly extracted from the archive, the only input plug in selectable was the Mupen64 Basic one. Was fixed, somehow, by copying the blight_input.so and my ini from my working 0.5 folder. This only required a couple of minor button reassignments to get everything working fine.

The actual plugin is running just great (once selected!).

[Surkow]

@sultanoswing - this means you are not using the latest version of the blight input plugin. So the problem is still there.

[sultanoswing]

@sultanoswing - this means you are not using the latest version of the blight input plugin. So the problem is still there.

Indeed. But I have just retried extracting the blight_input.conf and blight_input.so from the 1.1 archive...and then blight is no longer selectable as an input plugin - but IS when I use the two files from the 0.5 release. It may be the older version of blight, but at least it shows up as a selectable input plugin!

[nmn]

Well, i just tried to run blight from this precompiled package. It worked for me, after installing SDL_ttf for 32bit (But i have to mention that it only wasn't installed already because i'm on a 64bit machine.)

If a plugin fails to load, almost always there will be output on the terminal. Have you tried using the terminal to launch Mupen64? You should see some sort of error other than the assertion at the beggining (I should look into that though)

Anyways, I got a Linux distro running and i'll be doing more work on the emulator again.

[sultanoswing]

*SOLVED* - installing SDL_ttf got the latest packaged version of blight's plugin working (either that or deleting a copy of blight_input.config from my /home directory).

This worked on Ubuntu Gusty 32-bit, FWIW. Thanks!

[nmn]

Glad you fixed that. Though, SDL_ttf should be installed by default - its the best font library in SDL for this kind of stuff, But i know alot of distros choose to keep it uninstalled initally. Perhaps we should include it our packages and have an LD_PRELOAD script to use it? Thats most convenient for those who don't have it. Theres already a reason to have a script - to force the CWD. Speaking of the CWD, i almost forgot i have to go change the icon code to not depend on that.

[Richard42]

*SOLVED* - installing SDL_ttf got the latest packaged version of blight's plugin working (either that or deleting a copy of blight_input.config from my /home directory).

This worked on Ubuntu Gusty 32-bit, FWIW. Thanks!

That's great to hear. We've had about 100 downloads so far for the binary packages and not many bug reports; I take that to mean that people are having success with this release. This is definitely good news.

Just this morning I got my MiniPC finally set up properly so that I can play mupen with full screen display on my TV and it looks perfect. :bouncy:

[TwistedWhizz]

Excellent! Thanks to all for your continued hard work on this. I'll make sure I pass this among my friends.

OK, so far the only problem I've encountered is with RiceVideo. When selecting full screen mode it shakes and flickers and is generally unplayable. However it seems to be OK when leaving it windowed. I'm using the 32bit version with a simple GeForce FX5600XT, and I'm selecting the same settings as I would if I used the older Mupen64. I have an AMD Sempron 2200+ processor. I've listed my specs before but thought it worth stating them again to assist. There doesn't seem to be any error readout when using the terminal to start Mupen64.

Hope this is helpful. If I've done something wrong please let me know. Many thanks.

:mupen64:

EDIT: Sorry, should have mentioned this is when playing Super Mario 64.

Oh right. So it's just me then!

I suppose I'll have to upgrade the old PC now if Mupen's development is to be ongoing.

[Richard42]

Oh right. So it's just me then!

I suppose I'll have to upgrade the old PC now if Mupen's development is to be ongoing.

I have a Geforce 6600 on my desktop PC and it looks perfect. The key here is the support for the Fragment Program in OpenGL. I may take some time to fix the problems in the OpenGL v1.4 shader just because quite a few people have older hardware that can't do the fragment programs, but I doubt I'll take a look at the 1.2/1.3 shaders.

I have added your bug to the TODO list and I will take a look at the fullscreen code, at least to fix the button/key command. But if I can't reproduce your video issues then I probably won't be able to solve them.

[nmn]

BTW, i just added the patch for the icon loading in SVN. Now you can open mupen64 any which way - just as long as icons is in the place its expected to be (the same folder as mupen or a folder specificied at build)

[sultanoswing]

BTW, i just added the patch for the icon loading in SVN. Now you can open mupen64 any which way - just as long as icons is in the place its expected to be (the same folder as mupen or a folder specificied at build)

Cool. This way I'll be able to load it directly using a Gnome panel application launcher* (command: "/home/username/Mupen64/mupen64") and still get the icons loaded :)

* (EDIT: instead of using the panel launcher to run a shell script, which cd's then executes)

[nmn]

Well, Until I make the rest of the rombrowser mod (Moving it to the non-depricated GtkTreeView over the depricated GtkCList) the icons will load for the toolbar but the rest of the icon loading functions have not been modified. But oh well, this way you can use the toolbar without using the tooltips to find out what the buttons are. I'll be working on moving the rombrowser over and when thats done i'll commit the code to SVN for that and the rest of the icon patch.

Also, Richard, Is the problem with WritePNG known? I just checked dump textures in Rice Video to see if it works. I ended up building Rice with the debugging symbols on and i got that it had an segment inside of Write PNG (liblinux/pngrw.c:531). I will go trace that down, but I might not find exactly what causes it to occur.

[Richard42]

Also, Richard, Is the problem with WritePNG known? I just checked dump textures in Rice Video to see if it works. I ended up building Rice with the debugging symbols on and i got that it had an segment inside of Write PNG (liblinux/pngrw.c:531). I will go trace that down, but I might not find exactly what causes it to occur.

I haven't tested the texture saving, so I was unaware of the WritePNG problem. I'll put it on the TODO list.

[nmn]

Okay, I partially solved the problem. Now i just need to correct the way it saves - currently its saving to [cwd]/[type]/[filename].png instead of [folder containing ricevideo.so]/texture_dump/[game string]/[type]/[filename].png. But truely other than that it works quite well, except for the fact that its pretty slow in realtime (but thats to be expected).

edit: The directory problem with texture ripping has been fixed. As of the latest SVN, Rice Video should be able to properly rip textures.

[alex4444]

*SOLVED* - installing SDL_ttf got the latest packaged version of blight's plugin working (either that or deleting a copy of blight_input.config from my /home directory).

This worked on Ubuntu Gusty 32-bit, FWIW. Thanks!

Hi, I had the same problem, I installed SDL_ttf and the blight's SDL input plugin 0.0.10 appears in the config dialog.

I have another problem now. When I try to run Zelda O of T, it shows "NO CONTROLLER". If I choose back the Mupen64 basic input plugin, I can use only some of the keys I configured with blight's config interface: movement keys, show/hide map key, start key and the action key. I had exactly the same problem with Mupen64-0.5, before trying this one.

I want to talk with the girl on the roof of the shop and I can't. :(

Gutsy, 64 bit..

Any idea what could be wrong?

Thanks!

[sultanoswing]

Have you removed all old plug in .conf files, including checking for ones in your /home/username directory? Just a thought.

[Richard42]

I have another problem now. When I try to run Zelda O of T, it shows "NO CONTROLLER". If I choose back the Mupen64 basic input plugin, I can use only some of the keys I configured with blight's config interface: movement keys, show/hide map key, start key and the action key. I had exactly the same problem with Mupen64-0.5, before trying this one.

I also saw this problem on my desktop PC. I'll fix it for the next release, but you should be able to work around this by editing the blight_input.conf file by hand. Assuming you're using the first joystick/controller, look at the very first section of the file underneath a line that says [controller 0]. Make sure that plugged=1 and device=0, and set all of the mappings for the buttons and x/y axes according to the controller you're using.

[TwistedWhizz]

Just wanted to say thanks so, so much for this release. For whatever reason, my initial problem with the full screen display has gone, and I'm now able to use this version exclusively.

So thank you, thank you! I'll pass this around my fellow Linux users, and I look forward to the next release.

Tremendous work.

:linux:

[cool spot]

Hello folks, i want to tanks you for this release too.

I've succesfully compile it under kubuntu 32bits, it works quite well for me except the dump texture feature.

Your talking about a svn repository in this trhead where this issue is resolved, but i don't know where is this damn repository, could you give me th adress, i would like to play with textures :bouncy:

[Richard42]

Your talking about a svn repository in this trhead where this issue is resolved, but i don't know where is this damn repository, could you give me th adress, i would like to play with textures :bouncy:

The URL for the repository is:

svn://fascination.homelinux.net:7684/mupen64-amd64/trunk/

The svn login is 'mupen64', and the password is 'Dyson5632-kart'. This account has read-only access to the project. For any developers interested in joining us on this project, drop me a PM and I can set you up with an account with read/write access. We've made a lot of progress in the last few months, and the next release should include an improved ROM browser by NMN and a new optimized 64-bit dynamic recompiler that I have built.

[sultanoswing]

Just a word of support - it's really great to see that a collection of enthusiasts are still keen & contributing to N64 emulation, particularly with multi-platform support, years after the console has been superceded. All the best for 2008 & beyond!

[cool spot]

Thank you for your help Richard42, the new gui is really nice :)

I had a little bug when trying to load a hi res texture for banjo-kazooie hizoka10s_Banjo-Kazooie_Retextures), here's the console output, don't know if this is useful.

(mupen64:11086): Gtk-CRITICAL **: gtk_box_pack_start: assertion `child->parent =
= NULL' failed
rom size: 16777216 bytes (or 16 Mb or 128 Megabits)
rom size: 16777216 bytes (or 16 Mb or 128 Megabits)
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:1448
CRC: 733fccb1 444892f9
name: Banjo-Kazooie
Manufacturer: Nintendo
Cartridge_ID: 4b42
European cartridge
size: 4096
PC= 80100400
md5 code:06A43BACF5C0687F596DF9B018CA6D7F
eeprom type:0
init timer!
memory initialized
[RiceVideo] SSE processing enabled.
[blight's SDL input plugin]: version 0.0.10 initialized.
[RiceVideo] SSE processing enabled.
[RiceVideo] Found ROM 'Banjo-Kazooie', CRC b1cc3f73f9924844-50
InitExternalTextures
Texture loading option is enabledFinding all hires texturesSignal number 11 caug
ht:
errno = 0 (Succès)

[Richard42]

I had a little bug when trying to load a hi res texture for banjo-kazooie hizoka10s_Banjo-Kazooie_Retextures), here's the console output, don't know if this is useful.

I found several bugs in the BMP loading code and fixed them. It should be able to load now.

[mudlord]

The URL for the repository is:

svn://fascination.homelinux.net:7684/mupen64-amd64/trunk/

Speaking of which, after some initial troubles, got your latest RV Linux code and started to add in your OGL/hi res fixes to my code trunk :)

[nmn]

Oh, Since it got mentioned above, Did you get my Linux texture rip path fixes and Richard42s BMP loading code fixes?

I got temporarily side tracked with the GUI, but i'm again working on it. Currently the new GtkTreeView based list is showing up but i need to add the icon at the side as a new column and i have some features i wish to add if i have time (But i will commit before trying so you can release after the inital changes are done)

edit: I should also mention that I tried to get z64 to work. I got it to compile by hacking the hell out of the makefile, it was actually quite trivial, but it doesn't seem to work right in 64-bit. I ought to try compiling a 32-bit build and seeing if the issue is anywhere related to that somehow.

[Richard42]

Speaking of which, after some initial troubles, got your latest RV Linux code and started to add in your OGL/hi res fixes to my code trunk :)

That's great to hear. A lot of open source projects (such as linux kernel and everything on freedesktop.org - like 100 projects) have moved to git instead of CVS/SVN. I watched Torvald's google talk on it and have only a little experience with it, but I think that git is designed to streamline exactly this operation - pulling patches from one repository to another. It may ultimately be the way to go for this type of project, though I do still like SVN.

@nmn: I'll wait to make the release until you're happy with the new ROM browser and it's all done.

[DarkJezter]

Good evening all,

Attached is a patch I'm working on to the current version of the svn repository, to include LIRC support in the command line tool. It's pretty basic, just allowing a guy to quit, save/restore states, and toggle fullscreen right now.

It's a bit rough, and if any amendments are needed for this contribution to be included in the tree, let me know. :D


--- Makefile.old 2008-01-04 06:49:28.000000000 -0700
+++ Makefile 2008-01-04 08:16:03.000000000 -0700
@@ -24,6 +24,9 @@
ifeq ($(VCR), 1)
CFLAGS += -DVCR_SUPPORT
endif
+ifeq ($(LIRC), 1)
+ CFLAGS += -DWITH_LIRC
+endif

# list of object files to generate
OBJ_CORE = \
@@ -144,6 +147,9 @@
OBJECTS += $(OBJ_VCR)
LIBS += $(AVIFILE_LIBS)
endif
+ifeq ($(LIRC), 1)
+ LDFLAGS += -llirc_client
+endif

# build targets
targets:
@@ -155,6 +161,7 @@
@echo " Options:"
@echo " BITS=32 == build 32-bit binaries on 64-bit machine"
@echo " VCR=1 == enable video recording"
+ @echo " LIRC=1 == enable LIRC support"
@echo " Debugging Options:"
@echo " DBGSYM=1 == add debugging symbols to binaries"
@echo " DBG=1 == build graphical debugger"
--- main/main.c.old 2008-01-04 08:20:15.000000000 -0700
+++ main/main.c 2008-01-04 09:12:26.000000000 -0700
@@ -60,6 +60,12 @@
#include <signal.h>
#endif

+#ifdef WITH_LIRC
+#include <string.h>
+#include <pthread.h>
+#include <lirc/lirc_client.h>
+#endif //WITH_LIRC
+
int autoinc_slot = 0;
int *autoinc_save_slot = &autoinc_slot;

@@ -68,6 +74,13 @@
static char cwd[1024];
int p_noask;

+#ifdef WITH_LIRC
+
+static pthread_t g_check_lirc_input = 0;
+struct lirc_config *g_config;
+
+#endif //WITH_LIRC
+
char *get_currentpath()
{
return cwd;
@@ -231,6 +244,60 @@
}
#endif

+#ifdef WITH_LIRC
+
+static void * check_lirc_input(void * arg)
+ {
+ if(pthread_setcanceltype(PTHREAD_CANCEL_ ASYNCHRONOUS, NULL))
+ printf("ERROR: LIRC CANNOT SET ASYNC EXIT!");
+ if(lirc_init("mupen64",1)==-1) exit(EXIT_FAILURE);
+
+ if(lirc_readconfig(NULL,&g_config,NULL)==0)
+ {
+ char *code;
+ char *c;
+ int ret;
+
+ while(lirc_nextcode(&code)==0)
+ {
+ if(code==NULL) continue;
+ while((ret=lirc_code2char(g_config,code, &c))==0 &&
+ c!=NULL)
+ {
+ char *c_ind = c;
+ while(*c_ind!='\0')
+ {
+ *c_ind=toupper(*c_ind);
+ c_ind++;
+ }
+//#ifdef DEBUG
+ printf("LIRC Execing command \"%s\"\n",c);
+//#endif //DEBUG
+
+ if(strcmp(c,"SAVE")==0)
+ savestates_job |= SAVESTATE;
+ else if(strcmp(c,"LOAD")==0)
+ savestates_job |= LOADSTATE;
+ else if(strcmp(c,"QUIT")==0)
+ stop_it();
+ else if(strcmp(c,"FULLSCREEN")==0)
+ changeWindow();
+ else
+ {
+ int val = ((int)c[0])-((int) '0');
+ if (val >= 0 && val <= 9)
+ savestates_select_slot( val );
+ }
+ }
+ free(code);
+ if(ret==-1) break;
+ }
+ }
+ return NULL;
+ }
+#endif //WITH_LIRC
+
+
int main(int argc, char *argv[])
{
char romfile[PATH_MAX];
@@ -545,6 +612,14 @@
romOpen_gfx();
romOpen_audio();
romOpen_input();
+
+#ifdef WITH_LIRC
+
+ if(pthread_create(&g_check_lirc_input,NULL,check_lirc_input , NULL ) )
+ return -1;
+ printf("Launching LIRC!\n");
+#endif //WITH_LIRC
+
// ------------------------------------------------------------
SDL_SetEventFilter(filter);

@@ -554,6 +629,16 @@
/* Run the emulator */
go();

+#ifdef WITH_LIRC
+ printf("Terminating LIRC...");
+ pthread_cancel( g_check_lirc_input );
+
+ pthread_join( g_check_lirc_input,NULL);
+ lirc_freeconfig(g_config);
+ lirc_deinit();
+ printf("done.\n");
+#endif //WITH_LIRC
+
/* Notify all dynamically loaded libraries to close down */
romClosed_RSP();
romClosed_input();

[Richard42]

Hey that's great - this would be a nice new feature to integrate into mupen64-amd64. But I don't think that some of these functions that are called (stop_it, changeWindow, etc) are re-entrant or thread-safe. Would it be possible to refactor this to remove the new thread that you create and just call the LIRC handler from within the existing event handling code?

[nmn]

GUI code is on the way. Sorry about the delay, i had to install a mother board today and then i had a strange error where the structure accessed from another file was changed and the other file wasn't recompiled and... Well, a cast was failing. In the end i found out all i had to do was recompile but i wasted half the day on it.

In other news, I've added a new option for filenames that allows you to select whether it shows the full path (fully implemented and saves to the configuration system), the columns can be reordered (haven't figured out how to make that savable :( ), and theres a few more things i'd like to add to the GUI that are left unimplemented or poorly done. And as a result of the GtkCList -> GtkTreeView port work i still have a bit of left over code to deal with. I'll try to get it all done ASAP. Hopefully in the very early morning.

edit: Oooh, LIRC would be awesome. An emulating Linux box connected to a TV with a remote controller :D *drools*

[DarkJezter]

I've been investigating ways of doing this, to ensure a minimal performance impact on the application, I believe a dedicated thread for the LIRC input is ideal. By default the LIRC client library blocks for input from the LIRC subsystem, and with a dedicated thread, instead of polling for input the kernel should be able to put the thread into a sleep state until such input becomes available.

As far as thread safety goes, I've done a bit of research, and I think that SDL may hold the answer. There is an SDL function to generate an event, which as best I can tell is in fact thread safe (see SDL_PushEvent on http://www.dranger.com/ffmpeg/functions.html) This way, the separate thread can generate the events when LIRC has input to process, and SDL will transfer the processing of those events to the main thread in the event filter function.

I won't be around to test this until at least Sunday or Monday, but I should have the mechanics fleshed out by the end of the day. Let me know if you think this will meet the need.

L8r

P.S. There isn't any kind of a forum dedicated to the development of this project is there?

[Richard42]

GUI code is on the way. Sorry about the delay, i had to install a mother board today and then i had a strange error where the structure accessed from another file was changed and the other file wasn't recompiled and... Well, a cast was failing. In the end i found out all i had to do was recompile but i wasted half the day on it.

Yeah that's an common issue with simple makefiles like we use in this project. If you change a header you need to do a 'make clean' before rebuilding, as the makefiles don't recognize the dependencies caused by header inclusion. There is a way of handling these dependencies properly with makefiles, but I've never set up a project using this method.

It sounds like you're making some good progress with the rom browser work. I still have a few days of work left with the optimization of the 64-bit recompiler before I'll be ready. We'll have some nice big new features in the next release.

[Richard42]

I won't be around to test this until at least Sunday or Monday, but I should have the mechanics fleshed out by the end of the day. Let me know if you think this will meet the need.

L8r

P.S. There isn't any kind of a forum dedicated to the development of this project is there?

I think your idea to use the SDL Event queue is the way to go. It fits nicely within the existing code and should properly protect the thread communication. The SDL documentation page (http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fPushEvent) confirms that it is thread safe.

This place is the official forum for Mupen64 usage and development.

[nmn]

Well i think he was refering to this branch of Mupen64, in which case, no, there is no sub-catagory for this branch.

I wasn't here this morning, because i accidentally set my up CPU fan wrong. lol glad i finally got lm-sensors working. Anyways, Back in business, glad to here that someones investigating LIRC support, and i'll be working in as many features and GUI improvements as i can today.

[DarkJezter]

Hey guys,

Thought I'd keep you posted, I've modified the patch to generate SDL events, specifically it actually generates phantom key presses and adds them to the event queue. They should then be processed normally by the event filter function as if a key on the keyboard had actually been pressed.

I'm not actually at home to test it, but once I get back probably by this time tomorrow I should have a new patch posted to the site.

[nmn]

Okay, the new GUI is in SVN. It moves depricated GtkCombo widgets to the newer GtkComboBox which is more proper. It moves the entire rom browser from the depricated GtkCList to GtkTreeView. An etched in border has been added to the Rom Directory list in the config dialog. The tabs on the rombrowser can be reordered, but its not saving that yet.

I'm in the process of adding some extra options for the toolbar. I have already made full pathnames a non-default option. The icons in the config dialog are loaded using the new icon loading mechinism and therfore work when you execute from a different directory.

Just to make it clear, while this GUI may be nearly appropriete for release, i'll be slowly committing patches for it. Releasing a new version should be fine whenever you think the components have matured enough.

[Richard42]

Thought I'd keep you posted, I've modified the patch to generate SDL events, specifically it actually generates phantom key presses and adds them to the event queue. They should then be processed normally by the event filter function as if a key on the keyboard had actually been pressed.


Glad to hear of your progress. I'm in the middle of refactoring the dynamic recompiler's register cache to use real 64-bit registers, which should give a good speed boost. Just drop the code here when you're ready, or PM me with a username/password and email address and I'll set you up with an SVN account if you would rather go that way.

[DarkJezter]

I presume you're only using the 64 bit registers in the x86_64 bit version of the recompiler. (Pity, as I'll probably be looking for ways to squeeze a modest performance gain out of an old Athlon XP 3200)

I've actually hit a rather significant snag in the development. Unfortunately the events pushed manually onto the queue are not run through the filter, so I've been examining the code for an alternative. It seems that I may need to add to the interrupt handler code to pull this all off, but I'm still getting acquainted with the internals of the emulator.

I'll PM you an update when I have it.

[Richard42]

I presume you're only using the 64 bit registers in the x86_64 bit version of the recompiler. (Pity, as I'll probably be looking for ways to squeeze a modest performance gain out of an old Athlon XP 3200)

I've actually hit a rather significant snag in the development. Unfortunately the events pushed manually onto the queue are not run through the filter, so I've been examining the code for an alternative. It seems that I may need to add to the interrupt handler code to pull this all off, but I'm still getting acquainted with the internals of the emulator.


I'm not sure what you mean about the 64-bit registers. Both recompilers support the full R4300 register set, which is 64 bits wide. The 32-bit recompiler has some pretty clever tricks with the register cache in order to support these using only the 32-bit registers present in the x86 instruction set. There is some room for improvement but not much. For the 64-bit recompiler I totally rewrote the register cache and all of the R4300 instruction compilers to use the native 64-bit registers which are available in the AMD64 instruction set. It's actually much simpler now, and I'm hoping it will translate into a nice performance boost.

I still have 2 or 3 more major optimizations to make before I'll call it done, so you can take your time, learn how it all works, and do it in the best way possible.

[DarkJezter]

Hey all,

The patch is done, and appears to be working rather well. I did add an empty function to the GUI version, mostly to prevent it from breaking the build process, however if LIRC support is to be added to the GUI version as well then the code will likely need to be re-written anyway. Perhaps adding LIRC support to the GUI version is a project I'll undertake at a later time.


diff -Naur mupen64-64bit.old/main/gui_gtk/main_gtk.c mupen64-64bit/main/gui_gtk/main_gtk.c
--- mupen64-64bit.old/main/gui_gtk/main_gtk.c 2008-01-02 07:14:05.000000000 -0700
+++ mupen64-64bit/main/gui_gtk/main_gtk.c 2008-01-11 08:45:15.000000000 -0700
@@ -42,6 +42,10 @@
#include "../../debugger/debugger.h"
#endif

+#ifdef WITH_LIRC
+#include "../lirc.h"
+#endif //WITH_LIRC
+
#include <gtk/gtk.h>

#include <SDL.h>
@@ -322,6 +326,10 @@
tr("The save state you're trying to load doesn't exist"));
}

+#ifdef WITH_LIRC
+void checkLircInput() { }
+#endif //WITH_LIRC
+
/**************************************** **************************************** *************************
* internal gui funcs
*/
diff -Naur mupen64-64bit.old/main/lirc.h mupen64-64bit/main/lirc.h
--- mupen64-64bit.old/main/lirc.h 1969-12-31 17:00:00.000000000 -0700
+++ mupen64-64bit/main/lirc.h 2008-01-11 08:05:59.000000000 -0700
@@ -0,0 +1,28 @@
+/**************************************** ***********************************
+ lirc.h - description
+ -------------------
+ begin : Friday 11 Jan 2008
+ copyright : (C) 2008 by DarkJezter
+ **************************************** ***********************************/
+
+/**************************************** ***********************************
+ * *
+ * This program is free software; you can redistribute it and/or modify *
+ * it under the terms of the GNU General Public License as published by *
+ * the Free Software Foundation; either version 2 of the License, or *
+ * (at your option) any later version. *
+ * *
+ **************************************** ***********************************/
+
+#ifndef __LIRC_H__
+#define __LIRC_H__
+
+#include <sys/poll.h>
+#include <string.h>
+#include <lirc/lirc_client.h>
+
+
+void checkLircInput();
+
+
+#endif //__LIRC_H__
diff -Naur mupen64-64bit.old/main/main.c mupen64-64bit/main/main.c
--- mupen64-64bit.old/main/main.c 2008-01-02 07:14:07.000000000 -0700
+++ mupen64-64bit/main/main.c 2008-01-11 08:53:32.000000000 -0700
@@ -60,6 +60,10 @@
#include <signal.h>
#endif

+#ifdef WITH_LIRC
+#include "lirc.h"
+#endif //WITH_LIRC
+
int autoinc_slot = 0;
int *autoinc_save_slot = &autoinc_slot;

@@ -68,6 +72,13 @@
static char cwd[1024];
int p_noask;

+#ifdef WITH_LIRC
+
+struct lirc_config *g_config;
+int g_lircfd;
+
+#endif //WITH_LIRC
+
char *get_currentpath()
{
return cwd;
@@ -231,6 +242,59 @@
}
#endif

+#ifdef WITH_LIRC
+
+void checkLircInput()
+ {
+ struct pollfd lircpoll;
+ lircpoll.fd=g_lircfd;
+ lircpoll.events=POLLIN;
+ if(poll(&lircpoll,1,0)>0)
+ {
+ char *code;
+ char *c;
+ int ret;
+
+ if(lirc_nextcode(&code)==0 && code!=NULL)
+ {
+ while((ret=lirc_code2char(g_config,code, &c))==0 &&
+ c!=NULL)
+ {
+ char *c_ind = c;
+ while(*c_ind!='\0')
+ {
+ *c_ind=toupper(*c_ind);
+ c_ind++;
+ }
+#ifdef DEBUG
+ printf("LIRC Execing command \"%s\"\n",c);
+#endif //DEBUG
+
+ if(strcmp(c,"SAVE")==0)
+ savestates_job |= SAVESTATE;
+ else if(strcmp(c,"LOAD")==0)
+ savestates_job |= LOADSTATE;
+ else if(strcmp(c,"QUIT")==0)
+ stop_it();
+ else if(strcmp(c,"FULLSCREEN")==0)
+ changeWindow();
+ else if(strcmp(c,"SCREENSHOT")==0)
+ captureScreen(screenshotdir);
+ else
+ {
+ int val = ((int)c[0])-((int) '0');
+ if (val >= 0 && val <= 9)
+ savestates_select_slot( val );
+ }
+ }
+ free(code);
+ }
+ }
+ }
+
+#endif //WITH_LIRC
+
+
int main(int argc, char *argv[])
{
char romfile[PATH_MAX];
@@ -545,6 +609,22 @@
romOpen_gfx();
romOpen_audio();
romOpen_input();
+
+#ifdef WITH_LIRC
+ printf("Launching LIRC...");
+
+ if((g_lircfd=lirc_init("mupen64",1))!=-1)
+ {
+ g_config=NULL;
+ if(lirc_readconfig(NULL,&g_config,NULL)==0)
+ printf("OK!\n");
+ else
+ printf("Error reading lircrc!\n");
+ }
+ else
+ printf("Error contacting daemon!\n");
+#endif //WITH_LIRC
+
// ------------------------------------------------------------
SDL_SetEventFilter(filter);

@@ -554,6 +634,17 @@
/* Run the emulator */
go();

+#ifdef WITH_LIRC
+ if(g_lircfd!=-1)
+ {
+ printf("Terminating LIRC...");
+ if(g_config != NULL)
+ lirc_freeconfig(g_config);
+ lirc_deinit();
+ printf("done.\n");
+ }
+#endif //WITH_LIRC
+
/* Notify all dynamically loaded libraries to close down */
romClosed_RSP();
romClosed_input();
diff -Naur mupen64-64bit.old/Makefile mupen64-64bit/Makefile
--- mupen64-64bit.old/Makefile 2008-01-02 07:14:14.000000000 -0700
+++ mupen64-64bit/Makefile 2008-01-11 08:03:18.000000000 -0700
@@ -24,6 +24,9 @@
ifeq ($(VCR), 1)
CFLAGS += -DVCR_SUPPORT
endif
+ifeq ($(LIRC), 1)
+ CFLAGS += -DWITH_LIRC
+endif

# list of object files to generate
OBJ_CORE = \
@@ -144,6 +147,9 @@
OBJECTS += $(OBJ_VCR)
LIBS += $(AVIFILE_LIBS)
endif
+ifeq ($(LIRC), 1)
+ LDFLAGS += -llirc_client
+endif

# build targets
targets:
@@ -155,6 +161,7 @@
@echo " Options:"
@echo " BITS=32 == build 32-bit binaries on 64-bit machine"
@echo " VCR=1 == enable video recording"
+ @echo " LIRC=1 == enable LIRC support"
@echo " Debugging Options:"
@echo " DBGSYM=1 == add debugging symbols to binaries"
@echo " DBG=1 == build graphical debugger"
diff -Naur mupen64-64bit.old/r4300/interupt.c mupen64-64bit/r4300/interupt.c
--- mupen64-64bit.old/r4300/interupt.c 2008-01-02 07:14:13.000000000 -0700
+++ mupen64-64bit/r4300/interupt.c 2008-01-11 08:31:13.000000000 -0700
@@ -46,6 +46,10 @@
#include "../main/savestates.h"
#include "../main/vcr.h"

+#ifdef WITH_LIRC
+#include "../main/lirc.h"
+#endif //WITH_LIRC
+

unsigned int next_vi;
int vi_field=0;
@@ -381,6 +385,10 @@
#else
updateScreen();
#endif
+#ifdef WITH_LIRC
+ checkLircInput();
+#endif //WITH_LIRC
+
#ifndef __WIN32__
SDL_PumpEvents();
refresh_stat();
@@ -420,6 +428,10 @@
break;

case SI_INT:
+#ifdef WITH_LIRC
+ checkLircInput();
+#endif //WITH_LIRC
+
#ifndef __WIN32__
SDL_PumpEvents();
#endif

[Richard42]

Looks pretty good. I'll try and get it patched in this weekend. Thanks!

[nmn]

Yay. Ironically enough i just got a device with an IR sensor and a remote like a few days ago on my Linux box so this shall be fun. (I was surprised it worked, being a TV tuner Linux/Latest GIT didn't support, but using a similar enough brand, it was awesome!)

[DarkJezter]

Booyeah! I've been fighting with a profiler to figure out why GoldenEye's been running so slowly, and I found a bug in the TLBWR function that was accounting for about 10% of the cpu time being consumed by the emulator.

Here's the patch, I haven't really done much research into whether or not this is the proper behavior of the r4300, but wrote it in such a way as to preserve the emulator's current functionality. This should make for a significant speed increase for any games that are heavy on the TLB like Conker's BFD, Goldeneye, and I'm sure there are others.


--- mupen64-64bit.old/r4300/tlb.c 2008-01-02 07:14:13.000000000 -0700
+++ mupen64-64bit/r4300/tlb.c 2008-01-14 15:30:37.000000000 -0700
@@ -341,13 +341,13 @@
tlb_e[Random].end_even < 0xC0000000) &&
tlb_e[Random].phys_even < 0x20000000)
{
- for (i=tlb_e[Random].start_even;i<tlb_e[Random].end_even;i++)
+ for (i=tlb_e[Random].start_even;i<tlb_e[Random].end_even;i+=0x1000)
tlb_LUT_r[i>>12] = 0x80000000 |
- (tlb_e[Random].phys_even + (i - tlb_e[Random].start_even));
+ (tlb_e[Random].phys_even + (i - tlb_e[Random].start_even) + 0xFFF);
if (tlb_e[Random].d_even)
- for (i=tlb_e[Random].start_even;i<tlb_e[Random].end_even;i++)
+ for (i=tlb_e[Random].start_even;i<tlb_e[Random].end_even;i+=0x1000)
tlb_LUT_w[i>>12] = 0x80000000 |
- (tlb_e[Random].phys_even + (i - tlb_e[Random].start_even));
+ (tlb_e[Random].phys_even + (i - tlb_e[Random].start_even) + 0xFFF);
}

for (i=tlb_e[Random].start_even>>12; i<=tlb_e[Random].end_even>>12; i++)
@@ -388,13 +388,13 @@
tlb_e[Random].end_odd < 0xC0000000) &&
tlb_e[Random].phys_odd < 0x20000000)
{
- for (i=tlb_e[Random].start_odd;i<tlb_e[Random].end_odd;i++)
+ for (i=tlb_e[Random].start_odd;i<tlb_e[Random].end_odd;i+=0x1000)
tlb_LUT_r[i>>12] = 0x80000000 |
- (tlb_e[Random].phys_odd + (i - tlb_e[Random].start_odd));
+ (tlb_e[Random].phys_odd + (i - tlb_e[Random].start_odd)+0xFFF);
if (tlb_e[Random].d_odd)
- for (i=tlb_e[Random].start_odd;i<tlb_e[Random].end_odd;i++)
+ for (i=tlb_e[Random].start_odd;i<tlb_e[Random].end_odd;i+=0x1000)
tlb_LUT_w[i>>12] = 0x80000000 |
- (tlb_e[Random].phys_odd + (i - tlb_e[Random].start_odd));
+ (tlb_e[Random].phys_odd + (i - tlb_e[Random].start_odd)+0xFFF);
}

for (i=tlb_e[Random].start_odd>>12; i<=tlb_e[Random].end_odd>>12; i++)



Edit: Actually, it seems my estimate of 5 to 10 percent may have been a bit conservative. Goldeneye on the Facility map was running at about 95-100 percent cpu usage, after this patch, that's dropped down to 60 to 70% :D

[Richard42]

Here's the patch, I haven't really done much research into whether or not this is the proper behavior of the r4300, but wrote it in such a way as to preserve the emulator's current functionality. This should make for a significant speed increase for any games that are heavy on the TLB like Conker's BFD, Goldeneye, and I'm sure there are others.


Hey that's great! Good work on the profiling and bug catch; that will be a major improvement for the games that use the TLB. I have merged both of your patches into the SVN repository.

[OmegaX]

Hi, I just downloaded Mupen64-amd64 1.1 from the first post but I can't get to compile it.
At first it complained about SDL_ttf so I installed it, now when running make I get this error:
g++ -o OpenGL.o -Wall -pipe -O3 -march=i686 -mtune=pentium-m -mmmx -msse -ffast-math -funroll-loops -fomit-frame-pointer -fexpensive-optimizations -fno-strict-aliasing -fpic -DPIC -D__LINUX__ -DX86_ASM `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -c OpenGL.cpp
OpenGL.cpp: In function `bool OGL_Start()':
OpenGL.cpp:431: error: `SDL_GL_SWAP_CONTROL' sin declarar (primer uso en esta función)
OpenGL.cpp:431: error: (Cada identificador sin declarar es reportado sólo una vez para cada función en el que aparece.)
make[1]: *** [OpenGL.o] Error 1
make[1]: se sale del directorio `/home/carlos/Programas/Mupen64-amd64-1-1-src/glN64'
make: *** [plugins/glN64.so] Error 2

I reviewed line 431 of the OpenGL.cpp file in the folder glN64 and I got this:

#if !defined(SDL_PRE_1_2_11)
SDL_GL_SetAttribute( SDL_GL_SWAP_CONTROL, 1); // only swap buffers on vertical sync
#endif

From what I can understand it seems that function is defined for a specific version of SDL, the version that comes with my Linux distro is 1.2.9, is version 1.2.11 required? Is anything that I can do to fix this error without installing a newer SDL? If the only way to fix this is to get a newer SDL I might switch to another distro but that might take a while.
Thanks in advance for your answers.

[Richard42]

From what I can understand it seems that function is defined for a specific version of SDL, the version that comes with my Linux distro is 1.2.9, is version 1.2.11 required? Is anything that I can do to fix this error without installing a newer SDL? If the only way to fix this is to get a newer SDL I might switch to another distro but that might take a while.
Thanks in advance for your answers.

Yeah I added that into the code a while back to force swapping on vsync to avoid tearing. I saw that it was a fairly new function in SDL so I wrapped it in that ifdef. You can safely remove it or comment it out and it should compile and run just fine on your machine. Ideally we should extract the SDL version number in the makefile and set that definition if the SDL version is older than 1.2.11. I'll put it on the to-do list.

[Richard42]

From what I can understand it seems that function is defined for a specific version of SDL, the version that comes with my Linux distro is 1.2.9, is version 1.2.11 required? Is anything that I can do to fix this error without installing a newer SDL? If the only way to fix this is to get a newer SDL I might switch to another distro but that might take a while.
Thanks in advance for your answers.

Yeah I added that into the code a while back to force swapping on vsync to avoid tearing. I saw that it was a fairly new function in SDL so I wrapped it in that ifdef. You can safely remove it or comment it out and it should compile and run just fine on your machine. Ideally we should extract the SDL version number in the makefile and set that definition if the SDL version is older than 1.2.11. I'll put it on the to-do list.

[Richard42]

From what I can understand it seems that function is defined for a specific version of SDL, the version that comes with my Linux distro is 1.2.9, is version 1.2.11 required? Is anything that I can do to fix this error without installing a newer SDL? If the only way to fix this is to get a newer SDL I might switch to another distro but that might take a while.
Thanks in advance for your answers.

Yeah I added that into the code a while back to force swapping on vsync to avoid tearing. I saw that it was a fairly new function in SDL so I wrapped it in that ifdef. You can safely remove it or comment it out and it should compile and run just fine on your machine. Ideally we should extract the SDL version number in the makefile and set that definition if the SDL version is older than 1.2.11. I'll put it on the to-do list.

[Richard42]

From what I can understand it seems that function is defined for a specific version of SDL, the version that comes with my Linux distro is 1.2.9, is version 1.2.11 required? Is anything that I can do to fix this error without installing a newer SDL? If the only way to fix this is to get a newer SDL I might switch to another distro but that might take a while.
Thanks in advance for your answers.

Yeah I added that into the code a while back to force swapping on vsync to avoid tearing. I saw that it was a fairly new function in SDL so I wrapped it in that ifdef. You can safely remove it or comment it out and it should compile and run just fine on your machine. Ideally we should extract the SDL version number in the makefile and set that definition if the SDL version is older than 1.2.11. I'll put it on the to-do list.

[Richard42]

bump so that OmegaX can see that I replied. (forum was broken for a while)

[ebenblues]

Hi,

I've just recently started using mupen64 and using the Rice plugin, all I get is a white screen. I can hear the sounds of the game (tried it with Super Mario 64 and Mario Kart 64), but I don't get any visuals. The glN64.so plugin works well with Super Mario 64, but it doesn't recognize a ucode in Mario Kart 64, so it won't play it. From what I've read, it sounds like the Rice plugin might be what I'm looking for if I can get past this white screen problem. I've tried with the binary rice plugin that comes with the mupen64 0.5 release and I also tried compiling the source posted at the top of this thread and both give me the same white screen. I hope someone here can help me.

Linux Distro: Slackware 12.0
Mobo: VIA VB7001G
Onboard video (lspci -v output):
01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01) (prog-if 00 [VGA])
Subsystem: VIA Technologies, Inc. UniChrome Pro IGP
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 21
Memory at f4000000 (32-bit, prefetchable) [size=64M]
Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
[virtual] Expansion ROM at fc000000 [disabled] [size=64K]
Capabilities: [60] Power Management version 2
Capabilities: [70] AGP version 3.0

glxinfo output:
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method,
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGIS_multisample,
GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_make_current_read,
GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample,
GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
OpenGL vendor string: VIA Technology
OpenGL renderer string: Mesa DRI UniChrome 20060710 x86/MMX/SSE2
OpenGL version string: 1.2 Mesa 7.0.2
OpenGL extensions:
GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture,
GL_ARB_point_parameters, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_mirrored_repeat,
GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_window_pos,
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax,
GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,
GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture,
GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_histogram,
GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset,
GL_EXT_rescale_normal, GL_EXT_secondary_color,
GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture,
GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp,
GL_EXT_texture_env_add, GL_EXT_texture_env_combine,
GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_vertex_array,
GL_APPLE_packed_pixels, GL_IBM_rasterpos_clip,
GL_IBM_texture_mirrored_repeat, GL_MESA_window_pos, GL_NV_blend_square,
GL_NV_light_max_exponent, GL_NV_texgen_reflection, GL_OES_read_format,
GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_texture_edge_clamp,
GL_SGIS_texture_lod

visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x22 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x23 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x24 24 tc 0 32 0 r y . 8 8 8 8 0 16 0 0 0 0 0 0 0 None
0x25 24 tc 0 32 0 r . . 8 8 8 8 0 16 0 0 0 0 0 0 0 None
0x26 24 tc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x27 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x28 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x29 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x2a 24 tc 0 32 0 r y . 8 8 8 8 0 16 0 16 16 16 16 0 0 Slow
0x2b 24 tc 0 32 0 r . . 8 8 8 8 0 16 0 16 16 16 16 0 0 Slow
0x2c 24 tc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x2d 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x47 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon

[Richard42]

I've just recently started using mupen64 and using the Rice plugin, all I get is a white screen. I can hear the sounds of the game (tried it with Super Mario 64 and Mario Kart 64), but I don't get any visuals. The glN64.so plugin works well with Super Mario 64, but it doesn't recognize a ucode in Mario Kart 64, so it won't play it. From what I've read, it sounds like the Rice plugin might be what I'm looking for if I can get past this white screen problem. I've tried with the binary rice plugin that comes with the mupen64 0.5 release and I also tried compiling the source posted at the top of this thread and both give me the same white screen. I hope someone here can help me.


Interesting - you have a unichrome integrated GPU. I've never worked with one of these before. Can you try running the mupen64_nogui application from the binary package of Mupen64-amd64 v1.1 and paste here the info which gets dumped out to the console?

[ebenblues]

Interesting - you have a unichrome integrated GPU. I've never worked with one of these before. Can you try running the mupen64_nogui application from the binary package of Mupen64-amd64 v1.1 and paste here the info which gets dumped out to the console?

Ok, I downloaded the mupen64-amd64 source from the top of the thread, built and ran it using the compiled Rice plugin I used before. I got the same white screen problems. The console output of running mupen64_nogui in fullscreen mode is pasted below. I tried passing DBG=1 on the commandline when I ran make all, but I got compile errors, so I had to build it without debug.

I should also mention with Super Mario 64, in the very first screen when you play the rom (Super Mario 64 logo pops up and you hear Mario's voice), the background is black and the Super Mario 64 logo is rendered correctly. But there is a white square where the "TM" should be and a white rectangle where the "(C)1996 Nintendo" should be. Then the entire screen goes white when it switches to the screen where Mario's head pops up.


Mupen64-amd64 version : 1.1
loading rom : 1%
loading rom : 2%
loading rom : 3%
loading rom : 4%
loading rom : 5%
loading rom : 6%
loading rom : 7%
loading rom : 8%
loading rom : 9%
loading rom : 10%
loading rom : 11%
loading rom : 12%
loading rom : 13%
loading rom : 14%
loading rom : 15%
loading rom : 16%
loading rom : 17%
loading rom : 18%
loading rom : 19%
loading rom : 20%
loading rom : 21%
loading rom : 22%
loading rom : 23%
loading rom : 24%
loading rom : 25%
loading rom : 26%
loading rom : 27%
loading rom : 28%
loading rom : 29%
loading rom : 30%
loading rom : 31%
loading rom : 32%
loading rom : 33%
loading rom : 34%
loading rom : 35%
loading rom : 36%
loading rom : 37%
loading rom : 38%
loading rom : 39%
loading rom : 40%
loading rom : 41%
loading rom : 42%
loading rom : 43%
loading rom : 44%
loading rom : 45%
loading rom : 46%
loading rom : 47%
loading rom : 48%
loading rom : 49%
loading rom : 50%
loading rom : 51%
loading rom : 52%
loading rom : 53%
loading rom : 54%
loading rom : 55%
loading rom : 56%
loading rom : 57%
loading rom : 58%
loading rom : 59%
loading rom : 60%
loading rom : 61%
loading rom : 62%
loading rom : 63%
loading rom : 64%
loading rom : 65%
loading rom : 66%
loading rom : 67%
loading rom : 68%
loading rom : 69%
loading rom : 70%
loading rom : 71%
loading rom : 72%
loading rom : 73%
loading rom : 74%
loading rom : 75%
loading rom : 76%
loading rom : 77%
loading rom : 78%
loading rom : 79%
loading rom : 80%
loading rom : 81%
loading rom : 82%
loading rom : 83%
loading rom : 84%
loading rom : 85%
loading rom : 86%
loading rom : 87%
loading rom : 88%
loading rom : 89%
loading rom : 90%
loading rom : 91%
loading rom : 92%
loading rom : 93%
loading rom : 94%
loading rom : 95%
loading rom : 96%
loading rom : 97%
loading rom : 98%
loading rom : 99%
rom loaded succesfully
loading rom : 100%
(EE) Cannot open config file.

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
eeprom type:0
Goodname:Super Mario 64 (U) [!]
16kb eeprom=0
memory initialized
Selected GFX Plugin: 1 - Rice's Video Plugin 1.1
Selected Audio Plugin: 1 - JttL's SDL plugin 1.3
Selected Input Plugin: 1 - blight's SDL input plugin 0.0.10
Selected RSP Plugin: 1 - Hacktarux/Azimer hle rsp plugin
[RiceVideo] SSE processing enabled.
[blight's SDL input plugin]: version 0.0.10 initialized.
[RiceVideo] SSE processing enabled.
[RiceVideo] Found ROM 'SUPER MARIO 64', CRC ff2b5a632623028b-45
InitExternalTextures
Initializing OpenGL Device Context
(II) Initializing SDL video subsystem...
(II) Getting video info...
(II) Setting video mode 640x480...
VIA Technology - Mesa DRI UniChrome 20060710 x86/MMX/SSE2 : 1.2 Mesa 7.0.2
[RiceVideo] OpenGL Combiner: OGL 1.2/1.3
(II) JttL's sound plugin version 1.3
(II) Initializing SDL audio subsystem...
(II) Allocating memory for audio buffer: 65536 bytes.
demarrage r4300
R4300 Core mode: Interpreter
PC=80000180:3c1a8032
reg[ 0]: 0 0 reg[16]: 0 0
reg[ 1]: 0 0 reg[17]: 0 0
reg[ 2]: 0 0 reg[18]: 0 0
reg[ 3]: 0 0 reg[19]: 0 0
reg[ 4]: 0 1 reg[20]: 0 0
reg[ 5]:ffffffff80364c60 reg[21]: 0 0
reg[ 6]:ffffffff803230f4 reg[22]: 0 0
reg[ 7]: 0 0 reg[23]: 0 0
reg[ 8]: 0 ff01 reg[24]:ffffffff8033a730
reg[ 9]:ffffffff80364c60 reg[25]:ffffffff8033a730
reg[10]: 0 fe reg[26]:ffffffffa430000c
reg[11]:ffffffff80364c60 reg[27]: 0 aaa
reg[12]:ffffffffa4400000 reg[28]: 0 0
reg[13]:ffffffffa4400000 reg[29]:ffffffff80200dc8
reg[14]:ffffffffffffffff reg[30]: 0 0
reg[15]: 0 fe reg[31]:ffffffff80246dd8
hi: 0 0 lo: 0 0
après 626367486 instructions soit 25559bfe
(II) Cleaning up SDL sound plugin...
[RiceVideo] Found ROM 'SUPER MARIO 64', CRC ff2b5a632623028b-45
[blight's SDL input plugin]: Closing...

[burpnrun]

Just some info about my experience. I dowloaded and installed the 32 bit binary of Mupen64 (1.1?) from the first page of this thread, then ran it without problem. As I'm using openSUSE 10.3 (KDE) and a Logitech RumblePad 2 (wired), I thought someone might have an interest in what I did.

1. Using Yast - Software Management, installed "joy2key", "libjsw", "libjsw-calibrator" (all of foregoing found by search term "joystick", and "SDL-ttf". Some other prerequisites may be included after you press "Accept" ... just accept them also. For the heck of it, I rebooted at this point, even though my RumblePad was already plugged in to a USB port.

2. Ran "jscalibrator" in a terminal window and "did my thing". I don't know if this is required, but, whatever! Only seemed to accept my left joystik, not the right one.

3. Downloaded the 32 bit version of Mupen64 v1.1 and unzipped it into my "OPT" directory, and renamed (the long unzipped directory name) to just plain mupen64. Any directory (including your Home directory/folder) will do. I also created a "roms" subdirectory under this mupen64 directory, and copied my legal Mario64 Kart ROM into it for a quickie test.

4. Created a desktop link to the mupen64 executable using Right-click on the desktop and selecting "New - Link to Application", specifying the /opt/mupen64 directory as the work folder or whatnot, and the "logo.xpm" file as the icon to use (the .png looks crappy on my system). Firing up the emulator through this desktop link took a hair-second, and then all there was to do was set the ROM directory, and setup the Rumblepad for Kart 64.

5. Setting up the Rumblepad is the toughest in the Input plugin dialogue. Just make sure your pad/stick comes up selectable in the input plugin, and make sure the "Plugged" and "Mempack" buttons are not darkened. I'm still experimenting with button assignments. Never ending.

No other adjustments. Firing up Kart 64 works perfectly. Screen quality (so far I've just used the stock 640x480 window) is great and sufficient for my purposes. Ditto the speed of the gameand sound. No artifacts, blips or quirks yet. Also tried Diddly Kong briefly ... same excellent result. The developer should be very proud of this!

FWIW, I have an Asus M2NPV-VM, AMD 3600x2, 2x1 gigs of DDR2-800 Patriot, and a Asus EN8600GT silent PCIe with a homebrew low speed fan screwed to it. The sound is on the MB, an AD 1986A chip, and using KDE and ALSA. Works straight off! YMMV.

OT, I also have WOW working perfectly under Wine, without Cedega. From what I gather, updates by Cedega are few and far between, buggy, and it seems that new/renewed subscriptions are dropping off rapidly now that Wine's goodness has avertaken whatever value-added Cedega used to supply. My comment is based on threads over at their forum. The view there is that Cedega is milking their old cash cow for whatever they can.

[ace214]

When I try to load high res textures into Zelda OoT:MQ, the program closes when I try to load the game. Here's the console output.

console:~/Desktop/Mupen64amd64-RiceVideoLinux-1-1-bin-32$ ./mupen64
file not found or wrong path

(mupen64:6753): Gtk-CRITICAL **: gtk_box_pack_start: assertion `child->parent == NULL' failed
rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
byteswaping rom...
rom byteswaped
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:144c
CRC: 1d4136f3 af63eea9
name: ZELDA MASTER QUEST
Manufacturer: Nintendo
Cartridge_ID: 4c5a
Country Code : f45
size: 4096
PC= 80000400
md5 code:2DE4D0F0788871CC4BB6D30B60F72184
eeprom type:0
init timer!
memory initialized
[RiceVideo] Disabled SSE processing.
[blight's SDL input plugin]: version 0.0.10 initialized.
[RiceVideo] Disabled SSE processing.
[RiceVideo] Found ROM 'ZELDA MASTER QUEST', CRC f336411da9ee63af-45
[RiceVideo] Enabled hacks for game: 'ZELDA MASTER QUEST'
InitExternalTextures
Texture loading option is enabledFinding all hires texturesSignal number 11 caught:
errno = 0 (Success)

Thanks for any help and all your work on the program.

[Tillin9]

@ace214: I can't see to get Master Quest to use hi-res textures either, which is really odd since I have Kman's pack and its working perfectly with regular Zelda64 under Mupen 1.2 and both ROMs under Project64. My best guess is this is an issue with Mupen calling the ROM ZELDA MASTER QUEST and Rice expecting it to call itself THE LEGEND OF ZELDA, since under Project64 Kman's pack works for both without renaming the directory. Mupen doesn't segfault on me, just refuses to load the hi-res textures.

Some things to check:
- Try release 1.2 or compiling from svn trunk if you're only on 1.1. Some OpenGL combined issues in Rice were fixed in 1.2 which might be affecting you.
- You have a hires_texture folder in plugins. (plugin should make it if not there)
- You can play the ROM without hi-res packs using Rice as to isolate video driver issues which Rice is still known to have.
- The pack works under Project64 as to try to isolate pack issues.

Also, I compiled from trunk and there is a really minor logo problem (i.e. a make error which was fixed by just # commenting out the cp for the logo. in the master Makefile) The big news is the recent speed improvement almost doubled my framerate under Glide64. :D

[ebenblues]

Also, I compiled from trunk and there is a really minor logo problem (i.e. a make error which was fixed by just # commenting out the cp for the logo. in the master Makefile) The big news is the recent speed improvement almost doubled my framerate under Glide64. :D
Thanks for the bug report. I fixed this issue in svn (the logo file was moved to the icons subfolder during the gui/nogui merge). I'm not sure how the binary release is going to work with the new multiuser support. We may need to provide an install script to make sure everything gets copied to the right place.

[Eck]

burpnrun,

Are you using a current distro and Kernel? If so, there's no need to install all those joystick calibration programs. In the older 2.6.18 Kernels I used to have to add joydev as a module to load at boot in YaST System Config Editor, but since 2.6.22 and OpenSUSE 10.3 this wasn't needed at all.

I use the same gamepad you do, and previously a Thrustmaster 2-in-1 Dual Trigger Rumblepad, and neither needed any kind of preparation or calibration like old midi port gamepads did. I simply plugged it in and it worked. KDE has a calibration and checking tool right in KControl but that simply confirms everything and I've never needed to go deeper into it and actually run the calibration in there. Gnome doesn't have that, but the Kernel driver still supports it and so the gamepad works regardless.

The only reason I need to check things in KControl or in /dev/input when in Gnome, is because I keep both the Logitech and my Adaptoid plugged in all the time and sometimes when the computer is started up the Kernel reverses the js0, js1 order of the pads (I keep the Rumblepad 2 as js0 and the Adaptoid as js1). In KDE when logged in I open Configure Desktop-Personal Settings (KControl on SUSE) and look in the KDE Components-Hardware-Joystick area to see which order the Kernel picked this time. If it's wrong I unplug them and plug them in with the Rumblepad first and that fixes the problem. If in Gnome I check in the /dev/input folder in the one that does the naming by name and make sure the Rumblepad is first. If not, again I just unplug them and plug them in in the correct order and things are fine. No calibration needed.

The Mupen64 joystick configuration works great as long as the system always uses the same joystick order (js0, js1) as when you originally set them in the GUI. As I check this in KControl or the dev folder at least once after a computer startup before playing any game that uses my gamepads that'll always be correct.

The jscalibrator stuff has been known to actually interfere with correct gamepad calibration. Some folks don't get things working properly until they uninstall that thing.

[Tillin9]

Another minor bug report. I'm been playing around with making a native Qt GUI,

http://sknauert.web.wesleyan.edu/qtgui.png

And noticed that the accelerator keys in our GTK interface don't work. Since we're creating them with menu_item_new_with_accelerator() I'm assuming we want accelerators.

Also, we don't seem to use any icon or hotkey convention. I'm not sure if there is a Gnome convention, but the GTK GUI should use it. I linked the icon paths to in my GUI so that they're now themable with the rest of the KDE / Qt apps.

Finally, and the reason for Kwrite to be open in the picture is I'm hitting a snag with the toolbar. I'd like the toolbar to be like the Kwrite toolbar, i.e. extend the length of the window and to have icons the same size. My icons are too small and not adjustable (there's a right-click menu which lets you make the icons bigger in Kwrite). This may be a Qt / KDE issue. Was wondering if anyone here knew the answer.

[ebenblues]

I'm been playing around with making a native Qt GUI,
The Qt gui looks good so far. Thanks for working on it! Are you working with the latest svn code? I just want to make sure you're working with the code after I did the gui/nogui merge because a lot has changed. If you're working with code before the merge, then you may be doing more work than you need to. I pulled a lot of non-gui-specific code out of the gui_gtk dir and put it into the main/ dir for use by any gui, e.g. language translation functions and functions to read/write the mupen64.conf file. Most of the changes are summarized in this thread (http://www.emutalk.net/showthread.php?t=43391). If you have questions, PM me and I can give you more details.

[Tillin9]

I have the latest svn. I waited to begin in earnest till after your merge. I also will wait for multiuser and probably the next release before thinking about a real branch / merge for a Qt GUI.

Right now I'm working on just getting the widgets right, and this toolbar is a bit of an issue. There's little point in a Qt GUI if it looks worse than the GTK one with the Qt-GTK theme engine applied (nearly every person running KDE has the GTK libraries anyway) as right now both GUIs are functionally identical.

I'm not sure how GTK development works, but much of Qt is using Qt Designer. Basically making the GUI .ui files, actions, and signals and slots. The GUI above is a preview from the designer (sorry if it seemed that I was further along), so right now while the GUI is somewhat complete, compiles and GUI things like accelerators and hotkeys work, no real emulation functions are registered. Actually plugging the GUI into the emulator is the easy part. ;)

I eventually plan on a gui_qt dir to parallel your gui_gtk one, and a flag to pick which GUI to build.

My biggest question is how should we handle the plugin GUIs. Our plugin_exec_x() way of calling plugin registered functions leaves a lot to be desired. Not only do most plugins not have an About or Test, so instead of a default "Not yet implemented box." we get nothing, but it means there is only one GUI for the plugin. Right now if I was to make my Qt GUI, Rice and Glide would still have GTK configs, and Blight's is SDL. This is not ideal. A more extensible plugin API is needed. Ideally plugins should also not depend on GTK / Qt / SDL #defines either, meaning one could use binary plugins with either a GUI or non-GUI build. Sadly this is some major work.

[Surkow]

[...] Right now if I was to make my Qt GUI, Rice and Glide would still have GTK configs, and Blight's is SDL. This is not ideal. A more extensible plugin API is needed. Ideally plugins should also not depend on GTK / Qt / SDL #defines either, meaning one could use binary plugins with either a GUI or non-GUI build. Sadly this is some major work.
Most of my input issues had to do with Blights input plugin SDL configuration screen. So it would be most welcome if a Qt GUI could be created for it.

[ebenblues]

I'm not sure how GTK development works, but much of Qt is using Qt Designer. Basically making the GUI .ui files, actions, and signals and slots. The GUI above is a preview from the designer (sorry if it seemed that I was further along), so right now while the GUI is somewhat complete, compiles and GUI things like accelerators and hotkeys work, no real emulation functions are registered. Actually plugging the GUI into the emulator is the easy part. ;)

I eventually plan on a gui_qt dir to parallel your gui_gtk one, and a flag to pick which GUI to build.
I think that's the most logical way to do it, and I would suggest including the special files used by Qt Designer in the gui_qt folder (maybe in a subdir). Judging by the code I've looked at, the GTK gui was all written by hand.

My biggest question is how should we handle the plugin GUIs.
<snip>
Ideally plugins should also not depend on GTK / Qt / SDL #defines either, meaning one could use binary plugins with either a GUI or non-GUI build. Sadly this is some major work.
I agree that there are issues with each plugin having to implement its own gui. I don't see a simple, extensible solution to this that's worth all the effort it would take. We may just have to go the route of implementing separate gui's for each plugin that we package with mupen64plus and pass an option to the top-level Makefile determining which gui to build. I know this isn't great, and I'm open to better ideas. :(

Most of my input issues had to do with Blights input plugin SDL configuration screen. So it would be most welcome if a Qt GUI could be created for it.
I'm glad to hear a request for this as I was planning to rework the blight input configuration gui to use GTK (and not 80% of the CPU ;)). I'm going to try to preserve the controller diagram, but add nice things like real checkboxes and enhance the plugin so you can also map higher level functions like exit, fullscreen, statesave, etc to controller buttons. Obviously this won't happen before the upcoming release of mupen64plus, but I'm shooting for getting that into the following release.

[Tillin9]

I agree that there are issues with each plugin having to implement its own gui. I don't see a simple, extensible solution to this that's worth all the effort it would take. <snip>I know this isn't great, and I'm open to better ideas. :(
I'm thinking the easiest thing is to change the API slightly. Mandate that the plugin register more GUI info, like which GUI options it has callbacks for, which toolkit they use, and pointers to them. The main program can then pick the best one, or if there is none, push a standard "Not implemented" dialogue. The current, search the plugin for the handle at runtime leaves a bit to be desired.

I'm going to try to preserve the controller diagram, but add nice things like real checkboxes and enhance the plugin so you can also map higher level functions like exit, fullscreen, statesave, etc to controller buttons.

This should help in getting out the pad data:
SDL_SaveBMP (SDL_Surface *surface, const char *file);

Hopefully this implement's .bmp's alpha properly. I'll use krita to change it into an svg (what Qt likes). You should be able to do the same to get something for GTK.

I guess I'll also tackle Rice's while I'm at it. It seems a big pain to made multi-tabbed GUIs in GTK by hand, which is why I guess we have one big panel. The Rice for Project64 has a much better interface (some more options which may or may not apply, yet - I haven't checked) which shouldn't be too hard to reconstruct via Qt.

[ebenblues]

This should help in getting out the pad data:
SDL_SaveBMP (SDL_Surface *surface, const char *file);
Thanks for the tip. I was able to extract the image to a bmp. The alpha channels didn't work properly, but I used the GIMP to manually remove the background. Here's the image converted to a png in case anyone else ever needs it:

http://i256.photobucket.com/albums/hh171/ebenblues/pad_image.png

[ebenblues]

I'm thinking the easiest thing is to change the API slightly. Mandate that the plugin register more GUI info, like which GUI options it has callbacks for, which toolkit they use, and pointers to them. The main program can then pick the best one, or if there is none, push a standard "Not implemented" dialogue. The current, search the plugin for the handle at runtime leaves a bit to be desired.
For the gui options (I assume you're talking about config/test/about), a simpler implementation that doesn't require changing the API would be to just remove the DllConfig/DllTest/DllAbout function definitions from any plugins where the functions are currently just stubs. Then the mupen64 code will know which ones are supported based on whether the function is there or not.

I like the idea of adding GUI toolkit info to the API though. Maybe we can modify the plugin info struct to provide a predefined bitfield indicating which GUI toolkits are supported. Then we can add an API call to set which toolkit the plugin should use.

[sl1pkn07]

i have little problems with SDL

/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libpng.so when searching for -lpng
/usr/bin/ld: skipping incompatible /usr/lib/libpng.a when searching for -lpng
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.a when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libSDL.a when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.a when searching for -lSDL
/usr/bin/ld: cannot find -lSDL

but all libsdl installed

http://sl1pkn07.no-ip.com/imagenes/libsdl.png
http://sl1pkn07.no-ip.com/imagenes/libsdl2.png

greetings

[Richard42]

i have little problems with SDL

/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libpng.so when searching for -lpng
/usr/bin/ld: skipping incompatible /usr/lib/libpng.a when searching for -lpng
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.a when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libSDL.a when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.so when searching for -lSDL
/usr/bin/ld: skipping incompatible /usr/lib/libSDL.a when searching for -lSDL
/usr/bin/ld: cannot find -lSDL

greetings

Looks like you're trying to build a 32-bit version of Mupen64 but only have the 64-bit development libraries installed, or vice versa.

[sl1pkn07]

aaa. sorry ><. im using "all" flag.

works with "bin-64" flag

(make VER=1.1.svn.254 bin-64 PREFIX=/usr)

EDIT: yes i have install SDL 32bits:

sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn$ ls /usr/lib32/libSDL*
/usr/lib32/libSDL-1.2.so.0
/usr/lib32/libSDL-1.2.so.0.11.0
/usr/lib32/libSDL_mixer-1.2.so.0
/usr/lib32/libSDL_mixer-1.2.so.0.2.4
/usr/lib32/libSDL_ttf-2.0.so.0
/usr/lib32/libSDL_ttf-2.0.so.0.6.3
/usr/lib32/libSDL_net-1.2.so.0
/usr/lib32/libSDL_net-1.2.so.0.0.5
sl1pkn07@SpinFlo:~/aplicaciones/mupen64-64bits-svn

[Richard42]

aaa. sorry ><. im using "all" flag.

works with "bin-64" flag

(make VER=1.1.svn.254 bin-64 PREFIX=/usr)


Actually this is deprecated now. You should check out and build the Mupen64Plus project instead. Our new home page is:

http://code.google.com/p/mupen64plus/

[sl1pkn07]

oks. i see this project in another thread (i have problems with Yasm (now solved))

thanks a lot

greetings

[Tillin9]

While I wasn't able to get much coding done, here's my new controller image:
http://sknauert.web.wesleyan.edu/controller.png
for use in the Gtk GUI. I'm planning on making the KDE GUI for blight, but if someone else has more free time and wants to do it now, feel free.

Also, feel free to give me comments on how it can be improved. I think its 95% there, but still needs a little more tweaking to be perfect. I also need to make the arrow overlays. (which will be a seperate graphic)

P.S. It seems the shadow on the bottom got cut off somewhere. This can be fixed by copying from one of the other curved and streching slightly. Sorry.

[Surkow]

It looks quite nice. But what about the triggers at the top of the controller?