MAGfest 11

by BP on 2013-01-07 at 01:41 PM

Shout-outs - or apologies, depending - to the folks at MAGfest this year, including the 200ish of you that I street-passed with. It was my first MAGfest, and also my first time driving south of Buffalo, NY, but the trip was worth it to meet so many awesome people, see so many awesome things, play so many awesome things, hear so many awesome things, and on the rare occasion, eat so many awesome things, too.

For those not familiar with it, the Music And Gaming festival is a four-day-long festival/convention that also happens to be the happiest place on Earth. Take that, Disneyland/world.

Oh, and a special shout-out (read: apology) to whomever ended up with that beautiful piece of Sonic the Hedgehog art I sketched up. You are probably a really awesome person.

It's almost time for me to get back to work on Return to Roots. Current tentative completion date is some time in March. Might actually have some folks helping out with it, which will nicely offset the fact that I'm starting a new job tomorrow.

New game incoming!

by BP on 2012-12-18 at 02:22 AM

For anyone who hasn't been following Ludum Dare 25, I participated in my first game jam and I'm pretty happy with the game it resulted in. There's an entire engine in there waiting to have more features added in to grow the game out a bit more, but until I find the time to do that, I will be fixing up a few tiny things and then putting the game on my website for download.

The game is called "The Hubris of the Bone Lord", based on the LD25 theme, "You are the Villain". It is a side-scrolling beat-em-up similar to games like Double Dragon 2 and River City Ransom.

Stay tuned; the LD25 version will be up for grabs before I go on vacation (so, within a week).

Getting ready for Ludum Dare 25

by BP on 2012-12-13 at 06:37 PM

The current state of my workstation. I'm going to be participating in Ludum Dare this weekend (on a whim no less). I'll be livestreaming my 48 or 72 hour game jam at I'm still undecided whether I'm going into the core "competitive" mode, or whether I'll just take it easy and do the casual jam. There's very little difference as it pertains to me - really, just a matter of whether or not I want to re-write my animation manager class. We'll see.

It also looks like I'll need to write some code for my post-rendering engine to automatically resize images that are Too Damn Wide.

Creating Texture Masks in XNA

by BP on 2012-10-04 at 11:14 PM

I ran into an interesting problem recently involving sprite colouring. In the game I'm currently working on (RTR), when the player defeats a boss enemy, the screen will temporarily flash white, leaving only the player character and enemy visible.

In most circumstances a Flash effect can be achieved by simply filling the screen with white at a specified opacity. This is insufficient for RTR because map objects can appear in the foreground in front of the characters.

I did some searching and came upon a solution using an fx file that would act as a sort of Post-Processing filter. The code for such a filter is as follows:


sampler2D baseMap;
float whiteopacity;

struct PS_INPUT { float2 Texcoord : TEXCOORD0; };

float4 ps_main( PS_INPUT Input ) : COLOR0
float4 color = tex2D( baseMap, Input.Texcoord );
return float4(1.0f, 1.0f, 1.0f, color.w * whiteopacity);

technique Technique1
pass Pass1
PixelShader = compile ps_1_1 ps_main();


There are two problems with this approach: One, it requires a separate call to SpriteBatch, resulting in 3 calls total if you want to draw UI elements overtop, and Two, it's an additive Draw, meaning overlapping textures would result in duplicate masking:

The issue with duplicate masking can be solved by drawing each layer and then immediately drawing the associated effect layer on top of that, but the result requires 2 calls to SpriteBatch for every layer you want to draw the effect to, and one call for every layer you want left alone. Even with short cuts, this would result in 7 separate SpriteBatch calls for each call of the Draw method in RTR (there are 3 foreground layers).

Using the above Effect file also makes PixelShader 1.1 a system requirement, though whether or not support for archaic hardware is a drawback/requirement is inconsequential.


The approach I ended up implementing involved the use of realtime-generated texture masks. Because maps in my game are tile-based and drawn from 16x16 tiles plucked from a much larger graphic image, I took the following approach.

After drawing the entire scene, I check each visible tile to see if it contains any foreground tiles. If so, the texture co-ordinates for each tile are passed to a Mask function that returns a 16 by 16 Color[] array, and that Color[] array is then fed into a 16x16 Texture2D object which is then drawn. The function that returns the mask is as follows:


//Assumption: maptex is a Color[] array that contains
//the tileset texture we are drawing from
//texture is the actual Texture2D object that contains the map texture
//x1 and x2 are the starting location of each 16 by 16 tile
//eg 0 means draw the 1st tile, 32 means draw the 3rd tile

public Color[] WriteMask(int x1, int x2, byte opacity)
Color[] mask = new Color[256];
for (int j = 0; j < 16; j++)
for (int i=0; i<16; i++)
byte a1 = maptex[j * texture.Width + x1 + i].A,
a2 = maptex[j * texture.Width + x2 + i].A;
if (a1 != 0 || a2 != 0)
mask[16 * j + i] = new Color(255, 255, 255,
(byte)(Math.Max (a1, a2) * opacity/255));
mask[16 * j + i] = Color.TransparentWhite;
return mask;


This function checks the 16 by 16 texture for all overlapping sprites and prints the highest alpha value to the "mask" Color[] array. The function is overloaded to support the masking of 1, 2 or 3 simultaneous layers. This ensures that we never overlap masks:

It also only uses one SpriteBatch call and doesn't require Pixel Shaders. With a few tweaks it can be expanded to do things like recolouring textures as a solid colour, something the native SpriteBatch command doesn't adequately support (it can recolour a non-white sprite solid black, but that's it).

RTR Demo v1.01 available

by BP on 2012-09-17 at 03:56 PM

I found out the hard way that the old installer I was using to deploy Return to Roots wasn't very maintenance-friendly, so I had to spend a day researching and creating a new one. The new installer packaged with RTR Demo v1.01 has some lovely features such as allowing you to actually specify the install directory.

Check the Steam Greenlight page for the list of changes.

Newer Posts

Older Posts