So I decided to make SprintfCat(), all the wonderful joy of sprintf, with the ability to concatenate with a already existant string like strcat.

Source code

//
//
size_t ath::SprintfCat( char * inoutBuffer, const size_t inBufferSize, const char * inFormat, ... )
{
	const size_t offset = StrLen( inoutBuffer );
	size_t ret = 0;
	va_list arg;
 
	//
	va_start( arg, inFormat );
	{
		ret = VSprintf( inoutBuffer + offset, inBufferSize - offset, inFormat, arg );
	}
	va_end( arg );
 
	//
	return offset + ret;
}

I had already created my own wrappers around strlen() and vsprintf(), the reason being the fault of Microsoft. With their implementation of the standard library, they decided to deprecate non-safe versions complain at you until you either used their own _s variants, or defined a certain preprocessor.

Source code

//
//
size_t ath::VSprintf( char * outBuffer, const size_t inBufferSize, const char * inFormat, va_list inArgs )
{
#ifndef ATH_PLATFORM_WINDOWS
	return vsnprintf( outBuffer, inBufferSize, inFormat, inArgs );
#else
	return vsprintf_s( outBuffer, inBufferSize, inFormat, inArgs );
#endif
}
 
//
//
size_t ath::StrLen( const char * inString )
{
	return strlen( inString );
}

While I do prefer to have safe versions, their _s variants are not present in the standard and so it makes the code not portable.

I'm still not quite sure about my naming convention for a variable that is an input and an output. While I do like the in or out prefix, I don't think inout looks right, being slightly too long. I wasn't a fan of io either. I have however grown to like the truncation of Athena namespace to ath.

So I made a function that will take the sources list and output the lines with line numbers.

Source code

void OutputWithLineNumbers( const char ** inSources, const unsigned int inCount )
{
	bool unendedLineNo = false;
	int lineNumber = 1;
 
	for( unsigned int i = 0; i < inCount; ++i )
	{
		const char * cur = inSources[i];
		const char * next = NULL;
 
		do
		{
			//
			if( !unendedLineNo )
			{
				printf( "%04d: ", lineNumber );
			}
 
			//
			next = strchr( cur, '\r' );
 
			//
			if( next )
			{
				size_t len = ( next - cur );
				char * lineText = (char *)alloca( len );
				memcpy( lineText, cur, len );
				lineText[len] = 0;
 
				printf( "%s\n", lineText );
 
				unendedLineNo = false;
				++lineNumber;
			}
			else
			{
				printf( "%s", cur );
				unendedLineNo = true;
			}
 
			//
			cur = next + 2;
		} while( next );
	}
 
	if( unendedLineNo )
	{
		printf( "\n" );
	}
}

This code requires the source files to have a carriage return as well as a new line character.

So I took at look into Build Rules in XCode. My main trouble within using them was finding the environment variables, even googling them doesn't turn up much information.

I think the output files act as an error check, if the output file fails to appear then the tool failed.

One other thing I had an issue with was the source files list. I tried comma and semi colon delimiters, and spaces, but the TGA file kept giving the warning on Tree1.tga. I have yet t0 find the a way to do this without multiple entries. And I'm thinking a separate tool for building files may be easier.

After creating another app and still haven't the same problem, I was about to report it as a bug when the answer dawned on me, I had the orientation lock on.

It would be nice if you could do it on an application basis as well as a global one, since I only turn it on because photos get orientated incorrectly.

The contents of my "Useless" app folder: Stocks, Weather, Contacts, Calculator, Voice Memos, Compass, Reminders. If only you could turn off the default apps as well.

On another note, I've added a page next to website for iOS specific links.

The first step in using separate shaders is to create an object to bind them onto that will be our overall shader program, known as a pipeline object.

Source code

GLuint gProgramPipeline = 0;
GLuint gVertexProgram = 0;
GLuint gFragmentProgram = 0;
 
//
//
int main()
{
	//
	CreatePipeline();
	CreateShaders();
 
	//
	BindShadersToPipeline();
 
	//
	do
	{
		//
		UpdateUniforms();
 
		//
		BindPipeline();
		DrawSomething();
		UnbindPipeline();
	}
	while( true );
 
	//
	DestroyShaders();
	DestroyPipeline();
}
 
//
//
void CreatePipeline()
{
	glGenProgramPipelinesEXT( 1, &gProgramPipeline );
}
 
//
//
void DestroyPipeline()
{
	if( gProgramPipeline )
	{
		glDeleteProgramPipelinesEXT( 1, &gProgramPipeline );
		gProgramPipeline = 0;
	}
}

This pipeline object acts similar to vertex array object (VAO) only with shader programs, however instead of using glUseProgram, a separate function glUseProgramStagesEXT() must be used to bind the shader program to the pipeline, specifying the role of the shader program.

Source code

//
//
void BindShadersToPipeline()
{
	glUseProgramStagesEXT( gProgramPipeline, GL_VERTEX_SHADER_BIT_EXT, gVertexProgram );
	glUseProgramStagesEXT( gProgramPipeline, GL_FRAGMENT_SHADER_BIT_EXT, gFragmentProgram );
}

Updating uniforms is slightly different as well.

Source code

//
//
void UpdateUniforms()
{
	//
	GLint uniformLoc = glGetUniformLocation( gVertexProgram, "myVertUniform" );
	glProgramUniform1fEXT( gVertexProgram,
			       uniformLoc,
			       1.248f );
 
	uniformLoc = glGetUniformLocation( gFragmentProgram, "myFragUniform" );
	glProgramUniform1fEXT( gFragmentProgram,
			       uniformLoc,
			       6.1218f );
 
	//
	uniformLoc = glGetUniformLocation( gVertexProgram, "myCommonUniform" );
	float commonValue = 2.0f;
 
	glProgramUniform1fEXT( gVertexProgram,
			       uniformLoc,
			       commonValue );
 
	uniformLoc = glGetUniformLocation( gFragmentProgram, "myCommonUniform" );
	glProgramUniform1fEXT( gVertexProgram,
			       uniformLoc,
			       commonValue );
}

Finally to use the program pipeline, we just need to bind it.

Source code

//
//
void BindPipeline()
{
	glBindProgramPipelineEXT( gProgramPipeline );
}
 
//
//
void UnbindPipeline()
{
	glBindProgramPipelineEXT( 0 );
}

fef

Some Sensorites have been known to be dicks

I came by an annoying problem when I was adding some asserts to my FBX to Athena tool. I was basically adding a check to my vertex buffer size to make sure it was not larger than a GLsizeiptr (defined as a long in iOS5 SDK).

I've always assumed chars to be 8, shorts to be 16, longs to be 32 and ints to be whatever the system wants it to be (most likely the register size for an atomic copy). However, my tool is setup using 64bit OSX project, and the long comes out as 8 bytes, so the value given by LONG_MAX is huge, while the int remains at 4 bytes.

I wouldn't have even noticed that my assert would have never been hit if it had not been for the warning the IDE gave after writing the statement, "Comparison is always true due to limited range of data type".

In the end I just replaced LONG_MAX with INT32_MAX (stdint.h). And after a bit of googling, I found this on wikipedia.

The sizes of short, int, and long in C/C++ are dependent upon the implementation of the language:

• On older, 16-bit operating systems, int was 16-bit and long was 32-bit.
• On 32-bit Unix, DOS, and Windows, int and long are 32-bits, while long long is 64-bits. This is also true for 64-bit processors running 32-bit programs.
• On 64-bit Unix, int is 32-bits, while long and long long are 64-bits.

While this does sound kinda familiar to me, I do not think I've ever had a situation where it has appeared to me until now.

Amy Pond <3

With my recent post about what iOS devices supported what extensions, I noticed a lot of people got to my website trying to work out how to use Vertex Array Objects (VAO) with the GL_OES_vertex_array_object extension.

They're easy to use so I thought I would write up a quick how-to use them. There is a limitation with the VAO however, it cannot be shared between contexts and can be problematic for multithreading.

If you plan to use one, either generate and create for each context you will be using it on. Or generate and create on the context you will be mostly using it on. It might be a mistake, since it says they didn't want to create the first non-shared named object in OpenGL ES, however at the same time they say no to sharing.

Like with any OpenGL object, first a name must be generated for the object, make sure you always initialise your name variables to 0, since this refers to a non-object.

Source code

GLuint gVAO = 0;
 
//
//
int main()
{
	//
	GenerateVAO();
	CreateVAO();
 
	//
	do
	{
		BindVAO();
		DrawSomething();
		UnbindVAO();
	}
	while( 1 );
 
	//
	DestroyVAO();
}
 
//
//
void GenerateVAO()
{
	// Generate Name for VAO
	glGenVertexArraysOES( 1, &gVAO );
}
 
//
//
void DestroyVAO()
{
	if( gVAO )
	{
		glDeleteVertexArraysOES( 1, &gVAO );
		gVAO = 0;
	}
}

I've also put the syntax in there for deleting the VAO when you do not need it anymore.

Now for filling in the VAO. The VAO is basically a block of memory for storing vertex data schematic. For fixed function, the schematic includes information about data type, count, stride, buffer offset and whether it is enabled. This is for every pointer, glVertexPointer, glNormalPointer, glColorPointer, glTexCoordPointer, etc.

And for the shader program pipeline, it contains the schematic for each glVertexAttribPointer.

Source code

//
//
void CreateVAO()
{
	// Bind VAO
	glBindVertexArrayOES( gVAO );
 
	// Bind Vertex Buffer
	glBindBuffer( GL_ARRAY_BUFFER, gSomeVBO );
 
	// Fill in the VAO with our vertex schematic
	if( hasShaders )
	{
		glEnableVertexAttribArray( 0 );
 
		glVertexAttribPointer( 0,			// Attribute bind location
				       3,			// Data type count
				       GL_FLOAT,		// Data type
				       GL_FALSE,		// Normalise this data types?
				       sizeof(float) * 3,	// Stride to the next vertex
				       0 );			// Vertex Buffer starting offset
	}
	else
	{
		glEnableClientState( GL_VERTEX_ARRAY );
 
		glVertexPointer( 3,			// Data type count
				 GL_FLOAT,		// Data type
				 sizeof(float) * 3,	// Stride to the next vertex
				 0 );			// Vertex Buffer starting offset
	}
 
	// Unbind VAO
	glBindVertexArrayOES( 0 );
}

You'll notice that when I am finished with with the VAO, I unbind it. This is because any changes to the vertex pointers will override any we have set within this function, so to protect the VAO we have just filled in, we unbind it.

When using a VAO, you will not need to bind the GL_ARRAY_BUFFER again the next time you use the VAO, since whenever you make a call to gl*Pointer() or glVertexAttribPointer(), the vertex buffer is stored with the vertex schematic. Because of this, you can have multiple streams of data from different vertex buffers.

Source code

//
//
void CreateVAO()
{
	// Bind VAO
	glBindVertexArrayOES( gVAO );
 
	// Vertex Buffer 1
	{
		// Bind Vertex Buffer
		glBindBuffer( GL_ARRAY_BUFFER, gSomeVBO1 );
 
		// Fill in the VAO with our vertex schematic
		if( hasShaders )
		{
			//
			glEnableVertexAttribArray( 0 );
 
			glVertexAttribPointer( 0,			// Attribute bind location
					       3,			// Data type count
					       GL_FLOAT,		// Data type
					       GL_FALSE,		// Normalise this data types?
					       sizeof(float) * 5,	// Stride to the next vertex
					       0 );			// Vertex Buffer starting offset
 
			//
			glEnableVertexAttribArray( 1 );
 
			glVertexAttribPointer( 1,			// Attribute bind location
					       2,			// Data type count
					       GL_FLOAT,		// Data type
					       GL_FALSE,		// Normalise this data types?
					       sizeof(float) * 5,	// Stride to the next vertex
					       sizeof(float) * 3 );	// Vertex Buffer starting offset
		}
		else
		{
			//
			glEnableClientState( GL_VERTEX_ARRAY );
 
			glVertexPointer( 3,			// Data type count
					 GL_FLOAT,		// Data type
					 sizeof(float) * 5,	// Stride to the next vertex
					 0 );			// Vertex Buffer starting offset
 
			//
			glClientActiveTexture( GL_TEXTURE0 );
			glEnableClientState( GL_TEXTURE_COORD_ARRAY );
 
			glTexCoordPointer( 2,						// Data type count
					   GL_FLOAT,					// Data type
					   sizeof(float) * 5,				// Stride to the next vertex
					   (const GLvoid *)(sizeof(float) * 3) );	// Vertex Buffer starting offset
		}
	}
 
	// Vertex Buffer 2
	{
		// Bind Vertex Buffer
		glBindBuffer( GL_ARRAY_BUFFER, gSomeVBO2 );
 
		// Fill in the VAO with our vertex schematic
		if( hasShaders )
		{
			glEnableVertexAttribArray( 2 );
 
			glVertexAttribPointer( 2,			// Attribute bind location
					       2,			// Data type count
					       GL_FLOAT,		// Data type
					       GL_FALSE,		// Normalise this data types?
					       sizeof(float) * 2,	// Stride to the next vertex
					       0 );			// Vertex Buffer starting offset
		}
		else
		{
			glClientActiveTexture( GL_TEXTURE1 );
			glEnableClientState( GL_TEXTURE_COORD_ARRAY );
 
			glTexCoordPointer( 2,			// Data type count
					   GL_FLOAT,		// Data type
					   sizeof(float) * 2,	// Stride to the next vertex
					   0 );			// Vertex Buffer starting offset
		}
	}
 
	// Unbind VAO
	glBindVertexArrayOES( 0 );
}

In the code above, the first texture coordinate set is interlaced with the position data (offset by the sizeof three floats), and is bound using the first vertex buffer (gSomeVBO1). But the second texture coordinate is contained within a second vertex buffer (gSomeVBO2).

Finally, using the VAO is easy.

Source code

//
//
void BindVAO()
{
	glBindVertexArrayOES( gVAO );
}
 
//
//
void UnbindVAO()
{
	glBindVertexArrayOES( 0 );
}

The call to glBindVertexArrayOES() with the VAO object name is just like calling everything we did in the create function. The only limitation is that one VAO is needed per vertex buffer, even if you have the same vertex schematic.

However, this is a great place for optimisation by sharing the same vertex buffer for vertex data with the same schematic. Then whenever you make a call to glDrawArrays() you can specify which vertex to start from. glDrawElements() is a little more complicated, you will need to increase all your elements in your index buffer so they point to the correct position within the shared buffer.

Or alternatively for glDrawElements(), you could share the same index buffer, and just specify the index buffer offset.

I also changed the entries to show equivalent functions instead of my bad descriptions of what the parameters do.

iOS4 Vector and Matrix Math

iOS4 Vector and Matrix Math: Part 2

So I ran through each version of GLES on a 1st Generate iPod Touch (MBX), an iPhone 4 (SGX) and an iPad 2 (A5), printing the returned string from glGetString( GL_EXTENSIONS ) for each device.

There are a some new extensions in iOS5, some of which are iPad2 specific. But you can see from the image, each newer device supports all the previous extensions.

I haven't had chance to run it on an iPad1 yet, so it will be interesting to see if there is any difference. I've only wrote a rough idea of what version of what SDK is required to use them.

Anything with '***' does not need the extension to work and has an implementation for that version of OpenGL ES.

Source code

GL_OES_depth_texture
GL_OES_blend_equation_separate
GL_OES_blend_func_separate
GL_OES_blend_subtract
GL_OES_compressed_paletted_texture
GL_OES_depth24
GL_OES_draw_texture
GL_OES_element_index_uint
GL_OES_fbo_render_mipmap
GL_OES_framebuffer_object
GL_OES_mapbuffer
GL_OES_matrix_palette
GL_OES_packed_depth_stencil
GL_OES_point_size_array
GL_OES_point_sprite
GL_OES_read_format
GL_OES_rgb8_rgba8
GL_OES_stencil_wrap
GL_OES_stencil8
GL_OES_texture_mirrored_repeat
GL_OES_vertex_array_object
GL_OES_standard_derivatives
GL_OES_texture_float
GL_OES_texture_half_float
GL_OES_texture_half_float_linear
 
GL_EXT_blend_minmax
GL_EXT_color_buffer_half_float
GL_EXT_debug_label
GL_EXT_debug_marker
GL_EXT_discard_framebuffer
GL_EXT_occlusion_query_boolean
GL_EXT_read_format_bgra
GL_EXT_separate_shader_objects
GL_EXT_shader_texture_lod
GL_EXT_shadow_samplers
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod_bias
GL_EXT_texture_rg				
 
GL_APPLE_framebuffer_multisample
GL_APPLE_rgb_422
GL_APPLE_texture_2D_limited_npot
GL_APPLE_texture_format_BGRA8888
GL_APPLE_texture_max_level	
 
GL_IMG_read_format
GL_IMG_texture_compression_pvrtc

For more information on each extension, most of them can be viewed here. Some of the newer ones in the EXT namespace are viewable on the what's new page of the beta for iOS5, though the page calls them by the APPLE namespace still.

LEGO Vashta Nerada

I've been meaning to do this in my engine for a while, but just never had a time.

Multithreading in OpenGL is simple enough as long as you are not accessing the same object as something on another thread.

In my case, I'm only using it for my loading thread so I will not be accessing any of the objects created until loading is complete, and I will not be rendering on the separate thread either, at least not yet, I could use it for render targets.

So first of all, the creation of a OpenGL context on iOS. The examples I'm writing here are just simple main() loops so simplify what has to be done.

Source code

int main()
{
	EAGLContext * mContext = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES2];
 
	// Make context active for this thread
	[EAGLContext setCurrentContext:mContext];
 
	//
	while( 1 )
	{
		// do some rendering
	}
 
	//
	return 0;
}

Simple enough, this code most people who have written any iPhone OpenGL apps will recognise, it creates an ES2 context and bind it to the active thread.

However, now we want a separate thread that does OpenGL commands. We could use the same context, but a call binding a buffer on one thread could override to bind on the other causing invalid or wrong calls, so we would need to synchronise the threads.

Instead we create a second context that shares objects with our first one.

Source code

//
//
EAGLContext * mMainContext = nil;
EAGLContext * mThreadContext = nil;
pthread_attr_t mThreadAttributes;
pthread_t mThread;
 
//
//
int main()
{
	mMainContext = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES2];
	mThreadContext = [[EAGLContext alloc] initWithAPI:[mMainContext API]
					       sharegroup:[mMainContext sharegroup]];
 
	// Make context active for this thread
	[EAGLContext setCurrentContext:mMainContext];
 
	// Create second thread for OpenGL stuff
	pthread_attr_init( &mThreadAttributes );
 
	pthread_create( &mThread,
			&mThreadAttributes,
			OGLThread,
			NULL );
 
	//
	while( 1 )
	{
		// do some rendering
	}
 
	//
	return 0;
}
 
//
//
void * OGLThread( void * inParam )
{
	//
	[EAGLContext setCurrentContext:mThreadContext];
 
	//
	while( loadingSomething )
	{
		// other opengl commands
	}
 
	// Flush changes
	glFlush();
 
	//
	return 0;
}

With this second context, any calls to binding objects to the context will not affect the other thread's context. the [API] just makes it so that I'm using the same ES version as the first context, the [sharegroup] is the shared resource group that will be used by both contexts.

However you must take care not to update an object that is in use in the main thread, and whenever you make a change that will affect the other thread, call glFlush() on the thread that modified, and then rebind on the other thread so the changes take place.

In my own engine I hold shadow states of all options set, so one problem with this system would be I would need to pass in the Context depending on the thread. Instead I wrapped a class around the context that holds the shadow states and the context, as well as a pthread_t object for the thread it is assigned to.

Then whenever I do anything that will alter my shadow states, I make a call to pthread_self() to get the current thread, and find the relevant context.

Source code

struct MyContext
{
	EAGLContext * context;
	ShadowStates states;
	pthread_t thread;
};
 
MyContext mMainContext;
MyContext mThreadContext;
 
MyContext * GetCurrentContext()
{
	int ret = pthread_equal( pthread_self(), mMainContext.thread );
 
	if( ret == 0 ) // 0 means not equal when using pthread_equal()
	{
		return &mThreadContext;
	}
 
	return &mMainContext;
}

There is only one object so far that I have found doesn't share between contexts, and that is a Vertex Array Object (VAO).

For now I'm just making my code think the extension isn't present when multithreading is enabled, but I need to come up with a solution to generate the VAO for each thread it gets used on.