StrmnNrmn, après quelques vacances bien méritées, vient de faire le point sur ce qu'il compte faire pour la prochaine version de son émulateur Nintendo 64, Daedalus.
Rappelez vous, avant de partir en vacances, StrmnNrmn avait publié la révision 9 de son émulateur, que vous pourrez trouver ici.
Il avait aussi publié un post sur son blog, dans lequel il demandait aux utilisateurs de son émulateur ce qu'ils souhaitaient pour la prochaine version (allez voir la news ici si vous avez oublié).
StrmnNrmn vient juste de finir d'analyser les demandes et les propositions. Voici, ce qu'il en résulte :
In many games, a lot of the time spent executing dynamically recompiled code is doing things which can potentially be emulated at a high level. For instance, over 5% of the time spent executing dynarec code in Mario64 is just converting matrices from floating point to fixed point format. Another 4-5% of the time is spent in a loop invalidating areas of the data cache (which is irrelevant in an emulator.) Some of the most expensive fragments are those which branch to themselves (i.e. those doing many loops). I can optimise for this to avoid loading and flushing cached registers on each iteration through the loop. I can implement a frameskip option (I had intended to implement this for R9, but forgot!) I can make use of the Media Engine (as Exophase suggested in conversation, as the ME can't access VRAM, it might make more sense to execute Audio and Display Lists on the main CPU, and run the N64 CPU emulation on the PSP ME) There are certain situations where I fail to create fragments in the dynamic recompiler - for instance if the code being recompiled writes to a hardware register, this triggers an interrupt and causes fragment generation to be aborted. I should be able to deal with situations such as this more gracefully. The fragment generator can do a lot more to improve register caching, and eliminating redundant 64-bit operations. There are many situations where N64 roms busy wait. I detect very simple occurrences of this, but not all of them. If I manually identify more complex examples I can have the fragment generator optimise them away. Some roms are causing the dynarec fragment cache to be repeatedly dumped and recreated (I think Banjo Kazooie is one example of this). Fixing this may just involve tweaking a couple of magic numbers. I currently optimise memory accesses under the assumption that most accesses are in the range 0x80000000 - 0x80800000, which is incorrect in the case of roms that make heavy use of virtual memory, or access RAM through the mirrored range at 0xa0000000. I can improve the trace recorder to collect information on which range a memory access fell in, and generate code to speculatively optimise for this. Now that the dynarec engine is producing much better code, the cost of display list processing is becoming more significant, and may finally be worth profiling and optimising.Voici une traduction des élements importants :
La demande la plus important de la part de StrmnNrmn était de savoir s'il fallait améliorer plus la compatibilité des jeux, ou plutot la vitesse d'émulation (quitte à perdre une compatibilité), ou enfin les deux de manière symétrique. La majorité des réponses s'oriente vers une évolution dans un même temps de la compatibilité et de la vitesse d'émulation.
Quelques points doivent être améliorés. Par exemple, le dynarec tel qu'il est codé actuellement pour Mario 64 prend des ressources mémoires qui ne font que calculer des matrices d'un format de nombre à un autre. De plus, ce même dynarec peut corrompre des lignes de code pendant leur exécution, ce qui est un peu gênant.
Un frameskip doit être ausssi implanté. StrmnNrmn devait le faire pour la version R9, mais il a oublié...
Il souhaite utiliser le Média Engine (comme suggéré par Exophase -auteur de gPSP ndt- ) vu que le ME ne peut pas accéder à la VRAM, il est plus logique d'exécuter l'audio et l'affichage par le processeur principal et l'émulation du processeur N64 par le Média Engine.
Il y a aussi des jeux qui rentrent dans une boucle d'attente exagérément longue. StrmnNrmn fait tout pour identifier "à la main" le code qui produit ces temps d'attentes.
Les accès mémoires doivent être améliorés, ce qui pourrait à terme produire du code bien optimisé. Cependant, en regard du travail fourni par StrmnNrmn, mais aussi en regard de ce qu'il reste à améliorer, l'émulateur pourrait ne pas voir le jour avant un bon bout de temps...
Pour quand cette version ?
On apprend aussi que le matin de la release de la R9, StrmnNrmn a réparé un bug qui faisait que l'Expansion Pak ne fonctionnait plus avec Zelda Majora's Mask et quelques autres jeux.
Et enfin, dernière nouvelle de StrmnNrmn, il assure que la version R10 sera surement release avant la fin du mois de Mars ! Oui vous avez bien lu
Il ne nous reste donc plus qu'à patienter avec la R9 en attendant cette nouvelle version ...
Source : blog de StrmnNrmn
Retrouvez les précédents articles sur ce sujet :
- Que voulez vous en plus dans Daedalus R10 ?
- Emulation Nintendo 64: DAEDALUS R9 disponible !
- Sortie de Daedalus R9 le week-end prochain !
- L'interface graphique de Daedalus R9 dévoilée
Commentez cette news en cliquant ICI
