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
@archimage oh yeah !!!
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
@archimage qq éléments sur tout ca :
Donc techniquement, on pourrait sûrement déjà profiter de retroarch linux avec le switchCRT intégré du moment qu'on a X11, mais ca n'est pas vraiment la philosophie Recalbox pour le coup. Mais ca doit tout à fait pouvoir s'essayer sur une raspbian.
Former dev - Please reply with @substring so that i am notified when you answer me
Ex dev - Merci de me répondre en utilisant @substring pour que je sois notifé
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
Bonjour tout le monde, question de débutant peut-être un peu hors sujet.
Un adaptateur HDMI=>VGA, avec donc une conversion numérique/analogique ne produit pas de latence ?
Viens par là, c'est pareil !
@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.
@archimage Les tests ont été faits avec un modèle précis d'adaptateur ?
Viens par là, c'est pareil !
@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
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.
Hello tout le monde !
Dans la dernière version de Retroarch, on voit dans les changelog :
– CRT/RASPBERRY PI: Initial support.
Vous savez à quoi ça correspond ? Ca aurait a voir avec le tant attendu switchres ? Voir le framedoubling qui permettrait d'utiliser un écran 31Khz ?
J'ai entendu que Ben Templeman travaillait sur une version de Retroarch adaptée à la puissance du Raspberry et contenant ces nouvelles fonctionnalités, mais je n'ai rien trouvé depuis quelques mois là-dessus...
Dés que j'ai un peu le temps, j'essaie de voir s'il y a du nouveau dans les menus. Mais faut que je me chope une autre SD pour installer la dernière béta, et éviter de foutre en l'air mon install actuelle...
salut à tous, je déterre le topic car jusqu'à maintenant je n'avais pas de soucis pour mon rpi 3 sur crt et là y a eu un pb et depuis je n'arrive plus à sortir du 240 pour mes emulateurs.
j'ai bien es qui s'affiche sur ma tv mais dès que je lance neo, snes ou autres le signal passe en 31, bizarre !!!???
j'ai lancé un tv service et bizarrement j'ai pas de dmt 87
je suis sous recalbox 6.0, j'ai essayé la version 4.1 et toujours rien.
quel boulet je fais...
Bonjour à tous, moi je viens d'acheter un PI2SCART pour jouer en 240p sur trinitron, malgrès avoir regardé plusieurs tuto sur la modification du fichier "conf.txt" sur la carte SD, rien ne s'affiche sur le trinitron mais toujours sur mon écran plat, déjà dans le fichier confg.txt d'origine sans modification il y a déjà une ligne très longue, je ne sais pas si je dois la supprimer et mettre les nouvelles lignes en dessus, ou modifié directement cette ligne, quelqu'un qui utilise un PI2SCART peut il me l'envoyer ou prendre une photo de celui ci...
@idarius
Bonjour idarius, j'ai un rasperry 3B+ AVEC PI2SCART, j'ai bien le fichier conf.txt sur ma carte SD, comment doit il être modifié, car il y a déjà une ligne trés longue dedans, et quand je met tes valeurs en dessous rien en s'affiche sur mon crt...
@retrobricoleur @Link71 hello, j'ai un pi2scart de chez smallcab, à l'époque j'avais fait les tests ça fonctionnait. Je peut refaire un test et voir ce qui cloche.
d'après la doc
disable_audio_dither=1 dtparam=audio=on dtoverlay=vga666 enable_dpi_lcd=1 display_default_lcd=1 dpi_group=2 dpi_mode=87 hdmi_timings=320 1 16 30 34 240 1 2 3 22 0 0 0 60 0 6400000 1#240
peut être dészactiver le spi et l'i2c qui utilise des gpios
dtparam=i2c_arm=off dtparam=spi=off
ne pas oublier de mettre un mode 87 ou default pour le mode global dans le recalbox.conf
global.videomode=DMT 87 HDMI
ou
global.videomode=default
Attention aussi de ne pas activer le support gpio des joy et bouton
controllers.gpio.enabled=0
"UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie
@ian57 j'ai oublié de préciser que j'ai un câble HDMI VGA péritel et pas un pi2scart
J'ai bien suivi le config.txt et le recalbox.conf et pas de dmt 87, c'est bizarre, ça vient de la version ??
Du recalbox
Du crt
La vie quoi 😎
@ian57 , bonsoir ian57,tout d'abord merci de me répondre, car le périphérique PI2 scart est peu répandu, ceux qui est dommage c'est qu'il y a sur youtube plusieurs video du PI2SCART sous recallbox, mais personne ne propose de pouvoir télécharger le fichier conf.txt.
J'ai rajouté les lignes que tu as indiqué dans le fichier conf.txt, mais quand je rallume le raspberry (il est branché en hdmi sur un écran de PC et en pi2scart sur Sony trinitron), mais à chaque allumage du raspberry 3B+, seul l'image que l'écran de pc apparait.
Sincérement c'est désespérant ...
@Link71
poste ton archive de support.
@retrobricoleur j'ai utilisé cela (câble HDMI VGA péritel ) sur une borne avec une tv 36 cm et une RB 6.1.1, il n'y avait pas de soucis particulier. J'ai le tuto sur mon wiki, il faut que je le publie sur le wiki RB.
Voici le schéma de mon cablage 
à la sortie du convertisseur vga.
ensuite pour les config c'est très différent du VGA666/pi2scart/rgbPi (ils utilisent tous les 3 le dpi en mode 18 bits 6 bits par couleur :
Dans le config.txt on configure comme si on avait un ecran 1920x240
hdmi_cvt=1920 240 60 1 1 0 0 hdmi_disable_edid=0xa5000080 #Enables the ignoring of EDID/display data if your display doesn't have an accurate EDID. hdmi_pixel_encoding=2 #Force the pixel encoding mode. By default it will use the mode requested from edid so shouldn't need changing. avoid_safe_mode=1 disable_overscan=0 #oversan enabled hdmi_drive=2 hdmi_group=1 hdmi_mode=6 hdmi_force=1
dans le recalbox.conf on force ES à s'afficher en 480 entrelacé, ça pique un peut les yeux, sinon on utiliser les CEA 8 HDMI un 240 non entrelacé, mais il faudra un thème adapté à cette faible resolution
system.es.videomode=CEA 6 HDMI #global.videomode=CEA 4 HDMI global.videomode=DMT 87 HDMI
ensuite il faut dire à libretro pour chaque émulateur de n'utiliser d'une partie de la fenetre 1920x240, pour cela il faut créer un fichier de config pour chaque emu : cf https://forum.recalbox.com/topic/18927/recalbox-6-1-sur-écran-crt/9 à placer dans /share/system/configs/retroarch
Par exemple mon megadrive.cfg
aspect_ratio_index = "23" custom_viewport_width = "1792" custom_viewport_height = "224" custom_viewport_x = "104" custom_viewport_y = "16"
il faut adapter les 4 dernière ligne en fonction de la géométrie de l'ecran. Il est possible de trouver les valeurs en reglant depuis le menu de retroarch
si cela n'est pas fait, l'image de l'émulateur sera complètement écrasée au milieu de l'écran.
"UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie
@link71 je n'ai pas eu le temps de faire de test ce soir. Que se passe 'il si tu ne branche pas l'HDMI et seulement le crt sur le pi2scart? Après mes tests etait avec un pi3 et pas un pi3+, ya peut être eu des changements
@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.
