Essaye de bidouiller les différents réglages de Retroarch : Frame Delay, Hard GPU Sync, Runahead, etc. As-tu mis des shaders lourds ? Etc. Compare les réglages que tu as mis entre l’ému SNES et l’ému Megadrive.
Edit : concernant les pilotes, tu dois être en OpenGL, essaye de passer à Vulkan.
Je n’en connais pas la raison, mais blastem n’est pas présent sur le buildbot (pourtant il a l’air de fonctionner).
Quand à FBAlpha, il est marqué comme émulateur Arcade, c’est effectivement sa fonction la plus connue, mais il sait également émuler megadrive, master system, gamegear, sg1000, pcengine, turbografx16, supergrafx, msx, coleco, et ZX spectrum. Par contre, comme je l’ai dit, il utilise des romsets spécifiques (= la rom doit porter un nom particulier, et le zip qui la contient doit également porter un nom particulier), donc je recommande aux personnes ne sachant pas se servir de clrmamepro et ne souhaitant pas chercher sur google comment on s’en sert de s’abstenir.
De toute façon si le problème est commun à 2 émulateurs megadrive qui n’ont à priori pas grand chose à voir dans leur code, je pencherai plus pour un soucis de configuration RA, un soucis de rom (tu as essayé différentes roms ?), ou un soucis hardware (les pilotes sont à jour ?). Autre chose à prendre en considération, le son n’était pas le point fort de la megadrive. Quand à la lenteur, tu as essayé d’afficher le framerate (Settings > Onscreen Display > Onscreen Notifications > Display Framerate) ?
Sous linux j’utilise en général GL & alsa pour les drivers, je ne connais pas les drivers par défaut sous windows, et alsa n’est clairement pas disponible. Par contre GL est disponible et recommandé (car tout les cores sont compatibles avec, ce qui n’est pas forcément le cas pour directx ou vulkan).
As-tu essayé des cores plus gourmands (non-Mega Drive…) pour t’assurer que tu as assez de puissance ?
Sinon je te conseille d’aller dans Réglages->Vidéo et de sélectionner “Fréquence estimée de l’écran” pour synchroniser ta fréquence de rafraîchissement avec celle de ton matériel, ça règle pas mal de problèmes de vitesse de gameplay, et de grésillements de son justement…
On est sur un cpu à 3.3Ghz quand même (la megadrive tourne avec genplus_gx, donc sans dynarec, sur un raspberry 2 à 900Mhz si je me souviens bien), et il fait tourner la SNES qui est plus gourmande.
Les résultats sont très variables selon la façon dont est codé le core, perso, sous linux, je ne l’active jamais.
Les cores plus gourmands c’est plutôt un test pour voir si ses réglages exhibent des problèmes sur des cores différents…
Et pour la fréquence, ce n’est pas une chose à “activer”, c’est simplement un réglage de la fréquence inhérent à RetroArch qui peut parfois être mal réglé par défaut… Où bien en passant d’une résolution 60 à 50 Hz par exemple, où RetroArch ne se serait pas adapté entre temps !
Comme suggéré, cela m’a permis de régler des problèmes de vitesse, voire de son qui grésille sur certains cores (sous windows, iOS, et macOS… Je n’utilise pas Linux…)
@Weedy_Weed_Smoker merciiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii ça fonctionne nickel !!! Suis trop content 
je me disais bien qu’avec ma config ça devait tourner sans problème, vu qu’avec un vieux Celeron cadencé à 1.7 Ghz ça tournait très bien !
@BarbuDreadMon merci pour ta réponse & pour ton aide, il me reste à régler le problème de la Dreamcast !
En effet malgré que j’aie installé les BIOS dans le dossier systeme, que ceux-ci sont bien reconnus dans RetroArch (la somme MD5 est bien correcte), Reicast & Redream plantent complètement !
Avez-vous déjà eu ce problème ?
2 bons exemples de core qui planteront si tu n’utilises pas GL en video driver, ou si tes pilotes de carte graphique sont foireux. Soit dit en passant redream est sans intérêt (l’émulateur est passé en closed source très vite après le début du projet, le core libretro repose donc sur une version antérieure qui doit faire tourner quelques jeux de manière à peine correcte). Il me semble aussi que certains shaders peuvent provoquer divers problèmes avec les cores utilisant opengl.
(retiré)
Sinon comme le dit @BarbuDreadMon, tu devrais effectivement sélectionner un driver vidéo compatible de toute façon sous peine de plantage… Et ne sélectionner que des shaders appropriés au driver vidéo utilisé !
Pour ce qui est de Redream, j’ai fini par l’acheter car c’est le seul émulateur Dreamcast pour macOS, et il marche extrêmement bien pour ça ! Mais c’est très dommage que l’auteur soit passé en closed source juste pour l’argent…
La version RetroArch est effectivement très ancienne, et ne fait pas honneur à cet émulateur qui est un tour de force pour un seul développeur !
Pas de téléchargement illégaux sur le forum, merci…
Sinon je ne sais pas ce que donne la version standalone de redream, mais la version libretro de reicast est plutôt efficace. A vu de nez, vu la compatibilité annoncé sur le site de redream, et les dates d’ajout de fonctionnalité, j’ai quand même bien l’impression que l’auteur se fout de la gueule du monde en s’appropriant du contenu GPL (= violation de license) provenant de reicast pour l’inclure dans son émulateur “closed source”.
@BarbuDreadMon Encore merci pour ta réponse rapide je vois que je suis entre pros de l’émulation ça fait plaisir ! Alors le driver video est bien en GL & le driver audio en XAUDIO par défaut.
En Standalone tous mes jeux Dreamcast tournent avec Redream (version Lite) & Demul, c’est bizarre non ?
@Weedy_Weed_Smoker merci pour ton BIOS mais malheureusement ça ne change pas le problème… sur mon deuxième PC (Intel i3 à 3.7 Ghz) Reicast fonctionne, c’est pénible tout ça…
C’est un lien externe, ce n’est absolument pas stocké par le forum… 
Sinon pour Redream, je suis complètement d’accord que ça devrait redevenir un émulateur ouvert, mais la compatibilité est excellente, et l’auteur à mis en place une fonction pour que l’émulateur ait un rendu parfait sur la version obsolète d’OpenGL intégrée à macOS !
@Sebiohazard as-tu comparé les réglages entre tes 2 PC ? Ça me semble bizarre que tu fasses tourner Reicast sur une machine et pas sur l’autre…
Le problème sous macos avec reicast n’est pas lié au core, c’est RA qui ne sait pas fournir un contexte opengl supérieur à 2.0 si je me souviens bien (d’ailleurs il y a un paquet de core utilisant opengl ne fonctionnant pas sur macos à cause de çà, dont l’un de ceux dont je m’occupe : kronos).
@Sebiohazard une autre piste pour tes problèmes de reicast serait un mauvais réglage dans les core options, mais j’imagine que tu n’as rien pu toucher à ce niveau si le core ne s’est jamais lancé pour toi ? Il faudrait poster ce que te dit le core en mode verbose pour en savoir plus.
Retire le quand même, çà reste contraire au règlement, merci.
Ok, c’est fait !
Sinon, macOS ne supporte OpenGL que jusqu’à la version 4.1, ce qui à d’ailleurs récemment poussé les auteurs de l’émulateur Nintendo Switch “yuzu” à retirer le support pour macOS…
Sur le site https://yuzu-emu.org/downloads/, on peut lire :
Mac OS is no longer supported due to Apple deprecating OpenGL and their current version not supporting the OpenGL extensions we require.
J’aimerais par contre connaître le point de vue d’un développeur concernant “Metal”, qui est le “Vulkan” privé d’Apple, pour le futur développement des cores RetroArch… Qu’est-ce que tu en penses @BarbuDreadMon ?
J’ai entendu qu’il existe des convertisseurs de code “Vulkan” pour l’api “Metal” d’Apple, mais je n’ai pas du tout creusé le sujet n’étant pas moi-même développeur…
Oui, macos a entre 5 et 10 ans de retard sur certaines technologies (opengl 4.2, pourtant sorti en 2011 il me semble, n’est qu’un exemple), mais visiblement çà n’empêche pas les acheteurs de continuer à se faire arnaquer en payant 2 à 3 fois plus cher du matos générique fabriqué dans leurs usines chinoises, agrémenté de logiciel qui, disons le franchement, n’ont quasi pas évolué depuis 10 ans.
Il me semble que metal est supporté par retroarch, néanmoins si les cores ne le supporte pas, çà ne sert pas à grand chose.
J’ai moi-même construit mon propre Hackintosh, n’acceptant pas de payer le prix fort pour une machine obsolète soit-dit en passant… 
Le système macOS est par contre excellent, et gratuit qui plus est !
J’utilise de temps en temps une distro Linux, mais ne l’utiliserais jamais pour autre chose qu’un projet temporaire… Et étant infographiste, l’OS d’Apple est pour moi un morceau de choix !
Il serait encore mieux si il était open-source comme son papa linux, au moins des gens compétent (vu qu’il n’y en a plus chez apple, ils ont visiblement remplacé leurs ingénieurs par des commerciaux) pourraient améliorer leur OS.
PS : je comprend le choix d’apple en tant qu’infographiste, déjà parce que j’imagine que t’as appris à bosser sur çà à la fac.
Tu es dur @BarbuDreadMon, tu veux parler de son papa UNIX plutôt, non ?
Bon, ils ont quand même distribué un peu du code source… https://www.redmondpie.com/download-ios-12-and-macos-10.14-source-code-finally-released-by-apple/
PS : Je suis autodidacte, mais ma mère étant rédactrice à toujours eu des Mac à la maison… J’ai commencé sur Mac SE FDHD avec KidPix et les excellents logiciels d’Apple pour les Mac avec pixels noirs et blancs uniquement…
A l’origine darwin était effectivement basé sur du noyau BSD (je me souviens vaguement avoir compilé darwin il y a looooongtemps, je ne sais pas si les sources sont toujours disponibles), mais il me semble que çà a changé avec le temps. Sinon on diverge un peu trop du sujet initial là xD
On est complètement hors-sujet, effectivement… Désolé @Sebiohazard !
Sinon… Tu as un point de vue sur ce sujet ?
On à déjà réglé le problème initial du post en tout cas, je crois qu’on va essayer de régler le problème de Dreamcast de @Sebiohazard quand il sera revenu parmi nous…
Comme dit plus haut, Metal/Vulkan c’est bien joli (il me semble que retroarch est compatible Metal), mais encore faut-il les implémenter au niveau des cores, il y a moins de personne qui maîtrisent ces API, et la compatibilité est quand même bien moindre qu’opengl à l’heure actuelle, aussi bien en terme de matériel (GPU post 2015 ?) que d’OS.