Preface

In my previous article, I introduced the detailed steps of how to deploy a web-based retro game emulator based on emulatorjs's docker (see article:Use docker to deploy web-side nostalgic game emulator based on emulatorjs), but in the end there is a problem that affects the gaming experience, that is, the default key configuration is unreasonable: the up, down, left, right and right arrow keys are controlled by the four keys ↑ ↓ ← → on the right side of the full keyboard, while the regular AB keys (jump, bullet) are pressed by the X and Z keys on the leftmost side of the full keyboard. For most people, the direction is controlled by the left hand, and the jump and bullet are controlled by the right hand. Doesn't this require playing with both hands? Is this tolerable?

So I did some research and tried to modify the default configuration by modifying the key mapping in the emu-main.js file, but failed. It seems that I also need to modify the loading order of emu-main.js and emulator.js in the loader.js file, so that emulator.js should be loaded before emu-main.js. I studied it for a long time but couldn't figure it out. The disadvantage of not having a programming background was fully demonstrated... So I had to change my thinking and start from the perspective of the profile configuration file, and finally solved the problem.

Ideas

By default, when you use a browser to access the front-end game web page, if you enter the RetroArch emulator's configuration interface with the F1 key and set it once through the "Settings"-"Input" option and save it, other games can also use this key setting. However, the premise is that it is accessed through the same browser, because the configuration file (retroarch.cfg) is bound to the browser (actually, the URL visited, so strictly speaking, it should be bound to the browser and the URL visited). So, as long as the configuration file can be stored not only "locally" in one browser, but also "synchronized" to different browsers on the same machine, or even different browsers on different machines, key configuration can be achieved. So how to solve this key problem? That is the profile.

[vip]

profile (Administrator settings)

In my previous article, I mentioned the profile management page of the emulatorjs management console:

Here you can create new accounts and manage the corresponding profiles of your accounts. For example, in the red box below the image above, enter "guest" for both username and password, then click "Create Profile" on the right to create a guest account under "default":

Click the guest account in the red box above to enter its configuration file interface:

In the above picture, the states folder stores game archives, and retroarch.cfg is the file that stores key configurations.

Game front-end page settings

Button configuration synchronization

The settings in the previous section are in the management console interface. The administrator needs to create accounts for different users in advance, and the specific games are on the front-end web page:

On the front-end of the game, click the button in the red box in the upper left corner. The interface after entering is as follows:

In the red box in the upper left corner of the picture above, enter the username and password of an existing account (for example, guest, guest), and then click login:

The image above shows the guest login interface. The "Push to Server" button in the upper right corner uploads the guest account's configuration file in the local browser to the game server, while downloading the guest account's configuration file from the game server to the current browser. Therefore, "Push to Server" and "Pull from Server" are how you implement key-based configuration tracking. In one already configured browser, push the configuration for the corresponding account to the game server. Then, log in with the same account in another browser and pull the configuration from it.

Default button

In fact, the default button is the configuration corresponding to the default user:

Let’s start from that page. Before logging in with a specific account, the configuration file in the red box on the lower left is the default user’s configuration file:

Follow the steps shown in the image above:
The first step is to click the DL Full Backup button to download all configuration files corresponding to the current browser (including the default user) to the local computer.
In the second step, use the Upload Full Backup button to upload the configuration file you just saved to overwrite the original configuration
Step 3. Access the front-end page in any browser, re-enter the interface (without logging into a specific account), and then click the top button Pull Default Config to download the default user configuration.

[/vip]

So in fact, it is just like logging in to a specific account and then pulling the configuration. Default only pulls the configuration without logging in, so it does not actually implement the underlying modification of the default configuration, but still implements it indirectly through configuration file synchronization.