In case the menu seems to scoll uncontrollably or very sensitive then most likely vsync has been turned off. To fix this issue, navigate the menu Settings→Frame Throttle and set the Frame Time Counter to 1.0x.

Some reasons for collecting ROM sets for various different versions of the same libretro emulation core would be:

• emulation cores such as MAME have versions that match specific ROM sets; for example, latest FinalBurn Neo releases are entirely synchronized to particular ROM sets,
• netplay will only work in case both players have the same matching ROM and the same matching core

For example, a MAME ROM collection might end up looking like a collection of folders containing ROMs meant to be ran by different libretro emulation cores:

/storage/external/MAME/0.37b/...
/storage/external/MAME/2003+/...
/storage/external/MAME/FBA 0.2.97.42

where each path contains the ROM set version that is supposed to work with a certain MAME core version.

Unfortunately, when scanning /storage/external/MAME for ROMs, retroarch generates playlists where the core_name and core_path is set to DETECT. When a player selects the ROM and attempts to play it, retroarch might ask with which core retroarch should run the ROM with. A player might not know the best version of the core to run the ROM with such that the player would end up selecting an ad-hoc core.

The following script traverses a previously generated playlist and attempts to set the "core_name" and "core_path" based on the names of folders containing ROM collections. A new playlist is then generated with each ROM mapped to the core corresponding to the ROM set version.

coreMapper.sh

#!/bin/bash
###########################################################################
##  Copyright (C) Wizardry and Steamworks 2020 - License: GNU GPLv3      ##
##  Please see: http://www.gnu.org/licenses/gpl.html for legal details,  ##
##  rights of fair usage, the disclaimer and warranty conditions.        ##
###########################################################################
## The following is a short script meant to read a retroarch playlist    ##
## and assign a default core for all ROMs previously scanned.            ##
###########################################################################
## The script works on the principle that certain roms within ROM sets   ##
## (ie: Goodset, No-Intro or MAME ROMs) work best with a specific core   ##
## or core version and it is mostly impossible for retroarch to guess    ##
## what core variant a certain ROM works with.                           ##
##                                                                       ##
## A playlist generated by retroarch may contain set the "core_path" and ##
## "core_name" to "DETECT", indicating that the ROM will be ran with the ##
## best-guess core that retroarch can find. Then, assuming, for example, ##
## multiple MAME ROM sets stored on the drive in separate folders such   ##
## as 2003+, 0.37b5 or FBA 0.2.97.42, this script can be used to set the ##
## "core_path" parameter to the core matching the folder names.          ##
###########################################################################
## Requirements:                                                         ##
##   * jq                                                                ##
##   * Bourne Shell (pure POSIX will not work, ie: dash)                 ##
## Example invocation:                                                   ##
##    $ cat MAME.lpl | ./coreMapper.sh >> MAME_mapped.lpl                ##
###########################################################################
 
###########################################################################
##                            CONFIGURATION                              ##
###########################################################################
 
# An array containing parts of paths in a retroarch playlist for which
# cores should be assigned. 
PATH_MATCH=(
    "2003+"
    "FBA 0.2.97.42"
    "0.37b5"
)
 
# A list of retroarch cores matching the path parts that must be set.
ASSIGNED_CORE=(
    "/tmp/cores/mame2003_plus_libretro.so"
    "/tmp/cores/fbneo_libretro.so"
    "/tmp/cores/mame2003_plus_libretro.so"
)
 
ASSIGNED_CORE_NAME=(
    "MAME 2003-Plus"
    "FinalBurn Neo"
    "MAME 2000 (0.37b5)"
)
 
# Set the jq binary that should be used (default: jq-win64.exe for Windows)
JQ="jq-win64.exe"
 
###########################################################################
##                              INTERNALS                                ##
###########################################################################
 
# Grab STDIN (pine input)
INPUT="$(< /dev/stdin)"
 
# Split indices using IFS (without other tools).
OIFS=$IFS
IFS=" "
INDICES=${!PATH_MATCH[*]}
IFS=$OIFS
 
# Perform all core substitutions based on the matching path part.
JSON=$INPUT
for i in $INDICES; do
    MATCH="${PATH_MATCH[$i]}"
    CORE="${ASSIGNED_CORE[$i]}"
    NAME="${ASSIGNED_CORE_NAME[$i]}"
    # Variable overloading without storing intermediary partial results.
    IFS="{}"
    read -d '' JSON <<< $(printf '%s' "$JSON" | \
        $JQ "
            walk(
                if type == \"object\" and (.path | type == \"string\" and contains (\""$MATCH"\"))
                then 
                    (.core_path |= \""$CORE\"" | .core_name |= \""$NAME\"")
                else 
                    . 
                end
            )")
    IFS=$OIFS
done
 
# Pretty print JSON result.
echo $JSON | $JQ .

In order to use the script, edit the variables under the CONFIGURATION header within the script, retrieve a retroarch generated playlist from ~/playlist (ie: MAME.lpl) and pass the playlist through the script, ie:

cat MAME.lpl | ./coreMapper.sh

All the BIOS files on RetroArch must be placed inside the system folder and they all have a well-defined filesystem layout given by the configuration for each core:

retroarchbiosfiles.zip

Under Lakka, /tmp/cores/*.info holds all the information files that point to the needed BIOS files for each core and their relative placement under the system folder.

The cheat system built into RetroArch is a classic memory scanner and the procedure to change any in-game value is as follows:

• pick a value to change (amount of lives, weapons, etc…),
• scan the memory for the value,
• change the value by playing the game,
• scan the memory for the changed value,
• repeat the above until no new matches can be found,
• add the matches to the retroarch cheat list,
• for all matches, increment or set the value by a desired amount

The second memory save card can be activated in order to be able to progress from one CD to the other while restoring the game. Games can be saved on the second memory save card which is shared amongst all games such that when a CD swap occurs the save game can be restored from the second memory card. To activate the shared second memory card, access the core menu Options→Enable Second Memory Card (Shared)→On.

Ideally, for netplay, all connecting participants should have the exact same versions of all assets involving the game:

• same ROM,
• same core,
• same core version,
• same RetroArch version,
• same architecture between netplay clients,
• etc

in order to be able to connect and play without any issues.

The problem is that due to various retroarch distributions, such as Lakka, core versions might mismatch between releases such that connections might fail with errors such as "Netplay disconnected".

The trivial solution is to compile a core for all versions and for all participating clients in order to ensure that the same version is used.

As an example, the following instructions will compile a FBNeo core for Windows, for a given FBNeo release. Windows clients will then have to download the exact core version and use that in order to connect to clients using the exact same core version.

First, the libretro-super source is pulled:

git clone https://github.com/libretro/libretro-super.git

then the core that is to be used is retrieved using libretro-fetch.sh:

./libretro-fetch.sh fbneo

The two commands will pull both the source and the most recent release of the FBNeo core. In order to match core versions, for instance, given a lobby room that advertises a game, such as:

Anonymous 	mslug 	FinalBurn Neo v1.0.0.03 c68d212 	No 	1.14.0 	12 Mar 23 05:20 UTC

with the FBNeo release hash c68d212, the c68d212 commit must be checked out via git for the fbneo core repository.

Since the FBNeo core is downloaded to the libretro-fbneo sub-directory, the following commands should revert the most recent source code release of FBNeo to the commit hash c68d212:

cd libretro-fbneo/
git checkout c68d212
git reset --hard c68d212

In order to compile the FBNeo c68d212 core, some environment variables must be set such as the compile to be used and the target platform to be compiled for. For instance:

export HOST_CC=x86_64-w64-mingw32 
export platform=win64
./libretro-build.sh fbneo

where:

• HOST_CC is the C compiler to be used (in this case x86_64-w64-mingw32 will be used as a cross-compile toolkit to compile the FBNeo core for Windows while on Linux),
• platform is the target platform (in this case win64, 64 bit Windows)

and the final command ./libretro-build.sh fbneo will start building the core.

If successful, after compilation, the FBNeo c68d212 core will be found within the dist folder named libretro_fbneo.dll

In order to use the compiled core, for Windows platforms, the libretro_fbneo.dll DLL should be copied within the cores folder inside the RetroArch folder structure and then loaded using RetroArch.

Here are some precompiled cores that should match various FBNeo hashes:

• https://files.grimore.org/libretro-cores/

along with a video demonstration on how to use the DLL files:

For more than 2 players, the 2nd controller Device Type must be set to multitap. Here are the steps necessary to set the 2nd controller to multitap:

• load a game with support for more than 2 players,
• open up the RetroArch menu with the game open (F1),
• navigate to Controls → Port 2 Controls,
• set the Device Type to Multitap,
• go back one screen (Controls) and select Manage Remap Files,
• select either Save Core Remap File which will enable Multitap for all games, or Save Game Remap File that will just enable Multitap whenever this game is loaded,
• go to the top-level menu and select Close Content to close the game

Now, when loading up the game again, a notification should mention that a remap file has been loaded (either core or game if the instructions above have been followed), netplay can be started in order to host a rooom and the game should allow more than 2 players to join.

Sometimes when playing in multiplayer, it is convenient to switch players. To that end, the following button can be mapped:

Settings→Input→Hotkeys→Netplay Play/Spectate Mode (Toggle)

that will make the current player register/deregister on the player rooster thereby cycling the player number.

For example, to switch between player 1 and player 2, both player 1 and player 2 use the above toggle to switch into spectate mode, after which player 2 switches again and becomes player 1 and finally player 1 switches again to become player 2. To switch back, the same operation is carried out.