Actualité
deadalus

Golden Eye et Daedalus ne font pas bon ménage ?

par
Source: hosh

Une petite news sur les avancées de StrmnNrmn le créateur de Daedalus : il chercherait à obtenir un Golden Eye fonctionnel dans les prochaines releases de Daedalus ... Cliquer sur suite !

StrmnNrmn créateur de Daedalus est en train, pour les amateurs du genre James Bond, de se pencher sur le jeu Goldeneye. Pour information ce jeu se lançait dans les premières releases de Daedalus mais il ne passe plus depuis un certain temps.




Vue de Golden Eye sous N64 :




Il ressort de son investigation différents points :


Golden Eye est un jeu inhabituel pour les jeux N64 sachant qu’il exécute plusieurs codes pour solliciter la mémoire virtuelle. StrmnNrmn pense que ce serait pour allouer le maximum de RAM disponible pour le jeu mais au détriment de la mémoire.

L'émulation du jeu pour le moment est très lente car pour assurer chaque instruction exécutée, l'émulateur doit examiner si l'instruction qu’il va chercher causera une exception TLB (Translation Look-aside Buffer) manquante. Ce processus est long, StrmnNrmn essaye de réorienter le tout vers la mémoire physique.

Pour contourner ce problème avec Golden Eye, StrmnNrmn a paramètré de fausses entrées dans la mémoire de son Emulateur Daedalus qui pointe directement au bon endroit dans l’image ROM.
De cette manière la rom N64 a un TLB beaucoup plus grand, et toutes les pages sont mappées de manière permanente.

Sur la Version PC de Daedalus tout fonctionne du fait de la mémoire virtuelle beaucoup plus importante sur un ordinateur. Dans le cas de la PSP la contrainte se trouve à ce niveau pour la ROM Golden Eye car les 12MO de cette ROM sont chargés de manière permanente dans la mémoire et il y a donc donc tout simplement pas assez de mémoire pour faire tourner le jeux intégralement comme avec les autres Roms N64

StrmnNrmn se donne trois orientations sur lesquels se pencher afin de trouver une solution pour le lancement du jeu Golden Eye via Daedalus.

Nous ne manquerons pas de vous tenir informé de son avancé sur le sujet, sachant que ces investigations qui restent cependant en second plan comme il nous l’indique au niveau du développement de Daedalus, permettrons dès lors le lancement des jeux similaires à Golden Eye sur les versions Daedalus à venir si ses recherches aboutissent.


Commentez cette news en cliquant ICI

Mots-clés

Commenter 5 commentaires

lmame
yogi a écrit: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
Signaler Citer
hlide_1
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 :D)

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]
Signaler Citer
gazeux_snake
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é).
Signaler Citer