Add a visual means of control mapping

[unknownbrackets]

This shows a PSP-shaped shadow, and buttons on top to help you map correctly.

I don't always immediately remember what controllers look like for various systems, and it's nice to see the original layout when mapping. Here's what it looks like:

One issue currently is that the buttons don't look so good at 1x PSP resolution, seems like texture filtering isn't playing nice. Didn't dig into that, but I think this is still a useful interface for many users.

Also adds a "Bind All" button that lets you bind each button in a row, which is common in other emulators. Fixes #9302.

Could've added volume/etc. buttons but we didn't have icons and I don't think they're important buttons. But this makes it easy to add them if we want to.

-[Unknown]

[hrydgard]

Fancy! Will look at it tomorrow.

[iota97]

Really nice, but I'm wondering if CTRL_HOME should be there.

I thought it was used just by some homebrews (same for the note, screen and the volume keys), if so I think it would be better just to bind the "mainstream" key here :)

[hrydgard]

The buttons look bad at 1x because we don't generate any mipmaps for the main UI texture. That could be fixed (but can easily lead to glitches which require extra padding around images in it to fix), or we could do our own fancy filtering in a shader, but as you say, not many people are likely running the UI at 1x anymore...

[iota97]

After finishing with VisualMappingScreen the main ControlMappingScreen doesn't get refreshed so it look like no change to the binding where made.

For reference this fix it:

index ebc924604..727dfcf4d 100644
--- a/UI/ControlMappingScreen.cpp
+++ b/UI/ControlMappingScreen.cpp
@@ -304,6 +304,8 @@ void ControlMappingScreen::dialogFinished(const Screen *dialog, DialogResult res
                KeyMap::AutoConfForPad(popup->GetChoiceString());
                RecreateViews();
        }
+       if (dialog->tag() == "visualizemapping")
+               RecreateViews();
 }
 
 void ControlMappingScreen::KeyMapped(int pspkey) {  // Notification to let us refocus the same one after recreating views.
diff --git a/UI/ControlMappingScreen.h b/UI/ControlMappingScreen.h
index d95818a3c..fd3eb6857 100644
--- a/UI/ControlMappingScreen.h
+++ b/UI/ControlMappingScreen.h
@@ -165,6 +165,7 @@ class MockPSP;
 class VisualMappingScreen : public UIDialogScreenWithBackground {
 public:
        VisualMappingScreen() {}
+       std::string tag() const override { return "visualizemapping"; }
 
 protected:
        void CreateViews() override;

[hrydgard]

It's really good-looking. I'm worried about the "Replace" checkbox from a UX perspective - whether it's understandable what it does. Maybe can make it clearer by showing a before/after somehow? not sure.

Related, when mapping a new key through the popup, it would also be good to see what the old mappings were. With the list UI, you already just saw it, but here it's kinda opaque (useful if you're not sure and just want to keep things the same, then you'll know what key to press to not change anything).

[unknownbrackets]

I'm wondering if CTRL_HOME should be there.

Well, I just added what there are icons for. I originally intended to make it pause but then thought that might be confusing in its own way. Also, some multidisc games apparently require pressing home.

The buttons look bad at 1x because we don't generate any mipmaps for the main UI texture.

I don't think this problem makes the addition worse in any way than what's currently on master, though.

I guess another option would be rendering the PSP or buttons to a temporary surface and sizing them down (i.e. manually mipmapping them, kinda) to avoid changing the entire UI texture or affecting other places.

After finishing with VisualMappingScreen the main ControlMappingScreen doesn't get refreshed so it look like no change to the binding where made.

I made it use the generation thing like Windows (and fixed Windows, which wasn't doing that properly.) I think it's better to avoid coupling with specific tags.

I'm worried about the "Replace" checkbox from a UX perspective - whether it's understandable what it does. Maybe can make it clearer by showing a before/after somehow? not sure.

I was thinking about making it a longer description and underneath the PSP (i.e. "Erase previous mappings" maybe.) That said, then the left side looks pretty weird.

Just to say, this part also isn't worse than current master - a pretty sizable percentage of users don't see those tiny [+] buttons or understand what they do. I think more people would figure out this Replace checkbox. Perhaps we should remove this and the existing control mapping screen until its UX is fixed too?

Related, when mapping a new key through the popup, it would also be good to see what the old mappings were.

We could add that, but it's not like you can't see the previous mapping on the other screen - which you have to look at first to even get here. Some may even just use this screen to see the PSP, and return to the other screen to actually add mappings (if they can figure out how it works.)

Another thing to think about is better explaining in the UX that you can map the same device button to multiple PSP buttons (some emulators and games actively prevent this, so users expect not to be able to.)

-[Unknown]

[hrydgard]

No the bad minifaction of the buttons at 1x is a very minor issue, absolutely not a blocker.

Yeah I'm absolutely not saying the old UI is ideal either - it also has bad issues and is not intuitive!

But now we'll have two UIs, that kind of depend on each other to get the full picture.

That said, I'm not at all against merging this, I think I will, and it's almost certainly a net positive as-is. I just wrote what came to my mind trying it - there might be a single UI that has the best of both worlds. Will probably try to make a complete redesign of the control mapping UI after 1.12 - but will it definitely make good use of the PSP shadow from this PR!

[hrydgard]

Code looks great and especially cool with the custom vector graphic!

I'm going to merge this, and we can iterate more on it later.