I've committed a few changes/fixes to the SVN repository. I fixed the printout of the plugins selected, and did some work on the plugin selection code. I changed the name of the #define in the config.h file and added some comments and removed a few small bugs from the code in main.c and gtk_main.c. I would still like to refactor it some more to be more user friendly.
I learned how the config/makefile setup for mupen64 actually works in Linux; I don't think it's documented anywhere and it was very confusing for me. I didn't really catch all of the details until I had gone through the code closely. When you run the configure program, it asks you if you want to "configure mupen64 to run in a user directory". If you answer 'yes' to this, then the emulator will be built so that it will look for a mupen64.conf file and 'plugins' folder in the same folder as the executable. However, if you answer 'no' to this question, it will build the emulator differently. In this case you have to run 'make install' and it will put all of the binaries and config files in a place like '/usr/local/mupen64'. And when the emulator runs, it will search for the config files in a hidden folder '.mupen64' off of your home directory. If it doesn't find the config files in your home, it will copy them from the /usr/local/... folder and make symbolic links to the libraries, then run out of your home directory. I'm sure this will be useful to somebody.
I also found the texture bug in the 64-bit build of the glN64 plugin. There is some sort of texture caching mechanism in Textures.cpp; I assume that it's to save the overhead of color conversion and opengl memory allocation; probably textures are reused very often. There's a loop which searches the list of cached textures to see if one matches the texture which is currently being loaded by the RDP code. For some reason the CRC check in the test statement was commented out, so the routine returned the first texture which matched the parameters for resolution, format, etc. That's why it looked like "PPPPP" - all of the letters had the same size and since the letter P was first, and thus at the top of the stack, it was always returned. Now the games look great! I played through a few races and mario 64 levels tonight.
I learned how the config/makefile setup for mupen64 actually works in Linux; I don't think it's documented anywhere and it was very confusing for me. I didn't really catch all of the details until I had gone through the code closely. When you run the configure program, it asks you if you want to "configure mupen64 to run in a user directory". If you answer 'yes' to this, then the emulator will be built so that it will look for a mupen64.conf file and 'plugins' folder in the same folder as the executable. However, if you answer 'no' to this question, it will build the emulator differently. In this case you have to run 'make install' and it will put all of the binaries and config files in a place like '/usr/local/mupen64'. And when the emulator runs, it will search for the config files in a hidden folder '.mupen64' off of your home directory. If it doesn't find the config files in your home, it will copy them from the /usr/local/... folder and make symbolic links to the libraries, then run out of your home directory. I'm sure this will be useful to somebody.
I also found the texture bug in the 64-bit build of the glN64 plugin. There is some sort of texture caching mechanism in Textures.cpp; I assume that it's to save the overhead of color conversion and opengl memory allocation; probably textures are reused very often. There's a loop which searches the list of cached textures to see if one matches the texture which is currently being loaded by the RDP code. For some reason the CRC check in the test statement was commented out, so the routine returned the first texture which matched the parameters for resolution, format, etc. That's why it looked like "PPPPP" - all of the letters had the same size and since the letter P was first, and thus at the top of the stack, it was always returned. Now the games look great! I played through a few races and mario 64 levels tonight.
