You are not logged in.
Hello !
I am currently writing an application in C++ that needs to load some .png images on the fly.
To do so, I'm using the GRRLIB_LoadTextureFromFile() function you provided (since I am not an expert of buffers and memory...).
for (int i=0; i<gameLayer.getChildrenCount(); i++) { Game* game = (Game*) gameLayer.getChild(i); if (!game->load(game->getCoverPath())) game->load("theGameChannel/images/noCover.png"); ... ... ...
Well, everything goes fine but if I have more than 27 image files, the other ones won't load at all.
More ! I found that depending on the images I use, the 28th image will either not be loaded or either be partially loaded, resulting in a texture corruption displayed on the screen.
This is why I concluded of a memory limitation.
Actually, I tried to mess around with the DEFAULT_FIFO_SIZE definition, and lowering the buffer size allow the 28th image to be fully loaded, but the 29th still won't show at all.
Do you have any clue on these limitations ? Maybe the GX initialisations ? Or do I have to call some methods just after loading a texture to free some space somewhere ?
Note : The total space used by my .png images is ~2.60Mo
Last edited by Obli (2009-05-30 15:09:03)
Offline
Are you using the latest svn version of libogc?
shagkur on http://forums.devkitpro.org wrote:
Hi,
latest SVN already contains a patch for malloc to handle mem2 aswell.
ofcourse mem2 will only be taken if we run out of mem1.
Also there's the lwp_heap API for custom memory management.
regards
shagkur
Taken from this page: http://forums.devkitpro.org/viewtopic.p … amp;t=1369
Maybe it could fixed the problem!!!
Offline
As a reminder:
MEM1 Memory is 24 MB
MEM2 Memory is 64 MB
Source: http://wiibrew.org/wiki/Hardware/Main_Memory
Offline