What's new

Mupen 64bit

Richard42

Emulator Developer
I do agree that we should improve the emulator. I haven't yet tested my SVN server from outside my home network so I'm not 100% sure that the port forwarding is working, but once it's set up right this will give us a practical way of working together.

I'm using mupen64 as part of a larger video game museum that I'm building; as a part of this project I have my own GUI written in python with pygame. So I'm really only interested in the 'nogui' build of mupen64 and its integration into this system. You're welcome to commit GUI improvements to the repository, however. If you want to make big changes that may break people's builds or take time to stabilize, we can make a branch to work on until it's ready to go back into the trunk. Most of the work that I plan to do will be fixing little bugs/annoyances and hunting down the remaining porting bugs. Maybe I'll do the dynamic recompiler some day too, because that's cool technology.

The best pattern that I've found for dealing with data types in a cross-platform way is to have a system/typedef header file where you define custom types like 'Int'/'Short'/'Char', or 'u32'/'s32'/'u64'/'s64'/etc. And then replace _all_ of the standard C/C++ types with the custom types in the code. This might be a worthwhile thing to do for mupen64, but it will be tedious. You would have to define a special Int-which-is-the-same-size-as-a-pointer type, in order to handle the code which does XOR on pointers for byte swapping. The only issue I see with applying this type handling to mupen64 is the plugins. It wouldn't be very clean to just copy this header file into all of the plugin sub-projects. To do it right would require having some common header file(s) which are shared between mupen64 and the plugin projects.

Richard
 

MIO0

New member
There is a standard header file (stdint.h) that contains typedefs for fixed sized integers, and even a typedef for an integer that is the same size as a pointer. I used it to make myself a 64 bit copy of Mupen, but it really isn't suitable for release as I ripped out the recompiler.

My local 64 bit copy of glN64 works well. I'll see if I can get it working with the SVN code, but I have another project I need to finish first.
 

Richard42

Emulator Developer
There is a standard header file (stdint.h) that contains typedefs for fixed sized integers, and even a typedef for an integer that is the same size as a pointer. I used it to make myself a 64 bit copy of Mupen, but it really isn't suitable for release as I ripped out the recompiler.

My local 64 bit copy of glN64 works well. I'll see if I can get it working with the SVN code, but I have another project I need to finish first.

Using stdint.h would be a good solution too. We could include that and replace all of the 'long long's with int64_t; that wouldn't be too hard.

It would be great if you could help with the glN64 plugin. It works okay but exhibits the texture problem which was illustrated earlier in this thread.
 

Richard42

Emulator Developer
Is yalls port of rice's plugin a port of hackatrix's port, or the latest version of rice?

This port was based on the Linux source which Hacktarux ported from Rice v6.1.0. A couple of days ago I looked through all of the SVN commit logs between v6.1.0 and now on Mudlord's SVN server, and it looks like there have only been a few changes in-between then and now. Later this week I may merge these changes into our 64-bit port.
 
OP
N

nmn

Mupen64Plus Dev.
!!!ABOUT THE GLN64 PLUGIN PROBLEMS!!!

They are GCC induced. The updates to GCC made it incompatible. Well, Okay, I think. When compiling to 32-bit with my old code it had the same problems.
 
OP
N

nmn

Mupen64Plus Dev.
Leaving the note, my GCC is broken and therfore it may be a while before i commit anything... sry.
 

Richard42

Emulator Developer
!!!ABOUT THE GLN64 PLUGIN PROBLEMS!!!

They are GCC induced. The updates to GCC made it incompatible. Well, Okay, I think. When compiling to 32-bit with my old code it had the same problems.

I compiled a 32-bit build (mupen64 v0.5) with GCC 4.1.2 (64-bit binary, cross-compiling) on my HTPC box with Fedora 8 test 3, and it does not exhibit this problem. The 64-bit port I did on my desktop box which is Gentoo, also using GCC 4.1.2, and the port exhibited the problem.

Does anybody know the differences between glN64 and RiceVideo? I think I should focus my work on one of the other. It seems to me like glN64 actually looks a bit better (no gaps between polygons in mario's face at startup, for instance). Are either of these plugins compatible with more games than the other? That's the most important factor for me.
 

Danny

Programmer | Moderator
I compiled a 32-bit build (mupen64 v0.5) with GCC 4.1.2 (64-bit binary, cross-compiling) on my HTPC box with Fedora 8 test 3, and it does not exhibit this problem. The 64-bit port I did on my desktop box which is Gentoo, also using GCC 4.1.2, and the port exhibited the problem.

Does anybody know the differences between glN64 and RiceVideo? I think I should focus my work on one of the other. It seems to me like glN64 actually looks a bit better (no gaps between polygons in mario's face at startup, for instance). Are either of these plugins compatible with more games than the other? That's the most important factor for me.

Rice would be the most compatible imo.
 

kdubya

New member
I like rice because it allows you to specify any resolution you want, and the way I have my HTPC set up there is no way to use any resolution other than my screwy one of 1240x702 without going into nvidia-settings. It also does high resolution texture packs, which are awesome.

Problem is mario kart flickers under rice and not glN64. A man has to have his mario kart. This was why I asked if you used the same version of rice as Hacktarix, I think the flickering is caused by some frame buffering issues in older versions of rice.
 
OP
N

nmn

Mupen64Plus Dev.
I haven't read to see if theres more to this convo on page 3, but the flicker bug may be fixable in various ways* (I experienced the same problem in various intros, Mario at some points, and Kirby64 during cinematics or decently heavy loads of polygons, even with 1964 under Wine with Rice)

In nvidia-settings:
- Try turning Vsync on and off. Yeah, I'm not kidding the least bit. You wouldn't even believe how sometimes this fixes the worst of problems.

In Rice:
- Try setting the pergame settings around - for some reason i could get certain games to not flicker 0_o
- In 1964 changing the counter factor worked for getting Wine to not flicker with Rice Video. (Interestingly, this leaves me to believe the flicker is a GLX or NVidia driver bug) Theres an equiv sitting somewhere in Mupen or Rice, i believe, but if not, you can probably find something similar enough.

*This list is definitely very incomplete.

--
-About the glN64 problems:

Maybe 64-bit induced. Not sure anymore. I need to get a new compiler, and well, I'm on Gentoo, so upgrading GCC means i need GCC which means I'm SOL. But I've ruined this installation enough, time to test another distros length of life.

-About Rice vs glN64:

Rice wins in compatibility by a long shot (Well, at least I'm pretty sure at least for frame buffer effects if nothing else) glN64 seems to get some things that Rice doesn't (which genuinely took me by surprise) but i don't remember it actually surpassing it at any point. I was especially surprised by some of the effects it understood which were likely not well written ones (on the game developers part)

And I'm downloading a new distro to handle my GCC problems. I'll try to port the GUI to Qt4, improve the makefile a bit, and have some new features in (Perhaps a special version of the graphics plugin API that calls special emulator functions to handle the GL context, leaving us the ability to have graphics appear in the emulator GUI in Mupen64 for Linux, something that would normally be a major problem to do.)
 
Last edited:

i23098

New member
amd64 build

Hi,

Is there a chance to provide a amd64 compiled build, so I could just untar/unrar/unzip :freak: and execute it? :huh: :saint:

For some reason I can't compile the source code :cry: :stupid:

Can't wait for 0.6 official release :party:

Keep up the great work :D
 

Richard42

Emulator Developer
No worries i23098,

I'm going to make a tag hopefully in the next week or so with a bunch of fixes and I'll provide 32-bit and 64-bit binary packages as well as the source. I fixed a crash in Rice Video for Carmaggedon tonight. The full-screen textures look weird but the game is playable now.

Richard
 

sl1pkn07

New member
i have a problem with RiceVideo-6.10-64bits

[email protected]:~/aplicaciones/mupen64-64bits-svn/ricevideo610-64bit$ ./configure
Found a working C compiler (gcc).
Found a working C++ compiler (g++).
Checking SDL...
./config.temp: 3: Syntax error: "(" unexpected
*** Couldn't find a working SDL library!
[email protected]:~/aplicaciones/mupen64-64bits-svn/ricevideo610-64bit$

i have all SDL library installed. im used kubuntu 7.10 Gutsy 64Bits
 

Richard42

Emulator Developer
i have a problem with RiceVideo-6.10-64bits

Checking SDL...
./config.temp: 3: Syntax error: "(" unexpected
*** Couldn't find a working SDL library!
[email protected]:~/aplicaciones/mupen64-64bits-svn/ricevideo610-64bit$

i have all SDL library installed. im used kubuntu 7.10 Gutsy 64Bits

This is another example of the configure file not failing gracefully. Your problems is that you also need to have the SDL development packages in order to compile the application. This contains the header files. You'll also need the GTK development packages while you're at it.
 

sl1pkn07

New member
o rly? XD

sdl.png
 
Last edited:

Richard42

Emulator Developer
Okay, so it looks like you have the dev packages. If there is a real issue with the path to the SDL header files you could get more debugging information by doing an "sdl-config --cflags" and looking at the config.log file. But if it's just that the configure script is broken because it does weird shit like compiling an executable into the same file as the source that it came from, then this would be a waste of time.

I would just ignore the 'configure' file - it's hosed and you don't need it anyway. Extract the 'config.h' file from the original archive to make sure that it didn't get overwritten and just run 'make'. If the build breaks on SDL_Init() or other SDL functions then you'll know that your system has an actual problem.
 

Richard42

Emulator Developer
o rly? XD

One more thing to watch out for: I'm not sure about Ubuntu 7.10, but in the Fedora repository there are separate <tool>-devel packages for 32-bit and 64-bit development. For some tools they cannot be installed at the same time, so you have to make sure you have the right one installed.

It looks like what's happening for you is that the compile is failing and the test source code is being marked executable and running as a script, and the shell interpreter is throwing that 'Syntax error: "(" unexpected' error. The config.log file should tell you why it failed to compile.
 

kdubya

New member
I finally got around to compiling this...

Mupen compiled with no effort, installed it and it works perfectly.

I had some trouble getting the rice plugin to compile at first but it was just that the configure script does not detect the gtk2 development packages if you are in a remote shell. It worked fine when I was actually on the machine.

Once I got rice compiled... I cannot get rice to work at all for about 75% of the games I tried (probably tried about 30 of them). Most games just segfault immediately. For the few that actually do something, I was only able to play 2 of them, Excite Bike and some other random racing game. Some games would show the company logos and then segfault right before the main menu and others would die when I tried to start gameplay. Nothing interesting was output.

Are there any debugging flags I could use so I could provide you with something useful? I am running 32 bit Fedora 7, and I am using the nvidia drivers from the livna repos
 

Top