Mupen64-amd64 and RiceVideoLinux v1.1 is here

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

*Sigh* So much for an elegant patch

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%

 

[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)
[B]    SDL_GL_SetAttribute( SDL_GL_SWAP_CONTROL, 1);   // only swap buffers on vertical sync[/B]
#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]

White screen with Rice plugin

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.