So it’s been a while since I’ve posted an update, but that’s not to say progress hasn’t been made. Very far from it. Bezzy was due last week, which means I spent all my days (and nights) scrambling to get it done. This has left me with little time to update this blog. I ended up getting everything I wanted done in time, albeit not quite as polished as I would have liked. Still, that’s how software development goes.

So what have I been working on for the past week? Keyframe animation, two Non-Photorealistic Rendering (NPR) fill techniques, and a little tech demo to tie all of this together. I also visited my “friend” Dynamic Tessellation for a bit.

We’ll talk about the first two today. Part two will be posted “soon”.

(read on…)

In my last post, I said I’d talk about how I fixed a rather “fun glitch” which related to fill modes. Just to refresh your memory, it looked a little something like this:

If you read my last post you can probably figure out what’s going on here. The fill geometry I’m rendering is smaller than the path itself. Here’s a screenshot that makes this a bit more obvious:

This is possible because the programmer has the ability to scale the fill and position the fill origin wherever s/he would like. What I need to do is ensure that the entire path is always filled, regardless of the fill parameters. This means that the geometry needs to be big enough to go from the fill origin to every vertex that creates the path.

(read on…)

I’ve taken a break from working on the confusing world of dynamic tessellation to work on the slightly less confusing world of fill modes. While the screenshots I’ve been posting should make it obvious that I already have filling working, it is still mostly prototype code, and therefore is filled with holes, hacks, and fun glitches like this:

We’ll go into how I fixed that in my next post. I want to spend this post talking about how I got fill modes to work in the first place.

Anyone who has done any work in OpenGL will tell you that creating gradient filled shapes is a trivial task. All the programmer has to do is assign colours to each vertex in a triangle and OpenGL will do all the magic colour interpolation for you. Unfortunately, this isn’t good enough for Bezzy. If we can only colour on a per-vertex basis, what happens when a gradient fill is applied to a path where the colour changes between vertices?

For example, let’s say we have a rectangle filled with a red-green-blue linear gradient fill. The rectangle has four vertices, one at every corner. We can colour those vertices red or blue, but since there are no vertices in the middle of the rectangle, we can’t colour anything green.

The obvious solution is to use pixel shaders to do the filling. Bezzy is targeted at computers with fixed-pipeline graphics cards, so I didn’t even consider that solution. Instead, I used a magic little videocard feature called the stencil buffer.

(read on…)

I’ve spent the past couple of days refactoring a tonne of code. That’s the problem with writing prototype/proof of concept code … eventually you need to go back and make sure it all works! With that out of the way (and the code looking pretty spiffy), I focused my attention on dynamic tessellation. I haven’t come up with an optimal solution yet, but I’ve made some good progress.

First, what the heck is tessellation, and why is my approach dynamic? Tessellation is breaking up smooth paths (in our case, Bézier curves) into a number of smaller lines. The more lines we use, the closer the approximation is to the actual curve, and as a result, the smoother the lines appear to be. Videocards are unable to render Bézier curves, they can only render points, lines and triangles. As a result, tessellation is critical to rendering curves on hardware.

Now the “dynamic” bit. This has to do with how we perceive smoothness. Basically, the bigger a curve appears on screen, the more lines are required to make it appear smooth. By scaling the amount of tessellation we use on the curves, we can ensure that we always have smooth looking curves using a minimal amount of lines.

Let’s take a look at the different approaches I took to solving this problem. I used three paths which I will creatively call (from left to right) Path 1, Path 2 and Path 3. The screenshot on the left shows the paths rendered in debug mode. Each line is coloured differently to make the tessellation obvious. The screenshot on the right shows how it would actually appear.

(read on…)

Yesterday I tackled the issue of morphing animation. As you might expect, morphing generates a path that is an interpolation of a source and destination path. My test subjects we’re these two innocent looking paths:

So we’re trying to get the shape on the left to morph into the shape on the right. The first attempt was, errr, “interesting”:

The second attempt was better. But, you know, better is a relative term …

A bit of tinkering later, it worked! And then I went nuts trying out different shapes and stuff. The result:

So that’s what we’ve got in the way of pretty pictures. Technical details below the cut.

(read on…)

Among the computer science courses and random electives I’ve taken this semester is a gem of a course: Computer Graphics, a.k.a. the dreaded CS 488.

The neat part about the course is the final project at the end of the semester: a graphics project of our choosing, absolutely anything we’re interested in. Most of the projects tend to be 3D games, scenes, or raytracers, but I’m trying something a bit different. A hardware-accelerated 2D vector drawing library called Bezzy.

For now, the feature-set looks something like this:

• Render shapes consisting of lines and Bézier curves
• These shapes can optionally be coloured in using solid, linear or radial fill modes
• Arbitrary clipping layers definable by the user
• Keyframe and morphing animation

I’ve made some pretty good progress. Here’s what Bezzy can do now:

Stay tuned for more!

I’ve been meaning to blog about this for a while now, but I’ve been terribly busy. Better late than never though, eh?

Three weeks ago, I did something huge. Something that I’ve been meaning to do for years, and something that’s even a bit life-changing.

I sat my Dad in front of my laptop and told him to push the “return” key. He wasn’t sure why he had to push it, but I was. As the person who was incredibly supportive and encouraging of my videogame programming hobby throughout my childhood, he was the perfect person for the job. On April 28th at 8:27pm he pushed the return key and unwittingly launched Caffeine Monster Software.

Caffeine Monster Software (or CMS, an acronym that people will forever confuse with content management system) is my indie videogame development studio. My debut game is Smiley’s Shooty Adventure, an upgraded and reworked game based off the original Smiley on the DS. I’ve worked on it tirelessly over the past year, tweaking and improving every aspect of SmileyDS, and throwing in plenty of new features while I was at it. It’s come out just as fantastically as I imagined it would.

It’s shareware too. Most CMS games will be. This is big deal for me. I’m hoping it’ll push me to make better, more polished games. And hey, if it makes me a bit of change on the side, I won’t complain too loudly.

So anyway, that’s that. I am, of course, working on more games, but that’s another subject for another time. For now: WOOHOO I’ve launched!

Gmail makes me smile because it’s intuitive.

(read on…)

Looking back, I can safely say Bioshock is one of the best games I’ve played in recent memory. I could discuss the various aspects it gets right for days, but instead, I’m going to be a bit grumpier and talk about what it could have done better. For today, let’s focus on what it does with emergent gameplay.

Bioshock provides the player with a complex simulation to play around with. The opening act does a fantastic job of introducing you to Rapture as a living world which you can influence. The player is even rewarded for “thinking outside the box”, which is something a worrying number of sandbox games fail to do at all. But where Bioshock falls short is encouraging the player to think outside these bounds.

Some may argue that the reward is the encouragement. To an extent, it is. At the start of the game, players experiment to familiarize themselves with its mechanics. But once the player gets better, they get into a routine, and the encouragement is lost. This isn’t a gamer thing so much as it is a human nature thing. Once you figure out an effective way to kill Splicers, or a sure-fire way to take down Big Daddies, the rewards are irrelevant. The rewards only worked when the player needed them. Now that they don’t, the experimental aspect of Bioshock gives way to the repetitiveness of your standard-fare first person shooter. It’s a shame, and I’ll admit that I’m as guilty as the next person in this regard, but it’s to be expected.

How do we fix this?

(read on…)