[$threadinfo[title]]

[Richard42]

Well finally, after a lot of work, here it is. A new release, with both 32-bit and 64-bit binaries and source, of the Mupen64-amd64 and RiceVideoLinux projects. Even with all the bugs and imperfections remaining, I christen it Version 1.0. :)

Please play with it, have fun, and report problems and crashes here on the forum. If you get a segfault, report your system details, what plugins were in use, the game you were playing, and what you were doing when it crashed. The RELEASE files have detailed information on the changes that have been made, but here are some of the things you might be interested in:

Highlights:
- Both 32-bit and 64-bit binaries compiled for GTK 2
- Dynamic recompiler works for 32-bit build, without tweaking the binary
- Binary packages include both Mupen64-amd64 and RiceVideoLinux
- Source packages can make 32-bit builds on 64-bit machines with makefile switch
- RiceVideo uses SSE2 transformation calculations for 32-bit and 64-bit architectures. Disable SSE in RiceVideoLinux.cfg if your CPU doesn't support it.

Game fixes:
- Fixed Carmageddon crash with RiceVideo
- Fixed Banjo Kazooie crash in RiceVideo
- Fixed screen flashes in Mario Kart and Kirby 64; they look great now
- Fixed decal problems in Super Mario 64; also looks great

NoGUI improvements:
- run a game just by ./mupen64_nogui /path/to/game.z64
- use --emumode 2 to run dynamic recompiler for 32-bit build; it works!
- use --gfx <path>, --rsp <path>, or --audio <path> to select different plugins
- like: --audio ./plugins/dummyaudio.so

[Toasty]

Awesome! I'll have to install 64-bit Ubuntu and give it a whirl!

[kdubya]

Its late but i thought i would give it a whirl real quick.

I did an svn update, I assume this gets me the same version you got here.

Tested about 7 or 8 games, across the board worked better than with the old version. No flickers in Mario Kart, THANK YOU. Mario tennis and golf had flicker type problems that were improved with this version. A lot of games that use tons of large sprites (NBA Hangtime) were slloooow and unplayable, now they run perfect and look freaking awesome with the texture enhancements.

The two obvious bugs I have found...
-I seg fault if I put a nonstandard resolution into the .cfg file. Would be fine but there are not widescreen choices.
-I seg fault if I turn on high resolution texture packs.

Thanks a lot man its awesome!

[agentdcooper]

Richard42 - I am running into some trouble trying out your files you posted - specifically I cannot UNZIP them.... The files "Mupen64amd64-RiceVideoLinux-1-0-bin-64.zip" and "RiceVideoLinux-1-0-src.zip" seem to work fine, but I am having trouble with ;
"Mupen64-amd64-1-0-src.zip"
"Mupen64amd64-RiceVideoLinux-1-0-bin-32.zip"

I just can't get them to open/extract without error... any ideas/suggestions? I am really looking forward to trying out your release!

;; here's the errors Im getting and the version of the program I am running to open//extract ;;

I tried Winrar [via Wine] - this gave the error "! Unexpected end of archive"
I tried Ark v2.6.4 - which gave the error "An error occurred while trying to open the archive"

> unzip --help
UnZip 5.52 of 28 February 2005, by Info-ZIP. Maintained by C. Spieler. Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.


> unzip ../Mupen64-amd64-1-0-src.zip
Archive: ../Mupen64-amd64-1-0-src.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of ../Mupen64-amd64-1-0-src.zip or
../Mupen64-amd64-1-0-src.zip.zip, and cannot find ../Mupen64-amd64-1-0-src.zip.ZIP, period.


-= PS =- Congrats on all your hard work, I am very grateful, and look forward to testing it out!

[Surkow]

Specification:
32bit Ubuntu Gutsy Gibbon.

In other words I tried the 32bit binary version.

When trying to open the config from Rice a small window without text appears and the terminal shows the following output several times:

Gtk-WARNING **: invalid cast from `(unknown)' to `(unknown)'

(mupen64:6860): Gtk-CRITICAL **: gtk_entry_set_text: assertion `GTK_IS_ENTRY (entry)' failed

When I click on about the program is killed and the terminal tell me it suffers from a segmentation problem.

Segmentatiefout (core dumped)

edit: I just tried SM64 and it the cut scenes looked great (couldn't play because I couldn't configure the input plugin because it kills the program). The only weird thing I noticed was that it looked like as if mario was glowing.

[Richard42]

@kdubya:

SVN update was the right thing to do - I fixed a lot of small issues at the last minute, and I also made a top-level 'releases' folder in the repository and put the zip files there. I haven't tried Mario golf or tennis yet. I'll put the 2 segfalts you mentioned on the TODO list.

@agentdcooper:

I have the same version of unzip (5.52) and it unzips those two files without a problem. I suspect it's a downloading issue. The Mupen64-amd64 source file should be 2371876 bytes long, and the 32-bit binary pack should be 1686074 bytes. Try doing an 'md5sum *' from the command-line, and here is what you should get for those 2 files:

c919b66278ed605f57e7ac25c74bb651 Mupen64-amd64-1-0-src.zip
7307b39c2e3e2affdc84ba7b50fa374b Mupen64amd64-RiceVideoLinux-1-0-bin-32.zip

If these hashes are not the same then your downloaded files are corrupt. You could try downloading with a different web browser, or right-click and Save As rather than left-click the links. Sometimes things get downloaded as text rather than binary.

@surkow:

I haven't tested the GUI extensively with either the 32-bit or 64-bit builds. It looks like you found a couple of things to add to the TODO list. You can edit the 'blight_input.conf' file by hand to set it up for your controller - right now it's set up for my logitech 'dual shock'-style controller, but the format of the file is pretty obvious so you should be able to change the axes and buttons used. I haven't seen the glowing Mario effect either - he must be quivering with anticipation at the new Super Mario Galaxy release. :)

[Surkow]

...

@surkow:

I haven't tested the GUI extensively with either the 32-bit or 64-bit builds. It looks like you found a couple of things to add to the TODO list. You can edit the 'blight_input.conf' file by hand to set it up for your controller - right now it's set up for my logitech 'dual shock'-style controller, but the format of the file is pretty obvious so you should be able to change the axes and buttons used. I haven't seen the glowing Mario effect either - he must be quivering with anticipation at the new Super Mario Galaxy release. :)

I've edited the input config file before so I know how it works (I use an xbox360 controller). This is what I mean with glowing:

http://img87.imageshack.us/img87/2312/schermafdrukricespluginiy5.th.png (http://img87.imageshack.us/img87/2312/schermafdrukricespluginiy5.png)

http://img159.imageshack.us/img159/865/schermafdrukricevideoliet2.th.png (http://img159.imageshack.us/img159/865/schermafdrukricevideoliet2.png)

Currently the glow is green but it differs per scene. Also a problem I noticed in the cut scenes is that the screen flickers randomly (some objects become black).

[Richard42]

I've edited the input config file before so I know how it works (I use an xbox360 controller). This is what I mean with glowing:
...
Currently the glow is green but it differs per scene. Also a problem I noticed in the cut scenes is that the screen flickers randomly (some objects become black).

Yep, I see it. It's a bug in my RiceVideo SSE vertex lighting code, and it appears to affect both 32-bit and 64-bit builds. You can disable SSE in the RiceVideo.cfg and it goes away. I'll fix it in the next few days but tonight I'm playing Mario Galaxy. :party:

[agentdcooper]

[QUOTE=Richard42;391808]@kdubya:
@agentdcooper:

I have the same version of unzip (5.52) and it unzips those two files without a problem. I suspect it's a downloading issue. The Mupen64-amd64 source file should be 2371876 bytes long, and the 32-bit binary pack should be 1686074 bytes. Try doing an 'md5sum *' from the command-line, and here is what you should get for those 2 files:

c919b66278ed605f57e7ac25c74bb651 Mupen64-amd64-1-0-src.zip
7307b39c2e3e2affdc84ba7b50fa374b Mupen64amd64-RiceVideoLinux-1-0-bin-32.zip

If these hashes are not the same then your downloaded files are corrupt. You could try downloading with a different web browser, or right-click and Save As rather than left-click the links. Sometimes things get downloaded as text rather than binary.

=======================
you were righton, md5 did not match when I used Firefox to download those 2 files (it happened everytime) ... when I used 'wget' the md5sum matched perfectly right off the bat.

thanks! i am using AMD 2600+ on 32bit platform - compiling both yr RiceVideoLinux plugin + Mupen64-amd64 32bit sources in Slackware 12, just to test - works great for MANY games - hires textures segfault each time I try with Zelda OoT cell shaded... I am mainly interested in using your updated RiceVideo plugin to see how well it stacked up ---- thanks for the work you put into these releases!

[Richard42]

Currently the glow is green but it differs per scene. Also a problem I noticed in the cut scenes is that the screen flickers randomly (some objects become black).

I managed to find some time after playing a couple of levels of Super Mario Galaxy - man that is an awesome game!

The black flickering is probably the same problem that I traced in Mario Kart. I would add 'ScreenUpdateSetting=1' in the Super Mario 64 section of the RiceVideoLinux.ini file -- this will probably fix it.

The green glow problem turned out to be in the original RiceVideo inline SSE code; when I ported it to GCC and 64-bit, I just assumed it was correct, but it turns out it was not. I fixed it and committed the fix to SVN. Since the 32-bit binaries seem to be very popular I've also attached a 32-bit binary build of the fixed plugin to this message. If anyone wants a 64-bit binary just shoot me a PM and I'll send it to you.

[Surkow]

All problems related to mario 64 seem to be solved. Good job!

[i23098]

Well finally, after a lot of work, here it is. A new release, with both 32-bit and 64-bit binaries and source, of the Mupen64-amd64 and RiceVideoLinux projects.

Great :bouncy: :drool:
You should update the homepage...

The green glow problem turned out to be in the original RiceVideo inline SSE code; when I ported it to GCC and 64-bit, [...] If anyone wants a 64-bit binary just shoot me a PM and I'll send it to you.

Maybe you should post it here, as more people could want it. If not, send it to me :)

[nmn]

We don't have a homepage to update. We don't have access to the official server.

If this program gets adopted to the Mupen64 official builds, then the page will probably get updated.

[Richard42]

Maybe you should post it here, as more people could want it. If not, send it to me :)

Okay, here it is. To tell you the truth, the 64-bit builds are just sort of a novelty right now. Unless someone has a fast enough machine to run the games at full speed with the Interpreter core, or he doesn't have the 32-bit compatibility libraries installed, he should be running the 32-bit build even on a 64-bit machine. The reason for this is that the 32-bit builds with Dynamic Recompilation are way faster than the 64-bit builds with the Interpreter. I think it takes about a 2.0 GHz Athlon64, Opteron, or Core 2 to not peg the CPU with the interpreter. And since all the processing takes place in a single thread, it won't make use of multiple cores.

[TwistedWhizz]

Magic, a fresh new Mupen for Linux! My thanks to all involved. :cheers:

I think I might be doing something wrong though: I can't seem to get RiceVideo up in my plugin options. What have I done wrong? I've got glN64, and the Mupen one, but no Rice. I know I'm a wally, but help me out! I'm using Ubuntu Gutsy 32bit, and I downloaded the file Mupen64amd64-RiceVideoLinux-1-0-bin-32.zip from this thread. Thanks.

[retroK]

Thanks for your efforts Richard!

[Surkow]

Magic, a fresh new Mupen for Linux! My thanks to all involved. :cheers:

I think I might be doing something wrong though: I can't seem to get RiceVideo up in my plugin options. What have I done wrong? I've got glN64, and the Mupen one, but no Rice. I know I'm a wally, but help me out! I'm using Ubuntu Gutsy 32bit, and I downloaded the file Mupen64amd64-RiceVideoLinux-1-0-bin-32.zip from this thread. Thanks.

Try to put the latest updated rice plugin from the previous page in the plugins directory. Currently even if it does appear you can't change the settings with the GUI.

[i23098]

First, thanks again for this great work.

I can launch games, but can't play as I don't know the keys. :plain:

I went to Options->Plugins, select Plugins tab and it's blight's SDL input plugin 0.0.10 selected for the Input. When I try Config, Mupen crashes :(

If I select Mupen64 basic input plugin, Config makes nothing :( I'm trying to find the keys, as cursors this way work :)

Help :unsure:

[Surkow]

First, thanks again for this great work.

I can launch games, but can't play as I don't know the keys. :plain:

I went to Options->Plugins, select Plugins tab and it's blight's SDL input plugin 0.0.10 selected for the Input. When I try Config, Mupen crashes :(

If I select Mupen64 basic input plugin, Config makes nothing :( I'm trying to find the keys, as cursors this way work :)

Help :unsure:

Correct, you have to edit the input config file yourself. It was primarily the command line version that was updated if I understand it well enough.

This is what Richard had to say about it:

I haven't tested the GUI extensively with either the 32-bit or 64-bit builds. It looks like you found a couple of things to add to the TODO list. You can edit the 'blight_input.conf' file by hand to set it up for your controller - right now it's set up for my logitech 'dual shock'-style controller, but the format of the file is pretty obvious so you should be able to change the axes and buttons used.

To make it easier for yourself you should compare the input configuration from mupen v0.5 to the new one.

[kdubya]

For the record I do not have any trouble changing the settings in rice with the GUI.

[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. :D

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.

[MasterPhW]

So I gave you some ideas, what you could implement, nice to hear!
I hope that we don't need to create a team for mupen in some years and call it Mupen-M, to merge all the forks, like we had to do with VBA...

[Surkow]

...

@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.

...

Sorry for making difficult requests. I assumed it was possible because the 1964 devs implemented it. If you have little time to work on it then you can ignore my feature request.

[Richard42]

@MasterPhW: Today I found the VBA-M forum and poked around there a little bit. I also have an interest in setting up a good VBA emulator. I dl'd and built the SVN version - it built with no problems - but haven't tried to run it. Right now I have a build that I made from the Gentoo ebuild - I think it's 1.7.x. Everything seems to work fine with that version but I think the sound may be a bit rough. I'll have to compare the two to see if the latest VBA-M is better.

@Surkow: You don't have to be sorry for making difficult requests. :) We'll put it on the TODO list and if someone gets the time and inclination some day, it'll get done.

[MasterPhW]

@MasterPhW: Today I found the VBA-M forum and poked around there a little bit. I also have an interest in setting up a good VBA emulator. I dl'd and built the SVN version - it built with no problems - but haven't tried to run it. Right now I have a build that I made from the Gentoo ebuild - I think it's 1.7.x. Everything seems to work fine with that version but I think the sound may be a bit rough. I'll have to compare the two to see if the latest VBA-M is better.

VBA-M isn't bad, is it?
Me= one of the reasons the project started, so I'm a lil bit proud! ;)
If you have any problem or such things feel free to post in the forum! :)
Best wishes for Mupen64...

[i23098]

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.

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.

As for Mupen+, i'll be looking for that and i'll see what i can implement right now.

Great that you're all working on it :drool:

I hope that we don't need to create a team for mupen in some years and call it Mupen-M, to merge all the forks, like we had to do with VBA...

It seems we already have a great team working on it :mupen64:

Now, the bug report :plain: Sound is "slow" and skips with Jttl's SDL plugin 1.3. With mupen64 audio plugin I get no sound :(

My system is a Sempron 3300+, 64 bits Kubuntu 7.10. Graphic card is onBoard GeForce 6100 and also onBoard sound (ASRock k8nf4g-sata2 board)

[Richard42]

Now, the bug report :plain: Sound is "slow" and skips with Jttl's SDL plugin 1.3. With mupen64 audio plugin I get no sound :(

My system is a Sempron 3300+, 64 bits Kubuntu 7.10. Graphic card is onBoard GeForce 6100 and also onBoard sound (ASRock k8nf4g-sata2 board)

Are you using the 64-bit build? If so, try running the 32-bit build with dynamic recompilation. If this fixes the problem, then it happens because your machine is not fast enough to run at full speed with the Interpreter.

[nmn]

Also to note, Mupen64 Audio plugin is an ALSA plugin, so if its not working, try running alsaconf on a root terminal before running the game. (This will do some 'maintenance' even if alsa is configured already.)

[i23098]

Are you using the 64-bit build? If so, try running the 32-bit build with dynamic recompilation.

I'm running 64 bits version. When trying to use 32 bits one, I got:


(mupen64:7703): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libqtengine.so: wrong ELF class: ELFCLASS64

(mupen64:7703): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libqtengine.so: wrong ELF class: ELFCLASS64


So I guess Ubuntu 64 bits doesn't like 32 bits binaries/libraries. :(

If this fixes the problem, then it happens because your machine is not fast enough to run at full speed with the Interpreter.

Ok. I'll wait, and hope that after all the merges that are happening that dynamic recompilation works on 64 bits too.

Thanks for all the work

[i23098]

Also to note, Mupen64 Audio plugin is an ALSA plugin, so if its not working, try running alsaconf on a root terminal before running the game. (This will do some 'maintenance' even if alsa is configured already.)

Ubuntu doesn't have alsaconf... I tried with alsamixergui increasing all the volumes I can but it didn't work :(

PS - I guess it's KDE fault. I tried with XFCE and now mupen64 audio plugin works.

[Richard42]

(mupen64:7703): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libqtengine.so: wrong ELF class: ELFCLASS64

So I guess Ubuntu 64 bits doesn't like 32 bits binaries/libraries. :(


It will probably be some time before I can get around to porting the dynarec to 64-bits. You can get it to work on your Ubuntu system, you're just missing some libraries. You can get them from synaptic. Or, you could install them from the command line like this:

sudo apt-get install ia32-libs ia32-libs-sdl ia32-libs-gtk

[nmn]

The fact that it tries to load any 64-bit libraries at all may pose a problem toward 32-bit interopability. Perhaps you need to set LD_LIBRARY_PATH to /usr/lib32 if this error occurs even with the 32-bit libraries installed.

[i23098]

I couldn't set up it, so I renamed lib32 to lib, just to try. In 32 bits runs awfully slowly. 5 frames/sec or so. Don't know why... don't worry, keep up the great work and when dynamic recompilation runs on 64 bits or I change machine (xmas is comming ;)) everything is solved :)

[mike_k]

Updated from svn today to rev 96 and found a few improvements since rev 86. Thanks for your work!
I still have a few quick questions: (using gtk 2.12.0)
1. I can't remove single path in Options->configure->Rom Browser, while "Remove all" button works.

2. What about hotkeys, documented in readme.pdf? They seems to be wrong...

3. I have icons directory with icons, but country flags are missing in the UI

4. A saved rom.st0 from mupen64 0.5 loads, but I have no sound. Loading that game from rom.eep(simply starting it) or any nonsaved games have no such problem. Can you give an advice how to investigate this? Nothing suspicious in logs...

[nmn]

1. I can't remove single path in Options->configure->Rom Browser, while "Remove all" button works.

2. What about hotkeys, documented in readme.pdf? They seems to be wrong...

3. I have icons directory with icons, but country flags are missing in the UI

4. A saved rom.st0 from mupen64 0.5 loads, but I have no sound. Loading that game from rom.eep(simply starting it) or any nonsaved games have no such problem. Can you give an advice how to investigate this? Nothing suspicious in logs...1. Oh shi-- Okay, my bad. I messed this up with the brand new GUI code. My PC crashed (A-FREAKING-GAIN >: ( ) and i hadn't been working on this much.

2. Hot keys.. er... I didn't know they were implemented -at all- in the GTK GUI, perhaps i'm mixing it up with some other program.

3. I understand. Its because the code for the country flags is very dirty and i hadn't the chance to uncomment and do a real fix on them.

4. Uh... wow? You could try to debug, placing a breakpoint on the audio plugin's init function or something like that, but remember to build a debug version. The GNU Debugger (gdb) will work fine for debugging, incase your wondering (though you probably already knew ;))

[Richard42]

Updated from svn today to rev 96 and found a few improvements since rev 86. Thanks for your work!


Yeah I'm knocking out all the bugs that have been mentioned on this forum; there's still a few more to go. I'll do another release in a week or two after it has stabilized.

Regarding the bugs that you brought up, we'll fix 1, 2, and 3. I haven't really looked at the snapshot save/load code, but I believe that the way it works is that it dumps the N64 memory state and all of the relevant data structures from the plugins, then re-loads them all to resume. It's a really tricky thing to make work properly, and the first time I tried it I was surprised that it worked at all. If at some point during development any saved data structure is modified, then the saved states will not be portable across this change.

I would begin diagnosing this by examining the snapshot save/load code to see exactly how it works and what it stores, then find out what structure was changed. It may be fixable, or it may not be. In general I'm not going to go out of my way to support portability for the snapshots, because implementing a system to guarantee that it will always work across changes is a nightmare.

[mike_k]

Ok, I guess debugging my 'sound in saved state' problem right now might be an overkill since you're instantly changing data structures =). I am ok with that. At least "in-cartridge" (.eep) state is usable now.

[Richard42]

Ok, I guess debugging my 'sound in saved state' problem right now might be an overkill since you're instantly changing data structures =). I am ok with that. At least "in-cartridge" (.eep) state is usable now.

I'm not going out of my way to re-arrange everything, but sometimes things do get moved in the course of fixing bugs and cleaning up. Without being familiar with the snapshot code, I don't know what to watch out for. The in-cartridge save should always work - if not then it's a bug.

[TwistedWhizz]

Gah! Can anyone tell me why I can't get Rice Video in this? It's in the plugins folder, clear as day, but not when I open Mupen 64. I can only use Gln64 and the Mupen video plugin.

What the chuffery....? :(

[Richard42]

Gah! Can anyone tell me why I can't get Rice Video in this? It's in the plugins folder, clear as day, but not when I open Mupen 64. I can only use Gln64 and the Mupen video plugin.

What the chuffery....? :(

Did you build it yourself? If not, which binary package are you using? Did you get any error messages on the console? If there are problems loading a plugin when the directory is being scanned, they will be reported to stdout. You can try 'ldd plugins/ricevideo.so' and post the output; you might have unresolved dependencies.

[TwistedWhizz]

Did you build it yourself? If not, which binary package are you using? Did you get any error messages on the console? If there are problems loading a plugin when the directory is being scanned, they will be reported to stdout. You can try 'ldd plugins/ricevideo.so' and post the output; you might have unresolved dependencies.

I'm on Ubuntu 7.10 32bit, with Nvidia GeForce FX5600XT (not the best I know...), and the file I downloaded is Mupen64amd64-RiceVideoLinux-1-0-bin-32.zip from the first page of this thread. I try to use it like I would the older Mupen 0.05, by double clicking the launcher and opening a rom. Should I be doing something differently with this? Sorry for the noobish questions....

[nmn]

Well, its in your plugins folder, its 32bit... uhh... hmm... Maybe we did something to brake the ABIs?

If you could just, use the console once to start Mupen, and exit, and feed the output to us, that would be pretty helpful.

[TwistedWhizz]

Well, its in your plugins folder, its 32bit... uhh... hmm... Maybe we did something to brake the ABIs?

If you could just, use the console once to start Mupen, and exit, and feed the output to us, that would be pretty helpful.

OK, I'm a numpty. How do I do that with executable launchers like Mupen's? I'm very new to terminal use.....sorry.

:blush:

[Richard42]

OK, I'm a numpty. How do I do that with executable launchers like Mupen's? I'm very new to terminal use.....sorry.

:blush:

No problem, we all gotta start somewhere. The thing that you're calling a lancher is actually the mupen64 program binary. You need to run this from the console and send us the information that it prints out. There should be a 'location:' bar in your file browser/explorer when you're looking at the mupen64 binary, and this should have the directory path to the binary. The path probably looks something like /home/your-username/Desktop/Mupen64-amd/....

You need to open up the console and type:

cd <mupen_path>

where <mupen_path> is the path that's in the location bar of your file browser. Then type:

./mupen64

The emulator will run and dump out a bunch of information. Select and copy this from your terminal window and paste it here. Additionally, you should type:

ldd ./plugins/ricevideo.so

and paste that here as well - that will tell us why it is not loading Rice video for you.

[TwistedWhizz]

Many thanks for your reply and your patience. I've followed your instructions and got this when typing ./mupen64:

Couldn't load plugin '/home/twistedwhizz/Emulators/Mupen64New/Mupen64amd64-RiceVideoLinux-1-0-bin-32/./plugins/ricevideo.so': libgtk-1.2.so.0: cannot open shared object file: No such file or directory

I also typed in ldd ./plugins/ricevideo.so as you said, and got this:

twistedwhizz@twistedwhizz-desktop:~/Emulators/Mupen64New/Mupen64amd64-RiceVideoLinux-1-0-bin-32$ ldd ./plugins/ricevideo.so
linux-gate.so.1 => (0xffffe000)
libgtk-1.2.so.0 => not found
libgdk-1.2.so.0 => not found
libgmodule-1.2.so.0 => not found
libglib-1.2.so.0 => not found
libXi.so.6 => /usr/lib/libXi.so.6 (0xb7dee000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb7ddf000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7cee000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7c5e000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7c46000)
libGL.so.1 => /usr/lib/libGL.so.1 (0xb7bb0000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7abd000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7a97000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7a8c000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7942000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb793f000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb793a000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7936000)
libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb78de000)
libfusion-0.9.so.25 => /usr/lib/libfusion-0.9.so.25 (0xb78d8000)
libdirect-0.9.so.25 => /usr/lib/libdirect-0.9.so.25 (0xb78c9000)
/lib/ld-linux.so.2 (0x80000000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0xb6f31000)
libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0xb6f2f000)

Hope this is of some use to you. I'd be very grateful if you could let me know if I've done something wrong! Many thanks again.

[Richard42]

Hope this is of some use to you. I'd be very grateful if you could let me know if I've done something wrong! Many thanks again.

Good job - that tells me exactly what went wrong. I made a mistake when I built the binary builds for the 1.0 release, and I built RiceVideo with GTK1.2 support instead of GTK2.0 support. This also caused problems with the RiceVideo config and about dialogs for other people. Your system doesn't even have GTK 1.2 installed, so it won't load the plugin. I've attached the latest 32-bit RiceVideo build to this message, and it was built for GTK 2.0. You should be able to extract the 'ricevideo.so' file from the zip and put it in your plugin folder, and this one should work.

[TwistedWhizz]

Thanks very much for replying. I've done as you suggest and downloaded the new plugin. I've extracted it, and replaced the old ricevideo.so with the new one, but now it won't start at all. When I type ./mupen64 as before, I now get -

Illegal instruction (core dumped)

I know noobs are a pain! What would you suggest here?

[Richard42]

Illegal instruction (core dumped)


That's very interesting. Did it do this as soon as you started the program, or after you tried to run a game?

Last night I ran a test, with the original 32-bit binary package that I posted on this thread, and the updated RiceVideo binary which I posted yesterday, and it ran perfectly for me. This should be the exact same configuration which you used to get this error, but I didn't get the error. I have an idea what may have caused this and how to fix it, but I need a little bit more information first. What CPU does your computer have? If you're not sure, you can run "cat /proc/cpuinfo" from the console and paste the output here.

[TwistedWhizz]

Hiya, yeah I get that message simply trying to run Mupen64 from a terminal. It won't open, and that's the readout.

I've got a fairly dated CPU I believe by most modern standards! It's an AMD Sempron 2200+, which I believe is clocked at 1.5 Ghz. This is the output from the terminal -

processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Sempron(tm) 2200+
stepping : 1
cpu MHz : 1512.005
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow up ts
bogomips : 3025.85
clflush size : 32


I also have 768Mb of RAM, in case that's of any use to you.

[Richard42]

Yep I found a small problem in the makefiles. When doing a 32-bit build on a 64-bit machine, the wrong CFLAGS list was being used, and it was getting compiled with '-march=athlon64'. The compiler probably used some instruction which isn't available on your CPU. I fixed this and re-built all of the binaries, which are in the attached zip file. You should unzip this and copy the mupen64 and mupen64_nogui binaries over your old ones, then copy all of the plugins (*.so) over the old ones in your 'plugins' folder. It's good that you found this problem because I bet it affected a lot of users with older CPUs.

[Richard42]

-I seg fault if I put a nonstandard resolution into the .cfg file. Would be fine but there are not widescreen choices.


Kdubya,

I'm trying to reproduce this bug to fix it, and it works for me. I put some weird resolutions into the rice video config file and they all work. Can you please give me some more info on this:
1. Did you build from source or use one of the binary packages? Which architecture are you using (32 or 64-bit)?
2. Which config file did you modify? What are the exact parameter names and values you used in the config file to cause the crash?
3. Were you using the GTK or NOGUI version? Was it in fullscreen or windowed mode?

Thanks.

[nmn]

More on the GUI fixes. In the latest SVN:

- The directory list was completely reworked in everyway to move from GtkList to GtkTreeView. If you liked Gtk 1.2 support... well, that brakes it. Sorry, but the GtkList is ugly, buggy, old and depricated :( On the plus side, i massively cleaned the code and made some slight other adjustments in dialog. Hope they work out :)

- The ROM list itself has not been reworked. This will probably take *ALOT* more work. I will try to get that done soon.

edit: To elaborate on what i mean by the last thing, the ROM list has not been *changed* yet. It shall be as it was, without the country flag showing up... (will be fixed soon)

And the QT GUI has frozen since i lost all of the code in a crash (which explains my absense of commits. I should've fixed the directory list problem the same night it was found but my partition table did not agree with Windows which i was installing for dualboot purposes and... yeah... long story short, it nuked my tables, and i'm too lazy to try to find the exact locations of the filesystems on it.. >_>)

[TwistedWhizz]

Yep I found a small problem in the makefiles. When doing a 32-bit build on a 64-bit machine, the wrong CFLAGS list was being used, and it was getting compiled with '-march=athlon64'. The compiler probably used some instruction which isn't available on your CPU. I fixed this and re-built all of the binaries, which are in the attached zip file. You should unzip this and copy the mupen64 and mupen64_nogui binaries over your old ones, then copy all of the plugins (*.so) over the old ones in your 'plugins' folder. It's good that you found this problem because I bet it affected a lot of users with older CPUs.

Thanks for all your time. I've done as you said, and it seems to work now. The GUI looks a bit different to the old Mupen (I dunno if this was intentional - the boxes at the top of the screen for open rom, start emulation, full screen etc, are now just little boxes with an X on them) but it starts OK.

However, I'm having exactly the same problem with rice video that I had with old Mupen. It still flickers blue when you enter a level. I've attached an image that I managed to capture to give you an idea. I won't bother you any more, since you've already done loads for us owners of older PC's, but I thought you may be interested in this.

Mario Rice Video Glitch (http://i214.photobucket.com/albums/cc175/kproject/marioglitch.png)

Thanks very much again for your time.

[Richard42]

However, I'm having exactly the same problem with rice video that I had with old Mupen. It still flickers blue when you enter a level. I've attached an image that I managed to capture to give you an idea. I won't bother you any more, since you've already done loads for us owners of older PC's, but I thought you may be interested in this.


I spent about a week diagnosing that flashing problem that you illustrated with that screenshot. I was looking at Mario Kart 64 but it affects many other games as well. In the end I found that it was due to an incorrect screen update behavior. I don't know why the emulator has multiple settings for when to update the screen, but it does. If you add this line: "ScreenUpdateSetting=1" to the "SUPER MARIO 64" rom section of the RiceVideoLinux.ini file, this problem will go away. I've updated the ini file in my SVN repository, so this will also be fixed with the next release.

[nmn]

The icons are alot better now, but unfortanatally, the method to load them has changed. Soon enough it will be fixed, but for now, the current working directory must be the application directory. (This would mean, for example, on a KDE desktop, the shortcuts "work path" must be the directory mupen64 is in. On a GNOME desktop, its hard to set the work path because GNOME doesn't directly support it.) Really the working directory belongs at the directory of the application if nothing else, but KDE and Gnome both set it to ~ i believe, when its not specified. (This is what makes double clicking applications directly in Linux usually not work :P)

[_Zack_]

Nice stuff, you guys are really hunting down those bugs :)

Btw, would you mind removing me from the svn mailing list Richard? My inbox is getting too flooded :p

Cheers, and keep up the great work guys :)

[nmn]

Richard42, do you think we should try to... *force* the global screen update setting to 1? It shouldn't do much harm considering it seems to work with pretty much any rom.

[sl1pkn07]

Thanks :)

[Richard42]

Richard42, do you think we should try to... *force* the global screen update setting to 1? It shouldn't do much harm considering it seems to work with pretty much any rom.

The thought had occurred to me. There is a value for the default setting of the ScreenUpdateSetting parameter - currently the default is 0. It is possible to change this default to 1 instead. I am a little reluctant to do this because I don't really understand why there is a setting for the screen update time. It seems like there should be 1 method or mechanism to handle this (ie, whatever the N64 hardware itself uses) and this should work with all the games. Since I don't understand why this setting exists (what problem it was intended to solve), I have no idea about what problems could be caused by changing the default. Probably the best thing to do would be to test a large number of games (maybe 50 or so) with both settings, and if there are fewer problems or artifacts with the new setting, then it would be safe to change the default.

I know that's a lot of work but in a relatively mature project it makes sense to spend effort to avoid a regression.

[Eck]

Hey again!

I noticed a mupen64-1.0-1.1 in the OpenSUSE Build Service. That's this project, isn't it? I think it's terrific that we have an easily installable rpm through our package manager available. Thanks!

But, some questions since I'm wondering what I want to do with this.

The comments state to use the GUI sparingly, if at all since it's buggy at the moment. Well, I've only used Mupen64 with the GUI. Most recently with the Mupen64 version 0.5-6.1 from the wberrier OpenSUSE Build Service repo with the only change being my using the version 12 Glide64 plugin and adding that since the package doesn't come with it.

Since the other emulators I use, fceu and zsnes, are not packaged with openGL support in the Build Service I compile them myself and just added PicoPico's repo to get kfceu for a gui to my built fceu. Back on Debian when the kfceu didn't install properly when I tried building it I went back to GFCEU, which still works great but kfceu is better with more resolution control.

If I add that additional emulator repo to get your Mupen64, it will have the higher version number and so remove the version I have that works just great for most things and replace it with your new version.

Although I do want to try the new version as you have related having fixed a lot of bugs in games with it, the one I have works just great for most of what I play. Not ever having much success with the Rice Video plugin, using your version centered upon that plugin really makes me committed to switching over to Rice. Especially since I will no longer have the older Mupen64 available. The packaged Mupen64 on the wberrier site, which installs to the system and not just the home folder extraction that the official 0.5 version did, is working much better than the official 0.5. It is handling full-screen switching and correct resolution and refresh rate and seems to be giving me higher fps scores all better than the original.

So you see I have reasons, including using the GUI and the various alternative video plugins, for wanting to stay with what I've got here.

Is there no way of simply taking your improved Rice Video plugin and replacing the one I now have on my Mupen64-0.5-6.1 version? Is it so radically changed now that a simple drop-in replacement just isn't possible? If it were, I could keep the working GUI, control the plugin with the GUI configuration control, and also still have the rest of the package with the improved performance I have been noticing with it.

Any shot of something like that working for a not so terminal oriented GUI lover?

[Richard42]

I noticed a mupen64-1.0-1.1 in the OpenSUSE Build Service. That's this project, isn't it? I think it's terrific that we have an easily installable rpm through our package manager available. Thanks!


That's cool - I have no idea who added this release to the emulator repo for OpenSUSE; I haven't heard anything about it. But I'm glad to hear that it's getting out. We're going to make another one soon because there have been a lot of fixes.


So you see I have reasons, including using the GUI and the various alternative video plugins, for wanting to stay with what I've got here.

Is there no way of simply taking your improved Rice Video plugin and replacing the one I now have on my Mupen64-0.5-6.1 version? Is it so radically changed now that a simple drop-in replacement just isn't possible? If it were, I could keep the working GUI, control the plugin with the GUI configuration control, and also still have the rest of the package with the improved performance I have been noticing with it.

Any shot of something like that working for a not so terminal oriented GUI lover?

Well you could always give it a try and see what happens. :) I assume that you are running a 32-bit system; if so take the last untagged 32-bit rice video binary which I posted in this thread (post #69 on page 7), extract the ricevideo.so plugin file, and drop it into the plugin directory wherever your Mupen0.5 was installed.

We've actually fixed quite a few GUI bugs in the last week or so - the blight input config dialog had issues as well as the directory browser. Maybe after we make the next release whoever added the last one to your repo will also add this one; hopefully this will be the best of both worlds.

[Eck]

I'm glad you're happy about it. I just hope it's all done right by whatever rules apply to open source/free software. I was surprised when I read that you hadn't been informed about it, especially since it appears not in someones personal directory under the /home:/ section, but in the semi-official emulator repository.

Heh, maybe a SUSE engineer really liked your work and decided upon it. Interestingly, the 0.5 version which works fine is relegated to a lower version number now and in that wberrier home directory. And that's the official one! Many more users will come across your version than the official one this way. It's nice to have it available all nice and automatically installable like this, however, like you said. But it does seem a bit backwards even to you I bet, no?

Nice about just needing to use the Rice plugin you already made to get some of your fixes into the Mupen64 0.5 I'm already using here. It's another advancement in the available video plugins which is always a good thing. As I explained, I hadn't had much luck with the included one and perhaps this will improve even more of the games.

The more contributions to the Mupen64 technology the better. The other night I tried turning on the frame buffer part in the Glide64 and running MarioKart64 to see if the video screen there would show up. It did not! Hmm. Other than that the game ran fine, but didn't appear to be any different from having that setting unchecked. If I recall correctly even though it's been some time since I used it, I believe the videos do show up when MarioKart64 is played on Project64 1.7 beta on Windows XP.

I guessing that, although slowed recently, development on Project64 was simply more active during the last couple of years since the last official Mupen64 came out and simply saw more improvements and games working better because of that activity, and of course I am talking about the beta version 7. During the same period the Mupen64 just stayed as it is, which is pretty darned good of course! However it is really nice to see all parties working on it again.

[Richard42]

I'm glad you're happy about it. I just hope it's all done right by whatever rules apply to open source/free software. I was surprised when I read that you hadn't been informed about it, especially since it appears not in someones personal directory under the /home:/ section, but in the semi-official emulator repository.

As long as they are in compliance with the GPL, it's all good and legal. The gist of the GPL is that if they are distributing binaries, they must also distribute the source or make an offer regarding where to download the source or purchase for a limited fee.

Heh, maybe a SUSE engineer really liked your work and decided upon it. Interestingly, the 0.5 version which works fine is relegated to a lower version number now and in that wberrier home directory. And that's the official one! Many more users will come across your version than the official one this way. It's nice to have it available all nice and automatically installable like this, however, like you said. But it does seem a bit backwards even to you I bet, no?

That's not good. I'm trying not to step on anyone's toes, and Mupen64 is Hacktarux's baby. What I've created is a branch of his work, and I try to emphasize this by always calling it by a different name: mupen64-amd64. Same with RV - I always call it RiceVideoLinux. I hope whoever created the SUSE repository entry reads this and puts it under a different name for the next release.


Nice about just needing to use the Rice plugin you already made to get some of your fixes into the Mupen64 0.5 I'm already using here. It's another advancement in the available video plugins which is always a good thing. As I explained, I hadn't had much luck with the included one and perhaps this will improve even more of the games.

Yeah the original N64 emulator designers who decided to use the plugin approach did a great service to the community, because that really improves the user experience. This is a very interesting project to work on.

[Eck]

Thinking here. You know what might sort this? A while back when OpenSUSE 10.3 was first released I had posted in CyberOrg's thread in the Compiz Fusion forum where he describes how to get the OpenSUSE packages. It was just to offer my experiences with using his repo, but I happened to mention how weird it was (actually I think this was during the RC1 period) that some of the game emulators I used happened to be in the Build Services Debian based repositories. I mentioned how I thought it strange when doing system upgrades that one of them (not an emulator) came from one of these Debian/SUSE hybrid repos and had installed Debconf and related dpkg stuff into my OpenSUSE installation. And I said that since one of those claimed that it made it so future package installs would honor the user configuration files, not replacing them with new ones from an upgrade, I hoped that this wouldn't interfere with normal OpenSUSE YaST package upgrades.

A couple of days later all those emulators had been moved into the normal OpenSUSE Build Service Emulators repo, no longer needed a user to activate any of those Debian based repos. So the problem, if it was a problem, had been fixed within a couple of days and was not present by the time 10.3 was released.

I know CyberOrg (can never remember his actual name although he's a major developer. I bookmark both his CyberOrg blog and personal blog whenever I come across them. Good OpenSUSE and Linux info there) tries to keep that thread clean of discussions not related to his Compiz Fusion repo and often moves conflicting stuff out of there. However it does appear that if he sees something funky being reported he manages to get action taken on it faster than a speeding bullet!

The most legit way would be for me to post a bugzilla bug somewhere. Bugzilla is one of the things about Linux I've never quite gotten a handle on. There's just so many of them! And what to post and fill in the blocks is also unclear. I've done it, but most often my bug sits there, with perhaps a reply and perhaps not, but the status never changes until I close the bug myself. It's just a weird place to me, although sometimes I browse through it, reading some other bugs to find something that has been happening to me and might clear up something.

I'll go complain somewhere. You're right that although terrific that the package is available, Hacktarux's official version should be like Mupen64 and any fork or 3rd party work should be named a bit (but not completely) differently, like you mentioned.

[Eck]

Okay, it's Novell OpenSUSE 10.3 Bugzilla Bug #344403.

https://bugzilla.novell.com/show_bug.cgi?id=344403

That's a copy/paste link but maybe you need to just go there and search?

Hopefully they'll fix the naming thing.

[nmn]

Even though i disagree with their decision to degrade the official builds, similar things have happened before. Its probably only because Mupen64s official builds are starting to get old, but i still see no reason to do what they did. Hope its all sorted out soon.

[Eck]

I don't think it was intentional. It's possible that it was simply thought to be a new official release and since it's the choice for N64 emulation on Linux, they just put it up. They didn't change anything about the official version on the other repo, only posted up this one. It's just the effect of the version numbering, the same file name, and the sort of hidden from the average user nature of the official version's repo that causes the trouble.

That search function they have is rather new and many users will likely just look in the top directory, see Mupen64 there, and just add that Emulators repo and wind up with this one.

But I think the official one with its fully functioning GUI, shortcut icons, full package of plugins (well, except for Glide64 for some reason. I just installed that myself afterwards), would be the one chosen by most users who want a stable released version. This new one would be more for those who want to see progress and experiment with things. With things as they are, they might not find out they have that choice.

With the bug report posted I would think someone will be looking into this. I have no idea how effective bug reports are or how fast appropriate action can be taken. I hope they arrange things so that somehow both packages are kept around in a more appropriate format so to avoid confusion. It is quite nice to have a choice and also would be nice if they could possibly be installed at the same time.

We'll see what happens, if anything, when the smoke clears! :)

[mudlord]

The other night I tried turning on the frame buffer part in the Glide64 and running MarioKart64 to see if the video screen there would show up. It did not! Hmm. Other than that the game ran fine, but didn't appear to be any different from having that setting unchecked. If I recall correctly even though it's been some time since I used it, I believe the videos do show up when MarioKart64 is played on Project64 1.7 beta on Windows XP.


You need to tick "read every frame" in Glide64 for the billboards to show correctly.

[Eck]

Thank you. I'll check for that in there in a bit and see how it goes. Read every frame kind of seems that it might slow things down, but maybe not. Everything plays smoothly so as long as that doesn't cause any hesitation it'll be a nice addition to see the billboards like we're supposed to.

If it does have some bad effect on things though, we really only see the billboard for a few moments while speeding through there so it isn't absolutely necessary for gameplay. But I'm actually expecting the best, since everyone's been saying this works, and I am using the last one available before that HQ series started.

[mudlord]

Read every frame kind of seems that it might slow things down, but maybe not. Everything plays smoothly so as long as that doesn't cause any hesitation it'll be a nice addition to see the billboards like we're supposed to.

It depends on the game & your video card bandwidth whether it slows down or not. I know that the newest PCI-E based video cards can handle "read every frame" perfectly fine, whereas older cards can have major issues with speed. I noticed simplistic games like Mario Kart 64 have less slowdown or no slowdown at all when using "read every frame" than games such as Donkey Kong 64.

But I'm actually expecting the best, since everyone's been saying this works, and I am using the last one available before that HQ series started.

Yeah this plugin works quite well for what it supports. Though, the HQ series will continue on with the next official Glide64 release, which will support hi-res textures, through the GlideHQ DLL.