New release: Mupen64-amd64 and RiceVideoLinux versions 1.0

[Richard42]

Yeah you have to edit the config file by hand. I looked at the blight input code; it looks like it's straight SDL and as such should be compatible, so the fix for the config dialog should be easy. If you want to use keyboard input (instead of joystick) then you must set the key=xxx values in the blight_input.conf file according to the SDL keysym values. I have attached a copy of the header file to this message - it contains a list of the keys and their corresponding values.

 

[nmn]

Actually, I've had Blight's configuration work fine in Mupen64, after a make clean, make... Not all that sure why, but it did after a make clean and make op.

And Rice Video config always worked for me..

edit: Nvm, it works no longer. I swear it though, it did infact work for me one time in 64-bit.

edit once more: Okay, i submitted a patch that should fix the problems for good.

 

[Surkow]

Do you guys know the reason for some games like ssb not starting? I noticed a lot of graphical fixes but the rice plugins now supports less games than before.

This is the error in the terminal:

Signal number 11 caught:
        errno = 0 (Gelukt)

 

[nmn]

Hmm... Are you on interpreter CPU?

 

[Surkow]

Hmm... Are you on interpreter CPU?

Nope, Dynamic recompiler.

 

[nmn]

...

Okay, well, just to reinstate it, There is infact no DynaRec in the 64-bit version and you must use Interpreter or Pure Interpreter until it is fully ported. Unless that is you want to make a 32-bit build, where it shouldn't have a problem, but if it does, try interpreter just to see.

 

[Surkow]

...

Okay, well, just to reinstate it, There is infact no DynaRec in the 64-bit version and you must use Interpreter or Pure Interpreter until it is fully ported. Unless that is you want to make a 32-bit build, where it shouldn't have a problem, but if it does, try interpreter just to see.

I'm using the 32bit version and both interpreter options do not make a difference. Also it doesn't matter what gfx plugin I'm using.

 

[nmn]

Okay, You've got me stumped. A signal 11 you say... hmm.... uhh... So its not a segfault.

Can you give us the full specs? Distro, CPU, GFX card, etc.

 

[Richard42]

I'm using the 32bit version and both interpreter options do not make a difference. Also it doesn't matter what gfx plugin I'm using.

Thanks for reporting the bug. I ran it in a debugger and duplicated the segfault. It is caused by an fwrite() command in the DMA code without checking to make sure the file opened properly. I've fixed it in SVN, but I think you can avoid it by making sure that the directories that hold the mupen64 and plugins are readable,writable,and executable for your user. If you can't get it to work and really wanna play SSB (it is fun) I'll post or email a binary.

Edit: oops I spoke too soon. I found several more instances of this bug at other places in the code and fixed them as well, and added some error logging to help understand what was happening. As it turns out, you need to create a directory called 'save' in the folder with the mupen64 binary. Then the file write will not fail and it won't crash. I bet this fixes a lot of games.

 

[Surkow]

@Richard - adding a save directory indeed solved the problem.

I'm really happy you guys are working on it this. I wonder if Hacktarux noticed and decided not to be involved? Since he doesn't post here. He also said he was working on a new cheat system. If he would release a new version of mupen he should integrate all things you guys have done so far.

 

[nmn]

Well, If he decides not to integrate our work in future versions, i guess i wouldn't be surprised, but the project here will definitally not stop. Rightfully, we can continue, and should be able to, this project, with no problems, as a branch of Mupen64 that has a different focus than that of the official Mupen64. Oh, and if you want cheats, i don't think that would be insane to implement. Is that something people want to have?

 

[Surkow]

Well, If he decides not to integrate our work in future versions, i guess i wouldn't be surprised, but the project here will definitally not stop. Rightfully, we can continue, and should be able to, this project, with no problems, as a branch of Mupen64 that has a different focus than that of the official Mupen64. Oh, and if you want cheats, i don't think that would be insane to implement. Is that something people want to have?

Yes, it's a wanted feature. But I suggest asking Hacktarux for more info because he already did some work on it.

Another thing I like to have is an option to remove the limit from the number of fps to speed up unwanted things (for example loading times, the intro of Ocarina of time etc). If I remember it correctly 1964 has an option like this where you only need to press a button to toggle between limit and not limit the number of fps.

 

[Richard42]

I would be surprised if Hacktarux started working on Mupen64 again and started from the vanilla 0.5 build, for a couple of reasons. One is that what we've done isn't so much a branch as it is a continuation from where he left off in 2005. In addition to the 64-bit port, we've fixed a whole bunch of problems that were keeping people from using this emulator. The second is that we have an SVN server setup and running. It's unreasonable to write software in this day without source control; even on my personal projects where I'm the only one making changes, I keep them on my SVN server because it offers so many advantages.

Regarding your feature requests, I'll put them in the TODO file. I have used the cheat mechanism in XMESS, which is fairly simple but works well. It's not a technically difficult thing to implement but it would take quite a bit of code and testing to do it right. The speed of the emulator is gated by the sound; if you use the dummyaudio.so plugin it will run as fast as possible. It should be fairly easy to be able to switch sound on/off while the emulator is running and thereby speed it up.

 

[MasterPhW]

I wonder, if the source changes for x86-64 linux could be also used for a native X64 windows binary, because it would be really great to have a native X64 windows N64 emu.

 

[Richard42]

I wonder, if the source changes for x86-64 linux could be also used for a native X64 windows binary, because it would be really great to have a native X64 windows N64 emu.

Somebody who was motivated could make this work on Win-64 but the changes are non-trivial. The inline Intel-style assembly would have to be ported. And I just checked the data model, and the types also need to change. With the Visual Studio 64-bit compiler, 'long' is still 32-bit rather than 64 (probably for ease of porting, since all the old-skool C programmers used long for everything, when they shouldn't have) so a few changes would need to be made there. It wouldn't be a huge amount of work but unfortunately the payoff would be very little. Not only would the Dynamic Recompiler no longer work, but MS chose a really shitty 64-bit ABI (application binary interface), again probably for ease of porting, so instead of getting the nice 15% performance gain that you can expect when porting a straight-C unix app to 64-bits, you'd get a much smaller gain.

 

[Hacktarux]

Yea, i've done some work on the emulator and i have some huge patch review to do before releasing a new version. I'm trying to review all patches carefully before accepting them. And as i couldn't work on the emulator at all during one year, i'm a bit late late. Since you're using svn, it won't be hard to trace your changes and i'll be able to merge your changes.

I can't force you but i would like to ask you to not do anything on cheats. I'm working on it and the way i'm doing it is a bit insane to implement Well, not that much but it definitevely takes more time than a simple gs cheat implementation. Basically, it will be a new way to handle cheats and will include features to help hacking games and debugging emulators and/or homebrew programs. The original plan was to release it before christmas but i think i'm a bit late on schedule now. I'll do my best to have it working as fast as possible. If you're interested, i may ask for development help when i'll have finished writing the specs. Additionnaly, i think there will be a huge amount of possible extensions. The only thing i'm worried about is the number of people interested in fully exploiting it.

 

[Surkow]

..

Regarding your feature requests, I'll put them in the TODO file. I have used the cheat mechanism in XMESS, which is fairly simple but works well. It's not a technically difficult thing to implement but it would take quite a bit of code and testing to do it right. The speed of the emulator is gated by the sound; if you use the dummyaudio.so plugin it will run as fast as possible. It should be fairly easy to be able to switch sound on/off while the emulator is running and thereby speed it up.

I'm happy Hacktarux is still working on the cheat system. So that is something you don't have to worry about.

About the sound...is it also possible to speed things up when leaving the sound plugin on? If the speed of the emulator is gated by the sound wouldn't the fps increase if you would speed up the sound?

 

[MasterPhW]

Yea, i've done some work on the emulator and i have some huge patch review to do before releasing a new version. I'm trying to review all patches carefully before accepting them. And as i couldn't work on the emulator at all during one year, i'm a bit late late. Since you're using svn, it won't be hard to trace your changes and i'll be able to merge your changes.

I can't force you but i would like to ask you to not do anything on cheats. I'm working on it and the way i'm doing it is a bit insane to implement Well, not that much but it definitevely takes more time than a simple gs cheat implementation. Basically, it will be a new way to handle cheats and will include features to help hacking games and debugging emulators and/or homebrew programs. The original plan was to release it before christmas but i think i'm a bit late on schedule now. I'll do my best to have it working as fast as possible. If you're interested, i may ask for development help when i'll have finished writing the specs. Additionnaly, i think there will be a huge amount of possible extensions. The only thing i'm worried about is the number of people interested in fully exploiting it.

Nice to hear! I really would like to see a new version of mupen.
BTW: did you think about some of the Mupen64k and Mupen+ ´patches?

 

[Richard42]

@Hacktarux: We'll leave the cheat system to you, since it sounds like you have a grand vision for it. My primary motivation for working on Mupen64 is to get more games working and playable with no graphical bugs/glitches.

@Surkow: It is possible to speed up the game without disabling the sound, but it's much more technically difficult to do this, especially if you want it to sound halfway decent. Someone who was competent in DSP could even add processing to keep the same pitch at the higher speed, but it would be quite a bit of work.

@MasterPhW: I didn't even know about the Mupen64k and Mupen+ projects. It looks like the Mupen64k guys have made quite a few changes; maybe if I have time this weekend I'll look through their repository or source to see if they've made any fixes that I can take.

 

[nmn]

Okay, i won't be touching cheats.

Now, for netplay, Mupen64k appears to be implemented into the Windows codebase already, So if i could just get enough time to start porting all of that to a better library that is multiplatform, i'm sure i could have it up and atleast running (albeit working) fairly quickly.

edit: Okay, so Kaillera may not be in the main codebase i'm not entirely sure. If anything, we should dump kaillera. As for Mupen+, i'll be looking for that and i'll see what i can implement right now.