shasha

ba tu peux filer les liens stp, je veux terminer ce classic une 10 em fois^^.

serieux vous faites comment? parce que ça m'interresse grandement!!

tiens le lien de psp trduction: http://www.psp-traductions.net/index.php?file=News&op=suite&news_id=8

je pense aussi que gpsp tourne mieux que snes9x. gpsp est en fait programmer pour la console alors que snes est un portage de l'emulateur pc. Maintenant pour les jeux, les versions GBA sont meilleurs a mon gout avec de bonne traduction et des bonus.

ou bien tu utilises le joystick, c'est moi fun qu'avec des vrai touche mais tu t'y fais rapidement.

StrmnNrmn a donc dit, sur son Blog:: "Wow, ça faisait longtemps que je voulais fournir cette mise à jour. J'ai passé du bon temps en Espagne, et après être revenu, j'ai passé de bonne soirée sur Crackdown (jeu Xbox360). Cela m'a fait du bien de faire une petite pause pendant quelques jours. Depuis ça, j'ai travaillé sur les diverses fonctions que j'avais promis pour la R11. J'ai parlé un peu au sujet de la mise en tampons de textures, étant le coupable principal pour avaler vers la mémoire pendant l'émulation. Quand j'ai commencé à profiler ceci en détail, je me suis rendu compte qu'un des plus mauvais point pour la consommation de mémoire était le support des texture mirroir de 4 ou de 8 bits sur la palette de textures. Il y avait réellement deux problèmes principaux qui aggravaient le problème. Premièrement, je n'avais jamais pris en main une palette de texture directement dans Daedalus. Je veux dire, au lieu de convertir une palette de texture de la n64 sur une palette de texture sur la PSP, je l'ai convertit vers des textures 32-bit RGBA. Ce qui veux dire que sur la n64, 64x64 pixels avec une palette de texture de 4-bit prendra 2KiB. En convertissant vers des textures 32-bit RGBA, ça prendra 16KiB - la mémoire est utilisé 8 fois plus. La deuxième soucis qui compliquait le problème était que la PSP ne supporte pas des textures mirroir. Afin de supporter cette fonction, j'ai du manuellement reproduire et faire la texture mirroir. Ceci signifie qu'une texture 64x64 mirroir le long des axes S et de T sur le n64 deviendra une texture 128x128 sur la PSP. Le problème principal que j'ai rencontré dû au manque de mémoire était dû à une lourde utilisation des palettes de texture mirroir 4-bit dans certains jeux. Une palette de texture 64x64 4-bit qui prend 2KiB sur la n64 consommerait un énorme 64KiB sur la PSP - 32 fois l'augmentation ! Le problème était que certains jeux employaient des douzaines de telles textures dans une simple liste d'affichage, et la mémoire disponible était rapidement épuisée. Ainsi, les couples de semaines où je travaillais à récrire les textures de Daedalus, c'était pour le support des palettes de texture 4-bit et de 8 bits directement. Ceci a pris beaucoup plus du temps que je pensais en raison du nombre d'endroits dans le code qui doivent communiquer autour des données de texture directement. J'ai également passé une semaine en essayant de dépister deux bugs horribles (dont tous les deux se sont avérés être des erreurs de logique de ma part). L'autre bonne nouvelle à propos de mon travail est que non seulement le support des palettes de texture économisait beaucoup de mémoire, mais également un petit bénéfice au niveau des performances. Produire moins de données de texture signifie généralement un peu moins de travail pour le CPU (la mémoire cache est moins utilisée), ainsi convertir des palettes de texture se fait maintenant un peu plus rapidement. Les palettes de textures sont également beaucoup plus efficaces au rendu (la plupart du temps étant donné qu'ils consomment moins de bande passante du bus et peuvent faire une meilleure utilisation de la cache des textures de la PSP.) L'autre grand gros morceau du travail est d'améliorer la manière dont je manipule les préférences pour chaque ROM. Un des grands problèmes avec l'installation actuelle de Daedalus est que le principal daedalus.ini se compose de détails à la rom spécifique (comme le nom de la ROM, type de sauvegarde, commentaires, etc..) et des préférences définies par l'utilisateur (telle que la synchro de vitesse, désactiver le dynarec etc..). Ceci signifie que je ne peux pas mettre une nouvelle version de daedalus.ini sans éliminer les préférences locales des utilisateurs. Ce que j'ai fait maintenant est de couper daedalus.ini en deux fichier : roms.ini contiendra les détails spécifique à chaque roms, et une version mise à jour sera distribuée avec chaque version de Daedalus à partir de maintenant. Si je sais que le dynarec cause à certaine ROM de se lancer, je peux ajouter une correction pour ceci dans roms.ini, et chacun pourra en profiter dans la prochaine sortie. Un autre bon exemple est le champ de SaveType ; chaque version de Super Mario 64 emploie 4k EEPROM, et ainsi une fois que ceci est configuré dans roms.ini, elle devrait ne jamais avoir besoin d'être modifié. L'autre fichier que j'ai créé s'appelle preferences.ini. Ce fichier n'ira pas avec Daedalus - l'émulateur le créera la première fois que vous changez quelques parametres en jouant à une rom, et les mettra à jour avec les changements que vous ferez dans le futur. Ceci signifie que quand vous copiez une version "fraiche" de Daedalus sur votre Memory Stick, la nouvelle version prendra votre fichier existant de preferences.ini et ainsi se rappellera de tous vos paramètres. Les paramètres que Daedalus pourra se rappeler pour chaque rom sont : * Vérification des mises à jour des textures * Frameskip * Limiter les Framerates * Recompilation dynamique (utilisé pour remplacer les paramètres dans roms.ini si vous avez un soucis avec le dynarec) * Audio * Ajuster la Fréquence * Contrôleur Dans les prochains mois, encore plus d'options seront configurables Les autres paramètres qui sera stocké dans preferences.ini (que je n'ai pas codé) sont toute les options depuis la page "Paramètres Globaux" - comme la taille du viewport, montrer les zones mortes, choisir d'afficher le framerate ou non, etc... Donc R11 s'affiche plutôt bien, même si cela prend un peu plus de temps que je ne l'avais prévu. J'ai encore quelques points sur lesquels travailler, mais j'essayerais de vous tenir au courant fréquemment des avancées pour la prochaine version. source: pspgen

le voila!!!!

A mon avis c'est fait exprés:grr:

Comme vous venez de le lire, Dark_Alex vient de terminer le firmware 3.30OE sans avoir de PSP sous la main. Avec l'aide distante de Mathieulh, il vient donc de fixer le dernier gros bug qui perturbait le fonctionnement de ce 3.30OE que tout le monde attend avec patience et sagesse depuis plusieurs jours. La release devrait donc arriver ce soir vers minuit si tout va bien, car il ne reste que l'installeur automatique à faire. En effet, chaque OE nécessite un nouvel installeur codé spécifiquement. En attendant, nous mettrons en ligne, dans le courant de la journée, une vidéo montrant le 3.30OE fonctionner puis le fichier une fois que tout sera fonctionnel.. voici quelque image en prime: http://www.hiboox.com/vignettes/1507/a793a247.jpg http://www.hiboox.com/vignettes/1507/e2da5b6f.jpg source: pspgen

ZINga BuRgA, le créateur de RCO Editor, a finalement réussi à éditer un fichier topmenu_plugin.rco customizé, qui fonctionne en 3.10OE !! Cependant selon lui, le 3.10 semble avoir des petits mystères intéressant : * Les ombres semblent être différentes * ZINga BuRgA n'a pas réussi à faire apparaître l'icone Mise à Jour Réseau A part ces deux problèmes, le reste semble correctement fonctionner ! Pour télécharger le topmenu_plugin.rco, vous êtes pour le moment obligé d'aller sur le site anglais de l'auteur et de vous inscrire pour pouvoir télécharger le fichier, en attendant une relase publique. Voici les instructions de l'auteur : Pour l'utiliser, utilisez mon RCO Editor. Si vous avez déjà un topmenu customizé pour les 3.0XOE, ouvrez le et sélectionnez l'option "Extract All", ouvrez le topmenu proposé sur le site de l'auteur et sélectionnez l'option "Replace Multiple". Notez que pour que cela fonctionne, vous devrez utiliser la dernière version de RCO Editor, la version 1.13. Note : Le RCO proposé est basé sur un des topmenu de l'auteur. Pour supprimer des images d'ombre et de lueur, remplacez-les avec le fichier "blank.dat" proposé encore une fois sur le site de l'auteur. En attendant, nous n'avons pas voulu demander l'autorisation de partage de ce fichier étant donné qu'il ne fonctionne pas encore correctement, nous attendrons donc une release publique pour vous le faire partager, car nous avons jgué inutile de vous partager des fichiers qui ne fonctionnent que partiellement. source:pspgen C'est pour bientot

mdr mais c'est pas un tunisien qui la hacké mais des turcs ya cas voir le drapeau

merci c'était ça en fait maintenant j'ai mis le crack paradoxe et sa marche trankil alocker donc

Bonjour tout le monde, voila mon probleme je veux joué à final fantasy 8 aprés avoir créé mon eboot je le lance dans ma psp 3.10 oe A' ya le boot psx et aprés plus rien:triste: j'ai éssayé mon dump sur epsxe, un emulateur psx, et il fonctionne trés bien j'ai résséyé avec psx2psp et autopopstation avec des comprésion différente et toujours pareil!!! est ce que quelqu'un sait ce que je dois faire pour y joué? merci d'avance

c'est peut etre la faute à ta memory stick. Y a un topic pareil: http://www.metagames-eu.com/forums/psp/t..84406.html Dans ce cas là, c'était la faute à une fausse MS

j'ai hate de le testé, j'espere qu'il sortira pendant le week end

le lecteur ouindoz n'est pas encore operationnel du moin pas encore...

peut bien oui. Bon merci darkz pour ta reponse

Bonjour j'avais deja un jeu psx sur ma psp 3.02 oe b et il marchais trés bien. MAis aprés avoir utilisé le 3.02 OE customizer et changer mon gameboot et mon soundboot j'ai remarqué que mon jeu ne se lancé plus, la psp freezai...pire encore plus aucuns jeux psx ne se lancé j'ai donc tout remis par defaut et la , Ô bonheur, sa remarche. Donc mes questions sont simple: est ce que quelqu'un a eu le même probleme que moi? et est ce que quelqu'un utilise 3.02 OE customizer sans rencontré de probleme??????