Solved advance mame 4.1

[Substring]

@ironic Quelques pistes pour advmame :

• tu edites ~/configs/advancemame/advmame.rc.origin et tu passes device_video à auto
• tu lances TERM=xterm advcfg -rc ~/configs/advancemame/advmame.rc.origin pour configurer ton écran
• tu peux éventuellement lancer TERM=xterm advv -rc ~/configs/advancemame/advmame.rc.origin pour fignoler chaque résolution

Pour 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

[ironic]

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.

[acris]

@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

[lolo]

@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.

[ironic]

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,

[Substring]

@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)

[ironic]

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

[Substring]

@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 :

• parce que ca n'interesse pas que recalbox (je pense que quand retropie va trouver ca ils vont se jeter dessus aussi)
• parce que je peux en faire une intégration dans recalbox
• parce que ca fait qq mois qu'on est bcp à bosser dessus, chacun à sa facon, ca serait un peu l'aboutissement de tout ca

[ironic]

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).

• Les résolutions verticales, les fréquences, les orientation.
• Il y a également la position et la taille de l’écran (de la résolution ouverte) horizontalement et la position verticale.
  (Ça permet de "calibrer' au mieux chaque jeux et je vous prie de croire que c'est utile)
• Le multi-thread est désactivé par défaut et peux être réactive individuellement (SMP_YES).
  (Il y a plus de jeux qui n'en n'ont pas besoin et ça permet de diminuer l'input lag).
• Puis il y a la fréquence horizontale et les porchs/syncro.
  (Inutile d'y toucher saut éventuellement pour certains moniteur récalcitrants).

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).

• Le script créé et lance un HDMI-Timings en fonction des données du jeux, lance le jeu et quand on quitte le je, restaure les HDMI_Timings d'ES.
• Le fichier advmame.rc et copier (avant le lancement du jeu) dans /tmp, modifié pour configurer l'orientation du jeu.
  display_rol no - misc_smp no

Le 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.

• La partie la plus intéressante du script est forcement le générateur de HDMI_Timings.
  Personnellement, je vais continuer dans cette voie car ça fonctionne du feu de dieu (Testé sur 7 TV CRT).

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

[Substring]

@ironic Là ca appelel à 10000 questions, bon courage

• ton hdmi_timings du config.txt, il n'est que pour ES si je devine bien ?
• le triplet 6 -25 5 tu le règles à partir de quoi ?
• pk réinventer ce que advmame fait déjà ?
• comment tu gères les jeux à plus de 224/240 lignes (genre rtype) ? Me souviens avoir lu que les tv entrelacent au-delà de 288 lignes (c'est de toi en plus)
• Pourquoi diable ne pas laisser advmame faire son taf tout seul ? Genre advcfg -> on configure le type de TV -> on ajuste l'écran -> en avant Guingamp !
• tu gères comment les moniteurs TRES capricieux genre PVM ?
• ca marche avec imame4all ? hahaha je rigole
• avec tout ca, il faut tjrs un retroarch.cfg par jeu pour caler le viewport ou non ?

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:

1. nous ne sommes pas le support de rgb-pi, bien que tu sembles très en contact avec aTg
2. pas véritablement de raison de privilégier rgb-pi plus qu'une autre solution genre HDMI2VGA. Je pense notamment à ceux qui disposent d'un moniteur PVM et qui sont sur BNC, et qui n'ont donc aucune raison de s'attarder sur rgb-pi
3. il profite très largement de notre travail sans y contribuer d'une quelconque façon
4. Je n'ai pas vu une seule fois les sources de rgb-pi OS, alors que la license GPL de Recalbox le lui impose. Au passage, c'est assez scandaleux d'oser renommer Recalbox à cette fin.
5. C'est qqu qui très clairement fait de l'argent sur le travail de Recalbox et de sa communauté. Sans Recalbox, il n'aurait pas d'avenir. Inversement, le CRT peut tout à fait fonctionner sans lui

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

[ironic]

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 ?

• Non.
  Le ficher 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.
  Config généré :
  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 = à 0
  custom_viewport_y = "0" Est toujours = à 0
  video_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.

[idarius]

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

[ironic]

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.

[ian57]

@ironic super merci pour ton travail et tes posts explicatifs très accessibles... ça rend cela bien plus facile d'accès.

[Substring]

@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 :

• une TV affichera toujours 224 lignes
• une TV peut éventuellement afficher 240 lignes
• une TV a peu de chances d'afficher entre 240 et 288 lignes sans toucher aux potards de la TVpour "resserrer" les lignes et toutes les faire tenir sur l'écran
  => 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.

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) :

• il faut pouvoir regler le triplet (d'ailleurs, ton fichier de DB le reproduit a chaque ligne alors que ca devrait etre une "variable globale" à tout affichage CRT). Là il faut une méthode claire pour caler ce triplet : en quelle resolution / fréquence, quels sont les critères pour dire "ca y est je suis calé". Ca m'échappe toujours
• 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. Si je me base sur la méthode de calcul venant de http://www.neo-arcadia.com/forum/viewtopic.php?t=37718, il faut aller chercher dans le code la durée de blanking de chaque jeu, trouver le front porch et le pulse, en déduire le back porch par addition. De là on peut calculer la fréquence verticale. Je sais, c'est pinailler sûrement, mais ca ne fait que 8 jours que je me penche vraiment sur le truc, encore un peu de mal à tout digérer. Mais j'ai un bout de ppython prêt à manger du code source de mame qui n'attend que qq lignes de modifs pour me générer ces infos. Et par chance, mame 0.78 et advmame ont la meme structure de driver avant que MAME ne passe tout en C++
• le 1920 de large a, si j'ai bien compris, 2 fonctions : réglage plus fin du centrage horizontal, pixel clock élevée à cause de cette histoire de 19.2 MHz et ses diviseurs entiers. De même le DPI est locké à 31.25MHz. En parlant de ca, faut s'assurer que tout ton travail marche aussi en HDMI. Je reviens à la pixel clock : sans en être vraiment sûr, mais je pense que plus la pixel clock est basse, moins le pi fournit d'efforts, et donc on réduit le lag. Ca a aussi d'autres incidences : les PVM qui n'aiment pas les résolutions bizarres (hein @idarius) (a ce sujet, on a testé sur un PVM un pi en 1920x240 avec rgb-pi ok sur une excellente TV cathodique Sony, ben pas moyen d'afficher quoique ce soit). Donc là encore, préparer un point de flexibilité sur le 1920

=> 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é

[ironic]

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 les TV a châssis analogique, il faut toucher aux potards dans la TV. Je le déconseille fortement aux non électriciens.
  ME suis pris un coup de 25000 volts de la THT, ça démonte
• Pour les TV a châssis numerique, il faut trouver le Service Menu a l'aide de la télécommande (faut trouver les infos sur le net, impossible de trouver par hazard) et toucher au reglages.
  La aussi je dis attention, une de mes TV (acheté 10€ sur les brocantes, une magnifique Philipps 55cm) à tenu 1 heure. J'ai activé par erreur une option hardware donc elle ne disposait pas. La TV boot en boucle, elle cherche le matos, le trouve pas, reboot... Plus rien a faire....
  (Mes autres TV ne permettent pas de faire de conneries dans le Service Menu).

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é.

• J'ai mis ces valeurs pour chaque jeux car elle permet d'adapté chaque jeux en fonction des contrainte de la TV.
  J'aurais du mettre 0, 0, 0 partout mais j'ai laissé mes reglages car il sont pus proche de la moyenne des TV.
  A 0, 0, 0, l'image a un enorme overscan.
  Voila les valeurs que j'ai pour les consoles. Il ne faut pas oublier que certaines consoles on besoin d'un overscan.
  Les 2 premires valeurs sont le nombre de ligne et la frequence.

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)

• Nombre de lignes 262.
• Synch vertical, j'ai mis 5 partout, mais cela fonctionne de 3 a 9 chez moi.
  C'est la que plus d'essais permettront de comprendre ou sont les limites des CRT, surtout les PVM.
• Reste 262-5=257 lignes.
• 257-240=17 lignes.
  Ces 17 lignes sont a repartir entre le Front et Back Porch vertical.
  Je divise par deux (Parce que je ne connais aucune de ces valeurs et quelles servent uniquement a positionner l’écran verticalement) et j’arrondis la valeur supérieur le Back Porch si il y a lieu. (Car j'ai remarqué qu'il fallait plus souvent descendre l'ecran que le monter)
• 17/2=8.5
  Soit Front Porch = 8 et Back Porch = 9

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...

[ian57]

@ironic rahhhhhh lovely ma culture TV t'en remercie

[Substring]

@ironic Je vais te passer en CRT maniac mec

L'approche de neo-arcadia etait l'inverse, à savoir partir des informations du driver mame, et tout recalculer à partir de là. Pourquoi ne pas avoir appliqué cette méthode ? OK c'est bcp plus long, mais ca permet d'être plus proche du système arcade, quitte à arrondir un chouia la fréquence pour s'en tenir à un pixel clock "faible" quand c'est possible. Exemple bete : c'est dommage de tout recalculer si le pixel clock de la board d'origine est quasiment egale à une du pi ...

Bon faut que je continue à mettre tout ca en équations, la stable de la 4.1 à faire parce que si je me disperse, je ne vais rien finir. Des joueurs sur PVM il y en a un certain nombre, j'aimerais autant essayer de leur faciliter à eux aussi la tâche, et jai besoin d'écrire et théoriser tout ca pour comprendre

[digitaLumberjack]

Magique

Bon je vais quand même relire une seconde fois, y'a pas mal d'info à intégrer.

Merci pour votre job