This is a small update, and due to personal reasons I am ceasing the maintenance.
- Changed the dpad of Super Pad skins to keep the consistency with other default skins.
- Changed the open graph image so it looks not awkward on Google search. While the aspect ratio is 2:1, Google only show the centre square of the image.
If nothing changes, the domain will expire at 4 June 2023. Mini Padder will still be available at https://dinir.github.io/mini-padder afterwards.
I am glad that I have made something I want that could be also useful to others, at least once in my life.
Thank you for your interest in Mini Padder.
[5.4.1] Dpad Focused Gamepad Skins Separation
Super Pad and F Commanders are for gamepads that has a dpad on the left side. I don't know how people use all kind of SFC pads, and Fighting Commanders before OCTA offers a switch to change how dpad is recognized by the recipient.
This update separates these skins into two variations: DP ones and LS ones.
LS variations work like the joystick skins and Mega Pad skin.
DP LS Listing unchanged marked with (LS)
Input for Dpad Dpad Dpad, Left Stick Fade Effect on Dpad Each Buttons Whole Pad
It seems like it's intuitive for many users to turn off the fading effect. The skins affected have been showing left stick inputs on a dpad under the identical dpad used for dpad inputs, which makes the stick input animation obstructed by the later dpad layer. Now they can be seen properly with fade off, via separated skin variations.
= = =
[5.4.0] Gamepad Skins Brightness Modification
Some games focus on precise control on analog inputs. That's two analog sticks and both the triggers. This update makes small changes to some gamepad skins so the shoulder buttons including the triggers can be as noticeable as the sticks are.
- XInput, DInput, Disc D-pad: shoulder button background is now as dark as its stick background
- F Commander: shoulder label colour is now the same to normal button labels
- XInput, DInput, Disc D-pad, F Commander: shoulder button active sprites have 1 pixel thicker outlines
I found that if R2 in a controller emits signal as both an axis and a button, it can interfere the left stick assignment and be wrongly assigned as left stick x axis. I changed the order so this can be avoided, unless a controller sending a touchpad click signal as an axis appears and gets popular.
A mapping for 'Unknown Gamepad' is also added. I found it appearing when my DualShock4 is plugged and not having its lightbar lighting. Since I believe DualShock4 is a standard DInput controller, I hope having this mapping made with it added to the repository is okay.
This is a simple change you can immediately notice. I hope this looks better.
Also I found that scrollbar customization is working on OBS 27.0.1 Browser, so I changed the look of it. Finally all the three rounded corners are now visible. I made the top-left corner to be not round so users can use the corner pixel to tell if cropping worked well. But I don't know if anyone is actually doing that, so I might make it round later.
Background returned to black. As I changed the control panel to be dark, it would be stressing eyes if the default background is still white (fallback from transparent).
It's for HORI Fighting Commander, and its many variants up to the recent model called 'OCTA'.
While making this, I added one of the features I wanted to add for a while. It makes a stick or a dpad and their background showing up on different layers, so the movements of both can be easier to read when they are both frequently being used.
Octa skin uses this feature, the stick background won't obstruct dpad. It's a gamepad for fighting games, so I think dpad is more important on it.
This brought some updates on Disc Dpad skins as well, and I am thinking of implementing that on default XInput and DInput skins, for their dpad and face buttons.
I wanted to add skins for HORI Fighting Commanders for a while, but I was skeptical about how useful they could be since they can't tell which button the user actually pressed: multiple buttons output a same input signal, multiple parts of a skin gotta be lighten up at the same time. Now the skins are available, you can decide if the skepticism was worth holding them back.
= = =
Joystick skin gets the N layout variant. It's told to be based on Neo-Geo button setup. Surprisingly more common than I thought to be, I can still find streams displaying a joystick in this layout every once in a while.
At first I made this app I thought users can just remap their inputs on a preferred existing layout, but then if they use XInput, this means they have to change the mapping every time they switch a controller. So I made this layout, and the Mega Pad variants are on the same gist. I am expecting to make more skins of this kind, which users with standard controllers can use without mapping the inputs. For controllers that have funky mappings, I still think it's best if you can connect them as a DInput controller, so you can keep different mappings per controller kind.
= = =
- bug fix and feature addition
- fix custom skin file type check
Last update added support for text files, but there was a mistake handling loaded files that prevented loading custom skins.- add a way to designate canvas to use on the instruction level
Instructions can draw on a different canvas other than the one designated by the input group by giving them an optional `layer` property.- skin update
- add F Commander skins
This includes the 6 button model for PS4, XBox One, and Switch, and the next generation model with an octagonal gate, for XBox X/S.- update existing skins
Disc Dpad skins now have the background for dpad moved behind the stick background.
Dpad sprite of XInput also got smoothed by a little bit.- add joystick N layout
Apparently this specific layout is told to be based on Neo-Geo.- mapping update
- add mapping for Switch Pro Controller
On DInput connection, this controller is expected to work identically to DualShock4. With the mapping added, the controller will be shown with the appropriate name.
The accepted extension was `.mpskin.json`, but now the app looks for.json
,.txt
, and.mpskin.json
, in that order.
All the default skins' config files are changed to `.json`, but any custom skins made before this update having `.mpskin.json` will still work. Wiki and a template for sharing a custom skin on GitHub also got updated to follow the change. Now you can directly load a custom skin downloaded from the Discussions category.
As the result, the initial loading impact has gotten bigger while fetching the config files in all accepted extensions. If it's found out to be troublesome, I may have to revert some of the changes and only support `.json`. Unless I can figure out how to replace a recursion holding a Promise with an iteration.
I did an ego search yesterday and found out someone made a video walkthrough on how to use Mini Padder. Thank you so much for spreading the words, Andilippi!
While watching the video I also found out that I forgot to remove the megapad variations from the skin list. Mini Padder would remove it from the list and put a default skin back to the gamepad slot, but it would be confusing to have a skin on the list that seemingly won't change anything.
This release fixes this bug and cleans up the skin list.
This update brings a change to MegaPad skin after I actually learned about the terrible present that is all the differences between two modern sega gamepads: Retro-Bit ones and 8BitDo's M30. It was so exhausting to realize the truth so I am gonna share what I could find in the journey below. I'll put changelog right below because the journey was quite long.
- replaced MegaPad skin variations
removed button label variations, and added mapping variations
This may render any custom mappings of the mentioned gamepads on XInput not working properly on MegaPad skins,
so if you have one you need to remap them on Mini Padder.- removed some skins from the default skin list residing inside GamepadRenderer
Disc D-pad, MegaPad, HBox- update message now can show bold texts and links
Realization
The existing MegaPad skin didn't really match the mapping of either of the two gamepads, so I think anyone who's using the gamepad had to remap before using this skin. It was weird, the skin's layout was based on M30's DInput mapping, at least it should've worked on M30.
I was wrong. Even the M30's mapping was different if it's connected on XInput.
No Info Available
Retro-Bit
Retro-Bit manuals can be found on their support site. There are total of 14 manuals for each of the available models, divided by the region, the connection method, the existence of the shoulder buttons. That's after excluding 'Wireless Receiver' ones.
Aside that their manuals are not even in the same format, it was frustrating to find out parts of the available information there seemingly related were actually all irrelevant, to this case where I am trying to find mapping for the gamepad API of Javascript. The 'numbers' for each buttons for DInput are not the numbers the browser will show, and even that was not available on all of the manuals. XInput mapping was all shown as Xbox controller button labels, which was really unhelpful because there are so many controllers that support XInput while having completely different mapping from the standard mapping. Mainly 8BitDo ones, but that's on later.
None of the numbers you can see above are relevant to my case, and none of the non-numbers are useful for the obvious reason. What you can grab is button indexes.
8BitDo
This looked easy to find the working mapping at first because the "information" was available right there on their FAQ page for M30.
Such a simple explanation, very easy to consume. But gamepads often support at least two methods: XInput and DInput, 8BitDo's cases usually much more than that. How can they end up writing such simple info on the FAQ page? I should've doubted this obvious thing when I saw it first.
It turned out their manual shows yet different mapping.
Even worse, the good feature of their products that is firmware update support, apparently sometimes updates the mapping of the gamepads as well. Terribly, they don't list that on their changelog, and the latest issue I can find on the internet was this 2-year-old archived reddit post.
8BitDo always had rather erratic layout when it comes to XInput mapping of their gamepads. I had the most gamepads of this manufacturers, but I know this little more of experiences will not earn me any useful general knowledge as I can't be sure about anything on their gamepads they released and will in the future.
General
As all their official materials are not helpful for Mini Padder which uses the gamepad API on Javascript, the only way I have left is googling. But it's 2021, websites have to prepare a message to ask their visitors to enable Javascript when they find their browser is blocking it. Googling was impossible for various reasons. Even if you get few search results, most of them are suspicious pages that redirect you to somewhere only to immediately close themselves.
I have put a star on the repository that collects all the found gamepad mapping for SDL2 Game Controller. It's obviously something else, and I really wish such thing also exists for Javascript Gamepad API. This is a bit unrelated, but the website I often ask any users to use to see the mapping decided to put their dataset on sale some times ago. The dataset is not the perfect one that has everything I need, but it was the only one of the kind I could easily find on the internet.
Anyway, I decided that it's impossible to gather any necessary info on the gamepads. Unless I find someone who's willing to help me. This definitely happens really scarcely, though.
The Mappings (I Guess)
Based on one friend I could bother asking (thank you CaptainGordon again), I could find out how Retro-Bit's sega pad is mapped. For it's Saturn USB varient. When I asked him to find the mappings, he told me that this gamepad doesn't work properly on DInput. Shoulder buttons and button combinations were not detected. So based on the only information I can acquire, I decided to forget about making mappings for sega pads and instead make copies of MegaPad skins that maps each button sprites differently, on their *expected* default mapping on XInput.
This is the mapping of the original MegaPad, if used on a standard XInput controller. Which is deprecated as of now.
This is the mapping of Retro-Bit Saturn pads and Megadrive pads, USB ones. Look how they manage to differ completely while all being made by the same manufacturers. I can't stop wondering if the Triggers and Bumpers difference was really necessary.
This is 8BitDo M30's mapping, "according" to their manual. One user I recently found told me how they were mapped, and that was again different to the manual. I decided to give up and follow the manual blindly. The mapping is also really different if connected as DInput, but it will take another ages for me to find someone who uses M30 on DInput.
Since DInput support looks impossible, and there's no way to tell different controllers if they're connected on XInput, I decided to just remove the MegaPad variations that has XInput and DInput button labels. If you want it back, you have to download it from past versions of the repository and manually arrange buttons.
This was exhausting. Especially because I am something of a Sega fanboy, only to find out the most popular choices of sega gamepad products had to be this different on things like button mappings.
Dividing MegaPad skin into layout variations was my best attempt to make this easier to deal with, but that will definitely look confusing to new users as they are all visually identical. This was exhausting.
In previous update I made a change to set deadzone for each stick separately, but at once when you click the corresponding button. This turned out to be not so great as I often find out I got one stick set but not the others. I needed to set one stick while keeping the other's value, and I ended up editing the mapping json manually.
So in this update, the deadzone setting buttons are finally divided into two representing each sticks. When it's not applicable, the button will say 'N/A'. Click the representing button to change the deadzone value of single stick you want.
- Super Pad skin uses dpad sprite for Left Stick
- Due to how fade-out works different for LS and dpad, there will be two sets of the same sprite showing up. If I can see which method is preferred by the gamepads users are using with this skin, I can either make dpad performing like stick, or remove the stick support.
- add a guide message for the skin menu
- OBS Interact window works not so smooth with dropdown lists.
- trim gamepad names on saving its mapping
- make deadzone feature to set deadzone for each stick separately
- change deadzone panel to let users change each stick separately
Diagonal Indicator
Since I added Disc D-pad and Mega Pad skins, the lack of a diagonal indicator in default skins always bothered me. Accidental diagonal inputs are bane of my existence, so being able to properly tell if such happened is very important to me, hence this release.
The sprite for the indicator is not final, and I'll keep contemplating about a possibly better sprite for it. But current sprite managed to look good on me, so it's included on the release.
Shoulder Buttons
I spent lots of times thinking of the design for shoulder buttons in default skins, and while I was satisfied with it, I was bothered that first area of trigger input is not visibly standing, because it comes down diagonally from a corner of a rectangle.
I shifted the trigger button shape into parallelogram, and shorten the width of shoulder bumpers to keep the overall width same. Now earlier press of a trigger button will light up as same amount of pixels as when it's just fully pressed.
Proper Dpad for Super Famicom skin
After I made Disc D-pad skins, I called it a day after making a variation of it with the SFC button layout. Later I changed the shoulder button shape and position of face buttons to make it close to the actual controller. It was but not enough, and I managed to get some time to make a proper dpad that would go with the controller. I hope it looks good enough to you.
I decided to go with still including the Disc D-pad when the skin receives a left stick input, on a new layer below the d-pad layer. This decision is not final, and I will see if it's better to just cut off the stick input from the skin.