Problem loading large image

[jplaza]

Hey, I'm having trouble loading a large image (1024x1024 pixels) with uLibrary. I'm using a PNG file, loading it with ulLoadImageFilePNG, but it doesn't show in the screen.

I tried using ulSetImageTileSize to fit the 256x192 pixels of the screen, but is the same. >(

When I use a shorter image (256x256) it works fine.

I hope you can help me! :cry: Thanks in advance.

[MaaS]

Hmm, me neither, If I use a file bigger than 256x256, loaded in RAM or VRAM, (8bits png/gif, beeing the only thing loaded, and tried also with banks A and B assigned to textures... just in case it was a memory issue)... it didnt show...

So... If, I load in UL_IN_RAM, a big 8bits image, say 1024x1024, and later set the tilesize to something like a 32x32 box... then, shouldnt the sprite in VRAM be only 32x32x8bits? not the whole picture?

In my case I had this problem when loading my map, as I have a tileset of 634 16x16 tiles, and that's a 256x640 tileset picture... so trying to load the map like in the example gives me a completely black map, except the first tile, that is transparent.

But then... i tried with different sizes (>256x256) and pictures and none showed :? plotting usually, a white box...

[Brunni]

Hello,
First, welcome on this forum :)
About your problem you can't load so big images simply because you don't have enough memory.
The default VRAM is 1 Mbit (= 128 kBytes).
You can expand it to 2 Mbits.
1 Mb is not a lot, in fact an image with the following dimensions: 256 x 256 x 8 bit per pixel is already 512 kbits. An image of 512 x 512 x 8 bit per pixel covers the entire 2 Mbits (and you will probably not be able to use it because a few bytes are reserved for the default font if you called ulInitText).
So no, it's impossible because you would need at least 2 Mbits to load a 1024x1024 image in the smallest pixel format: 2 bits (only 3 or 4 colors).
However as the main RAM is 4 MBytes, you can load and fit it in RAM, but you won't be able to display it because it requires moving it to the VRAM and there's not enough room.
Ah and ulSetImageTile will not help; the entire image is always loaded, even if only a part of it is actually displayed. It would be too slow to dynamically load parts of an image depending on your use. ;)
The only thing you can do is to load smaller images or use smaller pixel formats (i.e. PAL4 or even PAL2 if possible).

[MaaS]

Hmmm... let's say i want something like...

Bank A Textures (128 kBytes)
Bank B Textures (128 kBytes)
Bank C Textures (128 kBytes)
Bank D Textures (128 kBytes)

so i set...

ulSetTexVramParameters(UL_BANK_A | UL_BANK_B | UL_BANK_C |UL_BANK_D, VRAM_A, 512 << 10);


Then, shouldnt i be able to load in VRAM a 512x512x8bits image? as it will be 256K plus 2K for the text if initialized. :huh: Well, it doesnt run for me.. :S

What i do...

ulInit(UL_INIT_ALL);
ulInitGfx();

ulSetTexVramParameters(UL_BANK_A | UL_BANK_B | UL_BANK_C |UL_BANK_D, VRAM_A, 512 << 10);
ulSetTexPalVramParameters(UL_BANK_E, VRAM_E, 64 << 10);

ulInitText();

ulDisableTransparentColor();
imgCara = ulLoadImageFilePNG((const char*)cara512, (int)cara512_size, UL_IN_VRAM, UL_PF_PAL8);

while(1)
{
ulStartDrawing2D();

ulDrawFillRect(0, 0, UL_SCREEN_WIDTH, UL_SCREEN_HEIGHT, RGB15(0, 10, 0));

ulSetImageTileSize(imgCara,0,0,128,128);
ulDrawImageXY(imgCara,0,0);

shadowedPrintf(0, 0, RGB15(31, 0, 0), "Mem: %i / %i ",ulGetTexVramAvailMemory(),ulGetTexVramTotalMemory ());

ulEndDrawing();
ulSyncFrame();
}

...

Also... when using ulSetTexVramParameters, the size returned by ulGetTexVramTotalMemory is wrong, so maybe some settings are not init right or maybe it's just me :p... if u dont touch anything, default BankA is assigned, and ulGetTexVramTotalMemory is 131072 (128K), but if you do it yourself setting ulSetTexVramParameters(UL_BANK_A, VRAM_A, 128 << 10) then ulGetTexVramTotalMemory is 8192 (!!)

Thanks in advance :)

[krs]

-- HS --

Bonjour,

Je post du compte d'un collègue compte tenu du délai d'activation de compte...
(je repondrais dans les jours qui suivent sous le pseudo Kun)

Tout d'abord, bravo à Brunni pour cette magnifique librairie (comme alternative aux diverses limitations de la PALib, il n'y a pas mieux :)).

Et désolé de changer de langue en plein milieu d'un sujet...

-- Subject --

Je me demandais simplement s'il y avait un moyen de créer une image à partir d'une autre, mais avec des tailles différentes ?
Par exemple : UL_IMAGE* ulCreateImageFromImage(UL_IMAGE* img, int x, int y, int sizeX, int sizeY);

L'idée est de charger la grande image en RAM, et de charger (en plus) à la volée 1 ou 2 petites images dont on a besoin. Comme ça, seules les petites images seraient charger en VRAM.

Ceci afin de simplifier le travail sur une image, sans être obligé de la couper en petit bout :)

Merci d'avance.

PS : pour des raisons techniques/personnels/etc, nous ne voulons pas passer par la PALib.

[krs]

Petite mise à jour pour expliquer là où nous en sommes... (si ça peux donner des idées à quelques uns...)

-- Problématique --
Nous faisons un shoot them up sur DS, certaines map font dans dans les 6000px haut, avec une largeur fixe de 256px, et bien sûr, nous utilisons les 2 écrans :)
Le problème étant la taille de la VRAM.

-- Solution trouvée (désolé d'avance à Brunni qui s'efforce de faire une lib propre, pour les saletés que nous en faisons :)) --

L'idée : éviter les traitements inutiles, réutiliser autant que possible les informations de la map (que nous appellerons "le père").

Notre façon de faire :
Une méthode initialise n (15 sans notre cas) UL_IMAGE* qui servirons de segments, avec une hauteur et taille fixe (256*24), en allouant la mémoire nécessaire.
La map n'est jamais affichée !
Nous chargeons la palette du père en VRAM, et récupérons la paletteID au père, dont tous les fils (segments) hérites.
Nous avons ajouté 2 champs à la structure UL_IMAGE :
- Le premier permettant de savoir s'il faut libérer la mémoire correspondant au paletteID lors de la suppression d'un UL_IMAGE (afin de ne pas la libérer plusieurs fois, étant donné que tous les segments partagent celui de la Map).
- Le deuxieme permettant de savoir s'il faut free le champs texture. Afin de garder le même emplacement mémoire à chaque rechargement de segment (useless... sans doute).

Ainsi, à chaque fois que nous nécessitons un segment supplémentaire à afficher (alors, un autre segment n'est plus utile), nous changeons l'état de la texture pour indiquer qu'elle se trouve en RAM, nous remettons la textureID à -1, et nous faisons un memcpy du père vers le fils sur l'emplacement mémoire qui nous intéresse.

Ce n'est pas vraiment propre, et c'est très spécifique à ce type de map (pratique, car les images sont chargée ligne par ligne, et que justement, nous savons que la largeur que nous souhaitons sera toujours la même que la map initiale), mais ça permet d'éviter certains opérations qui peuvent être coûteuses.

-- Notes --
Ceci est juste une piste de réflexion pour ceux qui auraient un problème similaire, et nous ne publierons pas les changements pour 3 raisons :
1) ils sont très faciles à reproduire soit même,
2) plus on gère de cas particulier, plus c'est coûteux pour les cas génériques,
3) nous adorons la uLib car elle permet *tout* avec une base très légère, et nous pensons que c'est la meilleure des optiques à suivre. (Même si les libs qui gère **tout** avec un gros noyaux peuvent être beaucoup plus utiles à certains)

-- Questions --
Nous avons remarqué que lors du premier affichage d'une image, la fonction ulTexImage2D est appelée, et elle fait appel à la fonction swiWaitForVBlank.
Étant donné que nous avons que de très maigres connaissances en hardware DS, nous nous demandons quelle est l'utilité d'appeler cette fonction à ce niveau ?

Deuxième question : Brunni indique dans un autre sujet qu'il est possible sous certaines conditions de passer la VRAM à 512Ko, si quelqu'un avait un lien avec un peu plus de précisions, ça pourrait nous aider :) (car nous en sommes au début, et avec la méthode citée, avec une map de 256 couleurs, nous avons 24 * 256 * 15 = 90ko utilisé en VRAM déjà...)

Merci de nous avoir lu jusqu'au bout, vous avez beaucoup de courage :)

PS : *nous* car nous sommes 3 développeurs sur ce homebrew :)

[sdevilcry]

vous allez tout casser !!! :p

On a trouver comment agrandir la mémoire en 512 ko :),

ulSetTexVramParameters(UL_BANK_A | UL_BANK_B | UL_BANK_C | UL_BANK_D , VRAM_A, 512 << 10);

Enfin c'était sur un autre poste du forum.

Pour infos : (groupe qui développe le Subquest :p).

Bonne continuation.

Je tiens a féliciter brunni de cette lib qui est quand même bien énorme ainsi que les utilités que tu as crée a coter (GBA Graphics) . !