Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
fuss:retroarch [2020/02/18 01:26] – created officefuss:retroarch [2023/12/31 15:50] (current) – [Making Games with More than Two Players Work in Netplay (multitap)] office
Line 1: Line 1:
 ====== Fixing Fast and Uncontrollable Menu Behaviour ====== ====== Fixing Fast and Uncontrollable Menu Behaviour ======
  
-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''+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''
 + 
 +====== Assigning a Default Core to all ROMs within a Playlist ====== 
 + 
 +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: 
 +<code> 
 +/storage/external/MAME/0.37b/... 
 +/storage/external/MAME/2003+/... 
 +/storage/external/MAME/FBA 0.2.97.42 
 +</code> 
 + 
 +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. 
 + 
 +<file bash 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 . 
 + 
 +</file> 
 + 
 +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: 
 +<code bash> 
 +cat MAME.lpl | ./coreMapper.sh 
 +</code> 
 + 
 +====== Complete RetroArch BIOS Files ====== 
 + 
 +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: 
 + 
 +{{fuss: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. 
 + 
 +====== Cheating in Any Game with RetroArch ====== 
 + 
 +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 
 + 
 +{{video:fuss_retroarch_using_the_cheat_system.mp4?560x320}} 
 + 
 +====== Swapping CDs using PCX Emulator for PlayStation ====== 
 + 
 +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''
 + 
 +====== Solving Netplay Compatibility Issues on RetroArch ====== 
 + 
 +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: 
 +<code bash> 
 +git clone https://github.com/libretro/libretro-super.git 
 +</code> 
 + 
 +then the core that is to be used is retrieved using ''libretro-fetch.sh'': 
 +<code bash> 
 +./libretro-fetch.sh fbneo 
 +</code> 
 + 
 +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: 
 +<code> 
 +Anonymous mslug FinalBurn Neo v1.0.0.03 c68d212 No 1.14.0 12 Mar 23 05:20 UTC 
 +</code> 
 +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'': 
 +<code bash> 
 +cd libretro-fbneo/ 
 +git checkout c68d212 
 +git reset --hard c68d212 
 +</code> 
 + 
 +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: 
 +<code bash> 
 +export HOST_CC=x86_64-w64-mingw32  
 +export platform=win64 
 +./libretro-build.sh fbneo 
 +</code> 
 +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. 
 + 
 +===== Precompiled Cores ===== 
 + 
 +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: 
 + 
 +{{fuss:fuss_retroarch_solving_netplay_compatibility_issues_on_retroarch_using_precompiled_dlls.mp4?640x420}} 
 + 
 +====== Making Games with More than Two Players Work in Netplay (multitap) ====== 
 + 
 +{{video:fuss_retroarch_setting_up_multitap_for_more_than_two_players.mp4?480x380}} 
 + 
 +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 (<key>F1</key>), 
 +  * 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. 
 + 
 +====== Enabling Player Hotswap ====== 
 + 
 +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.

fuss/retroarch.1581989212.txt.gz · Last modified: 2020/02/18 01:26 by office

Wizardry and Steamworks

© 2025 Wizardry and Steamworks

Access website using Tor Access website using i2p Wizardry and Steamworks PGP Key


For the contact, copyright, license, warranty and privacy terms for the usage of this website please see the contact, license, privacy, copyright.