It is useful to be able to quickly and easily generate texture atlases from a number of source sprites to speed up development. A useful tool when developing using the XNA framework is the SpriteSheet Sample available on the XNA Creators Club website. One downside of this, however, is that you must still manually generate the XML file list by hand, which can be a pain if you have a lot of textures to place on the sprite sheet. Another is that it is XNA only

Because we also do development on the iPhone, it was useful to have a similar generator for that platform, as well as for the XNA framework, so we created a tool to easily generate the texture atlases for us. The packing code is based on the SpriteSheet Sample code, though the tool is written in plain .NET, so does not require the XNA framework to be installed (though it does require the .NET framework). The tool can produce a PNG file with the combined textures, as well as an accompanying binary file, called a TXA file, with the information on each of the packed textures. It also supports removing transparent borders from textures to produce a more compact output. It can also optionally produce a C style header with enums in, so you don’t have to look up the textures by their names.

The help files for the texture atlas generator tool contain information on the format of the TXA files, so you can write your own loaders if you wish.

As well as the PNG + TXA combination, the tool can produce an XNA XML file (and optionally a C# file with enums in) which can be imported into your Content project to build the sprite sheet during compile time. You do need to include the XNA projects in yours to access the Content Processor and runtime types. The runtime library also includes extensions to the SpriteBatch class, to make it easier to draw using the textures.

Finally, there is a runtime library to load the texture atlas on an iPhone. The iPhone code uses the PVRTexture class from Apple’s sample code, so you can convert the PNG to a PVR if you wish using Apple’s texturetool (though this can be problematic as the textures may ‘bleed’ into each other). The iPhone runtime library also requires zlib and libpng

Each zip contains a Readme.txt file containing license information and other tips. You’re pretty much free to do what you want with these things, use them however you see fit (commercial or non-commercial), but remember they are provided as-is, and we accept no responsibility for anything We’ve tried to tidy them up to make them usable by other people, but if you’ve got any problems or questions, post in the comments and we’ll try and help. There may be bugs in these, so let us know if you find any!

• Texture Atlas Generator
• XNA Runtime and Pipeline Libraries
• iPhone Runtime – Requires zlib and libpng

So, the problem is: Given a regular tile map, where each tile is either a square or a triangle taking up half of the square, generate sets of vertices which describe each ‘chunk’ of geometry in the map. E.g.:

The first method I tried was adapting this method, by representing each tile in a 2×2 way, like so:

Then performing the contour tracing algorithm in the link above, and removing every other point in the resulting list of points. At first it looked like this worked, but there were a couple of cases where a triangle was placed next to another triangle where the algorithm failed.

After thinking about it for a while, I came up with this method, which I’m pretty sure works, but if anyone can see any errors with it, please do let me know. I’ll give you the algorithm, then go through it in detail. The algorithm goes as follows:

Pick a start tile
    Add the start tile to the open list
    Remove the tile from the tile map
    Add each of the tile's vertices to the vertex list
    Add each of the tile's edges to the edge list
    While the open list is not empty
        CurrentTile = Tile at the end of the open list
        NextTile = Tile in the "forward" direction of the current tile
        If NextTile exists and shares a common edge with the current shape
            Add NextTile to the open list
            Remove NextTile from the tile map
            Add NextTile's vertices to the vertex list (without creating duplicates)
            Generate an edge list for NextTile
            Remove edges that overlap from the main edge list and the edge list for NextTile
            Add the remaining edges from NextTile to the main edge list
        Else
            Move on to the next "forward" direction for CurrentTile
            If "forward" direction for CurrentTile = initial "forward" direction
                Remove CurrentTile from the open list
 
Traverse the edge list and add the vertices that are used to the vertex list for your shape

So, what does that all mean? Well, lets go through it step by step:

Add the start tile to the open list

The easiest way to search for a start tile is to do a row by row search. Start at 0,0 and scan along the first row, then the second and so on until you find an occupied tile. This is your start tile. The open list is a list of tiles currently being looked at. The start tile will be the first tile in this list.

Remove the tile from the tile map

Removing the tile from the tile map means that the algorithm will no longer visit them. Obviously, if you need your tile map after running the algorithm, create a copy of it

Add each of the tile’s vertices to the vertex list

The vertex list stores each corner point that has been used by each tile. For the first tile, just add the world space corner points to the list.

Add each of the tile’s edges to the edge list

The edge list is an list of, you guessed it, edges! Each edge is a pair of indices into the vertex list. Note that edges should always be specified in the same winding order and should always start at the same corner. I.e. pick clockwise or counter-clockwise and use that for both the square and triangle tiles, like so:

Notice on the last triangle that we started at the top left (as there is no vertex in the bottom left, and this would be the next one round in our clockwise winding order).

While the open list is not empty

I.e. While we’re still examining tiles for our current shape.

CurrentTile = Tile at the end of the open list

Set the current tile to the last tile added to the open list

NextTile = Tile in the “forward” direction of the current tile

Each tile in the open list maintains the direction of the neighbour that it is currently examining. Each time a tile is added to the open list, its “forward” direction (i.e. the direction in which to examine) is set to “up”. I just use an integer here, with the range 0 – 3, representing up, right, down and left, in that order. When we’re on a tile, we examine the neighbour in the tile’s “forward” direction, and pursue that path as far as possible. The next time the algorithm comes back to a tile, it rotates to the next “forward” direction and tries that path, until all four directions have been exhausted.

If NextTile exists and shares a common edge with the current shape

If there is a neighbour in our current tile’s “forward” direction, then we check to see if the neighbour and the current tile share common edges. One way to do this is to generate a list of edges for NextTile using the current vertex list. Any edges which contain vertices in the current vertex list will use the same vertex indices as the existing edges, but in reverse order (due to each tile having the same winding order), like so:

In the above image, the shared edge is V2 -> V3 for the left tile, and V3 -> V2 for the right tile.

Add NextTile to the open list

Add NextTile to the end of the open list, initialising its “forward” direction to 0 (up)

Remove NextTile from the tile map

Remove NextTile from the tile map so it is not revisited by the algorithm (except for when it is returned to by the open list).

Add NextTile’s vertices to the vertex list (without creating duplicates)

Add each world space vertex for the tile to the vertex list, but don’t create duplicates for vertices that are already in the vertex list.

Generate an edge list for NextTile

Generate a list of edges (remember, each edge is a pair of indices into the vertex list), using vertices from the vertex list.

Remove edges that overlap from the main edge list and the edge list for NextTile

Remove any edges that overlap from both the edge list that was just generated for NextTile, and the main edge list. Remember, neighbouring tiles with overlapping edges will specify the indices of the overlapping edge in opposite order from each other. I.e. If a tile has an edge V2 -> V3, and the neighbouring tile has an edge that shares these vertices, the neighbouring tile’s edge will be V3 -> V2. This is due to the winding order, as shown above.

Add the remaining edges from NextTile to the main edge list

Any edges that do not overlap can now be added to the main edge list

Move on to the next “forward” direction for CurrentTile

When you reach here, it means there are no tiles to check in the current direction, so we should rotate to look in the next direction. If you’re storing your “forward” direction as an integer, simply increment it.

If “forward” direction for CurrentTile = initial “forward” direction

This is a check to see if we’ve exhausted each of the four directions. The initial “forward” direction will be 4 if you’re representing directions as an integer in the range 0 – 3. If the “forward” direction reaches 4, it means we have tested each direction (0 – 3) and we are done with this tile.

Remove CurrentTile from the open list

As we are done with this tile, we can remove it from the open list.

So, after we’ve generated our edge list, we now need to traverse it. Simply start at the first edge and follow the trial of edges around the shape until you reach the start vertex again. E.g.: First edge: V0 -> V1, so add V0 and V1 to your shape, then search for an edge that starts at V1. Next edge: V1 -> V4, so add V4 to your shape and search for an edge that starts at V4, and so on, until you reach V0 again. You’ve now got a list of vertices that represent your shape.

After this, two possible further steps are to optimize your final list of vertices (i.e. remove co-linear ones, so you are only left with the corner vertices), and remove any tiles which are inside your shape (unless you want to create shapes within shapes). Note, that the final step will only produce the outline shape of an object, so will not handle holes in closed objects. You may be able to handle holes in closed objects by recursively performing the last step and removing edges from the final edge list as you visit them, until the list is empty. This should give you multiple shapes, the first being the outer shape and the rest being the holes inside the shape, but I haven’t really looked in to this that much, so it may not work

Here’s a little animation of the algorithm. The grey edges are overlapping ones that have been removed.

Anyway, the problem is in the FBDialog.m file. There are a couple of lines that read:

UIWindow* window = [UIApplication sharedApplication].keyWindow;
if (!window) {
    window = [[UIApplication sharedApplication].windows objectAtIndex:0];
}
[window addSubview:self];

The problem comes when you try and show the Facebook dialog just after something other than the main window is the key window. This could happen if you’ve popped up a UIAlertView to ask if the user wants to publish to Facebook. The UIAlertView is the application’s key window and when you display your Facebook dialog, it adds itself as a subview of the UIAlertView (which is currently closing). So, your dialog will start to display, then when the UIAlertView finishes closing, it’ll disappear. The easy fix is to just change the FBDialog.m file so that it always uses the second line, and doesn’t try to use the keyWindow property:

UIWindow* window = [[UIApplication sharedApplication].windows objectAtIndex:0];
[window addSubview:self];

So, I’m guessing you have to set your release date way off into the future (because you have no idea how long it’s going to take Apple to approve your app), so that when it’s approved, you can bring it forward to the current date and it’ll be top of the new releases list. I’m going to be trying this with our next iPhone game, so I’ll keep you posted how it turns out. The one potential problem is that if Apple looks at the release date to determine when they’ll test your app, it might be a while before it gets tested.

Update: Apparently, from reading around, the release date will be listed as the earliest of (i) the date you set when submitting, and (ii) the date it is approved by Apple. So even if you set your availability date to some distant future date, then set it to something sensible when it’s released, it’ll be down in iTunes as the date it was approved. So I guess the moral of the story is this:

When submitting your app to the App Store, set the availability date to a month or two ahead (and remember to update it if you have to re-submit or if it takes Apple ages to approve it), so that it’s always ahead of the date it gets approved. Then, once it’s approved, set the release date to the date it was approved (so it actually appears on the App Store). You need to set it as soon as you receive the “Ready for sale” e-mail from apple, and remember to set the availability date to the date that Apple sent the e-mail (remember to take into account the time difference between you and Apple in Cupertino). E.g. If you receive the e-mail in the early hours of Tuesday morning, and you’re in the UK, then Apple will have sent the e-mail on Monday (their time), so your availability date should be Monday.

The first is using a custom font with a UILabel. Although you can set the font property of a UILabel, the only fonts you can create are system fonts. What you have to do is subclass the UILabel class and override the – (void)drawTextInRect:(CGRect)rect method with your own implementation.

First things first though, you need to load in your font. Note: With this method, you need to distribute the .ttf file with your app. Make sure this is ok in the font’s license.

// Get the path to our custom font and create a data provider.
NSString *fontPath = [[NSBundle mainBundle] pathForResource: @"FontFilename" ofType:@"ttf"];
CGDataProviderRef fontDataProvider = CGDataProviderCreateWithFilename([fontPath UTF8String]);
 
// Create the font with the data provider, then release the data provider.
 
// Note: s_CustomFont is a static variable, not an instance variable
// so that it can be shared between all instances of the custom font UILabel class
s_CustomFont = CGFontCreateWithDataProvider(fontDataProvider);
CGDataProviderRelease(fontDataProvider);

Now that you’ve got the font loaded in, you need to draw your text with it. Unfortunately, you can’t just set the font then call [super drawTextInRect: rect]. This is because there are actually two different methods of drawing fonts in Quartz. CGContextShowText displays a string of text using the currently selected font. You select the font using CGContextSelectFont, but this function is only capable of selecting a built in system font. The other option is to use CGContextShowGlyphs and CGContextSetFont. Notice that’s SetFont and not SelectFont.

The SelectFont / ShowText combination uses the name of the font to look up the font data and the glyph mapping table in the system. The glyph mapping table is used by the font renderering routines to match up glyphs from the font with characters in your string. There’s no way to programatically set the glyph mapping table, which is why there are the two methods of drawing text.

When using the SetFont / ShowGlyphs method, you need to manually convert the characters in your string to glyph indices in the font. Fortunately, this generally works out pretty easily, which we’ll see later.

Now that we have our font loaded in, we can write our custom drawTextInRect function. So, first thing’s first, you need to set the font to use:

CGContextSetFont(UIGraphicsGetCurrentContext(), s_CustomFont);
 
// We need to tell the system which font size to use too
float FontSize = 18; // 18-pt font size
CGContextSetFontSize(UIGraphicsGetCurrentContext(), FontSize);

Then we need to convert our string to glyph indices. Like I said before, this mostly works out quite easily. Usually, you just need to offset the character index by a “magic number”, and most of the time this number turns out to be -29:

// Convert the text to glyphs
int StringLength = [self.text length];
 
// Make sure you remember to free these after rendering
CGGlyph* Glyphs = malloc(sizeof(CGGlyph) * StringLength);
char* Chars = malloc(sizeof(char) * (StringLength + 1));
 
// Convert characters to glyph indices
[self.text getCString: Chars maxLength: (StringLength + 1) encoding: NSASCIIStringEncoding];
for(int CurrentChar = 0; CurrentChar < StringLength; ++CurrentChar)
{
    Glyphs[CurrentChar] = Chars[CurrentChar] - 29;
}

One thing to consider here is that any new line escape sequences will end up with some really high glyph index (as CGGlyph is just an unsigned short). But you have to handle new lines manually anyway, so it shouldn’t be too bad.

Finally, we can draw our text. You need to setup your text matrix and text position before drawing the text, like this:

// Set the text matrix, otherwise it draws upside down
CGAffineTransform TextMatrix = CGAffineTransformIdentity;
 
TextMatrix.d = -1;
CGContextSetTextMatrix(UIGraphicsGetCurrentContext(), TextMatrix);
 
// Set the text position - Remember, 0, 0 is the top left of the text's draw rectangle, not the screen
CGContextSetTextPosition(UIGraphicsGetCurrentContext(), 0, 0);

Note that CGContextSetTextPosition sets the same translation values that the translation component of the text matrix sets, so in the above case it’s obsolete. But when you start adding multi-line and alignment support, it’s cleaner to just set the text matrix once and then just use CGContextSetTextPosition to set the position.

Now just draw your glyphs:

CGContextShowGlyphs(UIGraphicsGetCurrentContext(), Glyphs, StringLength);

So there’s our basic custom font drawing routing. If I recall correctly, it’ll crash as soon as you have a newline in your string, because it tries to just use a glyph that isn’t there. What you have to do is, during renderering, scan along your glyphs until there is a new line, draw the glyphs up until the new line, then start again from just after the new line.

You can also implement alignment and word wrapping. To do this, you need to be able to measure the string, so here’s how you do that:

After a call to CGContextShowGlyphs, the current text position is updated and can be retrieved like this:

CGPoint EndPoint = CGContextGetTextPosition(UIGraphicsGetCurrentContext());

So EndPoint.x is the length of your string (assuming your initial text position was at 0, 0). You can prevent Quartz from actually doing any drawing while you’re measuring the string’s length by setting the text drawing mode to invisible:

CGContextSetTextDrawingMode(UIGraphicsGetCurrentContext(), kCGTextInvisible);

Remember to set your drawing mode and text position back to normal when you want to actually draw your text:

CGContextSetTextDrawingMode(UIGraphicsGetCurrentContext(), kCGTextFill);
 
// You can also set to the text colour to the UILabel's textColor property
CGContextSetFillColorWithColor(UIGraphicsGetCurrentContext(), self.textColor.CGColor);

Now that you have the text size, you can use the UILabel’s textAlignment property to determine how to align your text when you actually draw it. Word wrapping can be achieved using a standard word wrapping algorithm. Just keep drawing glyphs until EndPoint.x is greater than self.frame.size.width. Then you know you’ve exceeded the frame and need to word wrap. So then you can jump back to the previous word, reset the text position to 0, 0 and continue on. It’s best to store each line length during your measuring stage so that they can be used to align the text during drawing.

One problem I haven’t yet figured out is the height of a line. At the moment I’m just using FontSize * 1.2, which seems to work OK for the font I’ve tried this on. I’m sure there’s probably some better way to do it, but I haven’t looked into it too much.

You can use the measuring technique to automatically size the height of your custom UILabel, to prevent it from being clipped (seeing as how you can’t actually see your custom font in Interface Builder). I added a new function to my custom font label class to calculate the height of the word wrapped text. I then use the height to set the height of the frame. This does mean that I have to set the frame’s width, call the function then set the frame’s height to the returned value. It also means you have to make sure the graphics context is correctly set up during the heigh measuring function (which it probably won’t be if it’s called from outside the drawTextInRect function. The easiest way to do this is to create a temporary graphics context, like this:

CGSize ContextSize;
ContextSize.width = 480;
ContextSize.height = 320;
UIGraphicsBeginImageContext(ContextSize);
 
// Measure the string's height
 
.....
 
UIGraphicsEndImageContext();

So there you have it. That’s how I’ve got my custom font UILabels to be used.

The other awkward thing is a lot simpler. I didn’t realise how long that last one was going to be

The problem arises when you want to display a modal view controller straight after another one has been dismissed. It seems the best place to show the second one is in the viewDidDisappear function of the first UIViewController. However, calling presentModalViewController on the parent UIViewController from this function doesn’t work (nothing seems to happen). I’m guessing it’s because the modal view controller for the parent view controller is still pointing to the one that’s just disappeared, and that this gets cleaned up after viewDidDisappear is called, so any new modal view controller you set in viewDidDisappear is reset straight after the function returns (because the parent view controller is still in the process of cleaning up the first one). The solution is to use the performSelector function on the parent view controller with a delay of 0:

[self.parentViewController performSelector: @selector(myDisplayNextModalViewControllerFunction) withObject: nil afterDelay: 0];

The delay of 0 doesn’t mean that the selector is performed straight away. Because of the order of events in the run loop, the selector will be performed after the parent view controller has fully dismissed its modal view controller, so the next one will display fine.

Hope this helps