Bion première release de AnimEDS: check, mise à jour de SEDS : check. Quoi d'autre ?
En premier, une petite uniformisation de mon environnement de compilation ne serait peut-être pas une mauvaise idée. J'avais identifié un problème de performances dans la libfat pendant les congés de Noël ... ça pourrait valoir la peine de revenir dessus histoire de soumettre un "vrai" patch pour le projet devkitpro. Pour l'instant:
- démarrer SEDSgama.nds depuis le menu R4 et faire un "QUIT" vers rungama.nds: ok
- mise à jour interne de SEDSgama et rungama: ok, mais lent (compilé sur beetle)
- démarrer SEDSgama depuis runbeta: ok, mais empèche d'utiliser le loader pour sortir de SEDSgama.
Ensuite, on pourra voir pour les histoires d'effets miroir dans AnimEDS, la définition d'autres structures de sprites (changer le nombre de membres et l'utilisation des pages de sprites) et le support de tout ça dans le moteur de jeu (eh oui, l'idée, ça reste de faire des jeux).
this is the right place for quickstuff
vu que, sur la même carte SD, le "vieux" runme continue à avoir de bonnes performances, je peux éliminer les problèmes de fragmentation, en principe.
ReplyDeleteCurieux, toutes les écritures sont "partielles" ... un effet de la taille des paquets TCP, peut-être ?
ReplyDeleteau passage selon les spécifications, la DS n'a que 4K de cache de données. Une misère. Si une politique de caching (pour la mémoire de masse -- appelons-le L2) est telle qu'elle force une écriture à se produire longtemps (sic) après que les données aient été transmises à la libfat, elle risque d'avoir un fort écart de performances par rapport à une politique qui pourrait les expédier tant qu'elles sont dans le cache L1 aussi.
ReplyDeleteMe voilà occupé à tenter de réintégrer le fichier "cache.c" de la "vieille" libfat à l'intérieur de nouvelle... et de constater, assez surpris, que l'ancienne version ne contient pas __FAT_cache_readSectors in __FAT_cache_writeSectors, mais uniquement les versions "partielles": quand une écriture devait porter sur un secteur complet (voire sur un ou plusieurs clusters), __FAT_fwrite() fait directement appel à __FAT_disc_writeSectors et __FAT_fread à __FAT_disc_readSectors... enfin, je crois que c'est ça.
ReplyDeleteJe comprends mieux du coup les commentaires de wintermute à propos des copies qui sont moins efficaces dans le cas de la DS: les données ne transitaient par le cache que s'il n'y avait pas moyen de faire autrement (altération partielle d'un secteur).