views:

28

answers:

3

What should i do? I have some 512x512 png. I compressed them to PVR (which results terrible quality), and I'm preparing to compress the PNGs with pngcrush tool. The PVRs have about 2x-x larger filesize than the PNGs, maybe I can experiment with JPG files.

Are the images stored in a compressed state in memory? Or compression counts only at loading process? Or the images/textures are mapped uncompressed in memory?

The same queston goes to sounds. I tried different formats, like wav, mp3, aac, aiff (caf), but it seems that attaching the soundManager eats the same size of memory.

Is there a way to reduce the actual memory consumption, or compressions are only for speed up texture/sound loading?

Please shed me a light.

+1  A: 

You will always have the complete data in your RAM. For textures I can't recommend you anything, but for sound you could use mono files. This would reduce the needed size by 50%. You can also experiment with the bit-rate of your sound files.

JustSid
Ohkay, thanks, that seems an answer. So data is uncompressed in memory. I do use mono files since I began optimizing.
Geri
A: 

Compressed textures use less RAM since they are stored compressed in VRAM, and they are operated in compressed form.

So with compressed textures, you get benefits at uploading and VRAM store.

Matias Valdenegro
Are you sure? OpenGL ES stores textures afaik not compressed.
JustSid
If you use compressed texture formats (PVR, ETC) yes. Normal texture formats are not compressed.
Matias Valdenegro
So you say if I load a PVR, then the memory usage will fall back? Thats a pity 'cos the PVR compressed textures seems too jaggy for me. Is there any option to improve a PVR quality? I tried percepltual/linear-2bit/4bit versions, but they were horrible quality.
Geri
Yes, but the compression is lossy as you can see.
Matias Valdenegro
A: 

Regarding sounds, what you could try is buffering them - that means reading from the files as they are needed, and then discarding the data once it's been played.

Note that this isn't really useful if your sounds are small (say, explosions) and may actually do more harm than not (because it has to read the file every time it plays) - it depends how often it's played, of course.

Where this technique comes to use is things like music; in OpenAL, you can buffer small audio segments by using:

alSourceQueueBuffers(source, numbuffers, buffers);

There also exist functions to check the number of queued and already processed buffers:

ALint numqueued, numprocessed;
// total number, including the already-processed buffers!
alGetSourcei(source, AL_BUFFERS_QUEUED, &numqueued);
// number of buffers played completely
alGetSourcei(source, AL_BUFFERS_PROCESSED, &numprocessed);

Once you have the number of processed buffers, you can simply unqueue (and then remove) the ones that are done:

ALuint processed[numprocessed];
// fills "processed" with the buffers that have been removed
alSourceUnqueueBuffers(source, numprocessed, processed);

...and finally, remove the buffers (provided that they are unused):

alDeleteBuffers(numprocessed, processed);

For more info, you can see the OpenAL Programmers Guide (PDF warning): http://connect.creativelabs.com/openal/Documentation/OpenAL_Programmers_Guide.pdf

Tim Čas