Triple Eh?

One nice thing that I used & abused in iOS was it’s ability to render an NSString to a bitmap. This was great for getting lovely anti-aliased text, correctly spaced at whatever res you needed, and – bar the variable setup – was hardly any code:

// *snip*
CGColorSpaceRef colourSpace   = CGColorSpaceCreateDeviceRGB();
CGContextRef    context       = CGBitmapContextCreate(pixeldata, width, height, 8, width * 4, colourSpace, kCGImageAlphaPremultipliedLast | kCGBitmapByteOrder32Big);  
CGColorSpaceRelease(colourSpace);
 
CGContextSetRGBFillColor( context, 1.0f, 1.0f, 1.0f,1.0f );
CGContextTranslateCTM( context, 0.0f, height );
CGContextScaleCTM( context, 1.0f, -1.0f );
 
UIGraphicsPushContext( context );
[cocoaString drawInRect:CGRectMake(0, 0, width, height) withFont:font lineBreakMode:UILineBreakModeWordWrap alignment:align];
UIGraphicsPopContext();
 
// glGenTexture, etc...

Even after getting my 1205th bitmap font writer together, I still wasn’t convinced that the results looked as good as a properly kerned font. So I had a poke about to see what was involved in getting CoreText to write to a CGBitmapContext, and if it was possible to bundle your own, custom .TTF file, into the application resources so you’re not reliant on the system installed fonts. And surprisingly, there’s very little on the web about how to do this.

Now, it turns out that CoreText is probably the hairiest framework that I’ve tried to use on OS X. Not surprisingly, I guess, but be prepared. It’s assuming a more intimate knowledge of OS X types than I actually had.

Anyway, the font bundling turned out to be easy. Add the .ttf file to your application’s resource copy step, as usual. Then use CTFontManagerCreateFontDescriptorsFromURL to get the file path for the font. You’ll have a Font Descriptor that you can then use to create your very own NSFont object, which is good to go.

The tricky bit (for me) was working out how to actually get a string into CoreText, in a format that it’ll then render out. Turns out that you want a fancy Attributed String from which a CoreText line is created. That’ll actually do all the drawing for you. And it’ll draw to any context, so CGBitmap ahoy!

Anyway, the code.

BTW, I’ve removed all the error checking for brevity:

// Get the font
NSURL            *url         = [NSURL fileURLWithPath:[NSString stringWithUTF8String:_Game_Interface->GetPathForResource("SolomonP.ttf").c_str()]];
NSArray          *descriptors = (NSArray *)CTFontManagerCreateFontDescriptorsFromURL((CFURLRef)url);
NSFontDescriptor *fontDesc    = [descriptors objectAtIndex:0];
NSFont           *font        = [NSFont fontWithDescriptor:fontDesc size:font_size];
 
// String & Attributes
CFStringRef textRef = (CFStringRef) [NSString stringWithUTF8String:string];
CGColorRef colour   = CGColorCreateGenericRGB(1.0f, 1.0f,1.0f, 1.0f);
CFStringRef keys[]  = { kCTFontAttributeName, kCTForegroundColorAttributeName };
CFTypeRef values[]  = { font, colour };	
 
 
CFDictionaryRef	attributes   = CFDictionaryCreate( kCFAllocatorDefault, (const void**)&keys, (const void**)&values, 2, NULL, NULL );
CFAttributedStringRef attStr = CFAttributedStringCreate( kCFAllocatorDefault, textRef, attributes );
CTLineRef line = CTLineCreateWithAttributedString( attStr );
 
// Find out how big the string is expected to be...
CGFloat ascent, descent, leading;
float expected_length = (float)CTLineGetTypographicBounds(line, &ascent, &descent, &leading);
CGFloat line_height   = ascent + descent + leading;
const size_t width    = ( expected_length + 1.0f );
const size_t height   = ( line_height + 1.0f );
 
// Bear in mind, this will be a NON power of two texture. Which has been fine on all the macs I've tested so far :D
void *pixeldata	      = calloc(width * height * 4, 1);
 
// Context to render into...
CGColorSpaceRef colourspace = CGColorSpaceCreateDeviceRGB();
CGContextRef    context	    = CGBitmapContextCreate( pixeldata, width, height, 8, width * 4, colourspace, kCGImageAlphaPremultipliedLast | kCGBitmapByteOrder32Big );
CGColorSpaceRelease(colourspace);
 
// Output the string to the context
CTLineDraw(line, context);
CGContextFlush(context);
CGColorRelease(colour);
 
// Now generate the GL texture...
GLuint name;
glGenTextures(1, &name);
// etc...

And there you go. A Non Power of Two, Premultiplied Alpha texture, with whatever abuse you want to throw at the player. The NPOT thing hasn’t been a problem on any of the Intel macs that I’ve tested it on, so far. Can’t vouch for any older hardware though…

Probably worth mentioning at this point that my use of a purposefully pixelated font means this looks worse than the bitmap font. Gngngngngng.

Ok, long time since the last post. Sorry. I’d been holding off as I planned to do some more work on the graphics, thinking that I’d have something shiny to post, but that didn’t happen.

Instead, I’ve been under the hood the last couple of weeks and:

• Added keyboard control, so I can play as I code without the need for a joypad
• Replaced all the dynamic allocation for the main game objects and sprites, with a cache system that Guy used for PigOut (Thanks Guy!)
• Replaced all the file loading that was dotted about, and integrated PHYSFS, so now all resources are loaded from a single, packed file
• Started to replace the old Debug HUD with a new one, that uses the proper render path and text writing code (don’t ask)

Nothing to see, but quite a lot of code changes to get this far. The packaged resource file and dynamic allocation being two things I’d never done, but always wanted to have a pop at, so I’m quite happy with those.

As a good little boy, I’m quite often referring to the Apple docs to find out how to do things, and for the most part this is an illuminating process. I very rarely have difficulty with their docs and I normally get enough information to do what I want, with the minimum of fuss. So, as a good little boy, I’d been using the DisplayLink process they outlined in the GLFullscreen example. And it’s been a royal pain in the ass.

I made some changes to the way I handle XML parsing, so I had a general class rather than bespoke pieces for each of the XML files I’m using for the game data – as part of the tile map for the level backgrounds – and this uncovered the mother of all threading issues, that ended up in the bowels of the display link callbacks. I spent a couple of nights looking into this, before bailing completely. Gaz suggested just using the fullscreen option that’s arrived with Lion, which means going back to an animation callback (similar to how I drove Ballzup). The benefit of this is a much simpler way of setting up the Mac application, and no nasty threads to think about for the DisplayLink stuff. And it works like a charm

The downside, Beat Arena is now Lion only, but by the time I finish the next version of the OS will be out, so I don’t think that’s a problem.

And while I was in there, I spent a few hours doing some more optimisation.

Because I do all the transforms for vertex data on the CPU, the update function in my Sprite class was as issue. It’s called a lot, and the first memory accesses for the arrays was super expensive, so I did a little reading and started aligning data, prefetching what I can to take advantage of the cache and optimising the matrix multiplications to remove all the zero cases. The results seem to be pretty good. I nearly halved the cost of that function, which in real terms, gives me a bunch more sprites on the old Air.

I’ve also removed one of the FBOs, and now do the feedback effect by attaching the textures to one FBO in turn. I didn’t realise that swapping FBOs was expensive until I read about it this afternoon, so that was a quick fix. There’s more to get out of this, as there’s one copy stage at the end that I can probably remove, just by ping-ponging the order of the textures each frame.

Unfortunately for Beat Arena, it’s game season, which means all the games I’ve been waiting all year to play are starting to come out. My evenings are going to be spent shooting and adventuring for the next couple of months…

Made some good progress on Beat Arena this week. Code-wise, the temporary spawn manager has been replaced and hooked up to the playlist, so I can now spawn any number of baddies at given points in the track. Simple change, but it’s instantly made it feel more like a game; I now have waves of enemies spawning in and attacking, rather than the constant dribble from before.

I’ve also had a quick try out of my idea for the art and setting for the game, and I think it might work. I’m going to stick to something I know about (and can take the piss out of), so you’re going to take up the role of an intrepid bedroom DJ. I’ve got a couple of very bad jokes in mind for the intro and some ideas for bad guys & behaviours that made me smirk. Enough to get on with, at least until I change my mind in 12 months time.

So the last few nights have been spent pixeling up the player character. I’ve ended up going for a 16bit look as it’s the only thing I can draw. Cliched, given it’s the only thing me and every other bastard on the planet can draw, but there you go. It might not stay that way. Depends how bad my graphics look.

Next week’s mission: Getting my new sprites animated…

Small update this week. I’ve finally locked the player into the arena and processed collisions with the enemies, meaning you can die

More exciting, for me at least; I’ve finally thought of something that hooks the game to the music. Or at least, gives me a location and an art style that I can follow.

I’ve been unsure what to base the graphics around since I started the game, given the self imposed limitation of using 2D sprites, so I’m happy that I’ve finally got a direction to try out. If it works, I’ll have ticked the two main boxes for the look of the game: Don’t look like Geometry Wars and avoid a black background.

Code’s still the priority atm, though.

Rightly or wrongly I’ve decided that my Macbook air will be the minimum spec for my game. I reckon this is safe for a couple of reasons:

1. My Air doesn’t have a particularly fast CPU, although the GPU isn’t too shabby considering.
2. It’ll take me two years to actually finish anything, so Moore’s law will totally save me, not to mention Apple keep on cranking out the nice hardware, so people will upgrade.

Which is a pretty solid plan if you ask me, except for the fact that I’ve been able to drop frames on my Air without really trying.

So I had a little chat with one of the Super Brains at work – he’s also working on a bit of homebrew so we’ve been encouraging each other with the odd sneaky demo of our progress at work – the upshot of which was a couple of ideas to help speed things up: Timeslicing and Threading.

My thread-fu is a bit weak, my only experience being an attempt at debugging some shit old CGI code, long before I got into games, so I thought I’d have a pop at time slicing the particles. That sounded like a nice, easy change.

My first attempt was just to balance the particles into a couple of batches, process one half each frame, and render them. And as expected, this looked shit… Dirty fucking 30hz, man. So I binned that and tried capping the amount of time that I spent processing particles – doing as many as I could in the time, then carrying on where I left off during the previous frame, until I looped around or I could process everything in a one-er. This was a bit better, but not as nice as 60hz, possibly because I didn’t spend very much time on it (couple of hours all in, for both attempts).

But my particles were nicely segregated into their own process lists and everything already had separate Sprite adds because of the FBO use. Time to roll out the threads, then.

On my Mac Pro this one change gave me nearly 6 times as many particles per frame. On my Macbook Air, just shy of 3 times as many. Happy happy

So tonight it was time for the Physics. I kinda roughly had it in my head that I’d need to thread this when I started out, so I was careful to keep a total distinction between the actual physical objects and the game objects that had them. The only slight muddying of this were two lines of code where the physics object also set the game object’s sprite position and rotation during it’s update as it was a waste of a function call. Easy enough to split out into a synchronise function, which was basically all that I needed to do.

The main game loop is now, roughly, this:

1. Kick off the particle update thread
2. Kick off the synchronise thread
3. Poll input and do general house work for the frame
4. Block for synchronise then kick off the physics world update thread
5. Wait for the particle update to return then render all these to the feedback FBO
7. Add the FBO, HUD and Synchronised sprites to the render buffer for the screen
8. Wait for the physics to return then kick off the game object update thread, as this’ll be applying all the forces to the physics objects for the next frame
9. Add the player and render the finished screen
10. Do all my debug hud stuff
11. Wait for the update thread to finish

I don’t think that’s necessarily as groovy as it could be, but for now it’ll do. The Air is only dual core and performance is LOADS better. I can still drop frames on it if I’m pushing it, but it’s well past the point where I think the number of objects will be an issue. The point being, these fuckers will kill you, so you don’t want 400 of them on screen.

I still might override new and delete for all the game objects for an extra little squirt, and I know I will have to cap the number of particles and bullets to something reasonable, just in case. But the Air’s pushing 1000s of them now, which looks suitably mental.

And I can always time slice the baddie updates…

I did a bit of tinkering during my flight to the ‘States last week so thought I’d take a quick screenie. (Click to for the full size jobbie)

I decided that the cream background colour was too bright. I still don’t want to go to a really dark screen as it feels a little ‘me too’, considering nearly every twin stick shooter seems to opt for this, so I’ve tried to keep a semblance of the pastels in there. This also has the added bonus that I can do a smidge more additive blending without things going on a whitey straight away.

The tank for the player sprite was a quick bodge that I’ve just thrown in. I was bored of the circular thing… But tbh, I’m tempted to leave little tank tracks as you move about, Swiv style-e, which would probably cement it.

Not much more to report atm as I’m mainly playing with Pig Out levels, but I’ll try and do a bit of a tidy up over the weekend and post a vid…