mupen64 0.5?

I think 0.4 is current enough atm. IMO there wouldn't come a new version too fast.

Here's a little video of something new : http://mupen64.emulation64.com/tarzan2.avi

Hydrothunder starts to work with sound too but hangs after a while, and twine seems to work great so far. Stability has been improved and it should be a little bit faster now.

Hacktarux said:

Here's a little video of something new : http://mupen64.emulation64.com/tarzan2.avi

Hydrothunder starts to work with sound too but hangs after a while, and twine seems to work great so far. Stability has been improved and it should be a little bit faster now.

Click to expand...

that's good news !!!

did you succeed to get good sound with all musyx games ?

there is a remaining sound mystery with Boss Games Studio' games that have trouble with sound, as Stunt Racer 64 (no sound, no gfx (unknown ucode) and certainly hangings), Top Gear Rally, Twisted Edge Extreme Snowboarding (no sound), World Driver Championship (no sound, no gfx (unknown ucode) and certainly hangings).

May be you could have a look ? it'll be nice

Thanks a lot for Mupen, a great emulator for sure

Boss Games Studio's games are not the only games with sound "problems". Mupen's RSP seems to cause some problems with certain games even though it seems that it emulates more things that PJ's RSP. For example in Castlevania LOD with Mupen's RSP (despite the alists process selection) all the ingame sound effects are produced but some of them are produced in moment's that they shouldn't; there also some volume balance problems with it. On the other hand with PJ's RSP the game lacks some sounds but volume balance is fine and it doesn't seem to have any other noticable problems. Other games seem to have similar problems too (Zelda OOT, MK Mythologies).

PsyMan said:

Boss Games Studio's games are not the only games with sound "problems". Mupen's RSP seems to cause some problems with certain games even though it seems that it emulates more things that PJ's RSP. For example in Castlevania LOD with Mupen's RSP (despite the alists process selection) all the ingame sound effects are produced but some of them are produced in moment's that they shouldn't; there also some volume balance problems with it. On the other hand with PJ's RSP the game lacks some sounds but volume balance is fine and it doesn't seem to have any other noticable problems. Other games seem to have similar problems too (Zelda OOT, MK Mythologies).

Click to expand...

Huh? For me, at least with Goldeneye 007, the RSP allows all audio samples to be played, in fact, it's vice-versa, without the RSP, some music samples are missing.

Great Video - Nice improvements !
Keep up the good work :sorcerous:

Hac you are a god!

I hope .5 is still a possibility. 0.4 is very unstable on my system, and I can't revert back to .3 because I don't have GTK1 anymore :/

will the patches from the board be included in this version??

And how about switching to gtk2?

I won't switch to gtk2 now because as i've already said, the plugins are using gtk 1.2 too and it would add more confusion for users (we'd need to have two versions of each plugins if we want to be cross compatible with different mupen64 versions). Besides, i don't think it's a major issue to install a very small library such as gtk 1.2 that won't change anything to the rest of the system...

Concerning the patch, maybe i'll include them but not in their current state. The advantage of the nogui version was that it was a base to start a port in a new system. The patch jogibear9988 provided make it a linux only main file. It has to be changed so that it doesn't use the signal function for example. Or at least only when compiled on linux.

Some other small things about the patch :
- i haven't tried your patch yet (only looked quickly at the code) so this question can be irevelant but... what happen when there's no config file in the folder ? Do you have checked it doesn't crash.

- another thing, when people use the program in interactive mode, i don't get why people should see the filename in the menus, it's much better to see the name of the plugin that often contains informations about the version number...

Edit: ignore the last comment, i've just seen you've put both names.

I've use the Config file reading completely from the gtk ui, i think there is done a check for a existing config file or not!

i'm working on the patch to include compiler options to use the signal.h only on linux...

ps: dose the ini file reading functions working on the other os'es or sould this too oinly be enabeld in the linux version???

yea, ini works on all OS i think. The question about config file was asked because the gtk gui isn't working on all OS, so it's important that there's no need to launch a gtk gui to create the file.

the file isn't created when you run, it's only read when it exits! There are also three more Parameters wich weren't created by the gtk ui! (Fullscrenn, Emulation Mode, No Ask). If the file not exits, there is no error, it only uses no values for the Parameters...

i think we can use
#if defined (__linux__)
for the signal code, so that this is only compiled on linux!

but i have no change to test it, because i only use linux as os!

any news / is it in alpha || beta development status?

thanks

Will you be using a CVS server for the next (source code) release? It'd be a great way for people to contribute with patches/plugins etc.

testings...

#if defined (__linux__) works on linux
the other systems i can't test, so if someone could try.

i think we also should include a command line option create ini, or put a sample gui_gtk.conf in the source code so that the users know what options are there.

And i would rename the ini to mupen64.ini or mupen64.conf because i think gui_gtk.ini is not the best name.

#if defined __linux__ || defined __FreeBSD__ || defined __NetBSD__ || defined __OpenBSD__
would be better. FreeBSD has support for NVidia Cards and NetBSD and OpenBSD for a few 3dfx and Matrox Cards.