Je ne comprends pas ce qui est confus... Le viewport doit être custom et unique par console. Pour ne pas avoir de tearing j'ai besoin de sortir du 1920x224 pour la snes, du 1920x210 pour atari et 1920x275 pour pc engine, tous recentrés de 60 en y et 5 en x... c'est ma télé CRT via cette installation HDMI>VGA>SCART qui exige ça pour que l'image soit traitée correctement. Comme ça ne correspond pas aux preset par défaut dans recalbox, j(16:9, 4:3...) j'ai mis custom. Sauf qu'il retient un seul ratio custom pour toutes les consoles alors qu'elles sont toutes différentes.. . Si je mets 224 l'atari et la pc engine produisent du tearing.. J'ai cru comprendre qu'il y a deux manières pour forcer un viewport par console, soit mettre "save settings per core", soit charger une "configuration custom" depuis recalbox.conf. A partir de là apparait mon problème de manettes qui ne suivent plus les réglages d'Emulationstation. Je veux enregistrer ces réglages par console, sans perdre l'autoconf des manettes au démarrage des cores de retroarch. D'où ma proposition d'intégrer de nouvelles variables d'autoconf depuis recalbox.conf.

Je vais peut être sembler tatillon, mais pour moi il vaut mieux rester exigeant même si le chemin parcouru depuis LCD land est énorme. J'ai en effet le pi et les vraies consoles branchés sur le même écran. Pas deux écrans côte à côte, car je n'ai pas deux moniteurs identiques, ce serait l'idéal pour comparer. J'utilise un PVM 20L4 et une AV Famicom RGB vs Retroarch. Pour moi l'input lag n'est pas significatif des fois je n'arrive pas à comparer, mais je peux dire qu'il est présent lorsque je m'habitue à l'un puis je passe à l'autre. Je n'utilise pas une méthode scientifique pour le mesurer, je ne peux pas dire s'il est présent pour une grande partie des jeux, mais je le ressens sur ceux demandant une réactivité accrue, par exemple Super Mario Bros 3 et les changements de direction fréquents pendant les sauts. Pour moi il y a plusieurs hypothèses. Est-ce lié à la différence entre la fréquence réelle de la console et celle émulée ? J'ai constaté que le taux de rafraichissement estimé du moniteur est variable sur Retroarch... Est-ce spécifique à chaque core et son interpretation de la machine ? Aucune idée...

J'ai aussi comparé Super Mario Bros 3 avec un vrai PC en sortie VGA sur une Arcadevga, c'est variable selon les cores utilisés, en général un poil plus réactif mais toujours en dessous du vrai hardware. Petite précision, je n'utilise pas encore les hdmi timings, juste le mode 1920x240 j'attends que la 4.1 sorte en stable pour changer de config par manque de temps, ça peut peut être influencer la perception.

On peut continuer à se baser sur nos témoignages et sensibilités en attendant d'avoir une méthode scientifique pour mesurer ces différences.

En tout cas je ne serais pas étonné qu'il reste toujours des traces d'input lag à mon avis c'est intrinsèque à l’émulation, qui est toujours une imitation du hardware en software.

@ironic Voici le cable que j'utilise http://retrocables.es/tienda/index.php?id_product=55&controller=product&id_lang=4

Je suis en train de me demander si la fréquence 15khz ne dépend pas de la résolution verticale. Est-ce que 240p = 15khz ? Cela voudrait dire qu'il n'y a pas besoin de convertir le signal et que le pi sait le faire. J'ai quasiment le même adaptateur HDMI. Si le signal n'a pas besoin de conversion cela voudrait dire que ça devrait marcher de brancher le pi à ta borne.

@acris si je passe par là ça n'annule pas les autres parametres automatisés comme la detection des manettes ? De plus je ne comprends pas la différence entre ça et l'option Configuration Per Core. C'est la même chose mais en utilisant un deuxième fichier de config dans un autre endroit ?

Voici un test se performances sur le pi fait par Ben suite à notre discussion à ce sujet.

Pour lui le pi est parfaitement capable de gerer le frame doubling de la même manière qu'il peut gerer du 720p.

X11 selon lui n'affecte pas les performances au contraire il voit une amélioration.

Preuve en images.

Raspberry pi 240p sur 31khz

@cazeysan il a dit qu'il avait pris un modele au pif sur amazon avec une bonne appréciation, pas d'etudes précises sur le sujet, ça fonctionnait bien c'est tout

@cazeysan Ben a mesuré ça avec une camera tournant à 60fps passée à 1 frame par seconde, il n'a aucune frame de décalage en utilisant X11 et hdmi>vga, la frequence affichée correspond à la fréquence du jeu, pas de limitation comme on peut le constater sur un hdmi>vga utilisé avec le driver video natif qui donne accès à seulement une panoplie limitée de fréquences. Donc le hardware n'est pas réellement la cause du lag, mais la limite posée par le driver.

@Substring :

• Si un jeu est en 54.5hz par exemple, la fréquence à passer avec un nombre entier si on veut l'afficher sur du 31khz est de 109hz (54.5x2). Retroarch est capable soit d'insérer une blank frame à chaque image, ou une double frame, c'est ce que préconise Ben. Si tous les cores ne sont pas capables de supporter le double frame sur le pi pour une question de ressources ce n'est pas si grave, il suffirait de désactiver l'option 31khz 240p et passer en 31khz linedoublé (480p). Il faut voir le 31khz comme une cerise sur le gateau permettant de se passer d'un moniteur pro. Si tout tourne bien sur 15khz, c'est déjà pas mal. Je ne m'inquiète pas trop pour ça Ben fait partie de l'équipe de Retroarch et ils sont très enthousiastes avec l'arrivée de ses fonctionnalités, ils vont surement optimiser pour que tout marche bien sur le pi.

• je ne vois pas en quoi on s'eloigne si on reste sur un ratio X2 entier sur la fréquence, 30 images par seconde peuvent tres bien passer dans 60 images par seconde, si c'est 59.9 la fréquence d'origine, ça donnera tout simplement 119.8

• comme tout, il faut savoir ce qu'on gagne et ce qu'on perd : ce qu'on gagne c'est le support plug and play 240p 15khz/31khz avec toutes les modelines déjà fournies par retroarch en temps réel (cf sonic 2 switch bien en 480i automatiquement quand il passe en 2 players) et ça c'est déjà un bijou car on a les vraies infos délivrées par le core en temps réel y compris celles de mame ou fba. Deuxièmement, le fait de ne plus être dépendant d'un gpio, ou d'une extension quelconque, un simple hdmi>vga suffit pour faire le taf. C'est la solution la moins chère niveau matos, ça laisse le gpio libre. On perdrait de la perf ? Combien ? Quel impact sur nos jeux ? Je pense que c'est bien d'avoir une philosophie mais il faut la mettre à l'épreuve...

A suivre

Salut tout le monde,

J'ai longtemps cru que seuls les CRT 15khz ou trisync pouvaient encaisser du 240p tel qu'on l'aime, avec de vraies grosses scanlines, et une image sharp non upscalée sans filtres.

Cela est vrai pour du 240p en 60hz, 60 images par seconde, on rentre dans le spectre des écrans 15khz.

Cependant, lorsqu'on envoie du 240p120hz, par un savant calcul mathématique on rentre dans le spectre de compatibilité 31khz, et l'image 240p devient désormais compatible.

C'est ce que Mike Chi et Ben Templeman démontrent avec ingéniosité dans ces 2 vidéos.

L'image est affichée 120 fois par seconde au lieu de 60 fois par seconde, car il s'agit d'émulation, en effet l’émulateur contrairement à la console peut envoyer 2 images à la fois sur 2 instances séparées sans produire de lag.

On a donc le même rendu qu'un bon BVM en termes de finesse et de scanlines.

Dans le cas d'un upscaler et une vraie console il aurait nécessité d'enregistrer la premiere frame, et de la renvoyer immédiatement à l'écran, ce qui résulte à une frame de lag. Pour le moment un tel upscaler n'existe pas car il n'y a pas de fonctions de frame buffer suffisament puissant intégré.

Aujourd'hui Ben Templeman, qui a déjà porté CRT Switchres sur Linux et Windows en branche officielle, est en train de porter cette fonction 31khz dans Retroarch nativement, et ça va bientôt débouler sur Windows, Linux et une distribution spéciale Raspberry pi via la sortie HDMI, sans aucune limite de pixel clock, car il utilise des drivers video X11 spéciaux qui ne sont pas fournis d'office dans nos distributions habituelles. Il arrive avec ça à débloquer les limitations du pixel clock du pi et du coup rendre obsolète VGA666.

Cela veut dire qu'avec un simple pi, un vulgaire convertisseur hdmi>vga et un vieux crt de pc dont tout le monde veut se débarrasser car incompatible avec les jeux retro 240p, bein on fait à peu près ce qu'on peut faire avec un BVM multisync, pour le moment en émulation, et peut être bientôt avec de vraies consoles, notamment celles en fpga...

Donc si vous avez un vieux cathodique de pc qui traine et que vous êtes desespéré de trouver un bvm multisync... ou une Naomi 31khz qui traine par là, ou si vous avez peur de cramer votre trisync à switcher tout le temps en émulation, soyez patients...

Je vous laisse apprécier les vidéos.

15khz Ben Templeman Raspberry Pi Retroarch avec X11 et HDMI>VGA

31 khz Ben Templeman

31 khz Mike Chi

https://www.youtube.com/watch?v=OVKw_jJmAYY&t=37s

La versions nightly de Windows et Linux intègrent déjà la mise à jour, il vient d'annoncer qu'il se concentre sur le pi

le groupe facebook pi2jamma, le développeur lui même l'a dit

c'est en cours apparemment

Déterrage de topic :

J'ai découvert le travail de Ben Templeman qui a integré le CRT switchres à Retroarch sur Linux et Windows.

Je n'ai pas eu le temps de tester mais je trouve ça vraiment fantastique.

Il vient d'annoncer qu'il travaille sur portage sur Raspberry Pi.

Voici le lien de son GITHUB

https://github.com/alphanu1/MME4CRT

@eckomecko Les CRT VGA démarrent à 640x480p, et n'incluent pas des résolutions SD comme 256x240p, ce qui nécessite d'upscaler la résolution (2X par exemple), ça se traduit par un doublage des pixels pour compenser l'absence de scanlines qui sont des lignes entières de vides, c'est ça qui fait que c'est moins joli d'upscaler. D'autant plus que si tu fais du 2X pour préserver le ratio de la résolution que je t'ai donné en exemple, tu te retrouves avec un 512x480p, ce qui veut dire que tu auras soit des bandes noires, soit une déformation pour rentrer dans du 640x480p qui veut dire création de nouveaux pixels au pif qui n'existaient pas dans le dessin d'origine, un peu comme le ferait un antialiasing. Pour résumer, si tu veux un rendu parfait il faut jouer avec la résolution d'origine, dans le framerate d'origine avec un écran qui supporte cela nativement.