So I wrote a quick word wrap template class today that will do this. It doesn't give line spacing yet, which I'm still unsure whether or not it should be this.

The way it works is when you create the word wrap object, you can pass to it's constructor a value for the maximum width a line can be, this can be a floating point value, or an integer (it defaults to integer).

Then you call Parse() and give it a string, it will go through that string, checking the width of characters until the accumulated character widths are greater than the maximum width, or a new line is found. It will output this line of characters and move onto the next bit.

If it finds a word that is longer than maximum width, it will do one of two things. First if it is at the start of a newline, it will cut the word at the point it goes over. If it is already part way into a line, it will cause a new line and put the word on the next line.

I've included with this blog entry the header for the word wrap class, it comes as part of a test project in Xcode (it uses the Lorem Ipsum text), but the source and headers should work in another C++ IDE.

One format is the bezier curve, a curve made from four points. Two fo the points are the start and end position, and the other two are control points that describe how it should curve.

Since all three axis can be animated, I made it possible to make a 3-component vector bezier class using the bezier class I created, and just calculate the point coefficients once, passing them to the bezier class to get the position. This of course only works if the time length for curves are the same on all three axis.

I've made a sample, it is an Xcode project that uses GLUT to render a 2D bezier and a 3D bezier. The code should work with other IDEs. One thing I should warn is that this bezier class only works when the time step is constant between the control point and it's respective point.

P0 (0, 0) ... keypoint 0
P1 (2, 10) ... keypoint 1
C0 (0.666667, 42.6212) ... control point 0
C1 (1.33333, 10) ... control point 1

T0 = (C0 - P0) -> (2, 42.6212)
T1 = (P1 - C1) -> (2, 0)

The above sample is from the COLLADA forum, as you can see the time step is 2 for both T0 and T1. The same post describes how to calculate the S0 if your time step is not constant.

So a few days ago I started with the Wiimote, I had planned to try to the PS3 controller but I didn't have one, so borrowing one of my housemates Wiimotes I set to work.

There is quite a lot of documentation on the Wiimote at the moment, whether it is the correct way to do things is questionable, since there are cases like "1? - it is set to 1 by the Wii" and "set this to 0x55 at memory address X and set to 0x00 at memory address Y to enable it".

I started with website called The Wiimote Project, but as their documentation grew scarce I found a better site (which it seemed to copy it all from anyways) called WiiBrew. The WiiBrew wiki is quite comprehensive and within a few minutes I already had the LEDs flashing.

I won't go into a lot of detail, I'll just show the basics that I've got to grips with from the documentation on WiiBrew - LEDs + Motor, Buttons, and Battery.

Connecting the Wiimote

Connecting the Wiimote to a Mac is far simpler than it is for XBox 360, for a start its a Bluetooth device that operates using the normal protocols and it doesn't require a key to activate. To connect, first turn on Bluetooth on your Mac, and then select "Set up Bluetooth Device...".

Follow on the onscreen instructions, and when it gets to the point where it is searching for nearby Bluetooth devices, press 1 + 2 to soft synchronize if the Wiimote isn't bound to another device, or the sync button to hard synchronize (unbinds the Wiimote from anything it remembers).

When it appears, select it and click the "Passkey Options..." button. Select the "Do not use a passkey with this device" option and then OK. Continue on and the device will be setup and connected. You can't actually tell since the LEDs are still blinking, but if you have done it correctly, the Bluetooth icon should be different, or the menu will have a disconnect option for the device just setup.

One annoyance I had was with getting rumbling working on the XBox 360 pad, eventually after essentially pinging all messages, I found and worked out the format for the rumble message, which was annoyingly nothing like the others listed.

Well after that I got kinda bored with the 360 and decided to turn towards another console controller, the Wiimote. And I thought I'd write my own driver.

Long story short, when I was having trouble getting my driver working, I looked at the code for the driver for Tattiebogle's XBox 360 pad driver, only to find out that it has redefined the rumble message to it's own format, namely the 4 byte one, only to forward on the settings to the 360 pad.

Well I'm glad I figured out why the message was different, kinda annoying that wasn't in his FAQ. Hopefully others will find this post and go "ohhhhhhhh" like I did when seeing the code.

As for the Wiimote, writing a driver for a Bluetooth device I've decided doesn't make sense, the device is already designed to communicate with another bluetooth device, so I made a class instead, using a Bluetooth API and documentation I found on WiiBrew.

I'll hopefully post my Xcode project for testing the 360 pad in a few days. And I'll probably write up my Wiimote stuff once I get it working the way I want. I'm really tempted to buy lots of cheap USB and Bluetooth devices on eBay now just to see if I can write drivers for them.

I had no trouble with getting the LEDs flashing, but for some reason the rumble actuators just would not respond to my message with success.

I had searched at all other documentation on the pad on the internet, but although I found two variations of rumbling, neither worked.

It has taken my a week or two, but then I got the inspiration to just fire all possible messages to the pad, nullified apart from the header, and see responds with success. So I wrote some code to send 255 different type ids, with 255 different lengths.

Source code

//
//
void HIDInput::TestDevice( IOHIDDeviceRef inDeviceRef )
{
	unsigned char reportData[255];
 
	// Nullify Report
	memset( reportData, 0, sizeof( unsigned char ) * 255 );
 
	// Loop through most possible messages
	for( unsigned char reportType = 0; reportType < 255; ++reportType )
	{
		for( unsigned char reportLength = 0; reportLength < 255; ++reportLength )
		{
			// Setup Header
			reportData[0] = reportType;
			reportData[1] = reportLength;
 
			// Send Report to Pad
			if( DeviceSendReport( inDeviceRef, reportType, reportData, reportLength ) )
			{
				printf( "Success - Type(%u), Length(%u)\n", reportType, reportLength );
			}
			else
			{
				printf( "Failed - Type(%u), Length(%u)\n", reportType, reportLength );
			}
		}
	}
 
	//
	printf( "Finished\n" );
}

I'll explain show the function body for DeviceSendReport in a minute. After running this, only two reports returned with success, one was the LED report, and the other was of Type 0 with length 4.

Since the header take two bytes, I guessed the last two must be Actuator A and Actuator B. And after setting one of them to 0xff, I successfully managed to get one of the actuators rumbling, and then the other actuator with the other byte.

Now for the code for sending reports to the pad.

Source code

//
//
bool HIDInput::DeviceSendReport( IOHIDDeviceRef inDeviceRef, const unsigned char inType, const unsigned char * inReportData, const unsigned char inReportSize )
{
	return IOHIDDeviceSetReport( inDeviceRef, kIOHIDReportTypeOutput, inType, inReportData, inReportSize ) == kIOReturnSuccess;
}

As you can see it takes a parameter called inDeviceRef, this is the value that was passed to DeviceMatchingCallback in the previous entry. And now here is the code to get the LED flashing, there are a few status values for it, so I've created an enum with some comments explaining what each do.

Source code

//
//
enum LEDStatus
{
	kLED_AllOff = 0x00, // All LEDs are turned off
	kLED_AllBlink = 0x01, // All LEDs repeatedly blink on and off
	kLED_P1_FlashOn = 0x02, // Player 1 LED flashes then stays on
	kLED_P2_FlashOn = 0x03, // Player 2 LED flashes then stays on
	kLED_P3_FlashOn = 0x04, // Player 3 LED flashes then stays on
	kLED_P4_FlashOn = 0x05, // Player 4 LED flashes then stays on
	kLED_P1_On = 0x06, // Player 1 LED turns on
	kLED_P2_On = 0x07, // Player 2 LED turns on
	kLED_P3_On = 0x08, // Player 3 LED turns on
	kLED_P4_On = 0x09, // Player 4 LED turns on
	kLED_Rotating = 0x0a, // LEDs flash on in sequence
	kLED_CurrentBlink = 0x0b, // Currently active LED blinks
	kLED_SlowBlink = 0x0c, // All LEDs blink slowly
	kLED_Alternating = 0x0d, // Player 1 & 4 alternate blink with Player 2 & 3
};
 
//
//
void HIDInput::FlashLED( IOHIDDeviceRef inDeviceRef, const LEDStatus inStatus )
{
	//
	const unsigned char kReportType = 0x01;
	const unsigned char kReportSize = 0x03;
	const unsigned char kReportData[kReportSize] =
	{
		kReportType, kReportSize, static_cast<Core::byte>( inStatus )
	};
 
	//
	DeviceSendReport( inDeviceRef, kReportType, kReportData, kReportSize );
}

As you can see, it is fairly simple to send a message, all you have to remember is that the first two bytes contain a header (one byte for type, and one type for the size of the report including the header size). And finally for rumbling the motors.

Source code

//
//
void HIDInput::SetRumble( IOHIDDeviceRef inDeviceRef, const unsigned char inBigSpeed, const unsigned char inLittleSpeed )
{
	//
	const unsigned char kReportType = 0x00;
	const unsigned char kReportSize = 0x04;
	const unsigned char kReportData[kReportSize] =
	{
		kReportType, kReportSize, inBigSpeed, inLittleSpeed
	};
 
	//
	DeviceSendReport( inDeviceRef, kReportType, kReportData, kReportSize );
}

I had some minor problems with the rumble not changing after the first call to SetRumble originally, however it turned out that I had just accidently set the report data variable to be static, so the initialisation was only setup with the first values passed.

Other Rumble Reports

As I mentioned before, I've found other message formats for rumbling the motors, I don't know if its a version thing, or something, but here are the other two I've found if you have trouble with mine.

Version 1 (Tattiebogle)

Source code

//
//
void HIDInput::SetRumble( IOHIDDeviceRef inDeviceRef, const unsigned char inBigSpeed, const unsigned char inLittleSpeed )
{
	//
	const unsigned char kReportType = 0x00;
	const unsigned char kReportSize = 0x08;
	const unsigned char kReportData[kReportSize] =
	{
		kReportType, kReportSize, 0x00, inBigSpeed, inLittleSpeed, 0x00, 0x00, 0x00
	};
 
	//
	DeviceSendReport( inDeviceRef, kReportType, kReportData, kReportSize );
}

Version 2 (http://euc.jp/periphs/xbox-controller.ja.html)

Source code

//
//
void HIDInput::SetRumble( IOHIDDeviceRef inDeviceRef, const unsigned char inBigSpeed, const unsigned char inLittleSpeed )
{
	//
	const unsigned char kReportType = 0x00;
	const unsigned char kReportSize = 0x06;
	const unsigned char kReportData[kReportSize] =
	{
		kReportType, kReportSize, 0x00, inBigSpeed, 0x00, inLittleSpeed
	};
 
	//
	DeviceSendReport( inDeviceRef, kReportType, kReportData, kReportSize );
}

As usual, my Courage game played host to testing this new method of control.

First of all, the XBox 360 pad uses a 0xff device class (Vendor specific), so normal HID drivers (they use a device class of 0x03) will not attach to it, so I needed to download a driver for MacOSX that could handle this. Also I didn't have a Microsoft Wireless Gaming Receiver so I bought a wired pad instead.

I tried the Tattiebogle driver, and at first it worked, but after I logged into VMWare Fusion and used by pad in Vista it stopped working on MacOSX. Or it could have been that I got the Wacom Bamboo pad installed recently.

So after a bit of searching I found another driver, which although didn't work, sparked Tattiebogle's to life. This one is known as XBox HID Driver for Mac OS X.

Once it was all up and running, getting code to listen for the 360 pad was a breeze, and Apple has a nice section on your website for it Technical Note TN2187: New HID Manager APIs for Mac OS X version 10. I'll summarise the basics needed to connect to the pad.

None of this code cleans up properly, like I said I only just started with the HID manager, so I'll probably post an example App at some point that does clean up properly when shutting down.

Setting up HID Manager

The following code is quite straight forward, it just sets up two callbacks, one for when a device matches what we are looking for, and one for when a device is removed.

The IOKit.framework is required.

I also have two global variables, one for the HID manager, and another the device we going to be reading (this code can only do one device since we only have one buffer variable).

Source code

//
//
#include <IOKit/hid/IOHIDLib.h>
#include <IOKit/hid/IOHIDUsageTables.h>
 
//
//
namespace HIDInput
{
	//
	void DeviceMatchingCallback( void * inContext, IOReturn inResult, void * inSender, IOHIDDeviceRef inIOHIDDeviceRef );
	void DeviceRemovalCallback( void * inContext, IOReturn inResult, void * inSender, IOHIDDeviceRef inIOHIDDeviceRef );
	void DeviceIOHIDReportCallback( void * inContext, IOReturn inResult, void * inSender, IOHIDReportType inType, uint32_t inReportID, uint8_t * inReport, CFIndex inReportLength );
	Boolean Device_GetLongProperty( IOHIDDeviceRef inDeviceRef, CFStringRef inKey, long * outValue );
	long Device_GetVendorID( IOHIDDeviceRef inIOHIDDeviceRef );
	long Device_GetProductID( IOHIDDeviceRef inIOHIDDeviceRef );
 
	//
	IOHIDManagerRef l_IOHIDManagerRef;
	uint8_t * l_pReportBuf = 0;
}
 
//
//
int main( int argc, char * argv[] )
{
	// Create a HID manager with a default allocator
	l_IOHIDManagerRef = IOHIDManagerCreate( kCFAllocatorDefault, kIOHIDOptionsTypeNone );
	assert( IOHIDManagerRef );
 
	// Look for all device and open the manager
	IOHIDManagerSetDeviceMatching( l_IOHIDManagerRef, NULL );
	IOHIDManagerOpen( l_IOHIDManagerRef, kIOHIDOptionsTypeNone );
 
	// Register Callbacks to be run with application loop
	IOHIDManagerRegisterDeviceMatchingCallback( l_IOHIDManagerRef, HIDInput::DeviceMatchingCallback, NULL );
	IOHIDManagerRegisterDeviceRemovalCallback( l_IOHIDManagerRef, HIDInput::DeviceRemovalCallback, NULL );
	IOHIDManagerScheduleWithRunLoop( l_IOHIDManagerRef, CFRunLoopGetCurrent(), kCFRunLoopDefaultMode );
 
	//
	while( true )
	{
		// loop application
	}
 
	return 0;
}

The call to IOHIDManagerSetDeviceMatching() can have a dictionary passed to it to look only for devices matching certain criteria, but for simplicity, I'll just be checking all devices in this example, so I passed NULL as a second argument.

Checking for XBox360 Pad

With the code setup for calling back when a device is found that matches (or all devices in our case), we now need to check the device vendor id and product id to be sure they are what we are looking for.

Source code

//
//
Boolean HIDInput::Device_GetLongProperty( IOHIDDeviceRef inDeviceRef, CFStringRef inKey, long * outValue )
{
	CFTypeRef tCFTypeRef = IOHIDDeviceGetProperty( inDeviceRef, inKey );
	Boolean result = FALSE;
 
	if( tCFTypeRef )
	{
		// If this is a number get its value
		if( CFNumberGetTypeID( ) == CFGetTypeID( tCFTypeRef ) )
		{
			result = CFNumberGetValue( ( CFNumberRef ) tCFTypeRef, kCFNumberSInt32Type, outValue );
		}
	}
 
	return result;
}
 
//
//
long HIDInput::Device_GetVendorID( IOHIDDeviceRef inIOHIDDeviceRef )
{
	long result = 0;
	Device_GetLongProperty( inIOHIDDeviceRef, CFSTR( kIOHIDVendorIDKey ), &result );
	return result;
}
 
//
//
long HIDInput::Device_GetProductID( IOHIDDeviceRef inIOHIDDeviceRef )
{
	long result = 0;
	Device_GetLongProperty( inIOHIDDeviceRef, CFSTR( kIOHIDProductIDKey ), &result );
	return result;
}
 
//
//
void HIDInput::DeviceMatchingCallback( void * inContext, IOReturn inResult, void * inSender, IOHIDDeviceRef inIOHIDDeviceRef )
{
	if( !inIOHIDDeviceRef )
	{
		return;
	}
 
	const long kVendor_Microsoft = 0x045e;
	const long kProduct_XBox360Pad = 0x028e;
 
	const long kVendorID = Device_GetVendorID( inIOHIDDeviceRef );
	const long kProductID = Device_GetProductID( inIOHIDDeviceRef );
 
	if( kVendorID == kVendor_Microsoft && kProductID == kProduct_XBox360Pad )
	{
		// Assert if we're trying to create a second XBox 360 pad device
		assert( l_pReportBuf );
 
		// Get the size of the report for the device and allocate a buffer. The
		// report size property should be right, however the packet header
		// seems to want 20 bytes, so I'm allocating 20 bytes to be safe.
		CFIndex reportSize = 20;
		//IOHIDDevice_GetLongProperty( inIOHIDDeviceRef, CFSTR( kIOHIDMaxInputReportSizeKey ), &reportSize );
		l_pReportBuf = static_cast<uint8_t *>( malloc( reportSize ) );
 
		// Register a report callback for this device
		IOHIDDeviceRegisterInputReportCallback( inIOHIDDeviceRef, l_pReportBuf, reportSize, DeviceIOHIDReportCallback, 0 );
 
		printf( "XBox Pad Connected.\n" );
	}
}
 
//
//
void HIDInput::DeviceRemovalCallback( void * inContext, IOReturn inResult, void * inSender, IOHIDDeviceRef inIOHIDDeviceRef )
{
	// Deallocate report buffer
	free( l_pReportBuf );
	l_pReportBuf = 0;
 
	//
	printf( "XBox Pad Disconnected.\n" );
}

We have two constants in the device matching callback, one that is the vendor id for Microsoft, and the other which is the product id for the XBox 360 pad.

Since this code only supports the one pad, I've added an assert which will be triggered if a second pad is attempted to be matched that is a 360 pad (it checks to see if the report buffer has already been allocated).

Once a device has been removed, I free the memory for the report buffer. I think I'm suppose to unregister the input report callback by passing null as the callback, but I'm not 100% sure yet.

All the other helper functions were found on the Apple website technical note.

Reading Pad Status

XBox 360 pad updates come through on a report type of 0x00 and are 14 bytes long (though I have read on other sites of people getting reports of 20 bytes, this just seems to be padding).

I have skipped the checking of the report type in this code, but it should probably be checked, as well as the report length.

Source code

//
//
void HIDInput::DeviceIOHIDReportCallback( void * inContext, IOReturn inResult, void * inSender, IOHIDReportType inType, uint32_t inReportID, uint8_t * inReport, CFIndex inReportLength )
{
	// Output hex for each byte in the report (always 2 characters long, making up the rest with 0)
	for( int i = 0; inReportLength; ++i )
	{
		printf( "%02x", inReport[i] );
	}
 
	//
	printf( "\n" );
}

That sourcecode allows you to read just the actual reports being sent from the pad, however if you want to be able to use it as a 360 pad. You'll get a message something like this...

0014000000002efcc70792ff9a06

The 0014 at the beginning is a packet header, first byte being the command, second being the size of the packet. The other sections are split up as follows...

0014aaaabbccddddeeeeffffgggg

a is an unsigned short of button flags

b is an unsigned char representing the left trigger (LT)

c is an unsigned char representing the right trigger (RT)

d is a signed short representing the Left Axis X

e is a signed short representing the Left Axis Y

f is a signed short representing the Right Axis X

g is a signed short representing the Right Axis Y

This can be put into a function like so...

Source code

//
//
void HIDInput::DeviceIOHIDReportCallback( void * inContext, IOReturn inResult, void * inSender, IOHIDReportType inType, uint32_t inReportID, uint8_t * inReport, CFIndex inReportLength )
{
	unsigned char leftTrigger, rightTrigger;
	short rightAxisX, rightAxisY;
	short leftAxisX, leftAxisY;
	unsigned short buttonFlags;
 
	// Copy bytes to their respective variables (incase they are not aligned correctly)
	memcpy( &buttonFlags, &inReport[2], sizeof( unsigned short ) );
	memcpy( &leftTrigger, &inReport[4], sizeof( unsigned char ) );
	memcpy( &rightTrigger, &inReport[5], sizeof( unsigned char ) );
	memcpy( &leftAxisX, &inReport[6], sizeof( short ) );
	memcpy( &leftAxisY, &inReport[8], sizeof( short ) );
	memcpy( &rightAxisX, &inReport[10], sizeof( short ) );
	memcpy( &rightAxisY, &inReport[12], sizeof( short ) );
 
	// Output pad stats
	printf( "Buttons %u\n", buttonFlags );
	printf( "LTrigger: %u\n", leftTrigger );
	printf( "RTrigger: %u\n", rightTrigger );
	printf( "LAxis: %d, %d\n", leftAxisX, leftAxisY );
	printf( "RAxis: %d, %d\n", rightAxisX, rightAxisY );
	printf("\n");
}

I don't know what the 2048 button flag is, it is possibly the synchronization button that is on the wireless controller. So here is a list of all the other button flags and their bit number.

Source code

//
//
enum XBox360_ButtonFlags
{
	XBOX360PAD_DPAD_UP = 1,
	XBOX360PAD_DPAD_DOWN = 2,
	XBOX360PAD_DPAD_LEFT = 4,
	XBOX360PAD_DPAD_RIGHT = 8,
	XBOX360PAD_START = 16,
	XBOX360PAD_BACK = 32,
	XBOX360PAD_LAXIS = 64,
	XBOX360PAD_RAXIS = 128,
	XBOX360PAD_LB = 256,
	XBOX360PAD_RB = 512,
	XBOX360PAD_XBOX = 1024,
	XBOX360PAD_A = 4096,
	XBOX360PAD_B = 8192,
	XBOX360PAD_X = 16384,
	XBOX360PAD_Y = 32768,
};

There is still a lot more to cover, so I'll probably make a follow up entry tomorrow or the day after for sending messages to the pad to make it vibrate, and how to clean up after you're finished properly. As well as post an example application.

I also found a few new variables to add to my list of debugging preprocessor. I'll explain on the next page since this one is getting rather long.

The wiki article also mentions something else that I didn't take into considering, and that is transparent objects, since there would be more than one lighting equation needed.

On the whole though, I'm glad I got a chance to implement it, one more thing I know how to do.

But the great thing is, depending on how many objects are in your scene, and how much overdraw can happen, this method is faster (I think, I don't know the cost of writing to a second colour attachment).

Colour Shader

The colour shader is just a basic shader I've setup to show. First of all the vertex shader...

Source code

//
// Varying Variables
varying vec3 Normal;
 
//
// Vertex Shader entry point
void main()
{
	Normal = normalize( gl_NormalMatrix * gl_Normal );
	gl_Position = ftransform();
}

As you can see this is just a basic vertex shader, transforming a vertex position into screen space and passing the normal onto the fragment shader through a varying variable type.

Now the fragment shader...

Source code

//
// Varying Variables
varying vec3 Normal;
 
//
// Fragment Shader entry point
void main()
{
	vec3 N = normalize( Normal );
	float kDrawLit = 1.0;
	gl_FragData[0] = vec4( 1.0, 0.0, 0.0, 1.0 );
	gl_FragData[1] = vec4( N, kDrawLit );
}

This is a typical fragment shader as well, using draw buffer zero for the unlit texel colour. However, I've normalised the interpolated normal that was calculated for this texel and I'm outputting it to draw buffer one, along with another value 'kDrawLit'.

When the w component of draw buffer 1 for this texel is set to 0.0, the texel will not have any lighting calculations performed on it in the post process. I came up with this when I started thinking about rendering a HUD before the post processing.

I've chose just to output red as a colour, anything is fine, such as a texture that is mapped to the object in question.

Per-Pixel Lighting Shader

Again, another simple vertex shader, passing a transformed vertex and texture coordinate to the fragment shader...

Source code

//
// Varying Variables
varying vec3 v_lightDir;
varying vec3 v_halfVec;
 
//
// Vertex Shader entry point
void main()
{
	//
	v_lightDir = normalize( gl_LightSource[0].position.xyz );
	v_halfVec = normalize( gl_LightSource[0].halfVector.xyz );
 
	//
	gl_TexCoord[0].xy = gl_MultiTexCoord0.xy;
	gl_Position = gl_Vertex;
}

Now for where the magic happens, the fragment shader, it uses two textures. The 'baseImage' sampler is for the colour buffer, whilst the 'nrmImage' is used for the normal texture we wrote...

Source code

//
// Uniform Variables
uniform sampler2D baseImage;
uniform sampler2D nrmImage;
 
//
// Varying Variables
varying vec3 v_lightDir;
varying vec3 v_halfVec;
 
//
// Fragment Shader entry point
void main()
{
	// Get texel colour and normal data
	vec4 kTexelColour = texture2D( baseImage, gl_TexCoord[0].xy );
	vec4 kNormalColour = texture2D( nrmImage, gl_TexCoord[0].xy );
 
	// Don't Perform Lighting on a non-lit texel
	if( kNormalColour.w == 0.0 )
	{
		gl_FragData[0] = kTexelColour;
		return;
	}
 
	// Calculate Ambient
	vec4 kAmbient = gl_LightSource[0].ambient * kTexelColour;
 
	// Process Light Direction and Normals
	float NdotL = max( dot( kNormalColour.xyz, v_lightDir ), 0.0 );
	vec4 kColour = kAmbient;
 
	// Add Diffuse and Specular is NdotL is greater than zero
	if( NdotL > 0.0 )
	{
		// Calculate Diffuse
		vec4 kDiffuse = ( 1.0 - kAmbient ) * ( gl_LightSource[0].diffuse * kTexelColour );
		vec4 kSpecular = gl_LightSource[0].specular;
		float kShininess = 60.0;
 
		float NdotHV = max( dot( kNormalColour.xyz, v_halfVec ), 0.0 );
		kColour += kDiffuse * NdotL;
		kColour += kSpecular * pow( NdotHV, kShininess );
	}
 
	// Write Pixel Colour
	gl_FragData[0] = kColour;
}

As you can see, if the w component of the normal texture is 0.0 then the colour value is outputted as it is. If not, using the normal and the light currently setup, the colour is modified to be lit before being outputted.

I've just used a simple Blinn shader for calculating the lighting.

The Application

Now for the application side of things, below is just some quick sample code for what I used for my example. As you can see I've used a unsigned byte to store the normal, a floating point texture may have better accuracy at describing it though.

Source code

//
//
namespace CommonApp
{
	enum TextureTypes
	{
		kColour,
		kNormal,
		kDepthStencil,
		kNumTextureTypes,
	};
 
	//
	const int kWidth = 800;
	const int kHeight = 600;
 
	//
	GLuint l_frameBuffer;
	GLuint l_textures[kNumTextureTypes];
 
	//
	GLuint l_colourProgram;
	GLuint l_lightingProgram;
}
 
//
// Use alternate INTERNAL_FORMAT if floating point textures are not supported
//#define INTERNAL_FORMAT GL_RGBA
#define INTERNAL_FORMAT GL_RGBA32F_ARB
 
//
//
void CommonApp::Init()
{
	// Code to load colouring shader program
	// ...
 
	// Code to load lighting shader program and setup uniform variables
	// ...
 
	// Generate Textures
	glGenTextures( kNumTextureTypes, l_textures );
 
	// Create Colour Texture
	glBindTexture( GL_TEXTURE_2D, l_textures[kColour] );
	glTexImage2D( GL_TEXTURE_2D, 0, INTERNAL_FORMAT, kWidth, kHeight, 0, GL_RGBA, GL_FLOAT, 0 );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
 
	// Create Normal Texture
	glBindTexture( GL_TEXTURE_2D, l_textures[kNormal] );
	glTexImage2D( GL_TEXTURE_2D, 0, INTERNAL_FORMAT, kWidth, kHeight, 0, GL_RGBA, GL_FLOAT, 0 );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
 
	// Create Depth Buffer
	glBindTexture( GL_TEXTURE_2D, l_textures[kDepthStencil] );
	glTexImage2D( GL_TEXTURE_2D, 0, GL_DEPTH24_STENCIL8_EXT, kWidth, kHeight, 0, GL_DEPTH_STENCIL_EXT, GL_UNSIGNED_INT_24_8_EXT, 0 );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
	glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
 
	// Generate Framebuffer and attach textures
	glGenFramebuffersEXT( 1, &l_frameBuffer );
	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, l_frameBuffer );
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, l_textures[kColour], 0 );
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT, GL_TEXTURE_2D, l_textures[kNormal], 0 );
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, l_textures[kDepthStencil], 0 );
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_STENCIL_ATTACHMENT_EXT, GL_TEXTURE_2D, l_textures[kDepthStencil], 0 );
}
 
//
//
void CommonApp::DeInit()
{
	glDeleteFramebuffersEXT( 1, &l_frameBuffer );
	glDeleteTextures( kNumTextureTypes, l_textures );
}

Just the usual code as you can see for setting up a frame buffer. Now for rendering the scene...

Source code

//
//
void CommonApp::Render()
{
	// Use Frame Buffer
	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, l_frameBuffer );
 
	// Set Draw Buffers
	const GLenum kBuffers[] = { GL_COLOR_ATTACHMENT0_EXT, GL_COLOR_ATTACHMENT1_EXT };
	glDrawBuffers( 2, kBuffers );
 
	// Use Shading Program
	glUseProgram( l_colourProgram );
 
	// Perform Rendering
	// ...
 
	// Reset Draw Buffer
	glDrawBuffer( GL_COLOR_ATTACHMENT0_EXT );
 
	// Reset Frame Buffer
	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 );
}

I've set it up so that drawing to draw buffer zero writes to the colour texture, whilst drawing to draw buffer one writes to the normal texture, to reflect what is being done in the shader.

You don't need to use the colour shader I described up above, as long as it writes out the normal and an unlit colour, any shader can be used for this process, but for demonstration I've made it in this example that all geometry is drawn with this shader program.

Finally with our scene rendered, we can moved onto the final post processing stage...

Source code

//
//
void CommonApp::PostRender()
{
	glActiveTexture( GL_TEXTURE0 );
	glBindTexture( GL_TEXTURE_2D, l_textures[kColour] );
 
	glActiveTexture( GL_TEXTURE1 );
	glBindTexture( GL_TEXTURE_2D, l_textures[kNormal] );
 
	glUseProgram( l_lightingProgram );
 
	// Render Fullscreen Quad
	// ...
}

Attaching the colour and normal texture, using the per pixel lighting shader program and drawing a quad. The images within this blog are the final result (showing a comparison would be useless since they look the same).

One downside to this is that all texels have to use the same shininess value, however the alpha value of the colour buffer could be used to control this.

It is only a start, I need to performance check it at some point to see if it gives better or worse performance and under what conditions.

Download Source: Per Pixel Lighting (MacOSX)

The glReadPixels() function with GL_DEPTH_COMPONENT was working, but I was having no luck at getting it displaying at any colour other than white without converting it first before writing it to a texture with glDrawPixels() - on reflection a floating point texture might have made this easier.

Anyways, when looking for answers, I found a way of using frame buffer objects to write out to multiple colour buffers, which allowed me to modify my Blinn shader to render a scene and the depth buffer to texture at the same time.

First of all, the shader needs to be shaders, instead of gl_FragColor, we use gl_FragData[n], where n is the index of the colour buffer we want to write to.

Source code

//
// Varying Variables
varying float v_farPlane;
varying float v_nearPlane;
 
//
// Fragment Shader entry point
void main()
{
	// Write Pixel Colour
	//gl_FragColor = vec4( 1.0, 0.0, 0.0, 1.0 );
	gl_FragData[0] = vec4( 1.0, 0.0, 0.0, 1.0 );
 
	// Write Depth
	float kDepth = 1.0 - ( gl_FragCoord.z / gl_FragCoord.w ) / ( v_farPlane - v_nearPlane );
	gl_FragData[1] = vec4( kDepth, kDepth, kDepth, 1.0 ); // Luminace style
}

And finally when binding your frame buffer object.

Source code

//
//
void RenderTarget::Setup()
{
	// Create Frame Buffer
	glGenBuffers( 1, &m_frameBuffer );
 
	// Bind Frame Buffer
	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, m_frameBuffer );
 
	// Attach texture to receive colour
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, m_colorTexture, 0 );
 
	// Attach Texture to receive depth buffer
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT, GL_TEXTURE_2D, m_depthTexture, 0 );
 
	// Attach Depth and Stencil Buffer (same object since my gfx card doesn't support them being separate)
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, m_stencilDepthBuffer, 0 );
	glFramebufferTexture2DEXT( GL_FRAMEBUFFER_EXT, GL_STENCIL_ATTACHMENT_EXT, GL_TEXTURE_2D, m_stencilDepthBuffer, 0 );
}
 
//
//
void RenderTarget::StartRender()
{
	// Bind Frame Buffer
	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, m_frameBuffer );
 
	// Set which index draws to which colour attachment
	const GLenum kBuffers[] = { GL_COLOR_ATTACHMENT0_EXT, GL_COLOR_ATTACHMENT1_EXT };
	glDrawBuffers( 2, kBuffers );
}

The call to glDrawBuffers() sets where gl_FragData[x] is being wrote to, I've specified there are two indexes, the first one points to colour attachment 0, and the second points to colour attachment 1.

Now when an object is rendered using that shader, it will output the normal colour buffer to colour attachment 0, and output the depth buffer to colour attachment 1.

Also, don't forget to reset the draw buffer destination after you're finished with it.

Source code

//
//
void RenderTarget::EndRender()
{
	// Reset draw buffer destination
	glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
 
	// Unbind frame buffer and all attachments
	glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, 0 );
}

I will probably remove the glBindFramebufferEXT() call to unbind the frame buffer at some point, so that the same frame buffer gets used for all render targets, only the attachments get changed.

I've read it is faster this way. For more information on this, there is this great article on GameDev.net about it called, OpenGL Frame Buffer Object 201.

I probably won't use this for writing out the depth buffer, but it did give me some ideas for per pixel lighting.

I just upgraded to the latest version of gDEBugger, and it kept notifying me that a lot of my code is using deprecated functions as of OpenGL 3.0.

So I have begun the long task of converting code and shaders alike, hopefully in a positive step since it will mean my DirectX 10 port of the Athena engine will have little modifications to work like the OpenGL and vice versa.

These functions are the first on my list, they are used for rendering my geometry.

glTexCoordPointer()

glColorPointer()

glNormalPointer()

glVertexPointer()

These have been replaced with glVertexAttribPointer(), a more useful system so you can specify custom attributes a vertex has, and link them to attribute variables in shaders (shaders are required now for everything like DirectX 10). So for a simple array of vertices, I linked them to attribute variable in my shader which was bound to location 0.

Source code

//
// Bind VBO Object
glBindBuffer( GL_ARRAY_BUFFER, m_vertexBuffer );
 
//
// Enable vertex attribute streaming on location 0
glEnableVertexAttribArray( 0 /* location */ );
 
//
// Set attribute offset, size, and type details for location 0
glVertexAttribPointer(	0, /* location */
			4, /* components */
			GL_FLOAT, /* type */
			GL_FALSE, /* normalize */
			sizeof( float ) * 4, /* stride */
			0 ); /* buffer offset */

I found out shortly after however that the index I was using for my vertex attribute is a reserved index by nVidia for their built-in attributes, as are 12 others.

0 - gl_Vertex
2 - gl_Normal
3 - gl_Color
4 - gl_SecondaryColor
5 - gl_FogCoord
8 - gl_MultiTexCoord0
9 - gl_MultiTexCoord1
10 - gl_MultiTexCoord2
11 - gl_MultiTexCoord3
12 - gl_MultiTexCoord4
13 - gl_MultiTexCoord5
14 - gl_MultiTexCoord6
15 - gl_MultiTexCoord7

So in the interest of keeping things sane I changed the location index to be 16, all that was needed was updating my shaders to use attributes rather than gl_Position, etc.

Source code

//
// Vertex Attributes
attribute vec4 a_vertex;
attribute vec2 a_texCoord0;
 
//
// Vertex Shader Entry Point
void main()
{
	//gl_TexCoord[0].xy = gl_MultiTexCoord0.xy;
	gl_TexCoord[0].xy = a_texCoord0;
 
	//gl_Position = gl_Vertex;
	gl_Position = a_vertex;
}

You may have noticed that I don't multiply my vertex by any transformation matrices, this is because my vertex coordinates for 2D are always in the range of -1.0 to 1.0. Doing it this way saves me changing projection matrix states whenever I want to draw 2D, so my projection matrix is always setup for 3D. Also, the source for this vertex shader program contains another attribute for the texture coordinate as well since I just copy-pasta'd my Bloom shader.

Now just two simple calls were needed to be added to my  shader program before it was linked, so that the vertex attribute is bound to the correct location.

Source code

glBindAttribLocation( m_program, 16 /* location */, "a_vertex" );
glBindAttribLocation( m_program, 17 /* location */, "a_texCoord0" );
glLinkProgram( m_program );

As you can see my vertex shader has a texture coordinate as well (I'm using my Bloom vertex shader as an example), so the final code for setting up the VBO for this is.

Source code

//
// VBO layout
struct TexturedVertex
{
	float texCoord[2];
	float position[4];
};
 
//
// Bind VBO Object
glBindBuffer( GL_ARRAY_BUFFER, myVBO );
 
//
// Enable vertex attribute streaming on location 0
glEnableVertexAttribArray( 16 );
glEnableVertexAttribArray( 17 );
 
//
// Set attribute offset, size, and type details for location 0
glVertexAttribPointer( 17, 2, GL_FLOAT, GL_FALSE, sizeof( TexturedVertex ), 0 );
glVertexAttribPointer( 16, 4, GL_FLOAT, GL_FALSE, sizeof( TexturedVertex ), sizeof( float ) * 2 );

I'm sure there is a preprocessor command to get the offset of a variable within a structure, but "sizeof( float ) * 2" works as well. My code is a bit more complex than is shown here (I have a vertex format class that manages what needs to be set where, and something to managed state changes et cetera), but you get the idea of how it all works.

Well that was one big change down, on the next page of this blog entry will be another big change, replacing glMatrixMode() and glLoadMatrix().