Mupen64Plus release candidate!

[ebenblues]

I like the GUI no plugin selected error as opposed to the crash, but think we should select default plugins, (Rice, mupen64audio, Blights, the RSP plugin - we only have one). Maybe the first time mupen starts we should send a message along the line of:

"Mupen64Plus uses a plugin framework to handle various aspects of N64 emulation. While the default plugins should work for most users, you may have better luck on by choosing another plugin. You can see the available plugins and options on the Plugins tab in Options->Configuration."

Thanks for the feedback. I'm working on fixing the issue where no plugins are selected by default. I don't know about the first time message. I could be completely wrong, but I think most users mess around with configuration settings and it might be more appropriate to have your message in some documentation in the help menu. Or maybe we should make a "Did you know..." dialog that pops up on startup, but can be disabled by the user. Something like that would have to wait for a later release tho.

- The mupen executable (either self compiled from svn or from the linked binary) won't execute from Konqueror, but works fine from the commandline.
- Wonder Plus starts fullscreen, it should start windowed or have an option, and "F1" doesn't work to toggle fullscreen. ideally "Alt-Enter" should be the standardize key for this since "F1" is usually the hotkey for help and used in multiple other emulators and programs. This should be standardize across plugins.
- Our GTK accelerators don't work (I know I brought this up before but we might want to fix this before the release).
- The X for windowed plugins should close the window (by ending emulation).
- Might I suggest Rice should have fog disabled by default, this lets the open source Radeon 3D drivers work by default.

I'm not sure what would cause the Konqueror issue. Does Nautilus have the same problem? I don't use KDE, so I don't have the tools to debug this one. For fullscreen, the emulator (not the plugins) controls which hot-key is mapped to fullscreen, so we should be able to change that to "Alt-Enter" fairly easily without changing the plugins if others agree that "Alt-Enter" is a more standard key for fullscreen. The GTK accelerator problem should be added to the TODO list, but I don't think this should gate the release.

 

[csi]

The mupen executable (either self compiled from svn or from the linked binary) won't execute from Konqueror, but works fine from the commandline.

It executes fine for me using eiher gnome-terminal, pcmanfm or nautilus. (I don't have konqueror installed)

2. To many useless confirmations
2.1 Load a rom which is a "bad dump" or a "hack"
2.2 You get asked if you want to load the rom anyway. Choose "No"
At this point no more popups should appear, but it goes on.
2.3 Confirm: "There is no Rom loaded. Do you want to load one?". Choose "No"
2.4 Error: "Couldn't load Rom!" --> OK

The biggest issue here is after we single-click a rom, and then press the play icon,
we get: "There is no rom loaded. Do you want to load one?"
I would recommend to get rid of this message,
the GTK "Play Icon" function should know we single-clicked a rom, and just run it.

--
Mupen64Plus-src 1.3 - 32-bit - Ubuntu Gutsy

 

[Richard42]

The biggest issue here is after we single-click a rom, and then press the play icon, we get: "There is no rom loaded. Do you want to load one?"

Yeah that's on the TODO list, but it's not a blocker for the 1.3 release. It should be an easy fix, though.

 

[okaygo]

I know I'm a developer, but I haven't had a chance to take a look at the code.

Bug: When I run Mupen64 32bit, on Ubuntu Gnome, when I run a rom using RiceVideo, my top bars close, removing the ability to close windows, move windows...

This wasn't present in the last version...


gah I'll take a look :3


--- after some investigation ---

main.c
SDL_SetVideoMode(10, 10, 0, 0);

This line seems to cause the problem, it removes the title bars on everything. Comment this line out, and it works fine. Not sure if this will break anything for anyone else.

 

[phorsyon]

...
- The mupen executable (either self compiled from svn or from the linked binary) won't execute from Konqueror, but works fine from the commandline.
...

This is a working path issue. Konqueror always uses the path as working path it was called with, which in most cases is $HOME. If you start mupen64plus without parameters it pretends that the working path is also the install path. This of course works fine in the terminal if you first cd into the mupen64plus directory or in nautilus, which always sets the current path to the working path. You can also trigger this unwanted behaviour from the terminal by NOT cd'ing into the mupen64plus directory and calling the executable directly from your $HOME e.g.:

phorsyon@HyperBel ~ $ games/N64/mupen64/mupen64plus
/home/phorsyon/: Invalid install directory

IMHO, this is a bug in konqueror not in mupen64plus and also not the way you start applications under linux/unix anyway. ;-)

 

[okaygo]

This is a working path issue. Konqueror always uses the path as working path it was called with, which in most cases is $HOME. If you start mupen64plus without parameters it pretends that the working path is also the install path. This of course works fine in the terminal if you first cd into the mupen64plus directory or in nautilus, which always sets the current path to the working path. You can also trigger this unwanted behaviour from the terminal by NOT cd'ing into the mupen64plus directory and calling the executable directly from your $HOME e.g.:

phorsyon@HyperBel ~ $ games/N64/mupen64/mupen64plus
/home/phorsyon/: Invalid install directory

IMHO, this is a bug in konqueror not in mupen64plus and also not the way you start applications under linux/unix anyway. ;-)

Anything the developers could do to solve this issue?

 

[Richard42]

IMHO, this is a bug in konqueror not in mupen64plus and also not the way you start applications under linux/unix anyway. ;-)

It would be nice if everyone would 'cd' to the executable dir before running an executable, but sometimes it is nice to be able to run an executable from another place. If Mupen64Plus is installed with the install script this bug actually should not appear. But I would still like to fix this, by adding one more check to the install dir logic, so it will be like this:

If install dir is given on command line:
 - if exist(<givenpath>/icons/logo.png), use <givenpath>
 - else fail with error message
* else:
 - if exist($PREFIX/share/icons/logo.png), use $PREFIX/share
 - else if exist(<cwd>/icons/logo.png), use <cwd>
 - else if exist(dir(argv[0])/icons/logo.png), use dir(argv[0])
 - else fail with error message

What do you guys think? Mupen64Plus should be as 'bulletproof' as possible.

 

[ebenblues]

main.c
SDL_SetVideoMode(10, 10, 0, 0);

This line seems to cause the problem, it removes the title bars on everything. Comment this line out, and it works fine. Not sure if this will break anything for anyone else.

Thanks for fixing that. I'm no SDL expert and during the gui/nogui merge, I noticed the nogui version had that line and the gui version didn't. I wasn't sure what the difference was so I just flipped a coin and put it in. I didn't notice any difference on my system with or without it (but I generally run in fullscreen mode), but it sounds like we're better off without it.

 

[ebenblues]

It would be nice if everyone would 'cd' to the executable dir before running an executable, but sometimes it is nice to be able to run an executable from another place. If Mupen64Plus is installed with the install script this bug actually should not appear. But I would still like to fix this, by adding one more check to the install dir logic, so it will be like this:

If install dir is given on command line:
 - if exist(<givenpath>/icons/logo.png), use <givenpath>
 - else fail with error message
* else:
 - if exist($PREFIX/share/icons/logo.png), use $PREFIX/share
 - else if exist(<cwd>/icons/logo.png), use <cwd>
 - else if exist(dir(argv[0])/icons/logo.png), use dir(argv[0])
 - else fail with error message

What do you guys think? Mupen64Plus should be as 'bulletproof' as possible.

Yeah, I didn't think the current algorithm would be much of a problem (and it sounds like it's not a huge problem) since most people will either be in the unzipped source/binary dir and run it to test or they will have installed it in which case we won't see this at all, but I'm fine with the changes you're suggesting since in this case, trying the same dir that the binary is in is a last resort. But I think I'll change the algorithm to use /proc/self/exe instead of arg[0]. It's more robust, even if it is *nix-specific.

 

[phorsyon]

Plugin Bugs Report

To the Win32 port requests:
Well I don't get it! There are about 10 N64 emulators for the Win32 plattform, but only 1 for linux/unix. IMHO there is absolutely no need for another Win32 N64 emulator. So why wasting time on Win32 compatibility?

To the Bug Reports:
I promised some bug reports here they are. Every block is a combination of machine type, mupen64plus version, used plugin (mostly gfx), game name, CRC and MD5 following a list of bugs. Just ask me if you need further information. ;-)

x86_64 / mupen64-amd64-1.2-bin-64 / blight
1. It is possible to assign one axis AND one button on a gamepad at the same time to a button in the emulator. e.g. left on the second analog stick and the first button on the pad can trigger "C left" in the emulator.

x86_64 / mupen64-amd64-1.2-bin-64 / glN64 + Jttl / MarioParty / CRC: 2829657e a0621877 / md5 code:8BC2712139FBF0C56C8EA835802C52DC
1. After a (complete) game is finished, the sound starts to stutter extremly loud. It's like there is garbage data in die audio buffer and played over and over again. You have to restart the game to get it back to normal.

x86_64 / mupen64plus-1.3-RC1-bin-64 / glN64-0.4.1 / MarioParty / CRC: 2829657e a0621877 / md5 code:8BC2712139FBF0C56C8EA835802C52DC
1. runs slower as with previous version (mupen64-amd64-1.2-bin-64 + glN64)
2. artifacts in mini games
2.1 sometimes characters and objects are flashing.
2.2 sometimes characters and objects are rendered multiple times. It's like the next motion frame gets drawn without erasing the previous one from the background. e.g. if a character moves from left to right you get a line of this character in different stages (overdrawing?).
2.3 while the screen is split up into 2 frames the second (either the right or the lower one) frame flashes.

x86_64 / mupen64plus-1.3-RC1-bin-64 / rice-1.2-dev / MarioParty / CRC: 2829657e a0621877 / md5 code:8BC2712139FBF0C56C8EA835802C52DC
1. artefacts in mini games
1.1 sometimes characters and objects are invisible

x86_64 / mupen64plus-1.3-RC1-bin-64 / rice-1.2-dev / Mario Kart 64 / CRC: 3e5055b6 2e92da52 / md5 code:7D54D888964A3B0D058EB80886C44C88
1. In high resolutions (tested with 1600x1200) and only in fullscreen mode the whole screen flashes + overdrawing artefacts. Sometimes there is a small centered picture-in-picture of the game, so the game runs as a small picture in the middle of the screen and the rest of the screen just flashes.
2. After every race the screen is split into 4 parts, where 2 of them shows the scores. The background color should here be black, but instead it's white most of the time and randomly flashes to black. Depending on the map there are other colors too.

x86_64 / mupen64plus-1.3-RC1-bin-64 / rice-1.2-dev AND glN64-0.4.1 / MISCHIEF MAKERS / CRC: 418bda98 248a0f58 / md5 code:EB3B078A74D4DC827E1E79791004DFBB
1. In Level 4-1 Astair's Lair you have to run away from a rolling stone. The sad thing is that's invisible. There are most likely more objects in the game which are invisible because of this bug but I only noticed this one so far.
2. The message "two events of type 8 in queue" appears countless times in the console

x86_64 / mupen64plus-1.3-RC1-bin-64 / rice-1.2-dev / MarioTennis / CRC: 839f3ad5 406d15fa / md5 code:FFF9B3E22ABB9B60215DAFB13AD5A4DE
1. The emulator crashes...
1.1 at the end of the intro (but you can skip the intro).
1.2 when you've started a game and hit the ball the first time.

x86_64 / mupen64plus-1.3-RC1-bin-64 / glN64-0.4.1 / MarioTennis / CRC: 839f3ad5 406d15fa / md5 code:FFF9B3E22ABB9B60215DAFB13AD5A4DE
1. Countless clipping artefacts.
2. Many black boxes around objects (render to texture not working?)
3. The replays are almost completly black, but skipable.

 

[Richard42]

To the Win32 port requests:
Well I don't get it! There are about 10 N64 emulators for the Win32 plattform, but only 1 for linux/unix. IMHO there is absolutely no need for another Win32 N64 emulator. So why wasting time on Win32 compatibility?

Ouch. Careful with that axe, I feel a flamewar coming on!

Thanks for the bug reports. I really need to create some kind of a spreadsheet to track these problems until they get resolved; maybe I'll do it tonight.. That's if I can tear myself away from playing crash and metroid on my VBA emulator.

 

[phorsyon]

Ouch. Careful with that axe, I feel a flamewar coming on!

Thanks for the bug reports. I really need to create some kind of a spreadsheet to track these problems until they get resolved; maybe I'll do it tonight.. That's if I can tear myself away from playing crash and metroid on my VBA emulator.

I didn't mean to start a flamewar. I just wanted to say that Win32 users already have plenty of N64 emulators where linux/unix users don't. So at this point there is more use in focusing on linux/unix to reach more users. It the long run Mupen64Plus may switch to an API Driven Core. Then it would be easy for other developers to write a Win32 frontend. But that's just my opinion.

How can you play your favourite games, while my favourite games still has unresovled bugs?

Just kidding!
Thank you for your work and have fun playing your games. :bouncy:

 

[ebenblues]

Thanks for the great buglist.

To the Win32 port requests:
Well I don't get it! There are about 10 N64 emulators for the Win32 plattform, but only 1 for linux/unix. IMHO there is absolutely no need for another Win32 N64 emulator. So why wasting time on Win32 compatibility?

If people are asking for it, then maybe there's something we offer that the others don't? We're hoping to eventually integrate netplay, which would probably be a desirable feature on all platforms. Also, the original intent of mupen64 was to make an emu that could be easily ported to multiple platforms, so I don't think the requests are that out of line.

x86_64 / mupen64-amd64-1.2-bin-64 / blight
1. It is possible to assign one axis AND one button on a gamepad at the same time to a button in the emulator. e.g. left on the second analog stick and the first button on the pad can trigger "C left" in the emulator.

I just noticed this last night and wasn't sure why anyone would want to do this...currently, for each button, blight_input allows you to have a keyboard key, controller button, controller hat, controller axis, and a mouse button set all at the same time. After our next release, I'm hoping to refactor the blight_input plugin in a few ways. One of them has to do with this. I was thinking of changing it so only one button/axis/hat is mapped to each input on the n64 controller. To keep the flexibility that the current plugin has, we could create input profiles where each profile defines different controller mappings. So you could define a keyboard profile, 1-player profile, 2-player profile, or different controller profiles for different games. Maybe eventually, we could add some sort of ini file capability so you can automatically switch to a particular controller profile when a certain rom is loaded. Any feedback anyone has on these ideas is welcome.

Also, FYI, I fixed the --noask and "too many dialog windows" problems you reported earlier. Thanks for testing!

 

[Richard42]

I didn't mean to start a flamewar. I just wanted to say that Win32 users already have plenty of N64 emulators where linux/unix users don't. So at this point there is more use in focusing on linux/unix to reach more users. It the long run Mupen64Plus may switch to an API Driven Core. Then it would be easy for other developers to write a Win32 frontend. But that's just my opinion.

I totally agree with you. But I also see their POV, in wanting to have another high quality EMU option available. Right now the reality of Mupen64 development is that we're only working on Linux because the devs are using Linux as their platform of choice. And since this is the most underserved segment of the N64 emu scene, there are a lot of people who appreciate it.

How can you play your favourite games, while my favourite games still has unresovled bugs?

Just kidding!
Thank you for your work and have fun playing your games. :bouncy:

I'm just enthralled with crash ripto's rampage and metroid fusion on my 32" trinitron TV with wireless controllers and the HQ3X filter with VBA-M. The filtered visuals are amazing and the gameplay is excellent.

 

[phorsyon]

At this point the only feature that mupen64plus offers which others don't is linux and 64bit support. It's not like I am totally against a win32 port. I just think it's less important right now. If netplay gets integrated then multiplatform support gets more important. On the other hand if all N64 emulator developers would design one network protocol for all N64 emulators.... wait a minute I just started dreaming. LOL

I am just a bit scared that mupen64plus will also die because it tries to do everything at the same and nothing get's done. This would leave me without any N64 emulator again.

I like your ideas for the input plugin. Multiple mappings just confuses user. Input profiles offers much flexibility. IMHO, you should focus on profiles for multiple/different controllers instead of profiles per games. Console games mostly already offer the best mapping possible or allow you to change the mapping ingame. The more likely thing to happen is that you invite some friends to play with mupen64plus on your htpc and they want to use their own gamepads instead of your already configured and working ones. This happend to me. I had to backup my blight config and created a new one. Now I always have to symlink between 2 configs.

So it would be great if you could create small key mapping configs for different gamepads and to create controller set configs with 1-4 of these gamepad configs. E.g.: I have 4 Saitek gamepads which behave identically. So i would create a gampad mapping config called "blight_input_pad-saitek.cfg" and a "blight_input_controller-set.cfg" config.

blight_input_pad-saitek.cfg

mouse=0
DPad R=key( -1 ); axis( 4+ )
DPad L=key( -1 ); axis( 4- )
DPad D=key( -1 ); axis( 5+ )
DPad U=key( -1 ); axis( 5- )
Start=key( -1 ); button( 9 )
Z Trig=key( -1 ); button( 3 )
B Button=key( -1 ); button( 0 )
A Button=key( -1 ); button( 1 )
C Button R=key( -1 ); axis( 2+ )
C Button L=key( -1 ); axis( 2- )
C Button D=key( -1 ); axis( 3+ )
C Button U=key( -1 ); axis( 3- )
R Trig=key( -1 ); button( 7 )
L Trig=key( -1 ); button( 6 )
Y Axis=key( -1 , -1 ); axis( 1 )
X Axis=key( -1 , -1 ); axis( 0 )

blight_input_controller-set.cfg

[controller 0]
plugged=1
mempak=1
device=0
keymap=blight_input_pad-saitek.cfg

[controller 1]
plugged=1
mempak=1
device=1
keymap=blight_input_pad-saitek.cfg

[controller 2]
plugged=1
mempak=1
device=2
keymap=blight_input_pad-saitek.cfg

[controller 3]
plugged=1
mempak=1
device=3
keymap=blight_input_pad-saitek.cfg

This way you could have several controller set configs, which further could be used on a per game basis if one really needs that too.

So what do you think?

BTW: Thank for your work and fixing my reported bugs. ;-)

 

[mudlord]

To the Win32 port requests:
Well I don't get it! There are about 10 N64 emulators for the Win32 plattform, but only 1 for linux/unix. IMHO there is absolutely no need for another Win32 N64 emulator. So why wasting time on Win32 compatibility?

Well, Mupen64 is after all a multi platform emulator, so it makes sense that a Win32 port is available. Denying people access to a emulator just because it doesn't fit in thier philosophies is very lame.

Take for example VBA-M. One of the major goals of that is we want multi platform compatibility from the get go. Thats why we have a fully working Linux/Mac/Windows SDL port. And we are going so far as to do the current Windows GUI entirely from scratch, in Qt4 just so Linux and Mac users get exactly the same interface as the Windows port. We don't think its fair just sticking to one platform, and I personally think a API driven Mupen64 core is the way of the future.

I'm just enthralled with crash ripto's rampage and metroid fusion on my 32" trinitron TV with wireless controllers and the HQ3X filter with VBA-M. The filtered visuals are amazing and the gameplay is excellent.

Glad you like it. :bouncy:

 

[okaygo]

Well, Mupen64 is after all a multi platform emulator, so it makes sense that a Win32 port is available. Denying people access to a emulator just because it doesn't fit in thier philosophies is very lame.

Take for example VBA-M. One of the major goals of that is we want multi platform compatibility from the get go. Thats why we have a fully working Linux/Mac/Windows SDL port. And we are going so far as to do the current Windows GUI entirely from scratch, in Qt4 just so Linux and Mac users get exactly the same interface as the Windows port. We don't think its fair just sticking to one platform, and I personally think a API driven Mupen64 core is the way of the future.



Glad you like it. :bouncy:

You should get back on MSN

 

[phorsyon]

Well, Mupen64 is after all a multi platform emulator, so it makes sense that a Win32 port is available. Denying people access to a emulator just because it doesn't fit in thier philosophies is very lame.

I am not doing this, read my last post.

Take for example VBA-M. One of the major goals of that is we want multi platform compatibility from the get go. Thats why we have a fully working Linux/Mac/Windows SDL port. And we are going so far as to do the current Windows GUI entirely from scratch, in Qt4 just so Linux and Mac users get exactly the same interface as the Windows port. We don't think its fair just sticking to one platform, and I personally think a API driven Mupen64 core is the way of the future.

I agree that's the way to go. Separating the core application from the GUI and offer one interface for all GUI devs on all platforms. This way no resources gets wasted. I just felt into that nightmare your were going "fix" the code to compile on win32, produce a mess, drop linux support and finally let the project die again.

So more or less just a missunderstanding. I am glad. :bouncy:

 

[ebenblues]

I really need to create some kind of a spreadsheet to track these problems until they get resolved; maybe I'll do it tonight.. That's if I can tear myself away from playing crash and metroid on my VBA emulator.

Now might be a good time to reconsider a simple bug tracking system. Someone in another thread had mentioned google's free project hosting service:

http://code.google.com/hosting/

Maybe this is a better option than a spreadsheet? okaygo modified the TODO list today to say which bugs he's working on, and that works, but it's kind of primitive to have everyone modifying the TODO list to manage who's working on what. And even that wouldn't be possible with a spreadsheet (unless it's committed to svn too). So what do you think?

As for you playing VBA...what's the point of working on an emu if you don't enjoy gaming?

 

[ebenblues]

I like your ideas for the input plugin. Multiple mappings just confuses user. Input profiles offers much flexibility. IMHO, you should focus on profiles for multiple/different controllers instead of profiles per games. Console games mostly already offer the best mapping possible or allow you to change the mapping ingame. The more likely thing to happen is that you invite some friends to play with mupen64plus on your htpc and they want to use their own gamepads instead of your already configured and working ones. This happend to me. I had to backup my blight config and created a new one. Now I always have to symlink between 2 configs.

Thanks for the feedback. My goal is to make the profile system flexible enough that you could use it for different controllers or different games. The reason I want different profiles on a per-game basis too is because I have a logitech controller that's basically a PS2 controller clone. For Mario64, I like the C direction buttons mapped to the right analog stick since in that game, the C buttons are used to control the camera. But in other games, this is a terrible mapping. But you're right, it's not that necessary if you have a n64 controller/adaptoid type setup.