input improvements

[ebenblues]

I had Richard42 create a svn branch for me to use to make improvements to the blight_input plugin. Here is a list of the changes I'd like to make:

1. Create gtk version of the config dialog.
2. Change config so only one input is mapped to each N64 controller button/axis.
3. Add support for different input mapping profiles.
4. Allow mapping of emulator hotkeys (exit, pause, fullscreen, etc) to joystick buttons.

#1 is to address some complaints about the SDL config dialog (uses too much CPU, requires libSDL_ttf which doesn't exist on all systems, non user-friendly checkboxes). The new gtk interface will still use the nice picture of the n64 controller from the SDL interface. This will also help give the mupen64plus gui a more consistent look and feel.

#2 is to address the fact that multiple inputs (joystick button, keyboard key, mouse button, etc), can be mapped to a single n64 controller input at the same time. This seems confusing and not user-friendly. The input profile system (#3) is meant to be a better way to provide this kind of flexibility.

#3 is to allow the user more flexibility in defining their inputs. You'll be able to save a certain set of mappings as an input profile. There's also been discussion of creating profiles that can be assigned to certain joysticks (not everyone has an n64 controller w/ adaptoid), or profiles that can be assigned to certain games. I'm going to start simple and make it so you can setup a config similar to today's blight_input config and then save it as a profile. Then, ideally, mapping input profiles to games would be done via the rom browser. Mapping input profiles to different joysticks might require a change in the config dialog interface...I'll post more on this when I get there.

For #4, now that I think about it...I'm not sure if this function is something that really belongs in blight_input. I don't want to change the Controller plugin API for something that seems specific to mupen64plus and not the n64 itself, so maybe it'd be better to make this part of the general mupen64plus config dialog. The only downside to this is then the code can't prevent a user from mapping the same controller input to both a emu hotkey and a n64 controller input, which could be kind of annoying for the user, but maybe it's not a huge problem. I'm sure they'd figure it out quickly.

Any feedback on these ideas would be appreciated. Are there additional items you'd like added to the list?

 

[Surkow]

I'm happy you are willing to port the GUI of the input plugin to GTK. Do you also have plans to make a Qt version? I assume rumble isn't possible with an SDL based input plugin.

 

[ebenblues]

I'm happy you are willing to port the GUI of the input plugin to GTK. Do you also have plans to make a Qt version? I assume rumble isn't possible with an SDL based input plugin.

I don't know qt. The most likely person to port it to qt would be Tillin9, who's working on the qt frontend for mupen64plus. From what I've read, rumble isn't supported by SDL yet.

 

[Tillin9]

I have a Qt Blight GUI on the TODO. Right now I'm working on Qt for just the core emulator. Once I figure out some toolbar and integration issues, the dialogues for the plugins can get Qt options easily enough. Ideally we'd have some kind of API extension, but right now I'm thinking just a flag to build Qt or build GTK. This is for the 1.4 release at the earliest though.

I probably should open a thread on GUI conventions soon too. Some ideas:
- Accelerators? Our GTK ones don't work.
- Hot keys? They need to be listed, plus which things should have them.
- Should the main window and plugin dialogue aim to be 640x480 or smaller for people running the emulator to a TV?

Right now I've been working on getting a better controller graphic. Who designed the arrows on Blight's? Ideally we'd have a real 3D model we can take rasters for the build, but keep all the info. so that later the plugin (or additional GUIs) can make use of it. Basically I'm thinking the quality level of Snes9x's input dialogue, if not better .

 

[ebenblues]

- Accelerators? Our GTK ones don't work.
- Hot keys? They need to be listed, plus which things should have them.
- Should the main window and plugin dialogue aim to be 640x480 or smaller for people running the emulator to a TV?

Right now I've been working on getting a better controller graphic. Who designed the arrows on Blight's? Ideally we'd have a real 3D model we can take rasters for the build, but keep all the info. so that later the plugin (or additional GUIs) can make use of it. Basically I'm thinking the quality level of Snes9x's input dialogue, if not better .

Glad you're on board to do the qt version of the blight input config dialog. I'm hoping to make it a little prettier, but I'm going to try to keep a similar layout to the SDL config dialog if gtk is flexible enough to let me.

Here are my comments on your 3 questions above:

-The gtk accelerator problem is on the TODO list, but we need to look into how to specify accelerator keys in the language translation files. I haven't looked into it fully, but from glancing at the lang files, I see accelerator keys specified using the '_' chars in the translation itself. I'm guessing this is how gtk implements them (or maybe not since they don't work!), but I wonder if there's a better way to embed that kind of info in the lang files that will work w/ different types of gui toolkits.
-My changes will include a new tab to the mupen64plus config dialog specifically for hotkeys. I want the user to be able to view/change the keyboard mappings and also be able to map a joystick button to them.
-I run mupen64plus on an SD TV and the current size of the dialogs has not been a problem for me.

Regarding the 3D model stuff, I'm not sure what you're envisioning for the dialog, but I personally like the pic of the n64 controller w/ the arrows. I took a look at snes9x's input dialog and it is nice, but it lists all controller buttons and mappings in a table format, assuming the user knows which buttons are which. It does have a nice graphic of the x, y, a, and b, buttons to clear up some confusion.

 

[segalion]

Are there additional items you'd like added to the list?

Please, include rumble patch (at least for an innitial support in linux...)

Reference here...
http://www.emutalk.net/showthread.php?t=41977

Thanks in advance.

 

[gen2brain]

Hello, since you are talking about different toolkits I thought this might give you some ideas, I read this on snes9x forums, byuu ( bsnes ) has wrote some gui wrapper that can be used for writing guis only once, and then compiled for gtk,qt,win32... Here is the link to discussion -> http://www.snes9x.com/phpbb2/viewtopic.php?t=3703&postdays=0&postorder=asc&start=100

 

[Tillin9]

There is basically only one way to handle translation and accelerators, you specify them manually in each language. In gtk the accelerator is specified by _, in Qt it's by an &. My comment was only that the current accelerators don't work, I honestly don't know why. This could be a reserved character issue if we implement our own translation functions. I'm not up to that yet. Now that I'm manually making my GUI, its slow work to get everything to look right. There are just lists of UI classes and KActions, etc. to compile. The GUI is probably going to be around 1500 lines (just like the gtk one) for widget positions, text, shortcuts, etc.

I'm somewhat hesitant to have emulator function control mapping to the joystick done by the GUI. This seems much more like an input plugin thing. Let me know if I'm misunderstanding what you're trying to do.

The current default size of main is 600x400. I just wanted to know if our policy should be to keep things SD compatible or if I should aim to make larger dialogs. I happen to be on a dual 1920x1200 or 1600x1024 monitor setup most of the time, so I might have a tendency to do this. I'd hate to design a nice GUI and then be told it needs to be smaller.

The 3D model is basically to replace our current pic with something a little nicer. The resolution is poor, you can't see all the button names and the arrows on the right make very little sense from a UI port of view. Why are they 90 degree angles on one side and diagonal on the other? Also, why do some buttons seem to randomly have arrowheads and some don't. I think the SNES dialog is better, but having the button fields on top of the diagram is not what I'm going for. My plan is to have an even number of fields on both sides of the image with arrows all the same width, with the same size head, and most importantly to separate the image from the arrows so someone can change it in the future.

As far as the BSNES GUI wrapper, the problem is that he only wraps very common UI components. Try running the gtk GUI with the gtk Qt Theme Engine. The widgets are now Qt widgets, but meta-objects like the file loading dialogue are not the right ones because only low-level widgets are wrapped. Similar things like making the button icons use KDE themable ones with fallback can't be done this way. As I mentioned on my KDE GUI thread, I think we want the GUI to be fully native. Sadly this means a loss of portability.

 

[Richard42]

The current default size of main is 600x400. I just wanted to know if our policy should be to keep things SD compatible or if I should aim to make larger dialogs. I happen to be on a dual 1920x1200 or 1600x1024 monitor setup most of the time, so I might have a tendency to do this. I'd hate to design a nice GUI and then be told it needs to be smaller.

I think we should compromise on the GUI size. 640x480 is really a very small size but full HD would cause problems for quite a few people (even those using monitors). Unless someone here objects, I would suggest a goal of having a fully usable GUI with everything fitting in when using a resolution of 1024x768. Some HTPCs will allow you to set this resolution even when the output is SDTV, and for those who are totally stuck with lower resolutions, they'll have to either use the GTK gui, or launch the --nogui build from MythTV, or deal with some things maybe getting cut off. It's not that big of a limitation; they will still have options and it's time to move into the 21st century anyway.

 

[Richard42]

Please, include rumble patch (at least for an innitial support in linux...)

Reference here...
http://www.emutalk.net/showthread.php?t=41977

Thanks in advance.

Hey this is great; I didn't know about this. There are a couple of issues that I see with this patch:

1. This will only work with Linux
2. It uses file i/o on some special device files to activate the rumble. Does anyone know how well-supported this is for different linux distributions and different joysticks?

#1 isn't too much of a problem; we're only supporting Linux at the moment anyway and we could IFDEF if to avoid conflicts with other systems.

But I wonder about #2. I may give this method a chance, and if it works with my logitech rumblepads (fairly generic gamepads), I'll include it.

 

[ebenblues]

FYI, I just committed a change to svn (r96) that adds support for mapping emulator special functions (fullscreen, stop emulation, etc) to controller buttons. If you're comfortable building mupen64plus from svn, I'd really appreciate it if you could try it out and give me feedback. There's a new tab in the main configuration dialog called "Hotkeys" that allows you to configure these mappings.

 

[segalion]

But I wonder about #2. I may give this method a chance, and if it works with my logitech rumblepads (fairly generic gamepads), I'll include it.

See force feedback support

http://sourceforge.net/projects/libff/

supported devices http://libff.wiki.sourceforge.net/SupportedDevices

Sadly rumble in linux is a very dark stuff.

 

[Tillin9]

I tried your svn code. I like the new ROM browser. The Qt gtk theme engine gets along a lot better with the newer gtk filebrowser. As far as the function mapper, it seems to only be able to map joystick buttons, not keys. This seems like a minor thing to add.

However, I still don't see why this isn't in the input plugin itself. I mean what happens if you map an emulator function and a controller button in a plugin to the same joystick button. I'm probably just not following the SDL code well enough. I mean, can SDL tell that this is already mapped (and if so complain)? Do we still have only one SDL input loop? Or now do we have one for the plugin and one for the GUI? (Note: the svn code does seem to run 1-2 frames slower than 1.3 on my system regardless of plugins)

 

[santa8claws]

Lirc support?

Hi all, I'm glad to see all the energy and great development work here!

I am using the mupen64plus binary release on my Mythdora 4.0 system running FC6. It works well with the Glide64 plugin on my Intel graphics integrated mb, so hats-off to the plugin developers

One thing I saw in this release is LIRC support, so I've been trying to get it working but so far no luck. My LIRC subsystem is working fine with mythtv, mplayer, irexec, but I cannot get mupen64plus to recognize any remote buttons.

If I rebuild from the src with LIRC=1 to enable the support, everything runs the same except the newly built Glide64 plugin prevents the keyboard shortcuts from working and still no LIRC functions.

Which plugin gets the LIRC events? Does the blight plugin work in tandem with the mupen64 input plugin to get LIRC events and map to keyboard shortcuts? How can I further debug this?

Thanks!

 

[okaygo]

I think that we should be able to bind any keys (including keyboard) input to the ROM Browser shortcuts, and as for 'double' bindings... That is a choice the user must make, (It isn't really a big deal)

 

[ebenblues]

One thing I saw in this release is LIRC support, so I've been trying to get it working but so far no luck. My LIRC subsystem is working fine with mythtv, mplayer, irexec, but I cannot get mupen64plus to recognize any remote buttons.

Did you read the wiki page? There are only a limited amount of functions that can be used with LIRC. Read the page and if you're still having trouble, I can help you more:

http://code.google.com/p/mupen64plus/wiki/LIRC

 

[ebenblues]

As far as the function mapper, it seems to only be able to map joystick buttons, not keys. This seems like a minor thing to add.

Yes, that's correct. My change only allows mapping of joystick buttons/axes to special functions. Keyboard shortcuts are still hardcoded. I'll open an issue to track configurable keyboard shortcuts.

However, I still don't see why this isn't in the input plugin itself. I mean what happens if you map an emulator function and a controller button in a plugin to the same joystick button. I'm probably just not following the SDL code well enough. I mean, can SDL tell that this is already mapped (and if so complain)? Do we still have only one SDL input loop? Or now do we have one for the plugin and one for the GUI? (Note: the svn code does seem to run 1-2 frames slower than 1.3 on my system regardless of plugins)

We've always registered an SDL event handler in the main mupen64plus code. That's how we know to stop emulation when the user hits Escape or to toggle fullscreen when they hit Alt+Enter. My change modified this event handler to look for joystick events too. The input plugins actually don't register a handler for SDL events. The core emulator code periodically polls the input plugin for current input from the user. It's not event-driven in the sense you're thinking of. See the GetKeys input API call for details.

As far as where this functionality belongs and allowing users to use the same mapping for both an n64 controller input and a special function. I wrote about this in the first post of this thread:

For #4, now that I think about it...I'm not sure if this function is something that really belongs in blight_input. I don't want to change the Controller plugin API for something that seems specific to mupen64plus and not the n64 itself, so maybe it'd be better to make this part of the general mupen64plus config dialog. The only downside to this is then the code can't prevent a user from mapping the same controller input to both a emu hotkey and a n64 controller input, which could be kind of annoying for the user, but maybe it's not a huge problem. I'm sure they'd figure it out quickly.

So actually, it is possible for a user to double-map a controller button. We currently don't have code to prevent it and I don't personally see the need for it, but I could be wrong.

Thanks so much for trying it out. I really appreciate your feedback. Glad you like the new file chooser dialogs.

 

[Richard42]

So actually, it is possible for a user to double-map a controller button. We currently don't have code to prevent it and I don't personally see the need for it, but I could be wrong.

I think it would be more user-friendly and trouble-free if the software warned the user when double-mapping an input event. But it would also take quite a bit of new code to add this feature. It would require extending the link-level interface between the core and the input plugins, and adding connector code in the mupen64 core and the 2 input plugins. That's a lot of work for such a small feature.

I believe that the actual SDL events come in to the core first, so without this feature the core functions will always take precedence over the game controls. At least users won't be able to configure the game controls to override the quit command.

 

[ebenblues]

I think it would be more user-friendly and trouble-free if the software warned the user when double-mapping an input event. But it would also take quite a bit of new code to add this feature. It would require extending the link-level interface between the core and the input plugins, and adding connector code in the mupen64 core and the 2 input plugins. That's a lot of work for such a small feature.

That pretty much sums up how I feel about it. It'd be nice, but I think it's a lot of work for very little benefit.

 

[santa8claws]

LIRC support

Did you read the wiki page? There are only a limited amount of functions that can be used with LIRC. Read the page and if you're still having trouble, I can help you more:

http://code.google.com/p/mupen64plus/wiki/LIRC

Yes, the wiki is pretty straightforward. I have my lircd daemon running with the .lircrc file and I added entries for mupen64plus. As I said before, I know my remote, lircd, etc, is all working with mythtv. I also have irexec running as a daemon to run some scripts when the "power" button is pushed to stop/restart mythtv. My remote receiver is a USB dongle which interfaces with lircd through the network UDP client interface, so one point is that it is not a HID keyboard class input device. However, I've tested everything with 'irw' and see my remote buttons working.

Also, I've verified that the 1.3 version I rebuilt with LIRC=1 is installed and runs games fine. But none of the remote buttons do anything.

One side issue is that the newly built Glide64 plugin seems to block all keyboard events and I can no longer use Esc to exit, etc. So I reverted to using the pre-built 1.3 binary Glide64.so plugin, and now keyboard shortcuts work fine. Is this related to the lirc remote input?

Any idea what could be going wrong? Is there a way to log the lirc stuff to the console or verbose debug messages?

Thanks!