Article de l'auteur de l'émulateur bsnes - Page 1

Ici
Il dit des choses intéressantes mais y'a pas mal de points sur lesquels je ne suis pas d'accord avec lui, je vous laisse lire pour voir ce que vous en pensez ^^

Je suis farpaitement d'accord avec lui. C'est quoi ton point de vue ?


Bon, je plaisante. En feit, je ne suis pas capable de voir ce qui peut être sujet à polémique. Manque de compétence de ma part sansaucun doute.

Par contre, je trouve intéressant un paradoxe qu'il soulève : parfois, un émulatur plus "précis" émulera moins bien un jeu qu'un émulateur moins chiadé. Intéressant. Que chercher quand on émule ?
La reproduction d'un comportement au plus bas niveau possible pour se rapprocher de la perfection, race conditions et bugs hardware compris ?
Ou émuler juste ce qu'il faut, voire simuler certaines choses (hardcoder en fait), pour reproduire ce qu'on sait d'une partie du fonctionnement dont on arrive pas à théoriser le fonctionnement ?

Ca doit pas être sur ce point que tu veux lancer le débat, mais je n'ai pas de réponse à cette question, si ce n'est "si ça marche, c'est bon" ^^

J'ai zieuté en diagonale et ça m'a l'air d'être grosso modo la même chose que ce qui est déjà sur le site de BSNES, du coup flemme de lire. (J'imagine qu'il y a des détails en plus, je vais donc remettre ça à plus tard).
Y'a qu'un truc qui me dérange dans ce qu'il dit en général (puisqu'il a l'air d'en reparler ici), c'est qu'il considère qu'un PC « capable de faire tourner l'émulateur » ne coute quasiment rien de nos jours, et qu'un CPU à 3GHz ça court les rues. Aux dernières nouvelles, je ne crois pas que ce soit le cas. (Même si c'est beaucoup plus facile avec les nouveaux Core iX)
Le reste je verrai en lisant en détail… :d

(désolé pour le pavé)

Folco (./2) :
Par contre, je trouve intéressant un paradoxe qu'il soulève : parfois, un émulatur plus "précis" émulera moins bien un jeu qu'un émulateur moins chiadé. Intéressant.

En fait, "moins bien", c'est relatif. En général, plus l'émulateur est précis, plus ça se rapproche du comportement du programme sur la vraie machine (à part les cas rares, du style deux "bugs" qui s'annulent mutuellement).

Par contre, prendre certaines libertés par rapport au hardware permet des choses intéressantes. Par exemple, ne pas synchroniser le CPU avec le reste du hardware - donc le laisser tourner aussi vite que le permet la puissance de l'hôte - a pour effet d'éliminer les baisses de framerate qu'ont certains jeux sur la vraie machine (par contre, pour d'autres ça fout tout par terre). On peut aussi aller plus loin, par exemple faire une émulation haut niveau d'une puce 3D en utilisant la carte graphique, ce qui permet de faire tourner les jeux 3D avec une résolution plus haute, des textures mieux lissées, etc.

Savoir si c'est une bonne chose ou pas, c'est un débat philosophique
Personnellement je suis pour, tant qu'on peut aussi switcher en mode "émulation fidèle" quand on veut voir à quoi ressemblait l'original.

Folco (./2) :
La reproduction d'un comportement au plus bas niveau possible pour se rapprocher de la perfection, race conditions et bugs hardware compris ? Ou émuler juste ce qu'il faut, voire simuler certaines choses (hardcoder en fait), pour reproduire ce qu'on sait d'une partie du fonctionnement dont on arrive pas à théoriser le fonctionnement ?

Autre débat philosophique ^^
Par exemple, dans MAME, ils ont un moment remplacé une émulation audio basé sur des enregistrements du vrai hardware par un modèle mathématique des puces.
Le problème c'est que le nouveau mode d'émulation demandait beaucoup plus de ressources, et était moins fidèle aux vrais sons.
Alors certes, utiliser des enregistrements, c'était de la triche. N'empêche que pas mal de gens ont vu ça comme une régression.

Folco (./2) :
Ca doit pas être sur ce point que tu veux lancer le débat, mais je n'ai pas de réponse à cette question, si ce n'est "si ça marche, c'est bon" ^^

En effet c'était pas à ce point de débat que je pensais, mais tes remarques sont intéressantes aussi

Ce avec quoi je ne suis pas d'accord dans son point de vue :

- critiquer les émulateurs optimisés pour la vitesse (ça transparaît si on lit entre les lignes, et c'est partagé par d'autres auteurs d'émulateurs optimisés pour la précision). C'est très bien de vouloir coller au plus près à la réalité et de penser à la préservation dans le futur, mais si le résultat est de rendre l'émulateur inutilisable sur du matos "normal", ça ne sert pas à grand-chose : préserver un jeu, pour moi ça veut dire qu'il soit jouable. C'est un peu comme si quelqu'un scannait des tableaux avec une résolution et un nombre de couleurs tellement élevés qu'on ne pourrait pas l'afficher sur les écrans actuels, et critiquait ceux qui les scannent en 300 dpi et en JPEG pour que les gens puissent les voir.

Les émulateurs optimisés en vitesse sont moins précis, certes, mais ils ont permis de faire tourner les programmes 10 ans avant ceux optimisés en vitesse. Pour moi ça mérite le respect. Et s'ils n'avaient pas été là, est-ce que les gens se seraient autant intéressés à l'émulation ?

- je me demande franchement si l'argument "c'est lent parce que c'est précis" n'est pas en partie bidon, pour couvrir le fait que les émulateurs ne sont pas optimisés. Par exemple il se félicite du fait que son émulateur peut synchroniser au cycle près, et non pas seulement à l'instruction près, contrairement à d'autres. C'est bien beau, mais il dit aussi que pour 99% des jeux il n'y a en fait besoin d'une synchronisation une fois par frame. Alors pourquoi ne pas détecter les cas où c'est nécessaire et synchroniser seulement à ce moment-là, au lieu d'utiliser une technique bourrin ? Ah c'est sûr que c'est plus dur à coder, mais du coup la config nécessaire est beaucoup plus raisonnable dans la plupart des cas. Et il y a des émulateurs qui y arrivent (je pense par exemple à Saint et Steem, qui sont des émulateurs d'Atari ST qui font tourner la plupart des programmes qui nécessitent une synchronisation précise, sans utiliser énormément de puissance processeur).

Au fond, si le fonctionnement du hardware est connu avec précision, écrire un émulateur précis n'est pas si difficile : on émule brutalement cycle par cycle, et vogue la galère. Optimiser ça pour ça tourne vite... c'est déjà nettement plus dur.

Mon point de vue en très résumé. J'ai lu une page attentivement mais j'ai TL;DR quand j'ai vu qu'il y en avait deux autres après

Quand t'es sur PC, tu fais ce que tu veux car tu disposes d'une puissance quasiment illimitée. Après, c'est à l'utilisateur de choisir ce qu'il veut suivant le matériel dont il dispose: émulation rapide ou fidèle.

Quand tu veux émuler la SNES sur une machine limitée (type console de salon pré-Xbox ou pire encore: console portable), tu dois chercher l'émulation la plus rapide possible. Point barre.

On en revient ni plus ni moins à la différence entre coder un émulateur et coder un simulateur...

Les émulateurs ne seront suffisamment précis que lorsqu'ils n'auront besoin que d'une radio des circuits électroniques pour fonctionner

Sinon, je pense que le plus rapide (et souvent le plus simple) doit être préféré à la précision tant que la différence n'est pas visible par l'utilisateur. En fait, le meilleur émulateur devrait être celui qui reconnaît le jeu (ou le programme exécuté) auquel il substitue une version au comportement identique et spécialement conçu pour la plateforme. Ce que veut l'utilisateur, c'est utiliser son programme de la même manière que sur le matériel émulé, il n'exige généralement pas qu'il s'exécute de la même façon.

Ah ok, le débat est "faut-il privilégier l'end-user (et l'émulateur qui marche 99% du temps) ou la masturbation intellectuelle (mais ça ne marche que sur 1% des machines). Intéressant.

Ce débat me tient à coeur, j'ai eu une expérience dans un monde parallèle où l'on disait "faut-il des dll qui marchent et assurent un compatibilité de plus de 10 ans en arrière, sur d'autres hw et OS, ou mieux vaut-il des programmes parfaitement natifs avec fausses dll, mais qui cassent tout les 10 minutes ?".
Le débat avait été fort intéressant.

(le mieux étant des fausses dlls obsolètes de plus de dix ans mais qui plantaient déjà toutes les 10 minutes à l'époque )

Nhut (./5) :
Mon point de vue en très résumé. J'ai lu une page attentivement mais j'ai TL;DR quand j'ai vu qu'il y en avait deux autres après

Quand t'es sur PC, tu fais ce que tu veux car tu disposes d'une puissance quasiment illimitée. Après, c'est à l'utilisateur de choisir ce qu'il veut suivant le matériel dont il dispose: émulation rapide ou fidèle.

Quand tu veux émuler la SNES sur une machine limitée (type console de salon pré-Xbox ou pire encore: console portable), tu dois chercher l'émulation la plus rapide possible. Point barre.

Pas mieux, c'est mon opinion.

Peut-être un détail si, une reproduction parfaite 1:1 ne me semble pas indispensable, et c'est préférable de faire un programme qui tourne sur des pc plus faibles (genre un netbook par exemple, en ceci j'aime beaucoup ZSNES parce qu'il est peu exigeant en termes de ressources et s'en sort avec quasiment tout -il n'y a qu'Actraiser 2 qui m'a forcé à prendre SNES9x car ZSNES n'arrive pas à dépasser la transition d'intro du stage 1).

Zerosquare (./4) :
Par contre, prendre certaines libertés par rapport au hardware permet des choses intéressantes. Par exemple, ne pas synchroniser le CPU avec le reste du hardware - donc le laisser tourner aussi vite que le permet la puissance de l'hôte - a pour effet d'éliminer les baisses de framerate qu'ont certains jeux sur la vraie machine (par contre, pour d'autres ça fout tout par terre).

Certes, mais si comme il l'explique on voit l’émulateur dans une logique de préservation, on souhaites peut -être justement retrouver ces défauts qui existaient dans le jeu original.

Zerosquare (./4) :
critiquer les émulateurs optimisés pour la vitesse (ça transparaît si on lit entre les lignes, et c'est partagé par d'autres auteurs d'émulateurs optimisés pour la précision). C'est très bien de vouloir coller au plus près à la réalité et de penser à la préservation dans le futur, mais si le résultat est de rendre l'émulateur inutilisable sur du matos "normal", ça ne sert pas à grand-chose : préserver un jeu, pour moi ça veut dire qu'il soit jouable.

La critique ne me parait pas si féroce que ça. Il dit bien d'ailleurs que sortir bnes il y a quelque année aurait été idiot, et qu'il souhaiterait faire encore mieux mais qu'il ne peut simplement pas avec le hardware actuel.
Il faut juste rester pragmatique et faire ce que l'on peu avec ce que l'on a.

Si aujourd'hui les machines permettent de faire plus précis, pourquoi ne pas le faire.
Celui qui se moque de la fidélité pourra toujours se tourner vers quelque chose d'autre, on peut pas dire que le monde des émulateurs manque de variété.
L'idéal étant de permettre de choisir, mais je suppose que ça doit être plus complexe qu'il n'y parait.

Uther (./11) :
Certes, mais si comme il l'explique on voit l’émulateur dans une logique de préservation, on souhaites peut -être justement retrouver ces défauts qui existaient dans le jeu original.

Ah mais je ne conteste pas qu'il faut aussi permettre une émulation précise.

Uther (./11) :
La critique ne me parait pas si féroce que ça. Il dit bien d'ailleurs que sortir bnes il y a quelque année aurait été idiot, et qu'il souhaiterait faire encore mieux mais qu'il ne peut simplement pas avec le hardware actuel.

C'est vrai qu'il ne le dit pas explicitement dans cet article, mais j'ai déjà entendu d'autres personnes dire la même chose avec plus de virulence.

Tiens, le monsieur pourrait bien essayer d'émuler la Saturn de façon fidèle à 100%, on va voir s'il se montre encore dédaigneux envers ceux qui veulent émuler de façon rapide

C'est déjà lui qui essayait d'émuler l'effet CRT des écran, à 5 fps ... C'est phosphor ou un truc du genre.

5 fps pour une émulation de phosphores ?!

La DreamCast, ce serait déjà pas mal, hein... Parce que Makaron EX, bof bof quoi...

Kochise

pokito (./14) :
C'est déjà lui qui essayait d'émuler l'effet CRT des écran, à 5 fps ... C'est phosphor ou un truc du genre.

J'ai vu des "emulateur" de CRT tourner en fullspeed hein

Zerosquare (./4) :
Au fond, si le fonctionnement du hardware est connu avec précision, écrire un émulateur précis n'est pas si difficile : on émule brutalement cycle par cycle, et vogue la galère. Optimiser ça pour ça tourne vite... c'est déjà nettement plus dur.

C'est sûr que toute la difficulté réside dans la vitesse, jusqu'à un certain point quand même. Comme il l'a dit la plupart des émulateurs ont un timing off, et ce fut par exemple le cas également de mon ému GB, pourtant je me suis appuyé sur les specs les plus précises que je pouvais avoir, sans penser à l'opti du tout dans un premier temps (c'était un projet d'école).

Qu'est-ce à dire? Une fois que tu vois que c'est faux, après c'est simple d'améliorer la vitesse, à la limite tu n'as pas besoin de faire des tests stricts pour t'assurer que ça n'a aucun effet de bord, tant que rien n'est visible. Puis comme ton timing est off certains jeux qui avaient tendance à ralentir légèrement deviendront encore pires (d'autres iront peut être plus vite au contraire). Une solution est d'augmenter la fréquence du CPU virtuel, mais c'est crade.

C'est ce qui arrive dans ~tous les émulateurs actuels. Vouloir faire un truc vraiment précis est très difficile, certainement largement plus que faire un truc rapide car la plupart des jeux ne sont que des applicatifs, qui ne présentent pas d’exigence élevée pour tourner. Le combo ultime c'est bien sûr de faire précis et rapide, et c'est très difficile car le coût des hacks type calcul du prochain événement nécessitant une inspection détaillée de telle ou telle partie peut se révéler dans certains jeux ou certaines démos largement supérieur à celui d'une implémentation naïve, et c'est justement ce type de softs qu'on peut souhaiter vouloir faire tourner puisque les autres émus n'en sont pas capables. Donc au lieu de demander 1 GHz pour Mario World et 4 pour Yoshi's Island on préférera un émulateur qui en demande constamment 2-3, car on sait quel hard il faut acheter

./17 > Maintenant son filtre va plus vite, mais au début c'était du matlab et ça ramait sévère ^^

Une des premières versions en C++ :

Avec un Q6600, donc pas non plus un processeur en mousse. Maintenant ça a l'air au point ^^

PS : en fait c'est pas byuu qui en est à l'origine, c'est un physicien d'où la version matlab.

16fps entrelacés de surcroît (je croyais que l'entrelacement aidait à accroître la fluidité ?)...

Mais c'est quoi son algo d'émulation de CRT ?

J'ai codé un algo d'émulation de la rémanence des phosphores, et ça prend ~20% de processeur pour du 768x576 à 50 fps sur mon vieil Athlon XP 3000+. Avec un processeur moderne ça doit être nettement moins, on peut probablement même optimiser davantage avec les nouvelles instructions SIMD, voire le faire entièrement sur la carte vidéo avec des shaders.

Bon OK, le mien est en ASM optimisé à la main et le sien fait peut-être d'autres trucs, mais ça n'explique pas une telle différence de vitesse...

Ca consiste en quoi émuler un CRT ?

Kochise

faire du vieux avec du neuf...

(ya que moi qui joue avec les filtres lissages à fond et résolution max pour que ça fasse un effet HD DE LA MORT ?)

Faut croire