[Arialia]

Le pb viendrait pas de

    if (useDLDI) {   
        // seek to right position and read data
        fseek(nds_file, file->pos, SEEK_SET);
        len = fread(ptr, len, 1, nds_file);
    } else {   
        memcpy(ptr, file->pos + (void*)GBAROM, len);
}

dans la fonction EFS_Read. Il n'y aurait pas un pb de réentrance dans le code vu que devoptab est utilisé pour le fread ?

il y a des chances ...

pour éviter ça dans ton nds_file tu spécifie le 'device' ? 'fat:' par exemple ?
évite aussi les fonctions fichiers de haut niveau je pense .... c'est un read que tu devrais faire , pas un fread ...

[Copper]

Par contre pourquoi cela serait-il lent uniquement sur Hardware

[Arialia]

sur emulateur il doit faire le memcpy ...

[Copper]

Ah oui effectivement pour le coup il faut vraiment debugguer sur hardware (ou emulateur gérant le DLDI)

Par contre fat: n'est pas le device par défaut ?

[Noda]

Le pb viendrait pas de

    if (useDLDI) {   
        // seek to right position and read data
        fseek(nds_file, file->pos, SEEK_SET);
        len = fread(ptr, len, 1, nds_file);
    } else {   
        memcpy(ptr, file->pos + (void*)GBAROM, len);
}

dans la fonction EFS_Read. Il n'y aurait pas un pb de réentrance dans le code vu que devoptab est utilisé pour le fread ?

Je me posait la question, mais NitroFS semble faire la même chose hmmm. Je vais faire un pti test de NitroFS sur hard pour tester sa vitesse, y'a quelque chose de bizarre quand meme...

Aralia: fat: est le device par défault, et de toute facon si tu affiche la variable efs_path le préfixe y est bien. Pour l'utilisation de fread par rapport à read, c'est qu'il me semble que fread est utilise le cache mais pas read, mais je me trompe peut etre..

En tout cas doit y avoir forcément une couille qq part!

[Alekmaul]

Oui, tu as raison, mais en regardant là (http://devkitpro.cvs.sourceforge.net/devkitpro/libfat/nds/source/nitrofs.c?revision=1.1&view=markup), ils font aussi l'inversion entre len et 1, à tester donc si le pb ne vient pas de cette lecture de 1 par 1 octet

  129 //reads from rom image either gba rom or dldi
  130 int nitroSubRead(struct nitroRawStruct *nrs, void *ptr, int len) {
  131    if(isNdsFile) { //read from ndsfile
  132       len=fread(ptr,1,len,nrs->ndsFile);
  133    } else {   //reading from gbarom
  134       memcpy(ptr, nrs->pos+(void*)GBAROM,len); //len isnt checked here because other checks exist in the callers (hopefully)
  135    }
  136    nrs->pos+=len;
  137    return(len);
  138 }

[Noda]

Bon j'ai testé en speed mon exemple avec NitroFS, et ca rame pareil... donc ca vient forcément des fonctions haut niveau du devoptab, pour l'instant rien à faire, à part peut etre tester avec les fonctions plus bas niveau (open, read etc au lieu de fopen, fread) pour voir si ca va plus vite ou pas.

Je vais en toucher quelques mots à Chism il aura ptetre une idée la dessus, et Wintermute aussi qui cassait bien les bonbons avec son devoptab qui au final fait ramer le bordel

[Alekmaul]

Petit up pour les beta testeurs, il semble que le pb vient bien de l'inversion entre len, 1 et 1,len dans les fread comme indiqué ici : http://forum.gbadev.org/viewtopic.php?p=157323#157323

Si certains veulent tester avant (il faut mettre à jour soit même la lib, y'a pas encore d'update) que Noda continue la mise à jour de sa superbe lib

PS : j'espère que AS_lib suivra dans la foulée ?

[t4ils]

c'est bien ça !

bravo les chti goy

* t4ils va pouvoir aller mettre tout ça dans StillAliveDS

edit : après pleins de test, ça fonctionne vraiment nickel
thanks

[Toiletking]

Juste une chtite question (de noob  ) : Est-il possible en bricolant la palib, de remplacer de manière transparente, via quelque p'tite modif de la lib, de remplacer PAFS par EFS et de garder les fonctions pafs telquel de manière à ce que, lors de la compilation avec ce dernier, on ne soit plus du tout aubliger de changer sont code?   

Ca serait le reve! comme ca op, je compile avec la dite version et je garde toute la souplesse et la simplicité de mon pafs favoris 

Edit : comme ca la doc de pafs ne bougerai pas 

[Noda]

Pour PAFS c'est possible, mais tu perdrais moins de temps à changer ton code qu'à faire ca 

Sinon j'ai bien avancé sur l'EFS today, et j'ai augmenté les perfs encore de 10~40% 

Au passage, les resultats d'un petit bench pour comparer les vitesses de l'EFS et de NitroFS:

EFS init OK! Testing...
Open a file: 0ms
small file fread (1blk): 15ms
small file fread (/1b): 15ms
dir listing: 1ms
big file fread (1blk): 1895ms
big file fread (/1b): 1895ms

NitroFS init OK! Testing...
Open a file: 177ms
small file fread (1blk): 194ms
small file fread (/1b): 195ms
dir listing: 184ms
big file fread (1blk): 2052ms
big file fread (/1b): 2049ms

Ca rockz hein C'est même plus rapide que de passer par la libfat, du fait du handle unique de l'EFS on ne perd pas de temps à ouvrir à chaque fois un fichier et à remplir le cache

[Alekmaul]

UNE RELEASE !!! UNE RELEASE !!! UNE RELEASE !!! UNE RELEASE !!! UNE RELEASE !!! 

[Michoko]

Je dirais même plus :

UNE RELEASE !!! UNE RELEASE !!! UNE RELEASE !!! UNE RELEASE !!! UNE RELEASE !!!

[Noda]

La release candidate sort demain (flemme de l'uper là ), avec support de chdir() complet (à tester) et la possibilité de fournir un path dans l'init (facultatif), en vue du support futur de argv[] par DKP

Si les derniers tests sont concluants, la release finale suivra, couplé à une MAJ de l'ASlib

[stravingo]

Très bonnes nouvelles
Quand tu dis "sort demain" à 00:21, tu veux dire "aujourd'hui", hein ? (hein? hein?)