MegaDrops

super cette news mais je voudrais savoir quelle version de l'émulateur passais goldeyenight s'il te plais ?

merci d'avance

yogi Wrote:super cette news mais je voudrais savoir quelle version de l'émulateur passais goldeyenight s'il te plais ?

merci d'avance

En tous cas il regarde pour la R12

Voici la traduction litérale (enfin presque) :

Tant que j'y suis dans l'édition du blog, j'ai aussi investigué pourquoi Goldeneye ne fonctionnait plus sur Daedalus (il a fonctionné dans les toutes premières releases, mais a cessé depuis un moment).

Goldeneye est un jeu assez inhabituel en ce sens qu'il fait partie de ces quelques titres qui exécutes du code dans de la mémoire virtuelle. Je n'en suis pas totalement certain, mais je subodore que cela lui permet de libérer plus de RAM possible. Il met en place un espace de mémoire virtuelle pour le code et les mappe dans des pages de la memoire physique en fonction du besoin (i.e. par le biais des exceptions TLB miss). J'imagine que cela signifie qu'il garde juste quelques douzaine de kilo-octet de code en RAM à un instant donné, plutôt que tout le segment de code. [en clair, le programme se sert d'un mécanisme qui garde un minimum de code en mémoire pour rendre disponible le reste comme mémoire de donnée pour le jeu - décor, texture, etc. Quand il passe à une autre bout de code, il le charge en mémoire à la place de l'ancien]

Quoiqu'il en soit, cela rend l'émulation extrèmement lent [tu m'étonnes !] - car pour chaque instruction executé, l'émulateur a besoin de vérifier si le décodage de l'instruction nécessite lémulation de l'exception TLB miss, laquelle invoque un handler d'exception du N64. Cela consomme horriblement du temp cpu, si bien que j'ai tendance à tricher en supposant que le pointeur d'instruction pointe en mémoire physique [et non en mémoire virtuelle pour éviter cette exception très coûteuse].

[Pour résumer, le dynarec n'arrête pas de recompiler les mêmes codes parce que ces codes ne restent pas toujours en mémoire. Comme ç'est très long, son émulateur part du principe que le segment est toujours en mémoire physique comme c'est le cas pour la grosse majorité des jeux N64 - et donc pour ce jeu, ça coince ! ]

Pour dépasser ce problème avec Goldeneye, j'ai mis en place quelque astuces pour que toute la mémoire virtuelle soit mappée dans la mémoire physique [et donc plus d'exception !]. Dans un sens, c'est comme si la N64 avait un TLB plus large [ie, le mécanisme qui permet la virtualisation de la mémoire] avec toutes pages virtuelles mappées de façon permanentes.

Normalement (i.e. sur la version PC de Daedalus) ca marche niquel. Le problème par contre avec la version PSP, c'est que la ROM (qui fait [quand même] 12 Mega-octet) doit être chargé en mémoire de façon permanente, et du coup il n'y a pas assez de mémoire libre pour le faire. Comme la majorité des rom N64 sont simplement beaucoup trop large pour rentre dans la ram de la psp, je dois découper leur ROM en pages dans la memory stick, et le charger à la demande (de façon très similaire à ce que fait sur la N64 )

Donc, il y a quelques possibilités pour le faire fonctionner:


* Désactiver de façon permanente le dynarec pour Goldeneye, et réutiliser les tampons dynarec (6 Mo en tout), l'expansion pak (non nécessaire ici d'aillauer, 4 Mo) et tout ce que je peux ramasser, pour mettre la ROM dans un block contigu en RAM.
* Trouver un moyen pour faire fonctionner l'astuce du mapping de la mémoire avec la technique du rom caching.
* Réexaminer comment gérer les exceptions TLB miss d'une meilleure façon.


Parmi celles-ci, la première solution est la plus aisée, mais c'est du bidouillage.

La seconde solution est un peu moins horrible, mais je ne suis pas certain que ce soit la plus stable à la longue .

Ce qui laisse la dernière qui fonctionnera probablement le mieux, mais je pense que c'est la solution la plus stable à la longue. Cela peut profiter à d'autres rom qui utilisent des techniques similaires. Si je peux parvenir à le faire fonctionner avec l'implémentation de l'actuel dynarec, cela ne devrait pas être plus lent qu'avec l'actuelle astuce en place.

De tout façon, étant donné le travail que cela implique, ce ne sera pas une priorité immédiate, mais j'y penserais.

[sur la fin, j'ai zappé des explications techniques parce que je me doutes bien que cela ne vous parlera pas plus... et que ça me saoulait de les traduire]

cool mercii pour l'info, il tue tout ce jeux, et si il pouvai faire un mode online sur le strmm ce serai nikel

Nouvelle news sur le blog (la 4eme en 24h quand meme).
Goldeneye n'était pas une priorité pour la r12 mais il n'a pas résisté quand même à essayer de le faire tourner.^^
Et il a réussi après une petite heure. Bon y a des bugs graphiques et il n'a pas réussi a faire du in game vu que ca plante pendant le chargement du niveau (il ne sait pas encore si c'est le chargement qui est très long ou si ca plante) mais ca avance 8) Ce n'est pas très rapide non plus (6-7 fps) vu que ca ne marche pour l'instant qu'avec le dynarec désactivé (il n'a pas encore trouvé pourquoi ca ne marche pas avec le dynarec activé).