GP32 Memory Issues?


Pirotic

Certified Guru
Joined
Feb 16, 2004
Messages
593
Hiya again, another technical question for you lot over something which has me baffled.

at the start of my application i load all the graphics and sound from .h files, like this:

//Engine Data
#include "gamedata\logo.h" //the logo
#include "plug.h" //splash screen
#include "plug_sfx.h" //splash screen audio
#include "gamedata\collision.h" //collision detection
#include "gamedata\tileset.h" //the tiles
#include "gamedata\charset.h" //the characters
#include "gamedata\menu.h" //game menu
#include "gamedata\cursor.h" //the mouse cursor (hand)

however, im now running into problems where changing the sound effects and and plug data to larger files, means my application 'forgets' all the data which is loaded afterwards..

for instance, i changed the plug_sfx to a larger file - and now everything boots and runs (and the sound plays), but the collision detection doesn't work as the collision.h seems to be returning all zero's instead of the proper values it should of loaded :p

at first i thought i must just be that i was using up all the ram, but surely it wouldn't even boot if that were the case, i would expect it to freeze or reset on me? so could there be another reason :p

im pretty new to C coding so it has me baffled, i tried moving the plug_sfx to the bottom of the include list, and indeed everything else loads, but when it goes to play the sound only half of it plays.

bizzare stuff, my whole app is under 8mb so no idea whats causing it

On a side note, is it possible to load the contents of a .h file temporarily into RAM, then play the sound/draw the graphic to a buffer, then 'forget' the .h file so it saves some RAM? or will it always have to load the whole .fxe content onto ram before it executes? :p

oh well, if all else fails i'll just have to jump two steps ahead and code the SMC file loader and keep the data seperate from the .fxe.
 
The contents of the .h file are hardcoded into the app. Its loaded into memory as part of your game when you game is loaded. Its using a static array size so you really cannot "clear" the memory and load it again when needed. You can erase the contents of the array if you did not declare it as const, but the memory allocated for it, will remain allocated. You could possibly get the pointer to this array and manually free the memory used (I think), however you would not be able to get that data back.

To do that you would have to dynamically load the files from the SMC during your apps proccess. And unload them when not needed anymore. Create pointers and use malloc and free to manage the memory.

I assume all of those listed .h files are audio and images converted using GP32 Converter.

Try using GpDevUtil to create external audio and image files that can be loaded dynamically at runtime.

For your other problem, all I can assume is that there is some memory problem, a pointer gone awry, memory over run, etc... loading this data from external files will let you control your memory a little better, but will not solve your problem.

To fix your problem, all you can do is try looking for any datatype that is using pointers and make sure you dont go "over" your allocated memory for those types.

i.e
Code:
int *bubba;
bubba = (int *)malloc(sizeof(int) * 5);    
bubba[10] = 15;
The int pointer bubba was initalized to the size of 5 int elements. If you try and go above the 5th element (like the example bubba[10] = 15;) it will over run the allocated memory, possibly overwriting something important. Make sure you always allocate enough memory, and never go over your allocated amount.


First, what I would do, is find the array that is 0's (the one thats being erased). When the app FIRST loads, check this array, very first thing you do, check to see if its all 0's.
Also check the pointer to the array, then after the array gets "erased" check the pointer again. Is it still pointing to the same spot in memory? You might have inadvertandly overwritten the array pointer, so its "pointing" to the wrong spot in memory.

After that, I would comment out as much code as I possibly can and still allow the program to function on the most basic level. And then start uncommenting individual blocks of code until I have found the one that causes all the chaos. And then figureout why that particular block is causing troubles.

Without seeing all of your code, all I can really do is speculate and offer suggestions, it could be something as simple as you setting the arrays pointer to a bad spot. Or it could be some nasty memory leak in your app.
 
thanks for going to the time to explain all that to me,

i feel im probably going 'over' the allocated space, as the problem seems to be when a certain data (sfx/gfx) goes over a certain file size - where as it happily lets me add new data without problems.

would really love to just make it load the maps from the SMC when needed, but sadly im using MiniGP32 which doesn't seem to support SMC files, or atleast doesn't document it such that a newb like me and find out how its done :p

the files which are causing problems are

const unsigned char plug[76800]

and

const unsigned short plug_sfx[38290]

could the unsigned have anything to do with it? (i have no idea what the difference is)
 
Pirotic posted on Apr 2 2004 at 01:12 PM said:
could the unsigned have anything to do with it? (i have no idea what the difference is)
Nope, the unsigned can't be causing a problem. the const key is the problem, as the arrays are "const" they cannot be modified, neither be unloaded dynamically. you should use pointers instead as Akuma no Houkon said.
By the way, const does not exist in C, it is a C++ keyword,and so are // comments. It is not really an issue, just something to remember. It can lead to problems if someday you try to code on some ... restrictive compiler ;)
 
Last edited by a moderator:
thanks again everyone for your help,

i've gone and read up a little on data types, memory address and pointers and such, even learnt that signed means it stores if its minus or positive, so an unsigned int can go twice has high but not into negative :D

im such a n00b!

had a fiddle with that example you gave,

int *bubba;
bubba = (int *)malloc(sizeof(int) * 5);
bubba[10] = 15;

but it doesn't seem to work, moans bubba is already specified :p

Anyway, went thru all my .h include files, and removed any references to const - also optimized a few of them - they only held yes or no values (1/0) and for some reason i had them as 'shorts', tried bool but despite by compiler supporting it, it moaned at me, so i settled with char, changed some of the massive int arrays into short arrays instead, etc - that should keep the memory problems off my back.

regards

Pirotic
 
Pirotic if you are using the offical SDK it has many SMC functions, Such as Read,Write,Open,Close, etc...plenty to do anything you need to.

About:

int *bubba;
bubba = (int *)malloc(sizeof(int) * 5);
bubba[10] = 15;

That works perfect on the compiler I am using, (except bubba[10] = 15; will overrun the allocated memory because you only allocated memory for 5 elements) are you sure its typed exactally like that? (copy and paste if you have to). I am using the devkitadv kit and the compiler included with that (which, by the way doesnt like // comments either)

Code:
/* global variables put these in your header */
unsigned short *SFX_Audio[5];  /* 5 elements so we can hold 5 sfx files */
ulong SFXSize[5];  

void LoadSFX(char filenamenpath, int sfindex)
{
unsigned long readbytes; 
F_HANDLE fh;
  if (GpFileOpen(filenamenpath,OPEN_R, &fh)==SM_OK)
  {      
  GpFileGetSize (filenamenpath, &SFXSize[sfindex]);
  SFX_Audio[sfindex] = malloc(SFXSize[sfindex]);
  GpFileRead(fh, SFX_Audio[sfindex],SFXSize[sfindex],&readbytes);
  GpFileClose(fh);
  }  	
}

It may need modifications to be used with your code, and may not work unless you are using the offical SDK because of the FileIO functions involved. But you get the idea.

The same or similar concept can be applied to any files you need to read. :)
 
i did start with the official SDK, but i've modified it slightly with improvements i found in the other SDK's.

i did indeed copy that code correctly when i tried it, it must just be my compiler is different, as my compiler is happy with // comments - oh well, i understood what you were trying to teach about memory allocation updated big portions of my code so it doesn't waste so much ram :D

also thanks for that sfx loading code, i'll see if i can modify it and use it in my project.

regards, and i've added you to the credit list on my project as a sign of respect

Pirotic
 
Back
Top