Mupen64-amd64 and RiceVideoLinux v1.1 is here

[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]

mupen64_nogui LIRC support

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.

--- 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 *drools*

 

[DarkJezter]

LIRC Patch - Thread Safety

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.