[Tuto] Les Surcharges, mais avec vous
-
Un autre qui peut être pratique, dans un .retroarch.cfg, pour pivoter les écrans:
video_rotation = "0"
; si 0 (orientation normale) si 1( pivoté à 90°), si 2 (pivoté à 180°), si 3 (pivoté à 270°)
video_aspect_ratio = "1.000000"
; aspect ratio du jeu une fois pivoté, laisser sur coreprovided ne changera pas le ratio en pivotant
aspect_ratio_index = "20"
; si 20, défini l'aspect ratio sur "Config", et donc appliquera le video_aspect_ratio donnéSi il y a moyen de définir l'aspect ratio automatiquement, ça serait super pour l'arcade.
-
@Bkg2k Merci pour cette option fantastique qui risque de ne pas être utiliser par le grand public mais tellement utile pour les pointilleux qui veulent modifier ou améliorer leurs expérience sans mettre le bazar dans le system (c'était surement l'idée).
-
@secamfr C'etait exactement l'idée
-
Exemple de surcharge pour utiliser deux romsets mame différents :
Merci à @Archangel54 pour son super boulot !
-
Les surcharges concernant le fichier recalbox.conf si elles sont "générales" n'ont que peu d’intérêt, comme par exemple changer l’émulateur d'un système, dans le recalbox.conf la modif suffit (le shader uniquement pour la gb par exemple),
par contre les config jeu par jeu ou bien comme montré pour le gb link c'est parfait -
@cissou Ca depend. En cas de partage des jeux sur NAS ou sur disque dur baladeur, ça permet de ne pas avoir à configurer les Recalbox individuellement.
-
Génial ça, ça laisse effectivement pas mal de possibilités.
Pour l'exemple de MAME plus haut en image, il n'y a pas besoin de spécifier du coup dans la conf le chemin ou sont les roms du romset MAME 2003 et 2010, la surcharge de conf s'applique d'elle même dans le sous répertoire correspondant c'est bien ça? -
@bkg2k ah oui j'avais pas pensé à ça
-
@kintao Oui c'est ça
-
@kintao oui, à noter qu'il est aussi possible de faire une surcharge de conf. qui ne s'applique qu'à une Rom donnée, en incluant son nom de fichier dans le nom du fichier de conf (voir documentation)
-
Ok merci a vous deux
-
En regardant la documentation, je tombe la dessus :
vice, qui émule maintenant le C64, le PET, le Vic20, le CBM2, ...
Personne en à parlé ??? Maintenant je cherche comment paramétré ça car il n'y a aucun exemple pour Vice juste pour Theodore...
Configuré un folder pour un Atari STE me parait intéressant aussi si quelqu'un à les bonnes commandes à mettre dans le fichier conf ? -
@secamfr Alors il faut avouer que pour les cores ça peut ne pas être evident à trouver...
Chaque core utilise ses propres réglages pour émuler les sous-systèmes. Et ça ne correspond pas toujours à ce que Retroarch affiche dans les options du core.
Les seules méthodes est:
- soit d'aller voir dans les source de l’émulateur quelle est l'option et quelles sont les valeurs possibles.
- soit de lancer le core sous RA, changer la machine, sauver la conf core et aller la dumper pour voir quelle option à bougé à quelle valeur.
Ce n'est pas forcement une operation facile et si des personnes le font, j'espère qu'elles partageront leurs fichiers ici
Par contre, dans le cas précis de VICE, c'est un peu different. Vice se décline en X cores differents, chacun spécialisé dans une machine. Et depuis la 6.1, tous les cores de vice sont compilés et inclus:
# ls -la /usr/lib/libretro/vice* -rwxr-xr-x 1 root root 3563032 Sep 22 10:54 /usr/lib/libretro/vice_x128_libretro.so -rwxr-xr-x 1 root root 2981496 Sep 22 10:54 /usr/lib/libretro/vice_x64_libretro.so -rwxr-xr-x 1 root root 2913424 Sep 22 10:54 /usr/lib/libretro/vice_x64sc_libretro.so -rwxr-xr-x 1 root root 1940192 Sep 22 10:54 /usr/lib/libretro/vice_xcbm2_libretro.so -rwxr-xr-x 1 root root 2073324 Sep 22 10:54 /usr/lib/libretro/vice_xpet_libretro.so -rwxr-xr-x 1 root root 2066832 Sep 22 10:54 /usr/lib/libretro/vice_xplus4_libretro.so -rwxr-xr-x 1 root root 2168464 Sep 22 10:54 /usr/lib/libretro/vice_xvic_libretro.so
Donc dans le cas précis de Vice, il suffit d'utiliser une surcharge
recalbox.conf
par sous-repertoire dédié a une machine, comme par exemple pour le VIC20:
c64.emulator=libretro
c64.core=vice_xvic
Attention cependant au scrape pour ces sous-machines. Dans le cas des TO/MO, vu qu'il n'y a qu'un système dans ScreenScraper et que les machines diffèrent très peu, ça ne pose pas de soucis.
Dans le cas du C64 par contre, avec skraper, il faudra ajouter les systèmes à la main et lui donner les sous repertoires manuellement, car les systèmes 8bit de commodore sont tous séparés dans la base ScreenScraper. -
@Bkg2k Merci pour toutes ces informations, je vais me débrouiller avec les core Vice, par contre j'ai essayer avec Hatari (atari ST), il écrit des informations dans le fichier retroarch-core-options.cfg et dans hatari.cfg, j'ai beau reprendre certaine ligne pour le passer en STE (changer le tos notamment) mais rien n'y fait...
A tu eu le temps de regarder pour l'Atari 800/5200 ?
-
Il y a une nouvelle page sur le gitbook pour les surcharges des .retroarch.cfg, avec les clefs pouvant être affectées juste ici.
Pour les options des .core.cfg par contre, faudra que je regarde de plus près, car elles sont propre aux cores utilisés, mais par exemple, si vous voulez désactiver le flickering sur la master system, le core genesisplusgx le permet avec l'option
genesis_plus_gx_no_sprite_limit = "enabled"
dans un .core.cfg, ce qui offre un rendu sans la limitation de 8 (je crois?) sprites par ligne horizontale, visuellement ça donne ça:de base: https://www.youtube.com/watch?v=QDCqgwWaWAg
avec l'option: https://www.youtube.com/watch?v=uqq9HEHDPQ0
Cependant attention, des modifs dans un .core.cfg sont enregistrées à la fermeture du jeu, donc si vous appliquez cette valeur sur le dossier de la master system, il sera présent la prochaine fois que vous lancerez genesisplusgx sur megadrive, à moins de surcharger là-bas aussi avec une autre valeur.
-
@fishou ah oui, j'avais pas pensé aux emulateur qui font plusieurs systèmes.
Ça le fait aussi si la surcharge ne s'applique qu'à un jeu donné ?
-
@noktambule oui, actuellement quand on lance le jeu, la surcharge (je parle que pour un type .core.cfg, pour le .retroarch.cfg il me semble que il n'y a pas de problèmes, et pour un .recalbox.conf c'est sûr que il n'y a pas de soucis) s'écrit dans le
system/configs/retroarch/cores/retroarch-core-options.cfg
et du coup, devient une option de base partout pour le core en question.Du coup si on veut surcharger une option de core pour un jeu, mieux vaut aussi surcharger en global (un exemple: Je veux activer du frameskip de 2 frames sur 3 sur dungeon magic
dungeonm.zip
pour final burn neo, du coup dans le dossier fba_libretro je vais avoir un
dungeonm.zip.core.cfg
contenant
fbneo-frameskip = "2"
Or si ensuite je relance un autre jeu sur le même emulateur, malheur, l'option reste active. Pour y remedier, je rajoute un.core.cfg
ans le dossier fba_libretro contenant l'option que je veux par défaut, ici:
fbneo-frameskip = "0"
Et je dois faire pareil dans le dossier neogeo qui utilise le même core, pour éviter d’avoir des endroits où rien n'est défini et où il prendrait donc le "dernier réglage chargé")
-
@fishou tu sais quoi ? Tu vas nous faire des fichiers prêts à l'emploi qu'on aura juste à copier /coller, ça fait trop mal à la tête ton truc !
(si tu pouvais même venir à la maison pour le faire...)
-
@Fishou Un grand merci à toi, c'est vraiment extra comme fonctionnalité !
-
Du coup, suite au message de @noktambule , j'avais voulu troller un peu et faire un éditeur de surcharges assez basique pour rigoler, manque de pot, il fonctionnait, et du coup j'ai légèrement peaufiné, et au final il semble "fonctionnel", bien que il ne présente pas toutes les fonctionnalités possibles.
Il se trouve à cette adresse (c'est un éditeur web) : https://surchargeur-ra-rb.netlify.com/
Avant toute chose:
- Cet éditeur n'est pas affilié au projet Recalbox, si il marche pas, c'est pas la faute des devs.
- Je le fourni "tel quel", possible que je le mette à jour, possible que non.
- Il n'y a que très peu de cores pouvant être affectés dans le .core.cfg actuellement.
- Je l'ai fait avec des outils que j'ai mais qui sont payant (Construct 2, même si la version gratuite pourrait permettre de le modifier à l'heure actuelle), et donc partager la source me semble pas pratique, les fichiers XML utilisés sont par contre accessibles (voir ci-dessous).
- C'est une interface qui communique avec deux fichiers XML fait main, l'un pour les catégories et clefs du .retroarch.cfg, l'autre pour la liste des cores et leurs options.
Pour un .retroarch.cfg, vous choisissez d'éditer un .retroarch.cfg au premier écran, vous sélectionnez la catégorie à éditer, le réglage à éditer, et vous rentrez manuellement la valeur, répétez pour chaque réglage de chaque catégorie, si vous n'avez pas de raison de surcharger un paramètre, ne mettez rien.
Pour un .core.cfg, vous choisissez le core voulu, puis l'option voulue, et enfin la valeur (pas besoin d'écrire manuellement la valeur ici), répétez pour toutes les options voulues, une fois une option éditée, vous ne pourrez pas changer de core à surcharger, la webapp ne supporte pas ça (et je ne pense pas lui faire supporter ça).
Dans les deux cas, il faut générer le fichier à la fin, qui sera téléchargé dans votre dossier de téléchargement, il est possible que le fichier n'est pas le bon nom si vous avez laissé les champs vides, auquel cas, ça se modifie avec la commande renommer de windows donc c'est pas grave, je vous conseille néanmoins d'ouvrir le fichier final pour vérifier que tout semble correct.
Désolé pour le pavé, mais je veux être sûr que les gens comprennent que c'est un outil qui ne sera peut-être jamais en version "stable", dans tous les cas, passez une bonne fin de journée ^^.