Reprise du message précédent :

Je pense aussi que c'est le plus gros problème de cette idée : les jeux 2D 8/16 bits avec des sprites travaillés passent très bien, les jeux 3D avec les textures dégueulasses et des polygones qui bougent tous seuls, dans une machine à 100€, je ne suis pas sûr...

Et sinon, suite à des "plaintes" de gens qui pensaient que l'émulation Saturn était un fake, Polymega a fourni un feed vidéo de l'émulation Saturn, avec Guardian Heroes, Sega Rally, Panzer Dragoon, Fighters Megamix et Dungeons & Dragons.
 
http://www.nintendolife.com/news/2 [...] ay_footage

C'est impressionnant  

Ridge Type 4    
Sans Dual Shock  

Je sais pas comment tourne l'émulation Saturn sur PC, ça tourne bien ? Il me semblait que c'était plutôt bancal ?

Non ça tourne pas bien. Il y a des trucs jouables, mais globalement, ça reste pourri. Ils ont beaucoup progressé ces dernières années, surtout grace à la montée en puissance qui leur permet plus de marges, mais bon...  
Et puis pour certains jeux, il faut un ému dédié qui ne va faire tourner que lui (le shining force), donc c'est pas la joie.
 
Du coup, voir ça, jouable, fluide, sans glitch graphique, c'est... étonnant.

C'est ce qu'il me semblait... du coup, comme tu dis, c'est très "louche".
Surtout qu'a priori ils ont un proc G5500T @3.2Ghz dedans, c'est pas non plus la folie (même si j'ai cru comprendre que c'était la fréquence le paramètre le plus important en émulation ?).
Ils ont beau avoir faire un partenariat spécifique avec un développeur d'émulateur Saturn, même en étant hyper balaise, le mec va pas soudainement résoudre tous les problèmes restants de l'émulation...
 
 
Après, si ça se trouve, ils ont 4 jeux qui tournent, et le reste est dans les choux

La PS1 passe bien sous rpi2 et 3 avec un bon filtre scanline.

Je trouve que cela passe mieux en basse résolution qu'en haute résolution.

Chapeau si c'est vrai.
Édit :

Ils ont peut être un partenariat avec Sega.

L'émulateur le plus précis est Mednafen.
Il y a une page avec la liste des bugs connus, il est très compatible. Le seul inconvénient, c'est qu'il est très gourmand (ne tournerait pas sur le hardware de la Polymega).
 
Je crois que c'est le seul émulateur open-source qui tient la route (devant ... Yabause et MAME ?), avec comme seule vraie alternative SSF, à la fois closed-source et mouru.

 
Même Sega n'arrive pas à émuler la Saturn, donc ça n'y changerait pas grand chose

Faut dire qu'elle était déjà dure à programmer, alors à émuler...

Des rumeurs voudraient que la Saturn elle même émule son propre système, alors bon...

Mednafen a vraiment changé la donne, la Saturn est bien émulée maintenant.

D'après les créateurs de la Polymega, l'émulateur Saturn marche bien parce qu'il n'y a pas d'OS complet derrière les émulateur, et leur système (basé sur Linux) est léger :
 

 
Il y a un gros éditeur qui participera à leur store, on peut s'attendre à Capcom ou Data East qui sont déjà sur la game boy nes :
 

 
http://www.nintendolife.com/news/2 [...] scepticism
 
J'espère qu'elle tiendra toutes ses promesses, même si je ne pense pas être client, c'est super prometteur comme projet.

pour ceux que ça intéresse, j'ai fait un topic unique
https://forum.hardware.fr/forum2.ph [...] w=0&nojs=0

Leur explication sur le fait que la Saturn tourne à pleine vitesse sur leur système (ce qui est sûrement vrai, ça n'est pas la question) est à la limite du foutage de gueule.
Ils n'osent pas avouer qu'ils ne peuvent probablement pas utiliser Mednafen à cause du matos trop limite, c'est tout.
Windows 10 / Linux ne vont pas rétrograder un quad core @ 3.8GHz en dual core @ 3.2GHz, faut voir à pas exagérer

Je sais pas, un os complet avec moult applications en arrière plan ça demande de la ressource. A quel point exactement je ne sais pas. En tout cas le quad /dual core ne change que le nombre de process pouvant tourner en parallèle et n'a pas tellement d'impact sur l'émulation (qui utilise généralement un seul thread), donc passer d'un quad sur desktop à dual sur un système dédié et avoir les mêmes performances ne me semble pas aberrant.

Désolé, j'ai édité mon post (mais pour à peu près le même message).
 
Généralement un seul thread, mais pas toujours...Mednafen par exemple, recommande absolument un quad-core. J'avais zieuté vite fait en jeu, il semble que le charge est bien répartie sur les quatre coeurs.
Il paraît qu'au moins certains jeux peuvent tourner sur dual core, mais m'est avis que ça doit facilement coincer...

Bah si c'est du Linux, il reste quoi d'autre que Mednafen en ému ? C'est le seul me semble-t-il

'Sais pas trop, Yabause ?
Beaucoup d'incompatibilités, ceci dit...

Je maintiens que quad -> dual pour un système dédié ne me semble pas aberrant. Et 600mhz c'est pas le jour et la nuit.

C'est un peu comme les jeux qui demandent une config beaucoup plus puissante qu'une Xbox ou PS4 pour un résultat équivalent, ça ne choque personne

Edit : et comme c'est une config fixe il devient possible de faire des optimisations dédiées donc c'est pareil ça ne me choque pas de pouvoir gagner quelques mhz pour un résultat équivalent.

Edit 2 : cela dit je demande quand même à voir sur pièces, mais la théorie me semble cohérente.

En passant, je suis tombé sur ce truc
https://twitter.com/saturnmemories/ [...] 56?lang=fr
 
   
 
(ça concerne juste le trailer du 4 septembre, pas la video Saturn du 13)

Oui ils en parlent dans l'interview, comme quoi l'équipe marketing a fait son truc dans son coin sans faire valider par les devs.

+1
Ce n'est pas les premiers a faire un os spécial retrogaming.

Retropie et/ou recalbox sont des os spécial émulation.
C'est pas pour cela qu'un émulateurs tourne mieux que sur un os classique.

Édit : Retropie tourne sur raspbian modifié. recalbox est building Root.
Le tout sur un raspberry pi qui n'est pas un monstre de puissance. Donc c'est encore plus sensible sur ce genre de config.

Tu ne double pas les perfs d'émulation par rapport a une raspbian "classique" sur un pi.

Je trouve que c'est un peu du bullshit. Sur un pc classique en idle tu n'a pas 20% d'occupation du cpu...

Je vois pas comment tu peux comparer un cpu ARM@1ghz et quelques avec un x86@3 et quelques...

Au contraire, compte tenue du matos, retropie/recalbox tournent très bien. Il faudrait comparer les versions x86 avec un Linux complet.

Justement.
Tu prends un pi avec une distribution Linux "classique"
Si tu fais tourner un émulateurs dessus, cela va tourner quasiment a la même vitesse que sur un pi avec une distribution spéciale.
Ce qui prouve que l'os n'a pas beaucoup d'effet sur les perfs même sur les petites configs.

Pour les consoles vs PC il suffit de voir les vidéos de comparaison sur Youtube pour voir que la comparaison n'est pas possible.

Sur console la résolution est plus basse, les effets graphiques sont limitées.
Sur pc c'est full HD voir 4k, effet graphiques a fond pour faire acheter les dernières carte graphique du moment.

Polymachin parle de PC d'un cpu 4 cores a un cpu 2 core. Un OS n'entraine pas le besoin d'avoir 2 cores de plus. Ou alors il est très mal optimisé. Tu va gagner un peu, mais pas autant.

Attendons de voir. Mais je pense qu'il y a beaucoup de bullshit.

Si tu parles de la différence Retropie/Recalbox, Retropie se base sur le coeur de Raspbian, mais ce n'est pas une surcouche, ça en utilise juste le noyau, Retropie n'inclut pas les services "desktop" de Raspbian qui tourneraient en arrière-plan.
Et d'ailleurs Raspbian est très loin d'être une distro "classique", c'est ultra léger de base, ça fait vraiment le minimum.
 

Je dis exactement l'inverse : tu prends un PC, tu lui mets les mêmes composants qu'une Xbox ou PS4, et tu as un résultat inférieur, parce que le jeu est optimisé à fond sur Xbox, mais pas sur PC.
 
C'est pareil ici : avoir un hardware unique permet (en théorie du moins) de faire des optimisations impossible à faire sur un logiciel qui doit tourner sur de multiples plateformes.
 
A voir en pratique évidemment, mais la théorie est là.
 

Tu as déjà ouvert le gestionnaire des tâches de Windows ? Il y a à peu près 200 process qui tournent en permanence.
C'est ça que facilite le multi-coeur (faire tourner plein de process en parallèle sans trop ralentir le système), et c'est de ça dont permet de s'affranchir un OS dédié (de virer tous les process "parasites" ).
Une fois que tu as viré la moitié des process, ton processeur est 2 fois moins en train de switcher d'un process à un autre, et donc il a plus de temps à consacrer à ton programme "principal".
 

Oui, je ne dis pas que ça va forcément tout déchirer. Mais sur le papier, ce qu'ils disent me semble possible, et même si il y a évidemment des exagérations marketing, je ne suis pas sûr que ce soit du bullshit.

(HS) Je pense pas me planter en suggérant que ça dépendra beaucoup plus de la nature des processes (leur niveau de priorité et leur éventuelle synchronisation entre eux ou vis-à-vis d'autres resources) que simplement leur nombre.
 
PS. exagération marketing, pléonasme

Alors
 
Un coeur de processeur n'est capable de traiter du code que d'un process à la fois. En pratique, il passe son temps à exécuter un peu de code d'un process, le mettre en pause, exécuter le code d'un autre, le mettre en pause, passer au suivant, etc.
Diminuer la priorité d'un process va juste faire en sorte qu'il repassera moins souvent en haut de la pile des process à traiter.
Synchroniser des process ça ne se fait pas trop, on synchronise plutôt des threads, mais ça ne change pas le concept. Dans les deux cas, la seule chose que ça fait, c'est de dire "cette ressource m'est réservée" et les autres process doivent attendre que la ressource soit libérée avant de pouvoir l'utiliser (cf les mutex).
 
Quand tu as autant de threads que de coeurs, ils peuvent s'exécuter "parfaitement" en parallèle et bourriner le CPU.
Quand tu as plus de threads que de coeurs, ton processeur passe du temps à switcher de l'un à l'autre. Plus le nombre de threads est supérieur au nombre de coeurs, et plus tes performances se dégradent : le CPU ne peut pas les traiter plus vite, et au contraire, il passe de plus en plus de temps à faire attendre les uns pour traiter les autres.
En programmation, la meilleure stratégie de multithreading c'est d'utiliser autant de threads que de coeurs, voire moins, pour qu'au moins un coeur soit disponible pour l'OS (ou le thread de l'UI, le cas échéant). Certains langages de programmation (.Net par exemple) proposent même des API pour automatiser le parallélisme des traitements, et celles-ci ne garantissent pas que tous les coeurs soient utilisés, parce que ça dépend de plein de trucs : par exemple, si ton CPU est au taquet sur un coeur, ça va automatiquement choisir de ne pas l'utiliser.
 
Même si les process sont gérés différemment des threads (c'est l'OS qui choisit qui passe devant, et la plupart des process n'utilisent en fait quasiment pas de processeur), le principe est le même : plus tu as de process qui travaillent, et plus avoir des coeurs est bénéfique ; et la corrélaire inverse, moins tu as de process qui travaillent, et moins le fait d'avoir peu de coeurs est impactant sur les performances.
En résumé : si tu as 2 process, 4 coeurs n'iront pas plus vite que 2 coeurs.
 
C'est d'ailleurs pour ça qu'en passant d'un quad core ARM à un dual core x86 ils ont laissé tomber le support de Twitch : l'émulation n'utilise généralement qu'un coeur, l'OS peut n'utiliser qu'un autre, avec 4 coeur il y avait moyen d'avoir un coeur pour Twitch, avec 2 ce n'est plus possible.
 
 
 
Bref, je maintiens : utiliser un dual core au lieu d'un quad core, si le nombre de process est réduit en proportions, ça peut n'avoir que peu d'impacts sur les performances.
Je dis bien "ça peut", parce que ça dépend de plein de trucs, mais en théorie, c'est possible.

Je viens de prendre une licence LaunchBox-BigBox, j'ai installé Retroarch, par contre j'ai pas encore vraiment trouvé comment on faisait des configurations par Core (j'en ai surtout besoin pour la n64 pour reconfigurer le contrôleur et essayer de rendre ça un peu plus joli).
C'est faisable à travers le menu Retroarch ? Ou faut absolument faire ça à travers l'éditeur de texte ?

À travers Retroarch oui, via les overrides de configuration par core.

Oui, je viens de trouver le menu.
Enfin il ne m'affiche aucune option, mais j'ai pu généré le fichier retroarch-core-options.cfg, je m'attendais à un fichier par core mais non c'est un fichier avec tous les cores mélangés. J'ai pu augmenter la résolution, mettre de l'AA, c'est déjà ça (je suis pas puriste).
 
Par contre pour le contrôleur, j'ai un fichier .rmp dans le dossier du core, mais je ne comprends pas comment le configurer, il semble faire référence aux noms des commandes de retroarch mais c'est un peu flou pour moi (et par le menu je ne peux rien modifier (et je ne comprends pas à quoi les trucs correspondent, y a pas "C-up, C-down", etc... bref, des noms de boutons qui correspondraient à la manette de n64)).

Et j'ai une autre question : vous auriez un thème launchbox à conseiller ?
J'ai essayé Ricewind et Comics mais ça n'atteint pas le WAF critique.
Ma femme est habitué à l'interface de Steam Big Picture, là launchbox elle trouve ça moche et surchargé de texte, elle n'aime pas les listes elle aime les petites vignettes comme Steam.

Tu parles de Big Box ? Moi j'aime bien Big Couch et Chicuelo.

Il y a aussi le theme Switch qui est simple et rapide. De preference la version Dark.
https://forums.launchbox-app.com/to [...] tch-theme/

Retropie ne fait pas la même choses ?

Si mais sur PI...

Il y a une version x86

J'installe en ce moment retropie sur un vieux pc (Atom + nVidia )

Ouais mais je veux garder ma base Windows (pour la compatibilité de ma bibliothèque Steam).