Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Sep 2012
Offline Last Active Jun 07 2013 12:05 PM

Topics I've Started

a question about OpenAL on iOS

04 May 2013 - 08:44 PM

i am adding sound to my iOS game using OpenAL, i downloaded the sample code "MusicCube" at Apple Developer, i use the code directly in my game and it works fine.

but however, i have a question about the sample code, in the sample code, in file MusicCubePlayback.m i find the initBuffer function, for your convenience i paste it here:

- (void) initBuffer

ALenum  error = AL_NO_ERROR;
ALenum  format;
ALsizei size;
ALsizei freq;
NSBundle* bundle = [NSBundle mainBundle];
// get some audio data from a wave file
CFURLRef fileURL = (CFURLRef)[[NSURL fileURLWithPath:[bundle pathForResource:@"sound" ofType:@"wav"]] retain];
if (fileURL)
_data = MyGetOpenALAudioData(fileURL, &size, &format, &freq);
if((error = alGetError()) != AL_NO_ERROR) {
printf("error loading sound: %x\n", error);
// use the static buffer data API
alBufferDataStaticProc(_buffer, format, _data, size, freq);
if((error = alGetError()) != AL_NO_ERROR) {
printf("error attaching audio to buffer: %x\n", error);
printf("Could not find file!\n");
_data = NULL;

my question is: after the alBuffer established, why didn't they free the _data?  i think the alBuffer should be a memory in audio card and through the initBuffer function we submit the audio data in _data to audio card(alBuffer) and then _data is no more needed so we can free it. but i tried to free _data and it cause the sound not play normal. 

i just wonder why it is not just as the process of creating textures in OpenGL: when creating texture, after the texture established we can free the image data. 

so, back to OpenAL and the MusicCube sample, did it freed the _data in some where else i did not notice? or it just not be freed? if _data not freed, may it cause memory inefficiency?  





ios opengles 2.0 lowp cause problem, right? and why?

12 December 2012 - 02:30 PM

i am working on a iOS 3d game, because i don't have a real device in hand, so i have being test it in iOS simulator, and it always run well.
today i got a itouch4 with 5.0.1 system and test my game on it.
i found a strange problem:
in shader, i set the texCoord to lowp, and the texture become mess on device (but nothing wrong in simulator), and when i modified it to mediump it fixed.
there are some other wrong effect, and they are also finally solved by change lowp to mediump or highp.
that is a little strange because even though we known a little precision loss many cause some flaws, but i never expected the flaw may so serious as to get totally wrong effect.
and this is not the most strange thing, i also found that after i changed some of the lowp to mediump or highp, the game runs much more fluent on the device than before.
so i start to suspect that may be lowp have some support issue on real device. does the system (here is iOS 5.0.1) not support lowp well?
anyone else have the similar annoying experience with lowp?
i also want to known if i should change all the lowp to mediump or highp (or may be better all change to highp)?

do i need to reserve space for vertex buffer?

02 December 2012 - 02:14 PM

i am using opengles 2.0. but i think the answer will be same with openGL.
i am using VBO. every frame i bind the vertexBuffer and then use glBufferData to submit a vertexArray to GPU.the size of the vertexArray is different each frame. so i wonder if the space of the vertexBuffer reallocated every time?
i guess if the vertexArray i submit this time is bigger than last time, the space of vertexBuffer on GPU side need to reallocate, and it may inefficient. am i right? do i need to reserve space for the vertexBuffer to avoid reallocation?

i read on the opengles 2.0 reference and found the information that if we call glBufferData with * data set to NULL, it will perform space reservation, for example: glBufferData(GL_ARRAY_BUFFER, n_byte, NULL, usage);