Reprise du message précédent :
une idée de quand arrive cette version 4.1 stable pour Pi3 justement ?  

La unstable marche franchement pas mal hein, j'ai eu zéro bug

j'ai pas d'autre carte micro SD pour tester malheureusement (j'ai pas envis de m'emmerder à tous copier, reinstaller, reconfigurer etc... si ca bug et que je veux repasser sur 4.0)
c'est surtout le bluetooth qui m'interesse avec ce 4.1

 
  C'est l'enfant de l'amour entre Retropie et Recallbox ?

bon sinon je viens de trouver comment acceder à recalbox manager, j'avais demandé y'a quelque semaine comment avoir la temperature du CPU, on m'avait repondu tout un system de benchmark hyper compliqué ...
 
en fait dans recalbox manager, onglet monitoring, on à l'utilisation CPU, ram, et la temperature CPU
 
avec mon rad de chipset, en jeu, ca tourne entre 49 et 54°C, plus regulierement entre 51 et 53°C, ca vous parait correct ?

 
fait une image de carte actuelle, si ca merde tu remet l'image à l'identique

Ah non moi je t'avais demandé de faire un benchmark avant que tu demandes comment voir la température
 
Les températures sont correctes ; avec mon boîtier/radiateur j'obtiens à peu près les mêmes chiffres. J'imagine que ton wifi n'est pas bloqué (contrairement au mien) mais moi j'ai pas eu besoin de bricoler

Ok !  
Et du coup, le fait de changer accélérait le jeu ?

Oui, ça accélérait un peu, et c'était un peu plus fluide car on passait de 50 à 60 fps.

je fais ca comment ? j'arrive deja meme pas à lire la carte SD dans le PC, un formatage proprietaire lors de l'installation de recalbox ?

et si je vois que 4.1 marche bien, comment je transfert mes sauvegarde des jeux à partir de l'image ?

ha ok, ben j'avais pas compris ca comme ça

wifi pas "bloqué" (je vois pas trop ce que tu veux dire par là ???), le Rpi3 est connecté à ma box

bricoler ne me derange pas, attendre la livraison d'un boitier venant de chine par contre oui

Je connais pas ce jeu  

 
   
 
https://sourceforge.net/projects/win32diskimager/
 

 
Not sure if serious malgré le redface, donc dans le doute : Bsnes est un émulateur SNES qui demande un gros CPU pour tourner correctement, car son émulation est extrêmement précise. Un Raspberry Pi ne peut pas le faire tourner correctement, pourtant ça n'émule que de la SNES.

merci, je vais regarder ça
 

du coup ca n'a aucun interet cette emu Bsnes non ? parce que celui sur recalbox fonctionne parfaitement

de mon coté je suis degouté mais j'ai du mal avec les roms de jeux PS1

Tekken 3 niquel, coolboarder 3 niquel

par contre gran turismo (le 1er) tous pourris en qualité, genre video archi compressé, hyper pixélisé (quand je compare à des video sur PSone, ca se voit franchement) et avec un genre de filtre à cadrillage de pixel sur toute la surface de l'image

sur Tombi! pas de son

medievil impossible à trouver en français

et impossible de trouver FFIX et Gran turismo 2 complet (il manque toujours un disque pour chacun, donc pas complet )

Tu crois que cela marche parfaitement mais non.
Dans la plupart des cas tu ne vois pas la différence mais sur certain jeu il y a des bugs graphiques ou des timmings qui changent.

Ou alors il est juste pas optimisé.
 
Au choix.
 
 
 
Ce qui ne veut pas forcément dire qu'il est pourri, hein. Mais ça m'étonnerait très, très, très fortement que ça ne soit pas possible de faire plus rapide en conservant l'émulation. Il "suffirait" probablement d'un peu d'efforts d'optimisation pour que ça passe tranquille sur pi3.
Aujourd'hui, tu as des systèmes de machines virtuelles qui émulent parfaitement des systèmes autrement plus complexes, il suffit de regarder ce qu'a fait MS avec la rétrocompatibilité Xbox 360 sur One.

Tu peux modifier le code source si tu veux
https://byuu.org/emulation/higan/
 
C'est de l'émulation bas niveau. c'est pour cela qu'il faut un CPU très performant par rapport au système émulé.

En général plus c'est bas niveau plus c'est performant  

J'ai pas dit que c'était facile
Je dis juste que "ça émule le processeur donc c'est lent" ce n'est pas une relation de cause à effet "valide" puisqu'il y a des tas de machines virtuelles qui font du bas niveau et qui sont performantes. C'est donc sans doute plutôt "c'est pas (encore) optimisé donc c'est lent".

tu peux faire du code en assembleur qui rame sa mère, c'est pas un souci

 
Tu as bien les fichiers de BIOS au bon endroit  ?

j'en sais rien, j'ai juste la rom du jeu que je place dans le dossier roms, un .bin pour gran turismo, idem pour tekken qui lui marche niquel
je pense que c'est juste une mauvaise roms pour GT

tombi! pas de son en jeu (mais dans les menu du jeu oui), donc je sais pas ce qui bug (j'en ai testé deux, un avec 3 fichier .ccd + .cue + .img , et un autre avec deux fichiers  .bin + .cue, y'en à un qui ne marche pas du tous mais je sais plus lequel)

j'ai rien compris à cette histoire de fichier bios   (pour moi un bios c'est le micro-logiciel d'une carte mere)

 
Au contraire, il est très optimisé un CPU x86 à 3GHz ne suffirait pas si ce n'était pas le cas.
Ce qui est coûteux c'est d'obtenir une vraie synchro entre les cycles des différents chips du système.
Et plus y'a de chips, plus c'est exponentiel.
 
Si le sujet t'intéresse, Byuu en parle ici sur 3 pages
https://arstechnica.com/gaming/2011 [...] -emulator/

 
Il te faut un BIOS de la console (c'est bien la même chose que sur une CM de PC).
 
Ici tu as un tableau de fichier de BIOS a avoir selon l'émulateur que tu utilise:
https://github.com/retropie/retropi [...] ystation-1
 
En récap pour la Playstation cherche un ficher SCPH1001.BIN sur ton Internet favori , place-le dans /home/pi/Retropie/BIOS/psx/, et c'est parti. (sauf si tu utilise Recallbox auxquel cas je peux pas t'aider )

j'utilise recalbox, c'est pas faute de l'avoir ecrit sur mes message au dessus

 
J'ai effectivement lû ton seul message qui ne comprends pas le mot "recallbox"    
Mais vu que ce sont les mêmes émulateurs dans les 2 distribs, je pense que la manip est la même, la seule différence est le dossier où il faut dropper le fichier

A part dire "bsnes est bien plus fidèle que les autres" (je n'en doute pas) et "c'est important la fidélité" (je suis d'accord), il n'explique absolument pas pourquoi son soft est lent. Il dit quelques fois "j'ai optimisé à mort" mais sans détailler. Je me doute bien que ce n'est pas le sujet sur cet article, mais ça ne m'aide pas vraiment à comprendre.
 
Bref, si ça se trouve son soft ne peut effectivement pas être optimisé, mais j'en doute très fortement.
 
 
Et merci de ne pas me sortir la non-réponse "t'as qu'à le faire", j'ai jamais dit que c'était simple juste pas nécessairement impossible.
 

recalbox et retropie sont basés sur les mêmes systèmes et architectures, donc à part les emplacements des fichiers, des configs, etc, ce qui est sur l'un sera certainement sur l'autre. Tu as besoin des bios sur retropie, donc sur recalbox aussi. Et tu ferais mieux d'utiliser des CUE pour tes ISO PSX, que ce soit sur retropie ou recalbox.

 
Tu as vu qu'il y avait des pages 2 et 3 ?
 
Notamment le paragraphe "So where does that extra 2.7GHz go? Synchronization" en page 2 et "Emulating the extra processors" en page 3.
Il parle de DICE également qui est l'exemple extrême de l' "accurate emu"

Oui j'ai vu.
"Synchronization" n'est pas une réponse qui me satisfait, à part "je sais pas faire mieux" (ce qui n'est pas un drame, on a tous nos limites).
Le "extra processors", à partir du moment où le processeur principal est lent, c'est normal que les processeurs complémentaires le soient aussi.
 
Et comparer quelque chose qui semble être un simulateur de hardware générique à ce qu'il fait, bon. C'est normal que DICE rame, si c'est générique. Là, tu peux sans doute pas faire autrement. Mais sur un truc spécialisé, tu peux sans doute optimiser, même en restant fidèle à 100%.
 
 
En fait j'aimerais bien des précisions plus techniques sur ce qui est lent. Par exemple, est-ce qu'il a localisé les bottlenecks avec des outils de mesure ? Qu'est-ce qui fait exactement qu'il pense que ce n'est pas possible de faire mieux ?

Justement c'est lent parce que tu dois synchroniser plein de processeur différent.

Mais pourquoi c'est lent de synchroniser plein de processeurs différents ?

La synchro bouffe énormément de temps machine lorsqu'il s'agit de respecter les cycles d'instruction.
D'après le développeur BSnes en LLE fait approximativement 100 fois plus de synchro que les émulateurs SNES concurrents en HLE. C'est le seul moyen de s'assurer qu'il n'y aura pas de glitchs graphiques ou de cracks sonores, même pour une obscure rom japonaise confidentielle.

Pour les co-pro présents dans les cartouches, les émus HLE se contentent de traduire (approximativement) les opérations de transformation (ex : bouge ce sprite d'ici à là) tandis que BSnes va émuler le fonctionnement du chip dans les moindres détails.
(La partie où il explique comment on décape un chip à l'acide nitrique avant de parcourir sa surface au microscope à balayage électronique est tout bonnement )

Justement en émulation, optimiser c'est la plupart du temps sacrifier la fidélité du rendu.
Et le plus souvent ces optimisations permettent ainsi de faire tourner un jeu A en full-speed, mais ce sera au détriment d'un jeu B qui va perdre un élément de background sur un scrolling parallaxe, etc...

Jamais il dit qu'il n'est pas possible de mieux faire...
Il pense être au bout de ce qu'il peut faire avec son niveau, qu'il utilise déjà des techniques évoluées comme le multithreading et la compilation JIT (et je pense que c'est un excellent programmeur).
Le salut viendra de la capacité de calcul en hausse des processeurs futurs.
Il est même confiant pour DICE

C'est comme une chaîne de montage : t'as un proc qui pose le chassis, un autre les roues, un autre la carrosserie, etc...
Et quand tout est prêt, alors la voiture sort de la chaîne et on commence la suivante.

En HLE, tu peux demander au processeurs "roues" de fabriquer 30 trains de pneus d'avance (*) pendant un temps mort, et venir piocher ensuite dans ton stock de roues en rafale quand t'en as besoin.

(*) voire même de "trucs ronds qui ressemblent vaguement à une roue" si t'es codeur d'un ému qui privilégie la vitesse par rapport à la précision.
Pas besoin que ce soit une vraie roue, à l'écran en 262*200 ça y ressemble assez

Non mais tout ça j'ai lu, merci tu ne fais que répéter ce qu'il y a dans l'article
 

Ce n'est pas ce que je veux dire.
 
Pour l'exemple le plus basique, tu as plusieurs manières de trier un tableau de données. Chacun a des performances CPU et mémoire différentes, et pourtant, tous ont exactement le même résultat : le tableau est trié de la même manière.
https://vinayakgarg.wordpress.com/2 [...] bble-sort/
https://en.wikipedia.org/wiki/Sorti [...] algorithms
 
Tu peux aussi faire des choses "toutes bêtes" comme déporter sur le GPU des opérations qui s'y prêtent : https://devblogs.nvidia.com/paralle [...] idia-gpus/ ; pas sûr que ça change grand-chose pour son cas à lui, mais ça fait partie des optimisations possibles sans perte de fidélité.
 
 
Plus généralement, la performance ça se mesure, et il y a des tas d'outils qui permettent de savoir quelle méthode exacte prend du temps. Si c'est la synchro elle-même (je ne sais pas ce que ça représente) et qu'il n'y a pas de moyen physique de faire autrement, pourquoi pas. Mais je suis (peut-être naïvement) convaincu qu'il y a au moins certains endroits de son code qui peuvent être améliorés.
 
 

Le multithreading c'est un peu la base. C'est trop compliqué pour beaucoup de gens (et pourtant je ne me considère pas comme un dev de génie), mais je classe pas ça dans les techniques évoluées.
Il utilise le "cooperative multithreading" qui n'a rien à voir avec les performances (je me renseigne en même temps donc pas sûr de moi sur ça). Ca a à voir avec une certaine conception de thread-safety, mais ça limite sévèrement l'intérêt des threads (vu qu'il semble qu'il ne peut pas y en avoir plusieurs en parallèle).
 
C'est pas la compilation JIT qu'il utilise, c'est la synchronisation JIT. Parce que la compilation JIT, on peut pas dire que ça améliore les performances
Je n'arrive pas à bien déterminer ce que c'est (pas tellement de résultats google...), mais ça semble plus, encore une fois, être lié à la synchronisation (et donc par extension au ralentissement) qu'aux performances. Je ne suis pas du tout sûr de mon coup.

Ah oui, et quand je vois qu'il parle de précision et de fidélité etc, et qu'il semble avoir zéro test unitaire sur son repository, je m'étonne un peu

Oui synchro JIT, effectivement la compilation JIT va pas aider
Désolé pour la vulgarisation et les répétitions également.  

Y'a deux questions à se poser ici:
Si le multithread c'est si facile que ça, pourquoi si peu d'emulateurs cherchent à en tirer profit? À part Bsnes et PCSX2 je n'en connais pas d'autres.
Et déléguer du calcul à un GPU, ça se fait au détriment de la portabilité d'une part, et d'autre part on quitte le LLE pour basculer dans la philosophie HLE, non?

Parce que c'est pas forcément adapté à tous les calculs. Emuler une machine qui a plusieurs CPU (comme la PS2, la Saturn...) ça a du sens ; pour une machine qui ne peut (globalement) faire que des opérations séquentielles, un peu moins. En faisant du bas niveau, ça a du sens de faire un thread par chipset.
 

Si tu utilises opengl c'est tout à fait portable, tous les GPU/SoC sont compatibles opengl aujourd'hui. Et puis bon, vu que bsnes n'est compatible qu'avec windows, la portabilité...
 
Et LLE/HLE ça n'a rien à voir avec l'endroit où tu fais tes calculs c'est juste que soit tu émules le matériel, soit un niveau au-dessus. Faut pas confondre langage bas niveau et émulation bas niveau Tu peux faire de l'émulation bas niveau avec du javascript si ça t'éclate

Mais par contre c'est peut-être pas le sujet pour ça, moi je vais arrêter d'en  parler parce que j'imagine que ça soule les autres

ok, mais du coup j'ai du mal à comprendre ce qu'apporteraient les fichiers bios puisque les roms que j'utilise fonctionnent, enfin avec des défauts certe (pas de son, qualité graphique), mais ils fonctionnent quand meme
concernant Gran Turismo, j'ai trouvé un ISO qui fait quasi 2x la taille des deux autres (350Mo vs 650Mo environ), je vais le tester j'espere qu'il est de meilleurs qualité

sans le fichier bios adequate, si j'ai bien compris, le jeu ne fonctionne pas du tous

enfin bon je débute encore la dedans, je pige pas encore tous

pour les .cue, bah je fais avec les fichier dans les roms que je trouve/telecharge, parfois il y en à, parfois non, mais dans les deux cas avec ou sans ca fonctionne, donc je sais pas à quoi il servent  

bon bah meme l'ISO de 65Mo à une qualité naze

et je viens de voir ca dans recalbox manager sur les fichier de roms de psx, ca pourrait avoir un lien avec mes soucis ?

pourtant il est bien present dans les fichiers bios ?!?!?!