Folco (./2) :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, 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.
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) :Autre débat philosophique ^^
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 ?
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) :En effet c'était pas à ce point de débat que je pensais, mais tes remarques sont intéressantes aussi
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" ^^
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.