Apparently I'm running out of heap memory with my PSPGL, SDL app. I think I'm getting too carried away with loading .obj files where I store the vertices, normals etc in dynamically allocated arrays and then use them for vertex arrays.
I preload the models on startup so the app doesn't get beyond a gray screen. Fortunately I can still exit by pushing the HOME button.
I'm already using PSP_HEAP_SIZE_MAX(), so short of being more tactful with the amount of models I load, is there anything else I can do?
It was suggested that I shouldn't be using the heap so much and instead use the stack for my member variables (that are used for the vertices, normals etc), but after doing some reading, I concluded that the heap is the best thing for loading vertices from the obj file.
I'm just putting this out there so that I can pick up some tips and tricks. I'm concluding that I just can't load so many models, although it doesn't seem like much really, because the poly count is pretty low.
Cheers
Need some advice for lack of heap memory
That's less than MAX, Wally. :) The main reason to use a negative heap instead of MAX is that MAX won't let any threads be created as there won't be any memory left for them (which might be part of his problem). A negative heap size means all of memory minus the number of KB specified.
One of the biggest wastes of space you'll see are png/jpg loaders that round the memory to the next power of two because that's what the PSP wants for textures. There's no smart packing, so the extra space is wasted. Also, most png/jpg loaders convert the image to 32 bit ABGR in memory. If you have 256 color palette images, it would be one fourth the memory to leave it as 256 color with a palette.
Oh yeah, if you have a Slim, be sure to use
in the makefile. That's what makes the extra memory in the Slim usable by homebrew. That and setting the heap size with MAX or the negative value.
One of the biggest wastes of space you'll see are png/jpg loaders that round the memory to the next power of two because that's what the PSP wants for textures. There's no smart packing, so the extra space is wasted. Also, most png/jpg loaders convert the image to 32 bit ABGR in memory. If you have 256 color palette images, it would be one fourth the memory to leave it as 256 color with a palette.
Oh yeah, if you have a Slim, be sure to use
Code: Select all
BUILD_PRX = 1
PSP_LARGE_MEMORY = 1
This isn't a solution to my issue unfortunately.J.F. wrote:The main reason to use a negative heap instead of MAX is that MAX won't let any threads be created as there won't be any memory left for them (which might be part of his problem).
I forgot about texture size considerations. I'm using 256x256 jpg pictures which are converted to GL_RGB. I have no idea what PSPGL is doing under the hood, but perhaps I'm not having a heap memory problem, but a memory problem in general.J.F. wrote:Also, most png/jpg loaders convert the image to 32 bit ABGR in memory. If you have 256 color palette images, it would be one fourth the memory to leave it as 256 color with a palette.
What do you mean 'with a palette'? You're just referring to RGB using less space than RGBA, aren't you? We're using RGB so I'm wondering if I should go to 128x128.
Good to know. Thanks.J.F. wrote:Oh yeah, if you have a Slim, be sure to use
in the makefile. That's what makes the extra memory in the Slim usable by homebrew. That and setting the heap size with MAX or the negative value.Code: Select all
BUILD_PRX = 1 PSP_LARGE_MEMORY = 1
[Edit]
I removed some textures and there is still a problem so I think it's the amount of heap allocation I'm using.
There are a number of pixel formats the PSP supports for textures. They can be 4 or 8 bits per pixel with an associated palette of 16 or 256 colors, or 15/16/32 bit direct colors. A texture done as 8 bit paletted consumes (width * height + 1024) bytes of space, while the same image as 32 bit consumes (width * height * 4) bytes. You can see that the paletted image is almost one fourth the size. The limitation is that you can only have 256 color for that image. That's usually not a problem as these are textures for specific things. Also, each texture could have it's own 256 color palette, so the palette for one texture doesn't limit the palette of another texture. It's not like Doom or Quake where everything shared one single 256 entry palette.
A 256x256 texture as RGB consumes 256 * 256 * 4 bytes (256 KB). So 16 textures like that consumes 4 MB of space. So how many textures are you trying to load at one time? How much memory have you devoted to them? These are things you need to work out ahead of time. If your game leaves 4 MB of space for textures, and you NEED them to be 256x256 RGB, you can only have 16 loaded at a time. That may mean you'd need to reload the textures before each object. Seriously though, you probably don't need 256x256 textures. 128x128 or smaller would be recommended. Use the smallest size for each texture you can. If a texture could be done as 16x16, do it! You can have many more 16x16 textures than 256x256, and often it will look the same on the final display.
A 256x256 texture as RGB consumes 256 * 256 * 4 bytes (256 KB). So 16 textures like that consumes 4 MB of space. So how many textures are you trying to load at one time? How much memory have you devoted to them? These are things you need to work out ahead of time. If your game leaves 4 MB of space for textures, and you NEED them to be 256x256 RGB, you can only have 16 loaded at a time. That may mean you'd need to reload the textures before each object. Seriously though, you probably don't need 256x256 textures. 128x128 or smaller would be recommended. Use the smallest size for each texture you can. If a texture could be done as 16x16, do it! You can have many more 16x16 textures than 256x256, and often it will look the same on the final display.
Yes, I'm using a LOT of textures. I'm surprised I've gotten away with it as long as I have. I see PSPGL has a palette extension so I'll have to read up on it.
[edit]
For the sake of anyone who finds this thread in a search, the problem was actually the result of not closing files that were being read. i.e. an fclose(file) was needed.
I see I started this thread in late December, so it only took me 6 weeks to figure out.
[edit]
For the sake of anyone who finds this thread in a search, the problem was actually the result of not closing files that were being read. i.e. an fclose(file) was needed.
I see I started this thread in late December, so it only took me 6 weeks to figure out.