Oh and before I forget – it has been a while since I’ve posted, after all. But, can you say “I told you so?”

1. Visible from outside
2. Already announced

I have to say, I was much more excited about going to GDC. I still am enough of a kid to get excited at the prospect of flying on a plane. I mean, how couldn’t you? You get to eat some weird food on a tray, people will rub swabs all over you to have a machine tell you that you smell of explosives, and you get to be put in extremely close proximity to someone who you don’t know and almost certainly won’t like for hours and hours. This particular trip does have some bonuses, however – as it’s not just for education but is actually “work”, I get to fly premium enonomy (the games industry hasn’t been able to afford business class since the GFC), something which I have been pining for since work first sent me to the US. From the almost reasonable legroom to the Champagne (well, sparkling wine – it’s not first class after all) you get when you board. You know, they actually even know your name.

But, I am getting waaay ahead of myself. The story starts in the gate lounge of Melbourne Airport. I had only an hour and a half ago hugged my partner goodbye (she was asleep, any more than that is probably illegal), and already I had begun to notice an almost unreasonable number of Apple Macbooks. Actually, any number of Macbooks is unreasonable – it’s a depressing reminder of just how gullible we are as a species. Not to mention that everyone with a Macbook (at least, at that time), had a certain… well, look about them. Maybe we could describe it as some form of ur-hipster. All of them had obviously spent at least an hour and a half on their hair and probably would describe themselves as “bi-curious”. After a while, one of them said to another group (I wonder what the collective noun for Mac users is? I’ll go with “bromance”) of them: “are you guys going to WWDC too?” The question dripped with – well, something that should never have gone past passport control. I sensed a general rumbling while everyone turned to the speaker, at which point, the entire bromance replied in the affirmative. One of the ringleaders quipped “you can always spot a cocoa developer!” Yes. Yes you can.

It hasn’t been premium all the way (I did have to mix with the proletariat, quel horreur as David Gaider would say) – and in my quest to discover the best airline (and to avoid Los Angeles airport, which is possibly the only major transit hub owned and operated by Satan himself), I’ve gone the roundabout route of going via New zealand. Via Air New Zealand, in fact. To be honest, I was expecting better (Singapore Airlines is still the king), but it’s at least better than Qantas, where they actively seek to harm you during your flight. I’ll be writing up some delicious reviews in the future, as I think they firmly sit in the “hate” section of my blog title. But that is for another time. Now, it is time for me to crash in this rather nice hotel, and steel myself for the coming week.

"Dragon Age Women". GIS even returned a Maxim shot. Saucy.

• bethany dragon age 2
• what should pulled pork look like
• i bought dragon age when it came out they ripped me off
• dragon age women
• dragon age sister
• 80286 memory addresses

Amazing.

Google image search can be quite unexpected sometimes.

Programmers!

Who needs them anyway? Well, it turns out that we in the games industry can sometimes find a use for them. One of my duties (perhaps surprisingly, especially to those who have met me) is to interview prospective games programmers and cast off any aspersions they have to the job.

In my experience, applicants tend to come in one of the following flavours:

• computer science students (making up about 90%) can’t program their way out of a singly-linked cardboard box. They have just graduated university (or sometimes, inexplicably, have been working as a programmer for several years). They have once heard of the term “algorithm”, and almost all of them have come out of a Computer Science course with obscene marks (furthering my belief that CS courses in uni are taught predominantly by lunatics);
• software engineers, people for whom boost and the STL are the second coming of Jesus, people who seriously believe that someone has a use for a hash_multidequeue. They are mercifully rare and generally don’t last long because the games industry doesn’t fit their ideas of a well run system;
• finally, we have the dungeon masters, people who dissolve caramel sweets into orange juice – while lecturing their senior programmers about the length of the integer ALU on the Motorola 68060, and how we should really be “thinking more about pipelining”. While the first group of applicants invariably becomes a group that doesn’t understand how much better other programmers are, this group becomes the set which doesn’t understand how much worse they personally are. Obviously I am part of this group.

Occasionally, you get a hire-able person from of any of the three above, or, even more rarely, you find someone actually worth their salt (yes, we still pay people with salt in the games industry, times are hard). However, I am not here to talk about any of them – that was one of my tangents. I am here to talk about the people who read Gamedev or Gamasutra, and believe everything in it – to the point where they repeat tired old maxims that have been perpetuated by the generation of programmers that refuses to use C++ because “all that OO stuff makes it slow”.

So, we lurch inexorably towards the point of this post. Virtual functions. I have told all of my team to get over it and use them where it makes sense (which is often quite a common occurrence), but I keep hearing people in interviews telling me that virtual functions are slow. So, like the scientist I am, I decided to find out once and for all what the deal truly is.

Let’s get down to business: why are virtual functions slow? Apart from the obvious “they aren’t”, theoretically they are slow because instead of the compiler emitting something like this:

mov ecx, object_address
call some_address

The compiler has to generate code to find out what function to call:

mov ecx, object_address
mov eax, [ecx]
mov eax, [eax + vtable_index]
call eax

The instructions themselves are not particularly expensive, the “slow” part (at least, according to received knowledge) is the potential cache miss caused by locating the real function address from the vtable (stored in the first few bytes of the object). Now, back in the days of the 486, this could be a problem – the extra size of the vtable, the slowness of memory access and the small CPU cache added up to a measurable performance impact. But what about now? My phone has about 100x the power of the first PC I ever owned (and I’m not including the ancient BBC Micro I inherited) – surely things have changed.

So, I constructed a test, I made a base class, a derived class, and two functions – one virtual, one not. The functions do some trivial maths on an argument and access a member variable (we have to do some actual work or the optimizer will simply remove the whole thing). The functions all follow this pattern:

int Test(int i)
{
    return m_Test * (i - 1);
}

I am using MSVC 2010 in stock release mode (minus link-time code generation, you’ll see why eventually). The functions are being timed by the high performance counter (RDTSC with multicore fixes via QueryPerformanceCounter) and the operation is being run 10,000,000 times. Here are the results:

• Virtual function: 0.063s
• Normal function: 0.018s

Holy balls! The virtual function is 3x slower! Because it’s impossible for me to be wrong, I looked at the generated assembly code to find out what was really going on.

// Virtual function
mov	edx, DWORD PTR [edi]
mov	eax, DWORD PTR [edx]
push	esi
mov	ecx, edi
call	eax

// Normal function
add	DWORD PTR _value$[ebp], eax
add	DWORD PTR $T68661[ebp], edx
add	DWORD PTR $T68662[ebp], esi
add	DWORD PTR $T68663[ebp], edi
add	edx, ecx
add	eax, ecx
add	esi, ecx
add	edi, ecx

While the first bit of code looks is a function call, the second one has been inlined to buggery. Inlining is an optimization method which basically copies and pastes the function body into the caller’s assembly, avoiding the (apparently costly) assembly call operation and the function prologue and epilogue (which usually consists of a few stack push and pop instructions).

I modified the code to add a control function call (the Win32 API call GetTickCount), and a non-virtual call to a function which was defined in another module (rather than just the header). By putting code in another module, we’re denying the compiler the opportunity to inline the code (at least, when link-time code generation is turned off). I’ve left the virtual function in the header, because it is clearly not being inlined. These were the results:

Suddenly, the gap has changed to a mere 20%. Still significant, but a lot better than 70%. But… there’s more. In this case, the function is being called via a member variable of the testing function’s class. The virtual method call is, as far as I am concerned, not strictly required – the type of the object is concrete at the calling site, but the optimizer doesn’t appear to realize this. However, things change if we call the method through a local variable rather than a member variable. The optimizer, recognizing that the type is known, inlines the function – somehow making it even faster than the normal inlined function at 0.005s (3x faster than the normal inlined function). The asm is totally different (no idea why, optimizers are unpredictable), which explains the discrepancy.

As is often the problem with benchmarks, they don’t represent real world situation. Recognizing this, I’ve changed the function payload (and the control) to look more like a real function rather than a getter, making them like this:

int Test(int i)
{
    return m_Test * (i - 1) * GetTickCount();
}

So, how does this fare?

What a surprise. Suddenly the whole virtual/nonvirtual thing gets blown out of the water. It turns out, unsurprisingly, that when you have a function that actually does work (or, for example, calls another function), the virtual call overhead just melts away into the background. I admit, virtual calls cost slightly more than nonvirtual calls, especially if the function itself is very cheap. But more importantly, inlining is really awesome and the compiler should do it all the time; and unfortunately, the optimizer isn’t that great at recognizing when a type is concrete.

There are a few extra considerations about inlining. First, LTCG isn’t a silver bullet. My non-inlined function didn’t get inlined when I turned on link-time code generation, until I moved the definition into the same module as the call site. Second, library calls defined in headers and .lib files don’t get inlined properly – infact, the only function that seemed to be inlined when I moved the definitions to a static library was the concrete virtual one (which makes no sense, especially since the library didn’t even export the other functions).

But it doesn’t end there! What about C#? It’s always been my belief that C# is what happens when someone who actually has a vague idea of what they’re doing decides to write a programming language. Remembering one of the oddities of C# (that all method calls are compiled down to the MSIL instruction callvirt) I repeated the tests, expecting it to do pretty well. It turns out that the JIT optimizer, while formidable, is even less effective at recognizing concrete types – all virtual functions were called through a vcall, even for locally defined objects. Interestingly, if the function is not marked virtual (or it is a struct member), the JIT compiler will inline it. And it will do an amazing job, too – it can inline any method from any class – even one in a different DLL!

Time for a verdict: virtual calls are marginally slower than nonvirtual calls, but any real performance difference probably comes from inlining rather than the virtual call overhead. Conclusion: get over it and stop mentioning it in interviews. Alright, I’ll put in a caveat – x86 (and x64) are both very forgiving architectures, and vcalls cost more on more rubbish platforms – but, they’re necessary constructs for well designed code, and you can take them from my cold, dead hands.

Where can you find a vague sense of dissatisfaction, three hours less life than you started with, and a whole two weeks of implied raping, for the low, low price of $7? In retrospect, there are actually quite a few answers to that question, although the correct one is the Dragon Age: Origins DLC, Leliana’s Song.  It’s set a few years before the events of DA: O, and chronicles Leliana’s fall from grace – the role of an Orlesian “bard” (criminal), her mentor’s betrayal, and her subsequent induction into (or should I say, “indoctrination by”) the Chantry.

Assume the role of Leliana, a young bard involved in a criminal ring that deals in political secrets. Accompanying her mentor Marjolaine on a high-risk mission, Leliana soon finds herself entangled in a game of intrigue that she cannot escape with just her beauty, charm, or stealth. The only way out of this game is to kill or be killed.

If this were DA2, those pumpkins would be ~animu-styled~ and on fire.

The story “opens” with you performing minor acts of vandalism and violence for your mentor, Marjolaine, in the market district of Denerim. Knocking out and humiliating a captain of the City Watch, bashing up a nobleman, stealing from a few merchants, etc. It was a little slow paced and slightly underwhelming – like a Neverwinter Nights community module. It did, however, have some goals beyond “kill this person”; it even had a small amount of actual writing.

I have to say, this was the best part of the module – it even looked like it had a branching “plot” (insomuch as there was a plot at all). As part of your brief, you’re meant to cause trouble, such as planting stolen goods on unconscious noblemen and making it look like one of your targets is an apostate. There are lots of possible combinations, but, sadly, after an hour of experimenting, I can save everyone the effort and tell you that there is only one option which does anything – to place every single incriminating item on the captain of the watch.

You see, this kind of half-assery is what infests DLC as a whole. The last real expansion of note for an RPG was the sublime Shivering Isles for Oblivion. Which was released, wait for it, four years ago. DLC is a plague on gaming in much the same way as consoles, and the newly christened wankery of casual gamers. After all, they disabled friendly fire from Dragon Age 2 for the console “gamers” (I use the term loosely), but they removed the option for friendly fire from the UI just in case it confused the casual player mouthbreathers (seriously, Bioware were concerned they might accidentally turn it on and smash their Xbox in a fit).

This is the kind of party I wish I were invited to. The kind with murder.

Anyway, the plot continues with a break in (to a castle map recycled from DA: O), another break in (to the same map – you wouldn’t want to blow the budget), a predictable betrayal followed by a harrowing suggestion that your protagonist spent 2 weeks chained in a dungeon “satisfying the guards” (complete with disturbing imagery). The last half an hour of the module allows you to escape, take out bloody revenge on your mentor and captor, and finish it off with a short detour into religion-induced insanity (don’t get too excited, it’s just a disembodied voice and a trip to a church).

I wanted to like this, I really did. Compared to the Darkspawn Chronicles, Leliana’s Song is like a perfectly pitched epic fantasy adventure. Unfortunately, so too is a baked potato. It suffers from the usual problems with DLC; bad pacing, no real investment in the characters, and the unmistakable  stench of “afterthought-ness”. It was quite strange to play, actually – it felt disturbingly similar to the innumerable, interchangeable NWN modules from 2003. Nothing really stood out as being good or particularly bad, it just started, happened, and ended. To be honest, the dungeon scene was probably the highlight of the whole thing because I at least remember it clearly.

Bioware may be making money hand over fist with stuff like this, but seriously, they need to try a lot harder if they want to keep their real fans.

We will look at a very trivial fixed size allocator – a bitmap allocator – and, following that (in the next post), we will look at a more flexible system.

2.1 Bitmap Allocator

A bitmap allocator is a trivial memory allocator algorithm, which, at its core, uses a structure called a bitmap to provide the book-keeping information. Fundamentally, a bitmap allocator has two regions of memory (that may be part of the same contiguous block), a management region – the bitmap – and the arena, a catch-all term for “usable memory”. The two regions are related by a mapping (or magnification) factor – each discrete element in the bitmap (often a single bit, hence the term), maps to some number of bytes in the arena. The bitmap itself is a contiguous array of these elements, which is like a scaled down version of the arena, only instead of storing the user data, it simply stores whether each section of the arena is used or not.

Key features:

• Book-keeping and user memory are separate, which protects against the internal memory manager state being corrupted;
• Allocation and deletion only requires that entries in the bitmap be marked as being used or free;
• Smallest allocation size is one page;
• Arena cannot be resized (without a large amount of work);
• Very few calls to the underlying operating system – once to set up the arena, once to set up the management area (these may be stored in contiguous memory if required);
• Trivial implementation has expensive allocation, cheap freeing.

Structure

The bitmap allocator is extremely simple to implement. It needs to maintain a pointer to the bitmap, as well as a pointer to the arena. In the simplest design, it needs only two more fields – the number of blocks it owns, and the size of each block. For simplicity, we will be using a bitmap where each element is of size unsigned char. The bitmap must contain slightly more information than used and free, we will need an additional state for boundary, a state indicating that it is the start of an allocated block.

Initialization

Initialization is very simple; it requires calculating the number of blocks given a specified arena size and factor, allocating the two regions, and setting all the entries in the bitmap to free. Our memory system will sit on top of the CRT malloc function.

BitmapAllocator::BitmapAllocator(int factor, int arenasize)
{
	// Calculate the number of blocks for a given arena size and allocate
	// We will round down when determining the number of blocks
	m_Factor = factor;
	m_Blocks = (arenasize / m_Factor);

	assert(m_Blocks > 0);

	m_Arena = malloc(m_Blocks * m_Factor);
	m_Bitmap = (unsigned char*)malloc(m_Blocks);

	// Set all blocks to free
	for (int i = 0; i < m_Blocks; i++)
	{
		m_Bitmap[i] = FreeBlock;
	}
}

The code above is, for the sake of simplicity, missing any form of sanity checks for the arena/factor size, but some things to remember:

• Smaller factor sizes mean additional book-keeping (unusable memory). E.g., a factor of 4 means for each 4 bytes of usable memory, a byte of memory must be dedicated to book-keeping.
• Larger factor sizes mean more wasted memory.
• It is sensible to require that the factor size is a power of two, or a multiple of a power of two. In order to ensure happy calling code, it is good to assume that any memory request over 16 bytes should be aligned to a 16 byte address; something that can be done by requiring that the factor is a multiple of 16.

Shutdown

Shutdown is a trivial matter of freeing the two memory blocks we have requested from the CRT.

Allocation

To allocate a block, we must:

1. Calculate the number of blocks required (rounding up)
2. Iterate over the bitmap, looking for a series of (at least the requested amount of) contiguous free blocks (in this case, using a linear probe like a naive string search)
3. Translate the bitmap address into an arena address
4. Mark the blocks we have allocated as used in the bitmap, marking the first block as a boundary block

void* BitmapAllocator::Allocate(unsigned int size)
{
	if (size == 0)
	{
		// See note
		return NULL;
	}

	// Calculate the number of blocks required (rounding up)
	unsigned int requiredblocks = size / m_Factor + ((size % m_Factor) > 0 ? 1 : 0);

	// Linear probe
	unsigned int location = 0;
	while (location <= m_Blocks - requiredblocks)
	{
		// Count the number of available blocks
		unsigned int available = 0;
		for (unsigned int i = 0; i < requiredblocks; i++)
		{
			if (m_Bitmap[i + location] != FreeBlock)
				break;
			available++;
		}

		if (available == requiredblocks)
		{
			void* pointer = (unsigned char*)m_Arena + m_Factor * location;

			// Mark the blocks as used
			m_Bitmap[location++] = BoundaryBlock;
			for (int i = 1; i < requiredblocks; i++)
				m_Bitmap[location++] = UsedBlock;
			return pointer;
		}
		else
			location = location + available + 1;
	}

	// Allocation failed, return NULL
	return NULL;
}

The see note part of the code above is because, strictly speaking, the standard requires that a zero byte allocation returns a unique memory address. In this case, we will flaunt the standard and simply return null.

Freeing

Freeing memory in a bitmap allocator is also very simple, we must:

1. Check for a null pointer
2. Convert a non-null pointer to a block entry
3. Begin marking blocks as free, the first block should be a boundary block.
4. Iterate forwards over the blocks in the bitmap until another boundary block is encountered, then stop.

void BitmapAllocator::Free(void* pointer)
{
	if (pointer == NULL)
		return;

	// Convert pointer to block index
	unsigned int arenaptr = (unsigned int)((unsigned char*)pointer - (unsigned char*)m_Arena);
	unsigned int block = arenaptr / m_Factor;

	// Check for validity
	assert(block < m_Blocks);

	// Ensure this is the start of the allocation
	assert(arenaptr % m_Factor == 0);
	assert(m_Bitmap[block] == BoundaryBlock);

	// Mark blocks as free
	m_Bitmap[block++] = FreeBlock;
	while (block < m_Blocks && m_Bitmap[block] == UsedBlock)
	{
		m_Bitmap[block++] = FreeBlock;
	}
}

2.2 Where to now?

The bitmap allocator is an incredibly simple allocator. It has very little state information, and is the simplest form of allocator to implement. It is very fast at releasing memory, and a more serious version of the algorithm can speed up the allocation code enormously (using, for example, a free list, or by storing information about contiguous free counts in the bitmap). Unfortunately, it requires a large block of book-keeping memory to function, which remains constant. In addition, by its very design, it is inherently wasteful for small allocations (given that the size of an allocation is always a multiple of the block factor).

Nevertheless, in about 100 lines of code, we have come up with a workable memory manager. It doesn’t support resizing of the arena, and it doesn’t provide a particularly usable or scalable system for an actual application, but, it is a good contrast to the next allocator we will look at; which has a very different design. Once we have covered these two designs, we will look at more advanced algorithms to improve them, working towards a fully featured memory system.

This is, according to Google Image Search, a picture of PROGRAMMING.

Welcome to my first post in a series about memory management in C++ (specifically, in games). In this, I will discuss how memory allocation works, why custom allocators are used in many programs, and what goals a custom allocator should fulfill.

In the course of this series, I hope to cover several designs of allocators, show some benchmarks, and explain the pitfalls of writing your own allocation system from start to finish. There is a lot to cover, and I’m going to be assuming a reasonable level of C++ competency.

Ready to dive in?

1.1 Memory Primer

For the sake of completeness, we will start with a quick primer on how memory allocations actually work. Most people should know that memory on their computer is vaguely determined by the amount of RAM – random access memory – that they have. RAM is only one part of a fairly complicated system that manages and maintains the memory used by applications on a computer.

At the highest layer, the layer seen by your application, the whole of the address space (which we will call the wilderness) is apparently empty, save for objects on the stack, such as local variables, and memory allocated to objects in the executable, such as the actual machine code as well as any compile-time constants. Your application can request additional memory from the operating system, which, if able to provide it, will return a pointer to an area that was previously part of the wilderness. This allocated memory can then be used by the application. If the application attempts to use memory that it does not own, the application will receive an access violation (or, if you’re a crazy Unix person, a segmentation fault).

That this system works in that way is an advance we owe to the original Intel 80286 (although it was vastly improved and made workable in the 386), and it is called protected mode. Protected mode is a hardware-supported system of disallowing individual programs from being aware of other running processes (at least, not without using specific interprocess APIs). In a protected mode operating system, each process gets its own “version” of the entire address space (all locations describable by a pointer). Needless to say, the ability to stop applications from writing into each others’ memory space is a fundamental requirement of making a multitasking operating system.

So, what happens when we request memory? Our call to new (or malloc, which is generally what new defers to anyway) will, barring any kind of user-side heap management (which does happen, I’ll go into that later), hit the operating system’s memory manager. The OS, being a privileged program, runs in a special mode, called ring 0. Protected mode systems have multiple privilege rings that code can execute in. In most modern operating systems, the kernel runs entirely in ring 0, while the applications run entirely in ring 2 (ring 1, designed for device drivers, is almost unused). A ring 0 application has a different view of the address space to a ring 2 application – it is able to access or “see” all the allocations made by other applications, which makes the OS’ address space significantly more cluttered. In addition to all the running applications, some of the address space is used by hardware – such as the entire block of video card RAM (indeed, these hardware reserved sections are the reason that 32 bit operating systems, while able to address 4 gigabytes of RAM, can only use less than that).

The kernel’s view of the address space is the entire map of all available, or addressable, memory on the system. Every 32 bit OS is able to address 4 gigabytes of stuff, whether it be normal memory, video RAM, sound cards (remember A220 I5 D3?), hardware interrupt managers, thread stacks, memory mapped files, you name it. Operating systems tended to carve up this area further, reserving, say, 2 gigabytes of that space to “kernel” memory (basically, memory used by the OS, drivers and hardware addresses), and allowing all the applications to use the remainder. A memory allocation request causes the operating system to look for a block of contiguous unused space in the virtual address table, mark it as belonging to the application, and return the pointer to it. If there was not a large enough unused block in the kernel’s view of the memory space, the allocation failed (which should demonstrate just why a 64 bit OS is essential).

The operating system is able to make additional use of this address space by not requiring that it exactly matches the RAM amount – it is able to take infrequently used blocks of memory and put them on the hard drive (in the page file), freeing up space in RAM, which is many orders of magnitude faster. Note that it doesn’t ever remove this memory from the virtual address space – it simply can change what is backing it. When a program requests to access that memory again, the OS can transparently reshuffle the memory, loading in data from the HDD to RAM, where the CPU can use it.

The last thing to explain about this whole system is the concept of pages. Memory is managed in discrete chunks – pages – the smallest block of data that the OS’ virtual memory manager cares about. For most operating systems, the page size is usually around 4kb. Each page is treated separately - they can be moved in and out of the page file and RAM independently (even if part of the same allocation), and there is no requirement that contiguous virtual pages are contiguous in RAM (indeed, they often aren’t). Pages vastly simplify memory management from the OS perspective – everything is the same size, there is no requirement that you have to have a large free block in physical RAM. Finally, when memory is freed (or the application is terminated), the OS marks the used pages as “free” and the cycle continues.

1.2 The Problem with Malloc

So, now that you understand the underlying systems going on with the OS level, what about malloc. Why, for example, would we even want to replace it?

From my description of the underlying system above, two things should be fairly obvious – one, that allocating memory requires a fair amount of operating system interaction, and two, that some other system must be being used for application memory management, given that the OS only cares about objects the size of a page (or some multiple thereof).

Enter the next part of the equation – malloc’s user-side (i.e., non-OS) memory management. Malloc, when a memory request arrives, will do one of two things. It will attempt to fulfill the request by providing a pointer to memory your program already owns (“here’s one I prepared earlier”), or, failing that, will perform the expensive task of requesting memory from the operating system. Depending on the exact implementation of malloc, it may request a significantly larger size than required, allowing it to then manage the larger, user space, block itself, or it may simply return the smallest multiple of pages – something which has a lower probability of failing – VM addresses must be contiguous.

Malloc will then carve up the space the OS has given it, annotate it with its own book-keeping data, and return the requested amount back to the application. When a free request comes in, it will update its book-keeping data, and potentially relinquish the memory back to the operating system.

Fundamentally, by providing a custom memory manager, we are changing the behaviour of this user-side system. We can’t speed up the memory management code that the operating system uses – we, instead, can use knowledge about our application to improve the performance of the memory system. For instance, we may know that our application will allocate and release memory in quick succession – we can immediately improve malloc (which is optimized for the general case) by not relinquishing the memory back to the OS. We may know that our application will only ever allocate tiny objects, and we can write a management system that is optimized for that case.

But that’s not all…

1.3 Widen the Scope

By using a custom allocator, we suddenly are no longer in the dark with the memory behaviour of our application. We can provide many more useful systems beyond performance tweaking, such as:

• Memory use tracking (or size/count histograms);
• Leak detection;
• Buffer overrun/underrun detection;
• Debugging info such as call stacks, allocation names, etc;
• Higher-level constructs and systems such as hedges and arenas, as well memory optimized for particular algorithms.

Now, there are third party solutions to all of these. I am a believer in reinventing the wheel, however; mainly because I think it is very useful to learn algorithms for yourself, and also because I get angry when I have to use anyone else’s code – the mark of a true programmer =)

In the next article, I will go through two very simple memory allocation algorithms – specifically, two that are both unfortunately useless, but provide a basis to build upon.

The Darkspawn Chronicles is the first real DLC module that Bioware released – I find it difficult to really acknowledge the existence of Return to Ostagar and Warden’s Keep given how insultingly bad they were, and will be leaving them for last. DC takes place in a bizarro alternate universe where the Warden Commander (i.e., you in the main game) died or perhaps never made it through the joining. Alistair has been crowned king, and has somehow managed to, in between feeling sorry for himself and lusting after Morrigan, accomplish all that your character would have in the normal game. You play a Hurlock Vanguard, who, for all intents and purposes, is just a sword and shield warrior in heavy plate armour. Your task is to lead the assault on Denerim and ensure victory for the Darkspawn.

You now fight as the Darkspawn! The city of Denerim, jewel of Ferelden, girds itself for war. As a hurlock vanguard, you alone hold the power to make thralls of your fellow darkspawn and drive them into the heat of battle. Heed the archdemon’s call Denerim must burn!

- Official Blurb

My happy Darkspawn family, me, "Crush Face", "Ghargh" and "the Irritating One"

Now, anyone with two brain cells to rub together should be pretty put off by this concept immediately – not only are they stripping all the non hack-and-slash mechanics by making the quest star a bunch of literally brainless, mute monsters, but they’re also replacing the (broken and badly balanced) player skill tree with the super limited monster skills of the Darkspawn. This entire module has no progression, no characterization, and no role playing at all. It’s a poorly implemented strategy game, more than anything else.

The game sets you up at the city gates with your Hurlock Vanguard. You have to punch through the defenders (led by notable characters from the game), and complete several minor quests for the Archdemon. These quests are all very simple, such as “kill the gate guards”, “kill the nobleman”, and, to mix it up a bit, “murder 10 innocent civilians”. It’s made slightly irritating by having constantly respawning mobs of enemies, but because Bioware have, over subsequent patches, progressively lowered Dragon Age’s difficulty from “respectable” to “console gamer friendly”, they prove to be little more than an annoyance.

Throughout your murderous rampage, you can “recruit” other (constantly respawning) Darkspawn minions using your enthrall power, which adds them to your party. While the Vanguard is basically a level 10 warrior with useless skills, the thrall Darkspawn are all effectively level 10 gelatinous cubes with no skills whatsoever, except their signature attacks. They are unable to use any items (even healing items), and upon dying, they get removed from your party.

I wish I had a capture of my ogre repeatedly punching Oghren in the face. That was the best moment of the entire game.

Fair enough, I suppose. It seems that I can’t really pick which I prefer – the thrall Darkspawn feel totally under-developed as classes (no surprises there), while the Vanguard is a vanilla human warrior with no discernible character or personality beyond a bitchin helmet. Each of the thralls has a different set of four or five skills, but the important thing to remember is that Ogres crush faces, and Shrieks are the cheatiest bastards ever, attacking about 2x faster than anything else. I pretty much completed the latter half of the game controlling the single Shriek in my party while telling the rest of my group to hold position at the gates.

You fight through the main Denerim districts, murdering the innocents in the market district (including Wade!), setting fire to the Elven Alienage tree (serves it right), and facing a preposterous number of respawning bastards in the palace district. While this is going on, you encounter members of the Origins party strategically placed (Oghren was in the market tavern – and before you get excited, no, you couldn’t go inside – but I made sure to kill him as brutally as possible) in the city. They must all be defeated. Especially Oghren. I can’t believe they brought him back for Awakening.

The final stand. See the fear in their eyes.

It ends with the showdown on the top of Fort Drakon, only you play as one of the Darkspawn mobs that comes in to help the Archdemon. There, you must defeat Morrigan, Alistair, Leliana, and “Barkspawn” the war-hound (I am so glad they chose that name to become canon). Naturally, if you have a Shriek or Ogre (or, better, both) you should have no difficulty crushing their puny human bodies and ensuring that the Archdemon reins supreme.

So. Overall? Well, I suppose in terms of sheer time to money ratio, it wasn’t bad. Sadly the whole affair was half-baked. It involved no (obviously) new assets, and, frankly, could have been thrown together by a junior using the toolset without any issues. The levels are all reused from the final battles of the main game, there is no dialogue at all, no meaningful choices, and really, no effort from Bioware.

Monster X-Presso: HAMMER

Okay, yes, I promised a Dragon Age DLC review today, but firstly, the DLC is so appalling that trying to wade through it is a lot like actual work, second, the DLC authorization/downloading stuff is as buggy as all hell, and third, it’s my damn blog and I can do what I like. I will, however, be reviewing an energy drink instead.

Monster is a fairly popular energy drink over in the states, but here it’s only really just started to appear. I’m not sure if we have got a reformulated version of the drink (or just a renamed version), but the “normal” Monster drink we get here has the dubious honour of tasting uncannily like dust – somehow it even manages to match the texture of it too. Think of it as being kind of like a liquid version of what you try not to inhale when you’re emptying a vacuum cleaner, only caffeinated. I generally avoid it, but today, I saw something exciting. A new Monster flavour – indeed, a new Monster concept.

Enter the preposterously named Monster X-presso: HAMMER (I believe the actual flavour is called “HAMMER“, while the drink itself is “monster x-presso”), the first “coffee” “flavoured” energy drink beverage to hit the shelves down under. Now, coffee in cans is nothing new to us here, we do, after all, live quite close to Japan, and those crazy chaps seem to have created an export economy based on cars, hello kitty, tentacle rape and coffee-inspired drinks. I think that coffee in a can should intrinsically be setting off some alarm bells with any sane person – especially given that they tend to contain milk and sugar, and, last I checked, milk wasn’t shelf stable. A quick examination of the can confirms that HAMMER also contains skim milk “concentrate” and cream (why not just use normal milk “concentrate”?), so, at the very least, I’m assuming it’s been heat-treated to buggery (or maybe irradiated) to give it a whopping 2 year unrefrigerated shelf life. This fact may start to explain the taste.

Hammer, home of the FOAM ZONE

But let’s rewind just a bit – I have (in moments of desperation) actually drank some of those suspicious cans of coffee from my local mysterious asian grocery store (you know the ones). They tend to be weirdly unlike what you wish they were, but some of them are passably drinkable. However, none of them released a noticeable fizz when being cracked open, unlike THE HAMMER. Actually, I was so shocked by it that I re-inspected the can, discovering an intriguing label (or is it, more accurately, a map?) as I did so. Well, don’t be fooled – despite the promises, my foam zone was a paltry centimetre high (maybe my Hammer was underpressurized), and there was no “creamy espresso”. In fact, what there was barely deserves to be called a “drink”.

Many energy drinks have an interesting taste – kind of like what you might imagine our space-faring descendants would be forced to drink in the deep darkness between stars to stop them from growing extra limbs or turning into gelatinous cubes, but this was different. This was, quite simply, a bit rubbish. It wasn’t even the kind of rubbish taste that you hope for; the kind where you can throw the glass down in disgust and cry out for a truffle to clear your palette. No, instead, it was okay – by far the biggest problem came from the sweetness level, which had been dialed up to 11.

In terms of nutritional content, it’s pretty lacking. It’s partly artificially sweetened, so, ml for ml it has about 50% less sugar than juice, it has about the same amount of caffeine as a regular cup of coffee (without the pesky taste), and it has a whole gram of taurine (which, I have no doubt, will pretty much pass straight through you).