@acris @alfacentory pas sur que ~/.advance existe par defaut
@Substring il crée l'arborescence de ~/..advance au 1er lancement d'un jeu.
Est-ce-que chez vous, Bad Dudes vs Dragonninja rame si vous désactivez l'option SMP ?
(C'est aussi le cas sur pas mal de jeux...)
Le SMP (Symmetric Multi-Processing) permet d'avoir "plus de pèche" pour émuler les jeux mais ajoute un assez gros lag input. Je crois qu'il est activé par défaut.
Je l'ai désactivé pour tous les jeux et quand je vois un jeux qui rame, je l'active.
Sans le SMP, le lag input est, sur pas mal de jeu, "presque" imperceptible.
Sinon, Advmame doit apporter la possibilité de créer à la volée les résolutions des jeux pour les CRT 15Khz.
Mais comment fait-il avec les jeux de plus de 256 lignes ?
Bon c'est impossible, ou alors, soit il passe en 625 lignes et jusque 288p
Ou, il divise la résolution verticale par 2.
Personnellement, j'ai supprimé tout (les roms) ce qui utilise une résolution supérieur à 256p.
Rpi2/Rpi3 - LCD/CRT- NES30 Pro-iBUFFALO
Tu utilises quoi comme manettes, tu est branché direct via le gpio.
Dernièrement il y a eu soit disant pour le rpi une optimisation du driver manette (moins de charge CPU et réduction de l'éventuel input lag).
Tu as testé l'utilitaire "advcfg" pour les réglages vidéo.
Et tient en parlant rom est ce que truxton2 fonctionne chez toi. Moi j'ai un retours menu à chaque fois.
@ironic Quelques pistes pour advmame :
~/configs/advancemame/advmame.rc.origin et tu passes device_video à autoTERM=xterm advcfg -rc ~/configs/advancemame/advmame.rc.origin pour configurer ton écranPour le SMP, voir sur le site de l'amulateur, il l'a déjà évoqué je crois. C'est du multithread, ni plus ni moins. L'avantage avec advmame c'est que la config par rom se fait dans le fichier de config
Pour la manette, j'utilise une iBUFFALO en USB (snes).
L'input lag le plus grand vient de l’émulation (de l’émulateur), que ce soit en USB (avec une manette pas trop pourrie) ou par GPIO, la latence est quasiment nulle.
truxton2 se lance mais écran noir.
On peut ouvrir le menu de advmame donc il n'est pas planté.
Après avoir quitté advmame, il nous dis que le CRC du fichier tp024_1.bin (qui est le programme du jeu) n'est pas le bon.
Il attend le CRC eb26f0e5 alors que la roms que l'on trouve partout a le CRC f5cfe6ee.
Je ne trouve pas cette rom...
Je n'utilises pas advcfg car j'utilise mon script de génération de résolution avec une base de donnée de tous les jeux de advmame (issue du listxml de advmame).
Le python c'est pas mal 
Aparté sur le python, je vois que le module pygame est installé, on peut le charger mais est-il pleinement fonctionnel ?
Les quelques exemples que je trouve sur le net ne fonctionnent pas, ou alors on peut pas utiliser pygame sans X ?
Ça fonctionne du feu de dieu et ça permet d'adapter les résolutions aux éventuellement probleme de cadrage en fonction des TV.
Je sais bien @Substring que t'es pas pour les bases de donnés de jeux, c'est pour ça que j'en parle pas trop.
Mais sur mes 4 TV, le résultat est différent en générant une résolution identique.
Bandes noires à gauches ou à droite, trop d'overscan horizontal, pas centré horizontalement ou verticalement.
(Bien-sur, ça ne s'adresse qu'a ceux qui utilisent des CRT...)
device_video est bien sur auto. Idem sur fb.
sdl ne fonctionne pas. (peut être du à mon intégration sauvage de advmame...).
Je me demandais simplement si en mono thread, baddudes ramait car il tourne très bien sous mame078 et fba.
Rpi2/Rpi3 - LCD/CRT- NES30 Pro-iBUFFALO
@ironic
la rom qu'il te manque est disponible, tu n'as pas checké ton romset avec clrmamepro 
Il attend le CRC eb26f0e5 alors que la roms que l'on trouve partout a le CRC f5cfe6ee
@ironic said in advance mame 4.1:
baddudes
C'est vraiment significatif le ralentissement avec baddudes, je viens de tester vite fait avec l'option SMP désactivé, (il est effectivement activé par défaut sur la version rpi), mais ça semble bien tourner.
Pour truxton2 je m'en doutais, mais merci pour la précision. Après remplacement du mauvais fichier .bin ça fonctionne convenablement. D'ailleurs la rom du set mame2010 est bonne.
Merci @acris
Effectivement, avec la bonne rom, Truxton 2 fonctionne parfaitement.
J'utilise pas tellement clrmamepro pour son interface assez lourde, mais faut dire qu'il fait du bon boulot.
Il y a beaucoup de jeux pour lesquels on peut désactiver le SMP et ainsi diminuer l'input lag,
@ironic moi je te propose un truc au lieu de t'enteter avec ton script, ta bdd et tout le toutim.
Fais ce que je t'ai proposé. La calibration de CHAQUE mode video prend une eternité. Mais comme tu sais quelles resolutions valent le coup d'etre reglees, prends des resolutions bateaux communes, regle bien ton ecran pour ces quelques resolutions (oui, ca peut etre long) et laisse advmame. Sinon pourquoi j'ia mis advance mame a ton avis ? C'est justement poru profiter de ses capacités, pas pour réinventer la roue 
Il n'y a pas X sur Recalbox voyons, tu devrais le savoir depuis le temps 
J'ai (enfin) acquis une TV cathodique. Comme je sais que advancemame génère les bonnes résolutions avec les bonnes fréquences, ni une ni deux me suis fié à un de tes cas de tests pourris : R-Type. Donc là si je te sors une photo, tu verras de suite les défauts (mal centré, de l'overscan etc ...) mais une fois que j'aurai réglé la résolution, rtype sera en full screen et en 55 Hz sans poudre de perlimpimpin ou calculs alambiqués. je pense vraiment que ca vaut le coup d'essayer un chouia (meme si oui, tu peux le dire, c'est TRES laborieux de regler son ecran pour chaque resolution, surtout que l'écran d'aide n'est pas le moins explicite du monde)
Merci pour ta sollicitude mais je ne m’entête pas, je "m'amuse".
Et en plus j'apprends, me suis lancé dans le Python ya quelques jours...
D'ailleurs, tout est fini pour Advmame, tout est opérationnel. Un seul paramètre à passer au script, le nom du jeu.
Advmame utilise également une (sa) base de donnée, j'utilise la même (listxml) mais avec plus de paramètres.
Je fais exactement ce que Advmame fait pour créer une résolution mais en un peu plus complexe et paramétrable.
Cela fonctionne également parfaitement pour Mame078 et Fba.
Je comprends parfaitement que Recalbox ne puisse pas proposer la perfection automatique car il est destiné à tous les utilisateurs, même les moins expérimentés. Du plug'n play,
Je ne propose pas ma solution pour une intégration dans Recalbox.
Néanmoins, si une solution permet d'avoir une meilleur gestion des résolutions d'arcades, ça peut être intéressant.
J'en parle juste pour ceux qui voudrais essayer (utilisateurs expérimentés only) et donc ne pas faire de rétention d'informations.
Oui je sais, ya pas de X sous Recalbox, je me demande simplement pourquoi je ne peux pas utiliser le module pygame bien qui soit installé sous Recalbox.
*ni une ni deux me suis fié à un de tes cas de tests pourris : R-Type
Lol, c'est dur ca
Rpi2/Rpi3 - LCD/CRT- NES30 Pro-iBUFFALO
@ironic je crois que le seul moment ou pygame est utilisé c'est pour la barre de progression d'un update je crois
Pour le cas de test r-type : c'est juste parce qu'il a une resolution et une frequence particulières, d'où le pk de mon test avec.
La question que je me pose, c'est : faut-il d'avord regler l'overscan dans le config.txt et ensuiteenvoyer la purée derrière ou ... 2h que je joue avec la tv, ca me vient à l'esprit.
Pour le côté power user, c'est qqc que j'ajoute au fur et a mesure dans recalbox, tout le monde n'a pas besoin que d'une solution plug'n'play.
Ca serait chouette de partager ton travail, pour plrs raisons :
Bon, j'ai été un peu long mais faut le temps pour se familiariser avec le Python.
@Substring
Si tu retrouves le script dont tu passes, fais moi signe, je voudrais faire une interface graphique en python pour créer/regler les HDMI_Timings. (Si j'ai le temps ou pas le choix, je ferais ca en C/SDL).
Le config.txt doit pas mentionner d'overscan, voici le mien (Attention c'est pour l'overlay de RGB-Pi):
hdmi_timings=460 1 22 51 80 282 1 6 6 19 0 0 0 51 0 9600000 1
gpu_mem_256=128
gpu_mem_512=256
gpu_mem_1024=512
avoid_safe_mode=1
kernel=zImage
dtoverlay=pi3-disable-bt-overlay
dtparam=audio=on
dtoverlay=pwm-2chan,pin=18,func=2,pin2=19,func2=2
dtoverlay=rgb-pi
enable_dpi_lcd=1
display_default_lcd=1
dpi_output_format=6
dpi_group=2
dpi_mode=87
Voila comment je procède pour Advmame (fonctionne également pour mame078 et fba).
J'ai créé une base de données à partir du fichier listxml de Advmame.
Dans cette base de données, il y a tous les jeux supportés par Advmame (enfin pas tous, que les 15Khz).
J'ai créé un script en Python qui cherche le jeu dans la basse de donnée et exploite les paramètres. Si le jeux n'y est pas, c'est retour sous ES
(On peut eventuellement lancer une rsolution stadard mais je ne l'ai pas prevu pour le moment).
advmame.rc et copier (avant le lancement du jeu) dans /tmp, modifié pour configurer l'orientation du jeu.display_rol no - misc_smp noLe script est ici.
Il faut l'utiliser comme ceci (Bon, il faut surement un peut adapter les chemins des fichiers dans le script)
emulator_launcher.py /recalbox/share/roms/advmame/aburner2.zip /recalbox/share/advmame_games.txt advmame
De cette facon, Tous les jeux 15Khz d'Advmame se lance avec la bonne résolution, la bonne fréquence et la bonne orientation.
Les réglages ont été fait sur une TV Trinitron 36cm et correspondent a 6, -25, 5 dans la base de donnée.
Sur une autre TV Trinitron de 36cm, je dois metre 0, -25, 5
Je suis pas sur que tout cela soit utile a beaucoup de monde mais dans la mesure ou cela fonctionne également pour mame, fba et les consoles, ça mérite d’être étudier.
Et petit question pour la fin aux membres de Recalbox.
Est-ce que ça ne vous dérange pas qu'on ouvre un sujet exclusivement consacré a RGB-Pi ? (Qui je le rappelle est Recalbox a 99.99%). Ça permettra de dégrossir la future intégration du CRT dans Recalbox.
Bon, comme je me suis lancé dans Python, vais surement réintégrer configgen dans mes bidouilles
Rpi2/Rpi3 - LCD/CRT- NES30 Pro-iBUFFALO
@ironic Là ca appelel à 10000 questions, bon courage
6 -25 5 tu le règles à partir de quoi ?Pas utile à bcp de monde tu dis ? Mec, tu aurais été à la HFS ce weekend ... Autant l'an dernier ils nous ont regardé avec une drôle de tête (LCD, pas pixel perfect, lag input etc ...), autant depuis qu'on dit qu'on bosse sur du 15k, ils commencent à être prêts à délaisser leurs PC pour un pi (véridique) (c'est même la conclusion de Metheore lors de l'intervention de Recalbox à la HFS 3, visible sur twitch, lien dans le fofo)
Pour RGB-Pi ... Là je suis bcp plus réticent:
Je ne te cache pas qu'on en a discuté ce weekend et qu'on est très mitigé sur la bonne réciprocité du travail de l'un envers l'autre. Je constate qu'on bosse pour lui, mais dans l'autre sens ...
Par contre, j'admire le travail que tu as fourni, très sincèrement ... En 6 mois tu as abattu un travail énorme et peux te targuer d'avoir a peu près tout défriché niveau arcade ... Franchement je suis impressionné ! Tout mon humble respect !
On a eu énormément de discussions ces 4 derniers jours sur le CRT entre nous ou avec d'autres, pour arriver à la triste conclusion que c'est juste impossible sans DB. Même pour te dire, j'ai commencé à plancher avec un dev retroarch sur le sujet pour voir comment se simplifier la tâche ... mais clairement, c'est l'enfer.
Maintenant, si je comprends bien, tu veux faire un mini "advcfg" histoire de caler les 3 chiffres magiques, c'est bien ca ?
Et dire que les consoles ca va etre le même enfer, voire pire avec celles qui changent de resolution en cours 
Le hdmi_timings du config.txt sert au boot et donc forcement a ES.
Mais une fois que l'on a lancé un jeu, on a changé la résolution et donc après avoir quitté le jeu, le script va rechercher les paramètres de résolution (J’espère que tout le monde a compris que hdmi_timing et résolution c'est la même chose) dans le fichier config.txt.
Çà permet d'avoir un seul endroit ou stocker la restitution de ES.
le triplet 6 -25 5 correspond aux réglages sur mon Trinitron.
(6), c'est le décalage sur la droite de 6*4 pixel (sur 1920).
(J'aurais pu faire pixel par pixel au lieu de 4 en 4 mais c'est très bien comme ça).
(-25), c'est le zoom. Donc a 0 j'ai un gros overscan et je resuit le zoom
(Ça joue sur le Front Porch et le Back Porch horizontal, je ne touche pas a la sync).
(5), c'est le décalage vers le bas (en nbr de lignes) de l'affichage, je soustrait 5 au Front Porch Vertical que j'ajoute au Back Porch Honrizontal. je ne touche pas non plus a la synchro Vertical.
Pourquoi réinventer ce que advmame fait déjà ?
Par-ce-que advmame ne fait pas tout.
Pour, par exemple R-Type, je peux soit l'afficher en 525 lignes, soit en 625 ligne.
Il faut pour cela que le nombre total de lignes soit supérieur ou égal 288.
Pour cela, on passe la fréquence horizontale de 15720 à 15840.
rtype, 256, 55.000000, H, 6, -25, 5, mame078_libretro.so, 15720, 48, 192, 240, 5
rtype, 256, 55.000000, H, 6, -25, 5, mame078_libretro.so, 15840, 48, 192, 240, 5
On peut aussi augmenter la Sync Vertical jusqu’à atteindre 288 pour les moniteur ne supportant pas un gros dépassement de fréquence horizontale.
(Je n'ai pas de PVM, je ne peux pas tester et comprendre ses limites mais je pense qu'elles se situe au niveau des synchro).
J'ai jamais parlé de iMAME4All.
il faut toujours un retroarch.cfg par jeu pour caler le viewport ou non ?
retroarch.cfg, celui qu'on passe en --appendconfig est généré par le script. Il y a toujours un fichier de config de basse passé en --config.custom_viewport_width = "1920" Est toujours = à 1920.custom_viewport_height = "256" Varie en fonction du nombre de lignes du jeu.custom_viewport_x = "0" Est toujours = à 0custom_viewport_y = "0" Est toujours = à 0video_refresh_rate = "55.000000" Varie en fonction de la frequence du jeu.video_rotation = "0"`` Change et passe a 1 si le jeu est vertical.Le but est approcher la perfection (Les PC ont du soucis à se faire) et donc de pouvoir gérer chaque jeu indépendamment.
Pouvoir activer ou désactiver le SMP permet de réduire l'input lag, Comment Advmame fait ça ? Il devine tout seul ?
RGB-Pi c'est essentiellement du Hardware.
Quand je parle de RGB-Pi, je parle du câble et de l'overlay.
Pas de sources pour RGB-Pi car c'est Recalbox et quelques petites modifs.
Faire de l'argent sur votre dos, c'est pas mon but mais je pense que vous l'avez compris.
RGP-Pi, c'est énormément de taf manuel pour fabriquer les câbles (moi je fais rien, je code), je pense qu'il soit normal qu'il les fassent payer. Maintenant, c'est vrai, sans Recalbox, pas de câble RGB-Pi.
Vais en discuter avec aTg.
Merci pour tes éloges, j'en ai tout autant (et même plus) à ton égard et celles des Devs Recalbox.
Merci et ... merde, vous faites chier ça fait 2 ans que j'ai ma tronche collé au moniteur, avec des Rpi, des câbles, des SD, des moniteurs, des TV partout dans la baraque, ma femme gueule
(Désolé, je mets tout ça sur votre dos:)
Je ne veux pas faire un mini "advcfg", a la base, c'est un "générateur de hdmi_timings".
J'ai juste couplé ça à des BDD.
Pour le consoles, il n'y a pas de BDD qui rassemble les résolutions des jeux.
Pour la neogeo, ca va, elle n'a qu'une résolution.
Pour les autres, c'est plus complexe et c'est carrément impossible (pour le moment) pour les jeux qui changent de résolutions en court de partie.
Coucou @substring et @ironic, je suis vos posts de loin avec attention, @ironic tu m'as scotché avec tes explications
Après le coté fréquence parfaite est un plus, parce que je me suis habitué à mes approximations.
Mais le fait de ne plus avoir à éditer de viewport retroarch, là, c'est classe !
Donc pour faire un résumé rapide, tu défini l'affichage parfait sur l'écran avec ton triplet, balance les résolutions et fréquences via ta base de donnée, et ton script se débrouille pour rester dans l'affichage défini par tes 3 chiffres.
C'est magique
J'en suis encore à avancer sur mes viewports par jeux pour fba, je dois en avoir fait une 100 ène, plus ça avance et plus j'ai la flemme.
Bref, chapeau a toi, c'est vraiment impressionnant !
Dès la période de concours finie, je me remet dans tout ça
C'est ça, absolument pu aucune édition des viewports sous Retroarch.
On modifie directement la taille de l'affichage.
Que l'image ai un énorme overscan horizontal ou alors de grosses bandes noires, on est toujours en 1920 pixels.
On règle ça avec le zoom. et le décalage horizontal.
Pour la position verticale aussi, pu besoin de régler le Custom Viewport Y, la résolution est crée et on utilise le décalage vertical de départ de résolution dans la BDD.
Je rappelle que la taille vertical n'est pas réglable par HDMI_Timings, il faut soit toucher au potard, soit utiliser le service menu. (ou jouer avec le 525/625 lignes).
Un exemple :
Si on a un jeux 224 lignes, pas de soucis, par contre, avec un jeu 240 lignes, on peut avoir des problèmes d'overscan. Assez souvent, on peut se permet d'accentuer l'overscan du haut ou du bas (décalage de l'image) pour afficher correctement le scrore ou d'autres infos.
Le jeu Toki est un bon exemple, il fait 240 lignes et si il est centré, on ne voit pas le timer du bas. Par contre, le score en haut ne touche pas le haut de l’écran, on peut donc monter un peu l'affichage et profiter pleinement du score en haut et du timer en bas. (Et ne pas oublier que ca peux beaucoup varier en fonction des TV).
Un autre exemple.
Xain'd Sleena, si on met le jeu en plein écran, tout est ok mais quand le jeu démarre, il y a de belles bandes noires sur les cotés et l'image a l'air un peut étriquée. Il suffit de passer, par exemple, le zoom de -25 a -10 ou 0 est on récupère le jeu en plein écran. L'overscan procuré par le zoom ne dérange en rien hors jeu et on est toujours en 1920 pixels horizontalement.
Quant au respect de l'aspect ratio, moi qui installais des PCB dans des bornes, je l'aurais réglé comme ça.
Pour le moment, j'ai pas optimissé les BDD, j'ai pas de retour, j'ai juste testé sur pleins de TV de mon coté pour être sur qu'il n'y avait jamais de désynchro.
Rpi2/Rpi3 - LCD/CRT- NES30 Pro-iBUFFALO
@ironic super merci pour ton travail et tes posts explicatifs très accessibles... ça rend cela bien plus facile d'accès.
@ironic said in advance mame 4.1:
Je rappelle que la taille vertical n'est pas réglable par HDMI_Timings, il faut soit toucher au potard, soit utiliser le service menu. (ou jouer avec le 525/625 lignes).
Dis-moi si je traduis correctement :
OK. Mais mon rtype, lui il en fait 256. Si tu l'affiches sur 525 lignes (idem sur 625) : soit ton jeu prend la moitié de la hauteur de la TV, soit tu doubles le nb de lignes, auquel cas on n'est plus pixel perfect. J'avour que le cas des resols avec plus de 240 lignes me rend vraiment perplexe.
Après, d'autres trucs m'échappent (je n'en listerai qu'une petite partie tout de suite) :
=> on en est à 3 paramètres dépendants du moniteur : le triplet et la resolution horizontale
J'arrête là pour ce soir, suis crevé lol Mais j'ai encore 2-3 palettes de questions derrière, surtout à la lecture du lien de neo-arcadia que j'ai posté
Une TV n'affiche pas toujours 224 ligne exactement.
Une des mienne affiche 236 lignes, une autre 230 lignes.
Mais c'est souvent proche des 224 lignes.
En 525 lignes, on affiche en moyenne 228 lignes.
525/2 car on est en non entrelacé. Ça donne 262 lignes (on arrondi).
262-6 lignes de synchro, il reste 0 lignes pour les porchs.
On peut baisser la syncho verticale ou augmenter la vitesse horizontale si la TV a besoin de porchs.
En 625 lignes, on affiche en moyenne 280 lignes.
625/2 car on est en non entrelacé. Ça donne 312 lignes (on arrondi).
312-6 lignes de synchro, il reste 50 lignes pour les porchs.
=> Conclusion : nous ne sommes pas tous egaux, et on peut se dire qu'une TV sur 2 aura de l'overscan si on veut du "pixel perfect". Sinon on doit adapter le nb de lignes, et là ca sent le tearing.
Oui.
Donc un jeu en 256 lignes (a moins de 57Hz sinon c'est dur de passer en 625 lignes) aura :
Soit des parties en overscan (en haut et en bas) pour un total de 256 - 228 = 28 liges.
Soit des bandes noires (en haut et en bas) pour un total de 280 - 256 = 24 lignes.
Les TV ont, soit un châssis analogique, soit un châssis numérique.
Pour le fameux triplet.
Je suis parti d'un HDMI_Timings qui apparemment passe chez tout le monde :
hdmi_timings 1920 1 48 192 240 240 1 8 5 9 0 0 0 60.0 0 37728000 1
Les Porchs horizontaux + la synchro horizontale = 1/4 de la résolution.
Le Front Porch = 1/10 de cette valeur.
La synchro = 4/10 de cette valeur.
Le Back Porche = 5/10 de cette valeur.
La 1ere valeur du triplet, celle qui permet de décaler l’écran, joue sur les Porchs horizontaux.
Valeur positive = décalage vers la droite
A 0, on a 48 et 240
A 1 on a 48-4 et 240+4
A 2 on a 48-8 et 240+8
...
Le script ne gère pas parfaitement les débordements, il met 0 si on a une valeur négative.
J’améliorerais ça quand j'aurais des retour, moi je le sais, ça me suffit.
Je recommande de commencer par la 2eme valeur.
Elle joue sur le zoom, elle ressert les Porchs horizontaux.
Valeur négative = rétréci l'image horizontalement tout en gardant les 1920 pixels de résolution.
A 0, on a 48 et 240
A -1 on a 48+4 et 240+4
A -2 on a 48+8 et 240+8
A -10 on a 48+40 et 240+40
La 3eme valeur joue sur la position verticale et donc sur les Porchs verticaux.
Valeur positive = décalage vers le bas
A 0, on a 9 et 10 (sauf si on passe en 626 lignes).
A 1, on a 8 et 11.
A 2, on a 7 et 10.
Bien-sur, à chaque changement de ces valeurs, la fréquence horizontale et le pixel clock est recalculé.
neogeo="224 59.1856 6 -22 4"
pcengine="240 59.94 6 -24 6"
playstation60="240 60 6 -24 6"
playstation50="240 50 6 -24 6"
megadrive60="240 59.92 5 5 4"
megadrive50="288 49.70 5 5 5"
mastersystem60="240 59.92 5 5 5"
mastersystem50="288 49.70 5 5 5"
n6460="240 60 6 -24 6"
n6450="240 50 6 -24 6"
nes60="240 60.10 6 -22 5"
nes50="240 50.01 6 -22 4"
snes60="224 60.10 6 -22 4"
snes50="239 50.01 6 -22 4"
amiga="270 50 -3 -26 6"
msx60="240 60 6 -22 4"
msx50="240 50 6 -22 4"
Vous pouvez voir que les SEGA on un zoom positif.
=> quels sont les critères pour dire "ca y est je suis calé". Çà m'échappe toujours.
Alors ça, ça dépend des gouts.
Je reprend l’exemple des SEGA, avec une console originale, il arrive très souvent qu'il y ai un décalage de l’écran.
(Bande d'un coté, gros overscan de l'autre).
Je pestais a l’époque quand je tombait sur une TV qui décalait l'image de façon inconsidérée.
La, on ne veut pas reproduit ce probleme, donc on cale l'image a sont gout.
Pour l'arcade, j'ai jamais vu un aspect ratio respecté a la perfection, les gars qui réglaient les moniteurs faisait ça a l'arrache.
Donc idem, on règle a l’œil en partant de paramètre de basse.
=> Dans ton fichier de DB, toutes les fréquences horizontales sont identiques. Je ne suis pas sûr que dans la réalité ce soit le cas.
Exacte, je prends cette valeur comme valeur de basse et après je la recalcule.
Pour du 240 par 60, on a bien du 15720
15720/60 = 262 lignes
Mais pour du 59Hz, on a pas 262 lignes mais plus. (plus on baisse en fréquence, plus on a de nombres de lignes)
Ne pas confondre lignes affichables (fixe) et lignes totales (variables).
15720/59 = 266.6 lignes..
J’arrondis a la valeur supérieur, soit 267 lignes. (J'aurais pu faire l’inverse, le temps me donnera, j’espère, raison).
Et je recalcule la fréquence horizontale.
267*59=15753Hz
Faut pas oublier qu'on est limité niveau pixel clock, donc pour les Porchs horizontaux, on peut pas respecté l'original.
On peut au mieux, les multiplier.
Pour les Porch verticaux (à 240p60)
Donc, on a pour notre HDMI_Timings de basse :
hdmi_timings 1920 1 48 192 240 240 1 8 5 9 0 0 0 60.0 0 37728000 1
Plus qu'a calculer le Pixel Clock
(1920 + 48 + 192 + 240) * 15720 = 37728000
On est pas obligé d’être en 1920, on peut être en, par exemple, 1600 (multiple de la resolution).
Parfait pour des jeux comme Mortal Kombat qui est en 400x254.
J'ai fais le choix de rester en 1920 pour le moment, pour pas compliquer les chose et pas etre obligé de gérer les resolutions horizontale des jeux. Mais ça fonctionne sans probleme.
Quand tu parles de Pixels Clock bas (déjà on a une limite basse), tu parles forcement de résolution et donc de pixels a afficher. Tu a surement raison mais dans la mesure ou le jeux a 60Hz affiche bien du 60Hz, c'est que tout est calculé et affiché dans les temps et que l’éventuel input lag ne doit pas dépasser 1 frame. Le "fb" du Pi excelle dans la mise a l’échelle.
Je testerais a l'occase...
Pour les PVM, je ne sais pas, j’attends des retour, je pense qu'il faut monter le Sync vertical a plus de 10.
J'ai 2 Sony Trinitron 36cm, c'est parfait, que du bonheur...
Le liens que tu as posté et la base de mes recherche
Si tu prends les VRAI Timings de la NeoGeo AES, tu peux multiplier par 5 horizontalement pour etre utilisé par le RPi
hdmi_timings 1920 1 80 175 255 224 1 16 3 16 0 0 0 59.583393 0 37502190 1
Pixel Clock limité = concession a faire...
Rpi2/Rpi3 - LCD/CRT- NES30 Pro-iBUFFALO
@ironic said in advance mame 4.1:
baddudes
C'est vraiment significatif le ralentissement avec baddudes, je viens de tester vite fait avec l'option SMP désactivé, (il est effectivement activé par défaut sur la version rpi), mais ça semble bien tourner.
Pour truxton2 je m'en doutais, mais merci pour la précision. Après remplacement du mauvais fichier .bin ça fonctionne convenablement. D'ailleurs la rom du set mame2010 est bonne.
