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.
@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.
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
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
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
@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.
La sortie de la 4.1 m'a permis de reprendre là où je m'étais arrêté, je vais bientôt mettre à disposition des fichiers permettant de jouer en 240p en pixel perfect, sans tearing en passant par le port HDMI. Cela marchera de manière automatisée en partant de n'importe quelle image officielle. Il suffira de copier un set de fichiers que je mettrai en ligne et acheter le cable et l'adaptateur sur les liens disponibles.
J'ai un pi2scart, un rgb-pi et un vga666, je pense que le travail d'Ironic avec Atg, celui de Jochen avec son Pi2scart, et le travail d'Ajefr est super intéressant et plus avancé que la méthode hdmi pour avoir vu ça de près.
Cela dit je pense que ça vaut la peine d'aller jusqu'au bout de toutes les méthodes pour pouvoir faire un vrai bilan sur le lag, des questions pratiques, de coût, les perspectives d'évolution de chaque méthode. Chacune a des limites bien précises et pourrait se débloquer selon le développement des drivers etc...
Cela ne se voit pas trop sur le forum mais on a des échanges sporadiques sur ces questions, et chacun tente des trucs de son côté.
Merci pour l'adaptation! Pikeyd se lance au démarrage ! les touches correspondent au mapping par défaut que l'on trouve sur le tuto, mais Pikeyd n'est pas reconnu comme un périphérique pour l'associer à Xarcade. Les touches clavier par défaut sont reconnues sur EVTEST, mais ne sont pas assignées à chacun des émulateurs, ni à Emulationstation.
Bonjour,
J'ai fait récemment l'acquisition d'un Pi2Jamma pour l'intégrer à ma borne.
http://strike-devices.net/index.php/pi2jamma/
Ce dernier a sa propre distribution Regamebox, mais aussi un script destiné à être utilisé avec Retropie pour faire reconnaitre les résolutions arcade, mais aussi pour intégrer un daemon permettant la reconnaissance de tous les boutons à travers le peigne jamma en passant par les GPIO restants.
J'ai réussi à obtenir l'image et le son en utilisant l'overlay VGA666 mais il me manque la reconnaissance des boutons. Le script concerné s'appelle Pikeyd165, il est disponible sur ce lien :
La méthode crée par Chris Binarystar ete reprise par Jochen Zurborg sur sa page :
" 1)
Download the latest version of Retropie and write to your microsd card using Win32DiskImager.
On your computer, open /boot/config.txt on the microsd card.
add the following lines at the bottom :
disable_audio_dither=1
dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
hdmi_timings=320 1 23 25 39 240 1 4 3 15 0 0 0 60 0 6400000 1
Extract the contents of p2j_setup.zip to the root of the USB stick containing your ROMs.
Plug a USB keyboard, the microsd card and USB stick into your Raspberry PI and power on.
Once booted, configure keyboard controls for Emulation Station.
Quit Emulation Station by pressing [START] and selecting QUIT (keep scrolling down) and then QUIT EMULATIONSTATION.
At the command prompt, type :
cd /media/usb0
then type :
sudo sh p2j_setup.sh"
Voilà, si jamais une adaptation de cette démarche à Recalbox, cela rendrait cette dernière entièrement compatible avec Pi2Jamma.
Je peux faire des tests si vous avez des pistes de modification car j'ai le hardware en ma possession.
Je trouve certains mots un peu forts à l'égard des gens qui bossent sur le sujet.
C'est toujours bien de voir du progrès quelle que soit la méthode de travail.
Le travail de recherche des modelines est vraiment ingrat et nécessite beaucoup d'experimentation hardware.
Je comprends parfaitement qu'Ironic mène cette recherche dans son coin. Il reste ouvert et explicite lorsqu'on lui demande des choses.
Traiter d'illuminés les personnes qui font progresser l'émulation dans ce sens n'apporte rien de productif.
Je suis sûr qu'il y a un recoupement à faire avec la branche principale de Recalbox en récuperant le gros du travail qui est de chercher les modelines.
Mais il faut être patient et dialoguer sereinement sans mépris.
Personnellement je suis impressionné par ce qu'ont accompli Subs Ironic et Atg et je doute que le cable soit vraiment super rentable il coute dans les 30 balles ce qui reste simple correct et accessible. Je trouve qu'il faut etre compréhensif que chacun a ses methodes.
Certains font du matos pour CRT basé sur Recalbox et on ne les pas entendus sur cette discussion.
Le chemin est encore long et j'espere que les efforts convergeront.
Salut,
J'utilise un setup HDMI>VGA>SCART>BNC qui ne marche qu'avec ce cable :
Il dispose d'un séparateur de synchro integré qui est alimenté en +5V par la broche 8.
J'ai dû modifier mon cable pour l'alimenter, et ça ne marche qu'avec ce setup.
En espérant que ça règle ton problème.
merci pour les réponses, je dois avoir de mauvaises roms alors 
oui, j'ai constitué mon romset avec clrmamepro, mais moon patrol n'y figurait pas alors je l'ai copié manuellement en esperant qu'il marche car j'ai vu par ailleurs quelqu'un l'a fait tourner sur recalbox sur un ancien thread, je pense qu'il doit se baser sur un core de mame plus récent que celui integré dans la version 4.02 stable
Bonjour,
Etant un peu dans le rush pour aider un ami pour mettre en place une installation sur borne, on comptait utiliser Recalbox à cet effet.
Je dois lui faire tourner Moon Patrol de Midway, je pensais que le jeu serait supporté par Mame, mais ce dernier ne se lance pas ni avec FBA libretro, ni Mame sur 4.02 stable
Auriez-vous une solution rapide pour résoudre ça d'ici demain ?
Je vous remercie
@julien-carpezat par definition un crt finira par mourir un jour quelle que soit l'input, si tu veux qu'il dure fais le reviser sinon achetes en un autre en stockage. Si tu ne lui envoies pas des frequences trop eloignées de 15khz ou des voltages exotiques tu n'as rien a craindre de ton raspberry je pense...
@idarius Pour la dreamcast sur les jeux en 2d j'entends bien ce sont des sprites, le 240p est préférable. En revanche pour la 3d, même si le passage en progressif fait disparaitre le scintillement, tu descends aussi en résolution de rendu vectoriel, même si les textures restent à la même taille, donc tu obtiens plus d'effets escaliers sur les vecteurs, et un scanline plus volumineux, ce qui n'a pas le même effet sur l'image quand ce n'est pas du pixel art rasterisé, c'est une logique complètement différente à mon avis. Quitte à choisir pour la 3d je préfère le scintillement de l'entrelacement aux escaliers sur les vecteurs en diagonales. C'est valable aussi pour la N64. Le progressif 480p serait l'idéal mais comme tu dis indisponible sur nos PVM à moins que tu trouves un crt 31khz.