[uLib] Probleme sur UL_VIRTUALFILENAME

[omg]

Ce soir je viens de me rendre compte que mon PC n'a pas de problemes de conversion de fichier *.bmp en *.png mais que la RAM qui stoque les différents fichiers de l'UL_VIRTUALFILENAME peut être saturée.Detailed Description
Virtual file list item. Used for RAM based devices.
De combien d'octet est cette RAM et surtout, est-ce la taille des fichiers jpg, png et gif qui est comptée ou la totalitée des pixels?
Merci! :)

[birslip]

La DS a 4mo de mémoire, mais faut voir que pour décoder les images ulib doit faire des malloc et pleins de choses comme ça, tu as combien d'octets pour tes images là?

Sinon tu peux toujours passer par un file system comme le dldi, je crois que ulib supporte ça? :)

[omg]

ben en fait l'ensemble s'élève à 14,7Ko... C'est pour ça que je trouve bizarre qu'elle ne puisse pas prendre beaucoup...
Bon je vais voir comment vider cette mémoire...
En fait je débute, je découvre...
Merci de t'interrésser Beerslip! ;)

EDIT:
Voilà ma déclaration de UL_VIRTUALFILENAME:
//Files stored in RAM.
UL_VIRTUALFILENAME ram_names[] = {
{"bear.gif", (void*)bear, (int)bear_size, &VF_MEMORY},
{"choose_screen.png", (void*)choose_screen, (int)choose_screen_size, &VF_MEMORY},
{"introup.png", (void*)introup, (int)introup_size, &VF_MEMORY},
{"introdown.png", (void*)introdown, (int)introdown_size, &VF_MEMORY},
{"q.gif", (void*)q, (int)q_size, &VF_MEMORY},
{"a.png", (void*)a, (int)a_size, &VF_MEMORY},
{"b.png", (void*)b, (int)b_size, &VF_MEMORY},
{"c.png", (void*)c, (int)c_size, &VF_MEMORY},
{"d.png", (void*)d, (int)d_size, &VF_MEMORY},
{"e.png", (void*)e, (int)e_size, &VF_MEMORY}
};Les 4 premieres images font 256x192, les autres sont plus modestes...
Quand je les change de place je vois tout de suite que mon probleme d'affichage vient d'une saturation de la mémoire...

[omg]

Pour ceux que ça interresse j'ai pallié au problème en effaçant mes images avec ulDeleteImage.
Je résume ://Exemple

#include "main.h"
#include "intro_up.h"
#include "choose_screen.h"

//Files stored in RAM.
UL_VIRTUALFILENAME ram_names[] = {
{"choose_screen.png", (void*)choose_screen, (int)choose_screen_size, &VF_MEMORY},
{"intro_up.png", (void*)intro_up, (int)intro_up_size, &VF_MEMORY}
};

int main()
{
UL_IMAGE *imgFondUp ;
int totalTime = 1; //To avoid a divide by zero the first time

//Initialize µLibrary
ulInit(UL_INIT_ALL);
//Initialize the graphical part
ulInitGfx();
//Initialize the text part
ulInitText();

//Sucks banks C-D + drops at 30 fps
ulInitDualScreenMode();

//Use bright pink as a transparent color
ulSetTransparentColor(RGB15(31, 0, 31));

//Register the file names for the RAM file system. This is not obligatory, you could directly pass "pointer, size" for file loading routines instead of "name, 0".
ulSetVirtualFilenameList(ram_names, ulNumberof(ram_names));

//We load our James character image. Note that the format is PAL4 (16 colors). It is enough for our image but may not for others.
imgFondUp = ulLoadImageFilePNG("intro_up.png", 0, UL_IN_VRAM, UL_PF_PAL8);

while(!ul_keys.held.A)
{
//Start our drawing
ulStartDrawing2D();

if (!ulGetMainLcd())
{
//If we're there, then we control the top screen
ulDrawImageXY(imgFondUp, 0,0);
}
else
{
//Else we're on the touchpad
ulSetTextColor(RGB15(31, 0, 0));
ulDrawString(0, 183, "ça marche?");
}

//End the drawing
ulEndDrawing();

//Wait the VBlank (synchronize at 60 fps)
ulSyncFrame();
totalTime = TIMER1_DATA;
ulReadKeys(0);
}
ulDeleteImage(imgFondUp);

imgFondUp = ulLoadImageFilePNG("choose_screen.png", 0, UL_IN_VRAM, UL_PF_PAL8);

while(1)
{
//Start our drawing
ulStartDrawing2D();

if (!ulGetMainLcd())
{
//If we're there, then we control the top screen
ulDrawImageXY(imgFondUp, 0,0);
}
else
{
//Else we're on the touchpad
ulSetTextColor(RGB15(31, 31, 0));
ulDrawString(0, 183, "C'est Ok!");
}
//End the drawing
ulEndDrawing();

//Wait the VBlank (synchronize at 60 fps)
ulSyncFrame();
totalTime = TIMER1_DATA;
}
ulDeleteImage(imgFondUp);
//Program end - should never get there
return 0;
}
Par contre je n'ai toujours pas saisi la taille maximum que l'on peut allouer...

[Brunni]

Alors niveau liste de fichiers il n'y a aucune limite parce que tu ne fais que passer un pointeur vers ta liste de fichiers (ram_names).
Sinon j'ai pas testé ton code mais la limite est 128 ko (taille de la VRAM par défaut, mais tu peux passer à 256 dans certaines circonstances, cf la doc).
Mais la limite c'est pas la taille des PNG hein, parce qu'un PNG prend peu de place mais on est obligé de le décompresser pour pouvoir l'utiliser sur DS. Donc une image toute blanche de 256x192 prend peut être 1 ko en PNG, mais une fois chargée elle prendra 256*192*taille_des_pixels. Pour du 8 bits par exemple ça donne 1 octet par pixel donc un total de 256*192 = 48 ko. Donc tu peux en charger 2 comme ça sur 128 ko, la troisième va être refusée, ça correspond bien à ce que tu as obtenu ;)
Si tu mets tes images en RAM elle est de 3.5 Mo environ (dépend de pas mal de choses), mais de toute façon µLib devra les copier en VRAM pour pouvoir les afficher donc tu ne gagnes rien.
Les ulDeleteImage ça aide parce que sinon ta VRAM sera vite saturée. Si tu veux garder une image en mémoire mais la sortir de la VRAM tu peux utiliser ulUnrealizeImage mais je te déconseille de faire ça vu qu'il y a relativement peu de RAM, le unrealize c'est seulement si tu veux modifier une image (tu ne peux pas accéder directement à la vram à moins de faire un ulLockImage) ^^

En gros si je résume tu peux avoir autant de fichiers que tu veux, mais tu ne peux pas les charger tous en même temps à cause de la petitesse de la VRAM. En gros pour chaque "scène" ou "niveau" du jeu tu dois te débrouiller pour faire passer le total des images que tu chargeras sur 128 ko. Et au prochain niveau tu effaces tout et tu remets les images adaptées au niveau suivant, c'est le principe du "loading" en début de niveau, que tous les jeux DS ont (même s'ils ne l'affichent pas) ;)

[omg]

Je ne connaisais pas la taille mais j'avais compris le principe.
Je commence a maitriser cette notion d'allocation de mémoire mais ça devient le bordel au niveau des noms des fichiers PNG... :rolleyes:
Mais bon, c'est juste une notion des noms a travailler :intro:
- intro_titre.png
- intro_anima_1.png
- intro_anima_2.png
- intro_anima_3.png
- intro_animb_1.png
- intro_animb_2.png
- intro_animb_3.png

menu:
- menu_fond_haut.png
- menu_fond_bas.png
- menu_choixa.png
- menu_choixb.png
- menu_choixc.png
- menu_choixd.png
...
Bref, il faut surtout ne pas oublier d'effacer les images qui devienne inutile... :p
Merci Brunni!

PS : Je code entierement mon jeu avec ta lib, mais pour le module de son je merde un peu pour le moment...

[Brunni]

Mwé pour le son, pour bien faire il faut utiliser l'arm7 (c'est pour ça que je ne veux pas parce que du coup c'est incompatible avec palib & autres). Le mieux à mon avis c'est d'utiliser palib juste pour le son (et év. le deuxième écran en mode 2D), mais bon... sinon y'a moyen de faire du son avec la libnds sauf erreur, mais je ne me suis pas renseigné. Dis moi si jamais tu arrives à le faire ;)

[omg]

Sinon y'a moyen de faire du son avec la libnds sauf erreur, mais je ne me suis pas renseigné. Dis moi si jamais tu arrives à le faire ;)Ben en fait je ne maitrise pas le Makefile et c'est lui qui m'empeche d'utiliser correctement setGenericSound, TransferSoundData, playGenericSound et playSound.
Je me retrouve avec des erreurs de merde... mais bon, le son n'est pas important pour moi pour l'instant. Je te tiens au courant!