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/viewtop...=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.