:: PlayerAdvance.org ::  

Pr嶰嶮ent   :: PlayerAdvance.org :: > :: Forums H嶵erg廥 :: > 無ibrary

無ibrary Official 無ibrary forum (English / Fran蓷is)

Publicit

R廧onse
 
Outils de la discussion Modes d'affichage
Vieux 07/09/2007, 16h35   #1
jplaza
 
Messages: n/a
Par d嶨aut Problem loading large image

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! Thanks in advance.
  R廧onse avec citation
Vieux 27/12/2007, 20h45   #2
MaaS
Newbie
 
Date d'inscription: 23/12/2007
Messages: 4
Par d嶨aut

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...
MaaS est d嶰onnect   R廧onse avec citation
Vieux 27/12/2007, 21h03   #3
Brunni
Super Mod廨ateur
 
Date d'inscription: 10/11/2005
Localisation: Un pays avec beaucoup de banques
Messages: 3 226
Par d嶨aut

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).

Derni鋨e modification par Brunni ; 27/12/2007 21h09.
Brunni est d嶰onnect   R廧onse avec citation
Vieux 09/01/2008, 02h32   #4
MaaS
Newbie
 
Date d'inscription: 23/12/2007
Messages: 4
Par d嶨aut

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...

Code:
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. Well, it doesnt run for me..

What i do...

Code:
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 ... 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
MaaS est d嶰onnect   R廧onse avec citation
Vieux 04/05/2008, 01h41   #5
krs
Newbie
 
Date d'inscription: 06/02/2008
Messages: 3
Par d嶨aut

-- HS --

Bonjour,

Je post du compte d'un coll銶ue compte tenu du d幨ai 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廥ol de changer de langue en plein milieu d'un sujet...

-- Subject --

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

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

Ceci afin de simplifier le travail sur une image, sans 皻re 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 est d嶰onnect   R廧onse avec citation
Vieux 05/05/2008, 02h46   #6
krs
Newbie
 
Date d'inscription: 06/02/2008
Messages: 3
Par d嶨aut

Petite mise jour pour expliquer l o nous en sommes... (si 蓷 peux donner des id嶪s quelques uns...)

-- Probl幦atique --
Nous faisons un shoot them up sur DS, certaines map font dans dans les 6000px haut, avec une largeur fixe de 256px, et bien sr, nous utilisons les 2 嶰rans
Le probl鋗e 彋ant la taille de la VRAM.

-- Solution trouv嶪 (d廥ol d'avance Brunni qui s'efforce de faire une lib propre, pour les salet廥 que nous en faisons ) --

L'id嶪 : 憝iter les traitements inutiles, r徼tiliser autant que possible les informations de la map (que nous appellerons "le p鋨e").

Notre fa蔞n de faire :
Une m彋hode initialise n (15 sans notre cas) UL_IMAGE* qui servirons de segments, avec une hauteur et taille fixe (256*24), en allouant la m幦oire n嶰essaire.
La map n'est jamais affich嶪 !
Nous chargeons la palette du p鋨e en VRAM, et r嶰up廨ons la paletteID au p鋨e, dont tous les fils (segments) h廨ites.
Nous avons ajout 2 champs la structure UL_IMAGE :
- Le premier permettant de savoir s'il faut lib廨er la m幦oire correspondant au paletteID lors de la suppression d'un UL_IMAGE (afin de ne pas la lib廨er plusieurs fois, 彋ant 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瘱e emplacement m幦oire chaque rechargement de segment (useless... sans doute).

Ainsi, chaque fois que nous n嶰essitons un segment suppl幦entaire afficher (alors, un autre segment n'est plus utile), nous changeons l'彋at de la texture pour indiquer qu'elle se trouve en RAM, nous remettons la textureID -1, et nous faisons un memcpy du p鋨e vers le fils sur l'emplacement m幦oire qui nous int廨esse.

Ce n'est pas vraiment propre, et c'est tr鋊 sp嶰ifique ce type de map (pratique, car les images sont charg嶪 ligne par ligne, et que justement, nous savons que la largeur que nous souhaitons sera toujours la m瘱e que la map initiale), mais 蓷 permet d'憝iter certains op廨ations qui peuvent 皻re coteuses.

-- Notes --
Ceci est juste une piste de r嶨lexion pour ceux qui auraient un probl鋗e similaire, et nous ne publierons pas les changements pour 3 raisons :
1) ils sont tr鋊 faciles reproduire soit m瘱e,
2) plus on g鋨e de cas particulier, plus c'est coteux pour les cas g幯廨iques,
3) nous adorons la uLib car elle permet *tout* avec une base tr鋊 l嶲鋨e, et nous pensons que c'est la meilleure des optiques suivre. (M瘱e si les libs qui g鋨e **tout** avec un gros noyaux peuvent 皻re beaucoup plus utiles certains)

-- Questions --
Nous avons remarqu que lors du premier affichage d'une image, la fonction ulTexImage2D est appel嶪, et elle fait appel la fonction swiWaitForVBlank.
尒ant donn que nous avons que de tr鋊 maigres connaissances en hardware DS, nous nous demandons quelle est l'utilit d'appeler cette fonction ce niveau ?

Deuxi鋗e 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嶰isions, 蓷 pourrait nous aider (car nous en sommes au d嶵ut, et avec la m彋hode cit嶪, avec une map de 256 couleurs, nous avons 24 * 256 * 15 = 90ko utilis en VRAM d嶴...)

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

PS : *nous* car nous sommes 3 d憝eloppeurs sur ce homebrew
krs est d嶰onnect   R廧onse avec citation
Vieux 29/05/2008, 23h51   #7
sdevilcry
Membre
 
Date d'inscription: 02/05/2008
Messages: 22
Par d嶨aut

vous allez tout casser !!!

On a trouver comment agrandir la m幦oire en 512 ko ,

Citation:
ulSetTexVramParameters(UL_BANK_A | UL_BANK_B | UL_BANK_C | UL_BANK_D , VRAM_A, 512 << 10);
Enfin c'彋ait sur un autre poste du forum.

Pour infos : (groupe qui d憝eloppe le Subquest ).

Bonne continuation.

Je tiens a f幨iciter brunni de cette lib qui est quand m瘱e bien 幯orme ainsi que les utilit廥 que tu as cr嶪 a coter (GBA Graphics) . !
sdevilcry est d嶰onnect   R廧onse avec citation
R廧onse

Liens sociaux

Publicit



Utilisateurs regardant la discussion actuelle : 1 (0 membre(s) et 1 invit(s))
 
Outils de la discussion
Modes d'affichage

R銶les de messages
Vous ne pouvez pas cr嶪r de nouvelles discussions
Vous ne pouvez pas envoyer des r廧onses
Vous ne pouvez pas envoyer des pi鋃es jointes
Vous ne pouvez pas modifier vos messages

Les balises BB sont activ嶪s : oui
Les smileys sont activ廥 : oui
La balise [IMG] est activ嶪 : oui
Le code HTML peut 皻re employ : non
Navigation rapide


Fuseau horaire GMT +2. Il est actuellement 07h24.


丼it par : vBulletin® version 3.7.2
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd. Tous droits r廥erv廥.
Version fran蓷ise #16 par l'association vBulletin francophone
Design par Ass-Itch, DJP et Dr.Vince