Pistachio Brainstorming

Lately I’ve been working on a custom game engine using Microsoft Visual C++ Express 2012 for Desktop. The project compiles into a dynamic library that will be linked to the main application that defines the game. The thing is I wanted to keep track of this engine version. I placed a major and minor version numbers, but I also, for the sake of curiosity, keep a build number. This number should increment every time a successful build of the project is performed. It will be reset when the minor version changes. That way I can keep track of how many different builds the project has have to a given major and minor version.

Obviously, I don’t want to manually increment that number. I could forget to do it, but more importantly, it will bore me. I’m really lazy. There are some free add-ins for Visual C++ that provides this feature out of the box (example). Unfortunately, the Express edition of Visual c++ does not allow you to install non-Microsoft add-ins, so it’s not a solution for me.

This post will summarize an alternative process I followed to achieve this automatic increment of the build number. It works on Visual C++ Express 2012 but I’m pretty sure it can also be applied to previous versions. This specific solution requires Git Bash because it involves the execution of a small Bash script. I’ve chosen Bash because I feel comfortable with it from my days of GNU/Linux, but any other (minimally powerful) script interpreter could work. I’ve chosen Git Bash because I already have it installed in my system as part of the Git for Windows package. The rough picture of the solution is:

1. Store the build number in a header file, for example version.h.
2. Create a script that increments a #define macro in version.h.
3. Execute this script every time Visual C++ performs a successful build.

It will be important to make sure the modified file timestamp corresponds to the original one in order to prevent having to build the project just for that.

Header file

In my case, the header file is very simple and looks like this:

Although macros must be avoided at all cost, in this case it is the easier way to show this solution.

Script

The script looks like this:

It is divided in three tasks:

1. Increment, replace, and print the modified version.h to a temporal file using awk.
2. Keep the original timestamp for the temporal file using touch.
3. Rename the temporary file to the original one using cp and rm.

The first task is performed by the awk script. You can read the manual for a full description. It basically prints all lines of version.h which don’t match the string “#define _MYPROJECT_BUILD”. For the lines that match that string, they find the value in the third column (columns are separated by spaces), add one, and then reprint the line. Notice that the script could need adaptation for your particular implementation.

The modified version.h file is stored in version_temp.h. We don’t modify the file in place because we want to keep track of the original timestamp of the file. This is needed so Microsoft Visual C++ does not notice the file has been updated and thinks the project needs to be updated. The timestamp of the original file is copied to the temporal file by the touch command.

Then, we copy the temporal file to its final destination preserving all the relevant information (timestamp) using the -p modifier in cp. Finally, we remove the temporal file.

Hook the script

In order to execute the script every time Visual C++ successfully builds a project you must hook the script to the post-build event. You can find this right-clicking in your project and then “Properties”. This will open the project property pages. Navigating to the “Configuration Properties” -> “Build Events” -> “Post-Build Event” in the left panel you will see something like this:

In the command line parameter I’ve written the following:

This calls the Git Bash interpreter (sh) defining all the environment variables (–login) which in turns calls our script (post-build). My directory layout is:

Notice that the post-build event is executed from the project directory  (SolutionDir\ProjectDir in my case) . That’s why the script refers directly to ‘version.h’ and ‘version_temp.h’ while the post-build hook refers to ‘../tools/post-build’.

Conclusion

And that’s it. Every time the Visual C++ project is successfully built the post-build script will update the ‘_MYPROJECT_BUILD’ macro value. In addition, as the timestamp of the file is preserved in the process, this change doesn’t trigger a project rebuild of the version-dependent files. Keep in mind, however, that to update the build number in the application you will have to force a rebuild of the system. Don’t forget that when you want to release a particular build of your application.

Sometimes you are bound to plot 2D real functions with a big positive maximum and a small (in comparison) negative minimum. In case you use a colormap like ‘jet’ you must be aware of two things:

1. Jet/Rainbow is usually a bad choice for colormap for several reasons.
2. The reader must infer which color corresponds to the zero value and then interpret where in the plot the values are negative and where positive.

The first problem can be avoided using ‘hot’ or ‘gray’ colormaps, but the second one can’t be solved with conventional colormaps.

The Polarmap function uploaded to FileExchange propose a clean solution – shade an existing colormap to place the white color in the value corresponding to the zero value. This is convenient because the reader then does not have to infer the zero value, since it is always white.

Nevertheless, there is still one problem when the z-axis of your data is not symmetric, i.e., when the maximum and minimum does not have similar absolute values. In such cases, the smaller extreme can end up washed away from the plot.

But not all is lost! If your main purpose is to demonstrate there is a negative part that is not negligible you can generate a colormap that is linear from zero to the maximum and linear from zero to the minimum.

This plot has the disadvantage that an unkeen  reader might think that the positive maximum and negative minimum are of the same order. Including a colorbar like the one on the right side of the figure should avoid most confusion, while highlighting that there is a non-negligible negative part in the figure.

The last figure was plotted using the following Matlab code:

where the NegativeEnhancingColormap function is a personal function that I release under a Creative Commons Attribution-ShareAlike 3.0 Unported License. You can download it for Matlab using the following links:

• Version 1.0: Download

When making a 2D game one usually must assemble several images (sprites) into a single big texture (sprite sheet). On the game the sprite sheet will be loaded and the different sprites will be shown accordingly to game events or the game internal time (animations).

Imagine that your awesome artist (<3) gives you these images that form the walking animation of a character from your game. For example, this one

and this one

and this one

etc. The result is an animation of the character walking downwards:

In the game you will load a unique image that conforms all the steps of the previous animation. Manually assembling that image is a really boring and (thus) error-prone task, but luckily we can avoid it using a shell script and ImageMagick.

As its web claims, ImageMagick is:

a software suite to create, edit, compose, or convert bitmap images.

We are specially interested in the compose capabilities which will allow us seamlessly assembling these sprite sheets. This operation is performed with the montage command line. Joining this powerful tool with the a shell script interpreter like bash is something that will save you hours of repetitive work.

For instance, imagine you have eight 128×128-pixel steps for the walking animation named “pj-waling-i.png” where “i” is the step number (1, 2, 3, …) and you want to assemble them into the 512×125 texture named “pj-walking.png”. To perform this task you could use the command line sentence:

Notice that the “[1-8]” selector ensures that all the steps are assembled. But what if the name for the steps are “pj-walking-first.png”, “pj-walking-second.png”, “pj-walking-third.png”, etc.? No problem! Bash allows us selecting images in a more complex way. The previous example can be modified to take care of this new situation:

The options of the command mean the following:

• -tile reflects the organization of steps. 4×2 means that it has 4 columns and 2 rows, 8×1 would mean 8 columns and 1 row, etc.
• -geometry gives the size and position of each step. 128×128 means that the images are 128 pixels wide and 128 pixels tall. +0+0 means that the origin of the image is in the top-left of the image.
• -background provides the color (or lack of it) for the background of the final image. In our case we use the keyword transparent to make use of the transparency of the animation.

The result is the following 512×256 pixel texture:

And the final script is this one:

As a final note, notice that a similar montage command can be used to assemble different animation sprite sheet, like the one presented in the above figure, into a single super sprite sheet like the ones found on the Internet.