[Blash]

Si tu n'utilises pas le code que j'ai mis plus haut la valeur de size est l'offset du fichier dans la rom. C'est pour cela que je disais qu'il ne "voit" qu'un gros fichier. donc si tu alloues un table avec  buffer = (u8*)malloc(size);
tu te retrouve avec un tableau énorme.

Donc ma correction est correcte

P.S. sous no$gba, j'ai pas encore tester avec le hardware

[Noda]

faudra que je regarde ca, normalement y'a pas besoin de ta correction c'est surement juste un truc à corriger dans mon driver mem gba

[Noda]

Pour la FFT en direct, c'est relativement très tendu.
Pour l'avoir codé pour mon projet avec le robot, on en a chié. (et au final, même pas de reconnaissance vocal, juste une reconnaissance "musical" (un note la fois hein, pas pousser mémé dans les orties))

Bah pas tant que ca avec un bon algo je pense? je me souviens en avoir fait ca en java sur tel portable (!) avec décompo de 128 freq, ca tournait bien, donc sur DS avec genre 32 freq ca se fait largement en temps réel je pense!

[Arialia]

Ah j'en étais sure que ça marcherait avec le devoptab 

contente que tu ai pu l'implémenter  j'avais eu l'idée de le faire mais j'ai eu la flemme et j'aime pas trop modifier le code des autres 

[t4ils]

voici les premiers résultats de mes tests :

utilisation nickel du efs:/, très pratique, j'utilise les mêmes fonctions du coup dans mon homebrew pour lire sur la carte où dans le répertoire efsroot (très pratique, ça me sauve des lignes )

cependant, tout fonctionne bien sur émulateur (desmume) mais écran noir au chargement d'un niveau efsroot sur hardware

je vais creuser un peu

edit : ça marche très bien sur hardware, faut juste attendre 10 secondes le chargement de la map, contre 0.1 auparavant ... je vais recreuser ce problème

edit² : bon bon bon ... je fais des fscanf, et c'est bien long
pour la même fonction, j'ai le droit à deux résultats selon DLDI ou EFS
DLDI va mettre 0 secondes à charger une map, alors que EFS met facilement 10 secondes

j'ai fais un débug output, j'ai le temps de compter les fscanf (~1500 fscanf à la suite)

Code:

for(i=0;i<768;i++){
            fscanf(fichier,"%d",&mapColl[i]);
            PA_OutputText(0,0,5,"map collision %d",i);
        }

on dirait que y'a un PA_WaitForVBL() dans le tas tellement c'est lent
pareil pour un fread, long en EFS, très court en DLDI

Code:

fseek(file, 0, SEEK_END);
                size = ftell(file);
                fseek(file, 0, SEEK_SET);

                buffer = (u8*)malloc(size);
                fread(buffer, 1, size, file);
                buffer[size-1] = '\0';
                sprintf(textIngame.textNiveau,"%s",buffer);
                free(buffer);
                fclose(file);

[Noda]

Merci des tests, bon a priori c'est pas normal hein, la vitesse de l'efs devrait être très proche de la libfat d'origine

Va falloir que je creuse tout ca un pti peu ^(et que je teste un minimum paske bon )

EDIT: bon tails dejà pour ton souci le pb de vitesse vient surement du bug remonté qq posts au dessus, vis à vis de la taille (genre ftell renvoir bien l'offset, donc va falloir que je corrige ca)

[thoduv]

Je crois aussi qu'il y a un bug de la libfat concernant ftell qui est super lent...

[Copper]

Je sais pas si ca peut aider mais il me semble que la fonction EFS_fseek devrait renvoyer 0 en cas de succès  et une valeur non nulle en cas d'échec (et non pas la position dans le flux)

[Noda]

Je sais pas si ca peut aider mais il me semble que la fonction EFS_fseek devrait renvoyer 0 en cas de succès  et une valeur non nulle en cas d'échec (et non pas la position dans le flux)

Oui,  pour fseek mais là j'ai fait l'implémentation des fonctions devoptab qui sont plus bas niveau

Bon j'ai corrigé le bug avec ftell, implémenté stat(), ajouté le retour de st_size dans dirnext(), et optimisé 2-3 trucs

Voilà la nouvelle itération, qui a été testée un peu plus (sous ému uniquement par contre):
http://noda.free.fr/nds/EFSv2_beta2.rar

Je pense qu'on s'approche de la finale, si les tests hardware sont concluants 

[Cobain]

super et merci

fait chier je peu plus dev sur DS

[Michoko]

Alors une première réponse rapide, je n'ai pas eu super longtemps pour tout tester:

après avoir ajusté le code, ça marche nickel en EFS sous NO$GBA 2.6a! Vraiment super, adieu les images FCSR !

Par contre, sur hardware, c'est suuuuupeeeeer leeeeent. Pourtant je ne fais pas grand chose, juste un GetFileSize:

Code:

u32 EFS_GetFileSize(FILE *file) {
	u32 size;

    fseek(file, 0, SEEK_END);
    size =  ftell(file);
	rewind(file);

	return(size);
}

Puis un chargement de fichier, genre :

Code:

// Loads a RAW file
u8* LoadMediaFile(char* name, u32 *size)
{
	u8* buffer;
	FILE* file;

	file = fopen(name, "rb");
	if(file != NULL) 
	{
		*size = EFS_GetFileSize(file);
	    buffer = malloc(*size);
	    fread(buffer, 1, *size, file);
	    fclose(file);
	    return(buffer);  
	}
	else
	{
	 	return(NULL);
	}
}

Et ça prend plusieurs minutes au minimum. Je croyais que ma DS était plantée, mais c'était juste que ça chargeait.

Il faudrait que je fasse plus de tests, mais je dois d'abord ajouter un output debug dans mon HB (d'habitude je débugge tout via des messages NO$GBA).

Pour info je teste sur un CycloDS Evolution.

Merci encore Noda, on prie tous pour que tu trouves la solution. Bon courage !

[t4ils]

V2 beta 2 même combat
la lenteur de mes chargements est toujours là

je suis retourné en V1 en attendant, donc je switch au gré des nouvelles versions pour de futurs tests

[Noda]

Hmm je vais voir ca c'est bizarre quand meme, j'espère que ca vient pas du devoptab?

sinon changement rapide à tester:
- remplacer fread(buffer, 1, *size, file); par fread(buffer, *size, 1, file);

vu que l'implémentation de fread va faire appel à ma fonction interne EFS_read() pour chaque bloc, il vaut mieux l'appeler 1 fois plutot que size fois car il y a un fseek à chaque read() (lent). Si ca vient de ça je vais essayer de voir pour virer ce fseek() (j'avais déjà l'idée de le faire de toute facons).

Quelqu'un pour confirmer que ca vient de ca ou pas?

[t4ils]

changement effectué :

Code:

//fread(buffer, 1, size, file);
            fread(buffer, size, 1, file);

résultat : même lenteur dans le fread :/

sur émulateur c'est nickel, depuis la beta1
ça pourra toujours me servir pour faire des vidéos

[Alekmaul]

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 ?