NEWSFLASH: Snowboarding is awesome

I'm from Massachusetts.  I grew up tolerating the cold and snow, but sometime during the windy winters at college on a campus laid out with a cruel, long walk from dorms to academic buildings through many wind tunnels, I sort of started to hate the cold.

But I understand now why cold weather exists:

SNOWBOARDING.

I went for the first time this month when some people invited me for work, and now I don't want to stop.  I even bought some gear:

It's a little bright, but when else do you get to wear interesting colors like that?  

I also started going with Tokyo Snow Club, their trips are pretty fun.

Pool Allocator

Another useful memory algorithm is a pool allocator, which allocates lots of small blocks of memory of the same size.  Often times in programming games (and other applications) there are times where you need to allocate small chunks for same-sized items such as matrices, or multiple instances of the same object.  Obviously a pool allocator is the natural fit.  My implementation is below. 

--> Open PoolAllocator.cpp in a new window <--

The code above is hosten on Google Code, and you can comment by double clicking anywhere, or by clicking in the left hand margin on the little speech balloon plus icon. You need to be signed in with a google account.  Please comment and tell me if my code sucks!

Implementing a stack allocator isn't hard, but there is one important memory saving trick I'll discuss below:

  1. When creating the pool, preallocate a large block of memory, the size of which is a multiple of the size of the separate pool elements.
  2. Add each of the free elements to a linked list.
  3. When someone wants to use a block, pop one off the free list and return it to the user.
  4. When a block is freed, add it back to the free list.
  5. When deleting the pool, assert that the number of free elements is equal to the pool size divided by the size of an individual element.

That part is easy.  But we have to consider where we will get memory for the linked list to track the free elements.  Or do we?  We have all this free space in each of the free elements, why not put it to good use?

NOTE: The one caveat here is that the size of each element in the list must be larger than sizeof(void*)

To track the free items in the free list itself we do the following.

  1. When creating the pool, after allocating the memory, starting with the beggining of the list, write the address of the next free block at the start of the current block.
  2. When providing a block to the user, return the start of the list, but not before setting the pointer to the start of the list to the next block.
  3. When returning a block to the free list, write the address of the start of the free list into the start of the newly free block, and set the start of the free list to the newly freed block's address.

Remember that when using the memory of the free block itself as the pointer to the next block, the equivalent to 

mFreeListStart = mFreeListStart->next;

Becomes:

mFreeListStart = (u32*)*mFreeListStart;

Where mFreeListStart is a u32* to the start of memory of the first element in the list,

next is a u32* to the next element,

and  u32 is a 32-bit unsigned integer type.

Stack Allocator

So I said I was going to start working on my game engine project, and I know it seems like I've been doing a whole lot of nothing, but I've been working this whole time!  ...Well some of this whole time.

Working on what?  On Memory!

I've written a few different memory algorithms now, but I'll start with the simplest: a Stack Allocator.

--> Open StackAllocator.cpp in a new window <--

The code above is hosten on Google Code, and you can comment by double clicking anywhere, or by clicking in the left hand margin on the little speech balloon plus icon. You need to be signed in with a google account.  Please comment and tell me if my code sucks!

A stack allocator is useful in games because many games allocate memory for levels in a stack like manner.  When a new game level is loaded, the memory for all the textures and meshes etc is loaded at once, and then nothing more is allocated during the duration of the level.  When the level is unloaded, all of the memory is freed.  A stack memory allocator is perfect for this sort of application.

Implementing a stack allocator is pretty simple:

  1. In the constructor, malloc a block of memory to use as the stack, and set it as the base of the stack and as the current top (ensuring it's not NULL).
  2. When memory is requested from the stack, store the address of the current top to return, and then move the current top up by the size requested.
  3. When freeing, you just set the current top back to the marker passed to the freeToMarker function.
  4. Clear the stack by setting the current top back to the base of the stack.
  5. When deleting the whole stack, you can ensure all memory has been freed by asserting that the current top is the same memory address as the base. 

The next write up I believe will be Pool Allocators.

LED Pac-man in Assembly

As part of training for new employees at BNG, we planned, soldered, and programmed (in assembly) games on a practice circuit boards with Renesas 16-bit H8/300H Tiny Series processors (specifically the H8/3687). 

Here's a video of what I made:

 

As you can see, it's a Pac-man themed dot-eating game.  I implemented 3 modes:

  • The first mode is an attract mode, like you'd see in arcades (when nobody's playing the game, it plays itself).  The dots slowly enter Pac-man's mouth and he eats them and gets larger and it flashes when he's at maximum size.  Also the digital display (the green number 8 LED) spins around in a circle.
  • The second mode is a timing game, where you have to push the green button when the dot is in Pac-man's mouth.  He eats it and grows larger.
  • The third mode is a button sequence game in which you just push the buttons in the correct order to feed pack man. (When we were soldering on the components, there was a lot of colored switches, so I put as many on as I could, and I had to think of something to use them for so they didn't go to waste.)

In addition to being able to change modes with the black button, the brown button changes difficulty, which is actually adjusting the speed of the timer that controls everything.

Here's a picture of the circuit diagram as planned in advance, though it is a little different than how it turned out in the end:

Circuit Diagram!The code was written entirely in assembly, which was a new challenge for me.  Compared to writing in C++, it felt like everything took years to do.  But it does make you realize how every line of code you write in C++ is really comprised of a multitude of these moves between registers and RAM (not to mention chip cache) and how all this complex logic breaks simplifies down into branch-if-zero's and other simple math equations. One thing I didn't have time to do was to understand argument passing in functions.  It looked complex and I had a lot to implement, so I just copied and pasted a few functions rather than mess with trying to use a feature I don't fully understand on a platform with no debugging to help me understand what I'm doing wrong.  But it would have been nice to learn if I had the time.

The (amateurishly written) source is available for download here, and is also after the break, with some unfortunately pink syntax highlighting.