Success @ Games Republic 2012

Today’s Games Republic 2012 event, held at the University of Bradford, was incredibly rewarding for our team. The day was spent exhibiting our PSP Minis title BounceBack (along with our SteelEngine PSP game engine) to both students and industry professionals, and of course, the judges! We received some excellent feedback and were very humbled to be awarded the following three prizes…

 1st Prize – Best Team – Awarded by Rockstar Leeds
1st Prize – Best Game Technology – Awarded by Four Door Lemon
1st Prize – Best Game Design – Awarded by Sumo Digital

Many Photos were also taken at the event. BounceBack will be available for download on the Playstation Store for both PSP and Playstation 3, Summer 2012.

Silencing ‘Unused Variable’ Warnings

Warnings generated by C++ compilers which inform you that your code has ‘unused’ or ‘unreferenced’ variables in undoubtedly a good thing. Warnings such as this usually suggest that a variable can be removed (perhaps it was a debug or temporary variable a frantic coder neglected to remove) or perhaps a variable which is not being properly assigned or accessed due to a typo or re-factoring cock-up. However there are instances where this kind of warning can prove troublesome, especially when warnings are treated as errors (a discipline I strongly advocate).

More specifically, this kind of warning can become difficult to cure within code heavily plagued with pre-processor conditions (either inlined or included via some ‘clever’ macro) which control which lines or sections of code are stripped and included under a projects often plentiful build configurations. Such mechanisms can prove very powerful, perhaps to strip all debug code from a particular build, or include specific code segments per platform. However code littered with nested conditional sections such as this often become messy and difficult to manage. As a result, some variables (which are in-fact referenced multiple times within the file) become un-referenced when building with a particular build configuration.

A Very Basic Example

Within the following code the msg variable is used within debug builds but becomes obsolete when carrying any non-debug build, yielding the compiler warning in question:

#include <stdio.h>

#if defined(_DEBUG)
#define DEBUG_PRINT( x ) printf((x));
#else
#define DEBUG_PRINT( x )
#endif

void main()
{
	const char* msg = "Some Debug Message";
	DEBUG_PRINT(msg);
}

The Solution?

In a case as simple as the above it might be tempting to checkout the DEBUG_PRINT macro and upon discovering that this macro only uses its parameter when _DEBUG is defined, nest the declaration of the msg variable within an identical conditional section. This will work perfectly in such a contrived scenario but when working with larger more complex codebases this approach can involve trawling through numerous nested macros and expansions, and may only fix the problem under a particular build configuration. Perhaps a better approach is to wrap the offending variable with the following macro which tricks the compiler into having used the variable under all build configurations (provided the macro is included within all build configurations of course).

#include <stdio.h>
#define ALWAYS_USE( x ) do { } while( &(x) != &(x) )

#if defined(_DEBUG)
#define DEBUG_PRINT( x )...
#endif

void main()
{
	const char* msg = "Some Debug Message"; ALWAYS_USE(msg);
	DEBUG_PRINT(msg);
}

The ALWAYS_USE macro shown above will make the compiler believe that the msg variable is always being used, however it’s contribution to the final executable should be non-existent when compiler optimisations are enabled (or at worst generate a NOP instruction on some compilers).

MSVC Generated Assembly NDEBUG (/O2)

void main()
{
    00F01000  xor   eax,eax 
    00F01002  ret
}

View Frustum Notes

The purpose of this blog post is to jot down a few handy tips and tricks worth remembering working with view frustums, ranging from the blatantly obvious to the more obscure. I don’t spend as much time reviewing these posts as I would like, so as ever, please feel free to comment with any corrections or related tips.

Inverse View Matrix

A cameras view matrix is most often represented as a homogeneous 4×4 matrix used to shift bases, transforming points from world space, to the camera’s own three-dimensional co-ordinate system (‘camera space’ or ‘view space’). However a cameras inverse view matrix can also have it’s uses. A camera’s inverse matrix represents the position and orientation of the camera it’s self within the world and can therefore prove useful in the following scenarios:

• When rendering game cameras within the world, perhaps useful when debugging or writing tools which deal with the positioning/manipulation of multiple cameras
• Extracting the camera’s translation and orientation when these values are not immediately available/accessible

Finding View Frustum Vertices

Sometimes it can be useful to find the world space vertices which define the corners of the view frustum, perhaps to render the frustum, or to find the distance to a particular point or edge. Given the position, orientation, aspect ratio and FOV of a camera it is possible to manually calculate the frustums corners, however a much more elegant approach is at hand.

Start by setting up the vertices of a cube with it’s local extents representing the clip-space of your graphics pipeline (OpenGL uses [-1,-1,-1]→[1,1,1] for clip-space whereas DirectX uses [-1,-1,0]→[1,1,1]). Next, transform this ‘clip space cube’ by the camera’s inverse projection matrix. This will reveal the corners of the view frustum in view space. Further transforming these points by the camera’s inverse view matrix will yield the world-space vertices representing the corners of the view frustum.

Caching View Frustum Data

This one may seem pretty obvious, but calculating data such as frustum planes, corners and angles can be computationally expensive and need only be carried out whenever the camera is moved or re-oriented. If your camera class has Set methods for properties such as position, lookat, FOV etc, it may be wise to check that the new value is unique before setting, re-calculating or storing any new data.

Storing View Frustum Planes / Normals

As planes can be represented using a pair of vectors (position and a unit normal) or better still in a single vector (ax + by + cz + d = 0), it might seem sensible to store a vector or vector pair per frustum plane. It is worth considering however that view frustums are almost always symmetrical and therefore calculating and storing only the left/top plane may be beneficial in some cases. When the right/bottom planes are required they can be generated on the fly by reflecting the left/top planes about the cameras local axis. If the view frustum is always parallel to a world axis this fact can be exploited by storing only the left/top frustum planes and simply inverting the appropriate component of the point/normal vectors to perform the reflection. Frustum planes can also be extracted directly from the camera’s view/projection matrix on the fly, see Fabian “ryg” Giesen’s excellent blog post for more information.

References

MSDN – Viewports and Clipping (Direct3D 9)
Frustum planes from the projection matrix
OpenGL Transformations

Checking Unix Executable Dependencies

Tonight I needed to check the runtime dependencies of a native unix executable. Luckily this can be achieved with a single command using the ldd utility (linux) or otool (MacOSX) to print a list of shared object dependencies as follows;

Linux

ldd myapp

MacOSX

otool -L myapp

Example Output

linux-gate.so.1 => (0xb76f8000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7601000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb75d5000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb75b6000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb759b000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb73f6000)
/lib/ld-linux.so.2 (0xb76f9000)

Creating Your Own Ubuntu Unity Launcher

Today I needed to setup a custom unity launcher for an application which would show in the unity dash and could be pinned to the unity launcher after launch. It turns out that unity launcher entries are represented as “.desktop” files and reside in the following location:

/usr/share/applications

or additionally per-user in the following location:

~/.local/share/applications

Below is a template for creating your own .desktop file, simply edit this to suit your application, the entries in the file should fairly self explanatory.

#!/usr/bin/env xdg-open
 
[Desktop Entry]
Name=Sublime Text Editor
Comment=Sublime Text Editor
Exec="/usr/bin/sublime" %F
MimeType=text/plain;
Terminal=false
Type=Application
Icon=/home/mimir/sublime.png
Categories=GNOME;GTK;Utility;TextEditor;Development;Utility;

Unit Testing Talks

Some interesting talks on Unit Testing from Roy Osherove.

Understanding Test Driven Development: video

Unit Testing Best Practices: video

Understanding Mock Objects: video

Command Line Aliases/Macros

Preface

Entering long winded commands with many parameters, paths and redirection in the shell/terminal can be time consuming, repetitive and prone to human error. Luckily on both Windows and on Linux you can provide simple abbreviations for long commands.

Windows

On Windows the DOSKEY command (provided by default with the operating system) is pretty versatile and can be used to easily configure macros and command abbreviations. DOSKEY is actually resident during all Windows command line sessions and is the underlying system responsible for maintaining the command history (which can be navigate with the updown/pgup/pgdown keys). Below I have listed some example usages of DOSKEY;

# Note: The $G character is a special doskey escape character for the
#       redirect character '>' which allows it to be specified as part of
#       the command without redirecting the doskey command itself.

doskey /history                                       # Show history of all previously run commands
doskey /reinstall                                     # Clear command history
doskey here=explorer .                                # Add 'here' macro to open an explorer window at the current location
doskey desktop=cd "%USERPROFILE%\Desktop"             # Add 'desktop' macro which takes you to the current user's desktop
doskey mp3list=dir %CD%\*.mp3 /S /O:N $G mp3list.txt  # Add 'mp3list' macro to recursively and alphabetically list all .mp3
                                                      # files below the current directory, inside mp3list.txt

Note: Any macros configured using doskey are only active for the active command line session. To create macros which persist between sessions consider placing all macro creation commands in a batch script, you then have two options:

1. Create a shortcut which opens the command line and runs your batch script immediately (shortcut location = %comspec% /k %path_to_script%)
2. Use an alternative command line environment such as Console2 which can be configured to automatically run your batch script on start-up.

Linux/OSX

On Unix-esque systems it’s pretty much the same kind of setup using the alias command. Some example usages are listed below;

# Note: All alias entries are wrapped in single quotes so there is no requirement for special alias
#       escape characters for piping / redirecting streams

alias here='nautilus ${PWD}'                          # Add 'here' macro to open a nautilus window at the current location
type here                                             # Prints the expanded version of the 'here' macro
unalias here                                          # Unregister the 'here' alias
alias blog='firefox http://tomtech999.wordpress.com'  # Add a 'blog' alias to open your blog in firefox
alias dumpenv='export -p | grep "/" > env.txt'        # Dump all bash environment variables containing a path to 'paths.txt'

Note: As with DOSKEY on Windows, any macros configured using ‘alias’ are only active for the active bash shell session. The easiest way to make aliases persist between bash sessions is to add all of your alias commands to the bashrc shell configuration file located in your home directory (~/.bashrc ). This script is executed whenever you open a bash shell and can be used to automatically register aliases for all bash sessions.

References

Microsoft DOSKEY Documentation
10 Handy Bash Aliases
Hak5 Linux Temrinal 101 – Create Your Own Commands
30 Handy Bash Shell Aliases For Linux/Unix/MacOSX

Symlinks on Mac OSX

Setting up symlinks on OSX is a breeze…

Example

sudo ln -s "/Applications/myapp.app/Contents/bin/myapp" /bin/myapp

This also has the additional benefit of adding myapp to the $PATH as /etc/paths contains an entry for /bin by default. Now the app is added to the path it can be launched within the terminal from any location.