forums.ps2dev.org

[GlennNZ]

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

[Wally]

Try PSP_HEAP_SIZE_KB(-1024);

It should work

[J.F.]

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

[GlennNZ]

[J.F.]

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.

[GlennNZ]

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.