[PR #1659] [MERGED] pad: improve messaging when UI config doesn't match savestate config, and document some edge cases #604

New Issue

claunia · 2026-01-29T19:08:45Z

claunia commented

2026-01-29 19:08:45 +00:00

📋 Pull Request Information

Original PR: https://github.com/stenzek/duckstation/pull/1659
Author: @jstine35
Created: 2/18/2021
Status: ✅ Merged
Merged: 3/27/2021
Merged by: @stenzek

Base: master ← Head: jake/multitap_8x_devices_in_state

📝 Commits (2)

6449207 pad: remove unreachable code block in DoState
9634479 pad: improve UI messaging when UI config doesn't match savestate config, and document some edge cases.

📊 Changes

2 files changed (+165 additions, -120 deletions)

View changed files

📝 src/core/pad.cpp (+161 -119)
📝 src/core/pad.h (+4 -1)

📄 Description

Adds 8x controllers and memcards into the savestate.
maintains backward compatibility
simplifies some aspects of the logic used to load states
renames NUM_SLOTS to NUM_DEVICES because slots are ambiguous (2 sio slots on a console, 4 slots per mtap, sometimes one or both are called 'ports' instead, etc)

This PR can be merged as it is, or choose to wait until the full multitap impl on the emu backend is finished (eg, Incremental strategy for better reviews vs. a monolithic commit that bumps the savestate version # only once). I'm expecting to have the multitap functionality part ready before 2/22.

testing

I ran lots of tests loading states from prev version that contained about 6x different variations of controller and memcard bindings on the host UI.

for discussion

One of the typical caveats of emulating mtap is mapping the controllers. Not all games enumerate mtap controllers in the same way. For example, if a user has an mtap on slot 1 and a regular controller on slot 2 of the console:

device 1 -> mtap 1 slot 1
device 2 -> console slot 2
device 3 -> mtap 1 slot 2

... or ...

device 1 -> mtap 1 slot 1
device 2 -> mtap1 slot 2
device 2 -> console slot 2

This shouldn't impact how savestates are handled in any case. It should probably be implemented as a game-specific remap setting that just changes how emu devices 1->8 are shown to the user in the UI.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/stenzek/duckstation/pull/1659 **Author:** [@jstine35](https://github.com/jstine35) **Created:** 2/18/2021 **Status:** ✅ Merged **Merged:** 3/27/2021 **Merged by:** [@stenzek](https://github.com/stenzek) **Base:** `master` ← **Head:** `jake/multitap_8x_devices_in_state` --- ### 📝 Commits (2) - [`6449207`](https://github.com/stenzek/duckstation/commit/6449207e045645ee91519b64fb14f688ab6e0bac) pad: remove unreachable code block in DoState - [`9634479`](https://github.com/stenzek/duckstation/commit/96344799a08c3195a50f0f5e8371ede68d853b54) pad: improve UI messaging when UI config doesn't match savestate config, and document some edge cases. ### 📊 Changes **2 files changed** (+165 additions, -120 deletions) <details> <summary>View changed files</summary> 📝 `src/core/pad.cpp` (+161 -119) 📝 `src/core/pad.h` (+4 -1) </details> ### 📄 Description - Adds 8x controllers and memcards into the savestate. - maintains backward compatibility - simplifies some aspects of the logic used to load states - renames NUM_SLOTS to NUM_DEVICES because slots are ambiguous (2 sio slots on a console, 4 slots per mtap, sometimes one or both are called 'ports' instead, etc) This PR can be merged as it is, or choose to wait until the full multitap impl on the emu backend is finished (eg, Incremental strategy for better reviews vs. a monolithic commit that bumps the savestate version # only once). I'm expecting to have the multitap functionality part ready before 2/22. ### testing I ran lots of tests loading states from prev version that contained about 6x different variations of controller and memcard bindings on the host UI. ### for discussion One of the typical caveats of emulating mtap is mapping the controllers. Not all games enumerate mtap controllers in the same way. For example, if a user has an mtap on slot 1 and a regular controller on slot 2 of the console: device 1 -> mtap 1 slot 1 device 2 -> console slot 2 device 3 -> mtap 1 slot 2 ... or ... device 1 -> mtap 1 slot 1 device 2 -> mtap1 slot 2 device 2 -> console slot 2 This shouldn't impact how savestates are handled in any case. It should probably be implemented as a game-specific remap setting that just changes how emu devices 1->8 are shown to the user in the UI. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

claunia added the pull-request label 2026-01-29 19:08:45 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/duckstation#604