So much progress

So much has been done.  I’ve gotten the menu screen (title) finished and it’s beutifal.  I got the early music soundtrack for the title and first two levels in place, and a way to transition between all of these things.

My latest work has been the pre and post status screen in the game showing you how many enemies and bystanders to expect before each level, and how many you correctly or incorrectly killed at the end.


Some of the funnest work has been coding up the cutscenes for introducing the environments in the game.  I’m still planning on only doing 3 environments (otherwise I’ll never finish this game), and making the 36 total levels out of different takes on these same environments.

Here’s a tease of the intro into the second environment of the game.

C++11′s take on retain cycles

I’d like to take a brief moment to discuss something rather programmy today.  Namely, the topic of retain cycles.  If you’ve ever programmed in Objective-C before (since the addition of ARC) or Swift, this concept will be very familiar to you.  But if you’re coming from other programming languages such as the older (pre-11) C++, This concept will be new and you might want to read on.

Now before I get started, let me say that this example may not be the most correct way to handle delegation via lambda (block) functions in C++11.  Many will tell you that shared ownership of objects in C++ can get you into trouble, and this is certainly a case of how that can happen.  However it’s the most conceptually compatible with other languages, which I value over “c++ correctness” due to the fact that I’m porting code from another language to start with, and shared ownership allows me to get work done without reasoning around the lifespan of my objects.

Now as many newcomers to C++11 know, concepts such as smart pointers and lambda callback delegation can really save you alot of time when developing new systems.  However, there’s ahidden evil in using these two concepts together, that must be uncovered.

Example 1 :: All is well

Consider this example:

and its output:

What we’ve essentially done here is created an object (via shared pointer), set a callback lambda, and issued a method call which at some point calls our callback.  We see that everything is working as desired.  Most importantly, we see that our object is properly deleted when we are finished our program (when the shared pointer goes out of scope).

Example 2 :: Not so much

Now lets look what happens when I add a slightly more complicated, second case.

Obj2 essentially is the same as obj1 right?  All we do is add a little printout of obj2′s someProperty value from within the lambda… and of course, C++11 dictates that we must explicitly declare all external objects that we access within our lambda (a capture list).

So what is the output then?

Note the alarming lack of “object freed” being displayed for obj2.  That’s right, the above code memory-leaks obj2.  You see, obj2 owns someCallback, and someCallback owns obj2 via a capture. This is a retain cycle and it permanently causes obj2 to be “forever retained” and therefore leaks.  Once a retain cycle is made, you can consider things to be more-or-less, too late.

This type of bug is a dangerous silent killer of the night.  Why?  Because it can be so easy to miss when developing.  Objective-C and swift have evolved over time to add compiler and IDE warnings about this kind of “retain cycle” problem.  C++11 assumes that you just wouldn’t write this type of code.  But when porting code over from Objective-C, this kind of code can pop up ALL the time.

So what do we do?

Solution 1 :: The ObjC way

Well Objective-C handles this problem by introducing the concept of “weak pointers”.  These are special pointers that ensure that they do not own their reference, they only keep track of whether or not it is allocated (if any shared pointers to it exist).  Luckily, C++11 brings the weak pointer to us as well.  A solution that uses them looks like so:

You’ll note now that running this code will solve the leak.  It’s also important to note that, while this is an ugly solution, this is/was the only way to solve a retain cycle of this nature in Objective-C.

However, for this explicitly unique case, in C++, there’s another way.

Solution 2 :: The tempting C++ way

What if I told you there was a way to solve the original problem by adding one character to the original code?  Here it is:

See that little ‘&’ added before obj2 in the capture?  This allows us to capture a reference to the smart pointer and not a value.  Why does this matter?  Well when a smart_pointer value is copied, it essentially increments its retain count of the object in question, and when it finally is destroyed by going out of scope, it’ll decrement the retain count, restoring the natural balance to the universe.  However, as I mentioned before, a retain cycle prevents the retain count from ever reaching zero in this case.  A reference to obj2′s smart pointer value allows us to forego the copy-increment mechanism and essentially stop obj2 from being over-retained.  Its essentially like taking a pointer to a pointer….

However, this solution can be dangerous, as it assumes the coder understands the rammifcations of doing things like capturing a reference to a stack variable, an argument, or anything that may be “dead” by the time the callback is ran.  Almost always, this “solution” may give unintended consequences.

The “correct” way

Here’s where things get somewhat opinionated. The “correct” way to handle this really depends on the situation at hand. I suggest that if you a working with a team, you might want to use the safer and more verbose weak pointer method since it is more explicit in its intentions and helps explain why strong ownership could be a problem.  Furthermore, if you are working in a smaller system where shared pointership is not necessary, you might want to avoid using shared pointers altogether (assuming you fully understand the ownership semantics of the objects being used in the captures).

Either way, the golden rule is to understand the side effects of the code you are writing and when using shared pointers, keep that little retain cycle demon in the back of your mind… always

Parallax Occlusion Mapping – Advances in shader land

Today was cool… at least the first part of it was, before I spend 5 hours tracking down a bug in some of the game code.

I stumbled onto a pretty cool little article geared towards a very awesome technique called “parallax occlusion mapping”. This is essentially bump mapping with some extra samples taken at each pixel to provide a realistic depth (or parallax) effect to the surface. This provides the illusion of realistic surface detail all while shading a single polygon. The article was somewhat dated and targeted for Direct3D instead of OpenGL, but I was able to port it over to GLSL 150 for OpenGL 3.2.

Here’s the original article:

And here’s my port of the shader code for anyone who is interested.


Some of this code is “massaged” by Verto Studio’s code converter when ran on mobile.  It’s definitely a pretty cool effect!  It requires 3 texture maps to work currently, a standard diffuse (color texture) map, a normal map, and a displacement or height map.  Lucky for me, there’s a sick little program called “crazy bump” for mac that can generate both normal maps and displacement maps from any standard diffuse texture map!

 WebGL demo

For those who want to see the shader effect in action, I got a WebGL demo which runs on chrome and safari (firefox and IE don’t work).

It’s an expensive effect however, so I’m not sure yet if I can work it in for Driveby Gangster.  Either way, it’ll definitely be a nice little addition to the shader arsenal.  If I do actually put it into use, I hope to eventually add self-shadowing effects as well.

What I’ve been doing

Tons of stuff has been accomplished as of late.  I’ll just list a few of em here.

  • I programmed a cool “breaking glass” shader for the street scene shop window so that when you shoot at it, it breaks
  • I made a “spark” particle shader for when you shoot at metal, and also programmed separate bullethole decals to appear depending on the surface you strike.
  • I bit the bullet and grabbed maya for finishing up some of the character animation stuff including animations for aiming the gun and getting hit by bullets
  • I started on and nearly finished a very awesome “beach” scene for the game.  This broke one of my cardinal rules about keeping the stuff simple, but I’m accepting the risk because a game with the same level over and over again is a pretty bad user experience.
I apologize again for the lack of quality updates on here, but I’ve definitely been prioritizing working on and finishing the game over keeping this blog up to date.  It’s a tradeoff I guess.

For the beach scene I modeled a cool sailboat for it entirely from scratch using verto.  I have big plans for this sailboat that I’m going to keep secret for now.

One thing that I’m really excited about was a small effort that took me two days. I managed to compile the entire C++ code base to JS using emscripten.  This means that I can display simple verto studio scenes in the web browser!  A quick demo of this, for people running on webgl enabled browsers, should display below…


Another youtube series

I’ve done so much since my last update. I have a bunch of screenshots on my desktop just waiting to be uploaded here.  I’ll try to submit a “real” update this weekend.

I just wanted to post to mention that I have uploaded a new tutorial series on YouTube regarding learning shader programming!   The playlist for the series is here:

Free the code

One of the reasons why love game programming so much is that it forces you to do things that would otherwise seem quite ridiculous. I have always liked to shoot first and ask questions later when it comes to implementing an idea. Sometimes it’ll just pop in my head and then I will start working on it and before I know it…it’s done. The last week and a half has been more work than I ever wanted to do but the result is awesome. A very large portion of my entire Verto Studio graphics engine and code base has now been rewritten in C++ and is now portable to any operating system.

This means I can now load and render my Verto Studio files on Windows, Linux, anything I want without any strict dependencies on Mac anymore.  As a game developer, this is an awesome feeling and I am beyond stoked.  I worked very hard on the Verto Studio tech over the last three years and to finally free it from OSX/iOS is great.

I’ve moved on the actual swift code of the in-progress Driveby Gangster Game project and hopefully I’ll have that done soon next week.  All-in-all I’d say the extra week of work was definitely worth it.