My job currently involves me teaching students the ways of DirectX. The current version of the class covers the fixed pipeline which is not the most useful for those going into game development. I’ve already started rewriting the class to focus on the programmable pipeline and shaders. The first day of this new class is pretty much complete and I’m creating the second day of shader class. The first day includes an introduction to shaders, loading, and applying constant variables. Also included are vertex transforms and vertex colors. The second day of shaders focuses on the different types of texture mapping as well as vertex animation. After the second day is complete there will be a final third day of shaders to include things I haven’t thought of yet.

Luckily, it’ll be a few weeks before the new topics are introduced.

More geeking out about iPhone game programming and textures. The version of the texture tool provided with the iPhone sdk outputs a compressed texture with absolutely no header information. The lack of header forces your code to know the details like width, height, bitdepth, and pixel format instead of it being nicely encapsulated in the file itself. This causes you to have to hardcode this data into your texture load calls and just makes for all around ugliness. I’ve since tossed out Apple’s version of the tool and started using the version that comes with the PowerVR sdk. While I have to do my conversions under Windows, it allows my code to be more generic in the way that it handles textures. I read in the first 52 bytes of the file to get all the information I need and then pass along the rest to OpenGL to drop into VRAM.

Here’s a small code snippet of what I’m now doing in my texture code.

struct PVR_Texture_Header
{
unsigned int dwHeaderSize;            /*!< size of the structure */
unsigned int dwHeight;                /*!< height of surface to be created */
unsigned int dwWidth;                /*!< width of input surface */
unsigned int dwMipMapCount;            /*!< number of mip-map levels requested */
unsigned int dwpfFlags;                /*!< pixel format flags */
unsigned int dwTextureDataSize;        /*!< Total size in bytes */
unsigned int dwBitCount;            /*!< number of bits per pixel  */
unsigned int dwRBitMask;            /*!< mask for red bit */
unsigned int dwGBitMask;            /*!< mask for green bits */
unsigned int dwBBitMask;            /*!< mask for blue bits */
unsigned int dwAlphaBitMask;        /*!< mask for alpha channel */
unsigned int dwPVR;                    /*!< magic number identifying pvr file */
unsigned int dwNumSurfs;            /*!< the number of surfaces present in the pvr */
} ;

NSData *fileContents = [[NSData dataWithContentsOfFile:[NSString stringWithUTF8String:filename]] retain];
if (fileContents == nil)
{
return false;
}

// pointer to the actual pvr image data, skip the header
char *pvrData = (char*)[fileContents bytes] + sizeof(PVR_Texture_Header);

// create the header and copy in the data from the file
memcpy(&textureInfo, [fileContents bytes], sizeof(PVR_Texture_Header));

The definition for the PVR_Texture_Header was found in the PowerVR SDK.

My first thought when planning to make a 2D game for the iPhone was to find a way to not re-invent the wheel. I did some web searching and came across the website for Cocos2D, a port of the library to the iPhone. Great, looks like just what I needed…well, not so much. After messing with the samples and starting to write some prototyping code I figured out a few things that concerned me not only about the library but texture handling in general.

Sprites with Cocos2D rely on the Texture2D class created by Apple to do their drawing as does the “game” code that Apple released at WWDC. It didn’t register at first that this would be a problem until I looked through the code to see how textures are handled. Non-compressed textures, like pngs, are first expanded to an equal power of two and dropped into a newly created texture in the correct swizzled format. Coming from a game development background, I knew that swizzling textures or doing any sort of conversion work at load or runtime is a waste so I turned my direction to the PVRCT format. This is the native texture format that can be essentially load and go. Using the new compressed texture format eliminated the conversion step but still required the power of two texture. Fine, not a problem, many sprites or frames are commonly dropped into a single texture anyway. Most video hardware require a power of two texture so this in itself didn’t surprise me, the requirement that it be an “equal” power of two though did. Meaning, a texture of 256×128 just isn’t possible. Turns out this is a limitation of the PowerVR MBX chipset (you can get the docs and SDK at the Imgtec.com website). Alright, I can work around this. Just drop multiple sprites into a single texture and move around the U,V coordinates to access the invididual images I need. This will eliminate the texture state change and speed up rendering anyway. Wait a second, Cocos2D doesn’t support this. They have a strict one texture to one sprite set up. This is the easiest way to get someone up and running quickly but is horribly inefficient when writing game code. The iPhone is very restrictive on the amount of memory available for an application.

So, In my haste to try and use existing technology I’ve discovered that I’m pretty much back at the beginning. I tossed out the Cocos2D library (it would have been more trouble than it was worth to change their code) and tossed out Apple’s Texture2D class and Apple’s version of the texture compression tool and started writing my own code. I wasted about three days exploring other options but it did give the opportunity to learn more about the hardware that I’m working on.

So far I now have the underlying texure handling and resource manager complete and am about halfway through the sprite code, all written in C++. Most of the code is platform agnostic with only bits and pieces requiring porting when converting to other platforms.

I’ll post more info as I continue my iPhone exploration.

I’m going to be participating in the Global Game Jam at FullSail here in Orlando at the end of the month. I’ve never been part of one of these events so I’m not quite sure what to expect. I’ve seen some really interesting projects come out of other Game Jam type events around the country so I’m definitely excited to be part of this.

More info can be found at http://www.globalgamejam.org/index.html