Future directions for Mupen64-amd64

[Richard42]

Hello N64 fans. Now that v1.2 is out, and the major contribution that I wanted to make is done (64-bit dynamic recompiler), I wanted to start a thread here to discuss the future of this emulator project a little bit.

First, the potential new features. Günther has done some great work in porting the Glide64-wonder-plus video plugin to amd64. This is very valuable in adding a 3rd video output option (and a very good one) to the project, so I'll integrate this. I played with it a bit today and it shouldn't take too much work.

Another thing is OSX/PPC integration. I looked over the ported code in lamer0's repository, and I while I didn't check it out in depth, it looked like sort of a mess at first glance. Since I don't actually own a Mac, there's no way I can make this work by myself. If a developer (preferred) or tester who has a PPC mac and/or an x86 mac would step forward, then we could tackle this as well.

A couple of the other developers who have recently submitted code have also expressed a desire for their own new features, so there may be other changes and additions as well.

Finally, I would like to solicit ideas for a new project name. There are 2 main reasons for this. For one thing, a lot of people read the name "Mupen64-amd64" and don't realize that the project is backwards-compatible and still runs on 32-bit machines as well. Secondly, the project is growing to encompass more than just Mupen64: it also includes Rice Video and soon the Glide64 plugins. So it would be nice to have a new inclusive name for the project. Some possible things to consider:

* The project is multi-platform, but it's really geared towards Unix. I tried not to do anything to break Win32 compatibility, but since no-one is testing and building on this platform, it's probably becoming less compatible.
* The thing that really sets this project apart from all other N64 emulators is native support for 64-bit (AMD64/EMT64) processors. But it builds and runs under 32-bit as well.
* The name can be anything - it doesn't have to include "Mupen64" or "Rice Video" or anything like that. When I make releases I'll pay proper tribute to these projects, but it's really a collection and extension of these other projects.

So, I'd like to hear ideas from you. Anybody got a good idea for a cool name for a unix N64 emulator compilation?

 

[ebenblues]

First, the potential new features.

Here's my 2 cents. I'm pretty new to this project, so hopefully I don't mention something that's already there:

1. RiceVideo doesn't work at all on my Unichrome graphics chipset, so obviously, my top priority is getting it to work.
2. Add fast-forward function similar to zsnes.
3. Modify blight input plugin so special functions such as exit, fastforward, etc can be mapped to controller buttons/keyboard keys. FYI, I use mythtv and I have my other emu's setup so one of my controller buttons is mapped to exit.
4. Modify blight input plugin to fake analog stick for controllers that don't have analog control sticks. For example, in mario64, you could have it so the controller defaults to run (like it does currently), but you could assign it so holding down another button while using the controller will make mario walk instead of run.
5. Network play, including in-game voice chat. Mario Kart 64 battlemode anyone?
6. Either get one set of plugins (video, audio, rsp, input) to work as well as possible with all games and make that the default, or (more likely), make it so the emulator will automatically "know" which plugins to load depending on the ROM. Not sure if mupen already has something like this, but I'm sure it could be improved. I'm thinking of making it more automagic so newbies don't have to mess w/ the plugins if at all possible.
7. Minor UI issue: Currently, if no rom is loaded, I highlight a rom from the browser and then press the play button, it tells me no rom is loaded. It should load the highlighted rom and start playing it.

I'll post if I think of more. Feel free to comment.

Finally, I would like to solicit ideas for a new project name. There are 2 main reasons for this. For one thing, a lot of people read the name "Mupen64-amd64" and don't realize that the project is backwards-compatible and still runs on 32-bit machines as well. Secondly, the project is growing to encompass more than just Mupen64: it also includes Rice Video and soon the Glide64 plugins. So it would be nice to have a new inclusive name for the project.

Agreed. Here are random thoughts:

• nix64 or 64nix
• LiN64 (kind of linux-centric, but I like the "N64" in the name...hopefully that's not a trademark violation)
• munix64
• muN64
• em64 (playing with "emu" and the "N" sound of "N64")

Maybe these ideas will lead us to the right name.

 

[Toasty]

Of those suggestions, LiN64 kinda jumped out at me. Anyone know if "N64" is trademarked and, if so, if that would cause problems with it being part of a name? (Even if that name isn't chosen it would still be good to know.)

 

[Richard42]

Of those suggestions, LiN64 kinda jumped out at me. Anyone know if "N64" is trademarked and, if so, if that would cause problems with it being part of a name? (Even if that name isn't chosen it would still be good to know.)

From USPTO, the word mark "N64" is trademarked:

Word Mark N64
Goods and Services IC 028. US 022 023 038 050. G & S: electronic game equipment for playing video games [ and tutorials; electronic game programs; video game programs; and educational video game programs ]. FIRST USE: 19970619. FIRST USE IN COMMERCE: 19970619
Mark Drawing Code (1) TYPED DRAWING
Serial Number 75077622
Filing Date March 25, 1996
Current Filing Basis 1A
Original Filing Basis 1B
Published for Opposition November 19, 1996
Registration Number 2107868
Registration Date October 21, 1997
Owner (REGISTRANT) Nintendo of America Inc. CORPORATION WASHINGTON 4820 150th Avenue N.E. Redmond WASHINGTON 98052
Attorney of Record Jerald E. Nagae
Type of Mark TRADEMARK
Register PRINCIPAL
Affidavit Text SECT 15. SECT 8 (6-YR).
Live/Dead Indicator LIVE

I have no idea if this would prevent us from using "LiN64" though. OTOH, if we do get OSX compatibility then this name would be excluding Mac owners.

 

[Hacktarux]

I have always considered your work as something that i will include in next mupen64 release. (Ok, i know, i'm a bit slow at developping right now... but i hope to improve that in a few months).

I wouldn't mind if you named it like it is the "experimental" or "unstable" or "developement" branch of mupen64. I don't like these words because your work seems fairly stable but you get the idea. If you want to have another name for your branch it's ok too.

Basically, when i'll merge your work with mine, i'll only check that you have not broken portability or that it's not interfering with something i'm planning to do in the future. Other than that i see no reason to reject anything you have done.

Anyway, i have a request.... if someone work on the OSX port. PLEASE add control configuration option. It'd prevent me answering 5 emails each day that ask how to use a controller on OSX

 

[Danny]

Richard, about the ppc support, you have a ps3 right? Fancy making a PS3 branch? I will gladly test lol

If not I understand why as you explained in another thread.

Either way thanks Richard, Hacktarux and nmm for your continued brilliant work on giving Linux a great N64 emulator worthy of any windows competitor.

Kudos

 

[Surkow]

I'd like to hear ideas from you.

I would suggest support for rumble and deadzone configuration. Currently blights input plugin configuration screen eats up 100% cpu time just by opening it (Mupen64-amd64 v1.2).

 

[Richard42]

I would suggest support for rumble and deadzone configuration. Currently blights input plugin configuration screen eats up 100% cpu time just by opening it (Mupen64-amd64 v1.2).

People have made some good feature suggestions here; I'll add them to the TODO file. Regarding rumble, unfortunately SDL does not yet support that (though I think they plan to). Only after SDL has support for rumble can it be added to the Blight input plugin.

I wouldn't mind if you named it like it is the "experimental" or "unstable" or "developement" branch of mupen64. I don't like these words because your work seems fairly stable but you get the idea. If you want to have another name for your branch it's ok too.

I'm thinking more along the lines of a name for the downstream project, of which I post the releases here. It's not just Mupen64, but also includes RiceVideoLinux and soon will include Glide64. I'll probably still call the Mupen64 component of this (my branch of Mupen64) "Mupen64-amd64" to differentiate this from your branch. I just would like to have a catchy name for the collection which doesn't suggest to people that it's only intended for 64-bit machines.

 

[JOPS]

I just would like to have a catchy name for the collection which doesn't suggest to people that it's only intended for 64-bit machines.

How about Mupto64 (Mupen64 up to 64-bits)?

 

[blargity]

A few things

I second the desire to bind save state, exit, and the like to joystick in the input plugin.

I'd also like to see reasonable multi user support. We have a *nix app that can't be installed out of a users home folder. I imagine if we could make that work, then distros would be able to supply Mupen64, and I could just apt-get it.

I'd like to see some stability improvements, mostly in the UI, not in the emulation itself. Of course, that might require me reporting the bugs ;-).

And of course I want better compatibility, but I think that goes without saying, and is a constant thing. I'd like to see the Rice Video plugin support some of the render modes available in the Glide plugin, since Rice generally performs better on my box, but doesn't actually play all games. Still, that's pie in the sky.

 

[thatmariolover]

An OS X port of the *nix improvements is obviously what I'd like to see. Sorry to hear the code is in such a sad state. I have an x86 mac I'm willing to do extensive testing on. I do have a PPC Mac as well, but it's relatively old (though it can run OS X 10.2 for sure, and probably at least test the PPC code).

If that's helpful, then great. If not, I could try reading up on coding and compiling for OS X - though I have only a basic understanding at this point.

 

[ebenblues]

I'd also like to see reasonable multi user support. We have a *nix app that can't be installed out of a users home folder. I imagine if we could make that work, then distros would be able to supply Mupen64, and I could just apt-get it.

I whole heartedly agree with you. Implementing it will be a balance though. Richard42's perspective is he doesn't want the program doing anything "behind the user's back". Automatically creating a ~/.mupen64 dir w/ conf files/plugins, etc on first run kind of goes against that philosophy, so we'll have to see if we can implement this in a way that is multiuser friendly, but is still in line with that philosophy (prompt the user to create these files or have a commandline switch that does it maybe). For now, I'm going to at least change the program so it looks for a ~/.mupen64 directory. The current code doesn't have that support.

Any suggestions on how you'd like it to act or how we could achieve the right balance would be appreciated.

 

[Richard42]

I whole heartedly agree with you. Implementing it will be a balance though. Richard42's perspective is he doesn't want the program doing anything "behind the user's back".

The base Mupen64 0.5 actually did have support for this 'multi-user' mode, but it wasn't really documented and I think I found a bug which actually prevented it from working at all. That's while I just removed it all - to simplify it and get at least one mode of operation working correctly.

Doing this the 'right' way would actually require a fair amount of work. The binary files (executable and shared libraries) should be stored in one place (system dir) and the config files in another (home dir). This would entail modifying mupen64 and all of the plugins which have config files (blight input, rice, jttl_audio, glide64), and probably adding code paths to pass along the config dir from mupen64 to the plugins. The config dir could be selected automatically at run-time (via searching current dir and home dir) or specified via a command-line switch.

Anything less than this and you're still going to have problems. The whole 'current directory' concept that's prevalent in the code should be abolished and replaced with explicit paths. Relying on the 'current directory' to be in the right place is bad practice.

 

[BomarJr]

i just wanted to say, THANK YOU!!!!

i have been waiting for somebody to update the osx version cause it's been LONG overdue (plus it no longer works with leopard)

so i give my thanks (again) and i wish u luck.

 

[thatmariolover]

i just wanted to say, THANK YOU!!!!

i have been waiting for somebody to update the osx version cause it's been LONG overdue (plus it no longer works with leopard)

so i give my thanks (again) and i wish u luck.

I'm using it on Leopard (10.5.2) on my Intel Mac. Granted it's buggy and crashes when you screw around in the menus, but it works on a basic level. Obviously we need an update though.

 

[nmn]

Wow, i have been gone for a very long time. Been busy. Anyways, I hope to do more for the GUI, maybe I'll do multiuser while i'm at it. (But i'll still be somewhat busy. )

 

[Surkow]

Wow, i have been gone for a very long time. Been busy. Anyways, I hope to do more for the GUI, maybe I'll do multiuser while i'm at it. (But i'll still be somewhat busy. )

I can remember vaguely that you wanted to use Qt instead of GTK for the GUI. Do you still have plans to do that?

Edit: This already answers my question.

The qt4 GUI is a side project, GNOME users may use it if they dislike the GTK one as it will still work great, and I'm also not going to cease work on the GTK2 version. Infact, I have implemented PNG icons that are dynamically loaded and made better icons for the GTK version, so i hope to release that as soon as i make it work when the cd is not the application folder (I'll probably copy off of the methods used to locate plugins and such since that will also respond to the compile settings that tell it where to look, in a special folder or the directory of the app)

More about the qt4 gui:

- It will probably resemble the Windows one more, i dislike the way the GTK2 one looks anyways
- It will not effect the plugins, unless i decide to port them too, but thats for another day
- It won't make the graphics plugin appear inside the window

I'm still thinking about ways to make the graphics appear in the window, right now my thoughts are still on an optional OpenGL context manager that plugins can use via a special Mupen64 Linux version extension of the plugin API. Its probably not all that hard to do and it would definitally help to make Mupen64 for Linux a bit more user friendly.

I would love to see the plugins ported to Qt as well. Also, would it be possible to give the blight plugin a native interface?

 

[blargity]

I've done some 'multi-userfication' before. Sounds like mostly grunt work, rather than anything technically complicated. It's a goddamn processor emulator, after all, I'm fairly sure the interesting engineering has already occurred.

I'll take a look at doing this myself. I program for a living, so that often takes the joy out of personal projects, but I might be able to get it up to speed.

Certainly the existing FD.O standards help out a lot here. I'll see how far I can get, and then let everyone know.

 

[nmn]

I still wish to add a Qt GUI to Mupen64 and multi-GUIs to all of the plugins, but I'm working on improving the native GTK 2 GUI first, since I lost all of my Qt code.

 

[Tillin9]

My wishes for Mupen64:

Very Doable:
- Aspect ratio independent output for those of us with widescreen monitors.
- Multi-user, if only so that distros can begin packaging Mupen leading to more users and more development.
- Better controller support, like macros for dynamic range to compensate for lack of analogue sticks.
- Qt based GUI and general GUI improvements to make Mupen more user-friendly.

Not so easy:
- Optimize the code since some of us have slower processors / graphics cards.
- Get a video plugin which can mesh with an ATI driver, ideally the open source radeon one. Rice video has black lines between textures, other plugins just barf unless the OpenGL level is turned down to the point where its no longer playable.
- Fix clipping / texture issues (Zelda64 for example) and increase game compatibility.
- Fully integrated and supported netplay.

Pie-in-the sky:
- MIPS CPU support so that Mupen could run under Linux-MIPS and/ or IRIX.