To iterate is human, to recurse divine.

Oversight hits 1.0

Posted: July 10th, 2010 | Author: | Filed under: Soapbox | No Comments »



Just a short blurb that Oversight, the WoW addon, has hit 1.0 and is now available both here as well as at WoWInterface. Enjoy!

Oversight goes Beta!

Posted: March 20th, 2010 | Author: | Filed under: Soapbox | No Comments »

So the WoW addon finally made it to beta. For all you PvP buffs out there, the main Oversight page can be found here with download link and all. This is one of the few projects I’ve actually undertaken to do myself. I didn’t want to take on a full-fledged game as I would undoubtedly delay and defer. Indeed, even this one did get delayed in favour of actual paying work.

Also, in the course of doing this, I discovered Sony Vegas. It seems really popular amongst the machinima people, and rightly so. It’s sooo easy to use. Much easier than Premier Pro. I put together this second video in scarcely less than a night’s work. Also spent the $68 on it, and it feels well worth it. That’s how software ought to be made.

I also got new hardware. I’m now sporting double 22″ LCD widescreen monitors, and a back-lit Razer Lycosa keyboard. It’s so handy, but more importantly, it makes me feel more like a professional developer!

Taming Visual Studio

Posted: March 3rd, 2010 | Author: | Filed under: Tutorials | No Comments »

This is a guide to setting up Visual Studio to make use a folder structure that is flexible and portable across multiple machines. It is intended for students, which is why no templates are included. After all, you are supposed to understand what each of the settings do!

Stay Away!

A lot of SDKs have tutorials and guides on installation, and advise that you make changes from the Tools > Options  screen as shown here. Don’t do it! What this does is make global changes to Visual Studio so that all your projects will use the same copy of the SDK. This means that you will find it difficult to use different versions of the SDK on different projects on the same computer. Also, if you pass your code to anybody else, they will need to get a copy of the exact same version of the library you are using and install it on their machines in a similar way in order to compile your code. The only SDK where it is permissible to touch this menu at all is DirectX, and that is because it is installed in an anal OS-monopolistic fashion. For anything else, follow the procedure below.

Our target is to get a working folder structure something like what follows. The bin folder will contain your executables. The lib folder will contain all your SDKs. The obj folder will contain all your object files so they may be discarded later. The project folders will contain the source code and project files of the various projects you have in the solution. This allows you to distribute your work in the following ways:

  • For end users, just give them a copy of the bin folder. That is all they need to run the program.
  • For source code inspection, just give them the project folder(s). Useful if you have quick questions on code snippets.
  • For distributing your source code, delete the obj folder and the intellisense file, and send the rest. This will ensure the end user can compile a copy of their own. This is what I expect to be submitted to me for assignments.

Creating a new project

So let’s get started. First thing is to create a new project from the File > New > Project menu. This will give you a choice of various types of projects to create. What you want to create is either a Win32 Console Application, or a Win32 Project. The Console App will provide you with a DOS box that you can cout to at whim. The main entry point for this would be main(). The Win32 project, on the other hand, makes a standard windows application without any console (unless you hack it in). The main entry point for this would be WinMain(). Make sure to tick the “Create directory for solution” checkbox.


After you fill in a suitable name for the project and click OK, you will come to this screen. Do not Finish immediately. Instead click on Application Settings. The top 4 options lets you change your mind and build a console app or Win32 project or even a library… talk about redundancy. In the checkbox below however, you want to tick “Create Empty Project”. If you do not do this, Visual Studio will create a lot of junk for you that you will need to clear out later. After you are done, click Finish.

Once you are done, the project will be created. I personally like to delete the “Header”, “Source” and “Resource” folders so I can implement my own structure, but that is up to your preference. What you must do, is add a blank .cpp file to your project. It doesn’t matter what you call it or what’s in it. What this does is tell Visual Studio that this is indeed a C++ project, so it will show you all the relevant C++ options. Never mind that the application I installed was Visual C++ Express. After you have done that, go to Project > Properties to configure your project.


The first thing you should do here, change the configuration to “All Configurations” so that you affect both the release and debug builds. Next, expand “Configuration Properties” on the left, and select the “General” category. Here you will change the output folders, to comply with the specifications we have above. These are the changes I made:

  • Output Directory, this is where all the exe files are made. Set it to $(SolutionDir)bin
  • Intermediate Directory, this is where all the obj files are made. Set it to $(SolutionDir)obj/$(ProjectName)/$(ConfigurationName)
  • Character Set, this changes all your strings to wide character strings. For game projects, you really shouldn’t be depending on the compiler for implementing unicode anyway. So set it to “Not Set”.


After that, click on the “Debug” category. Here, there is only one change to make. However, this setting needs to be set up for every single computer you move the project to. This is because Microsoft, in their infinite wisdom, decided that this particular setting should be personalized to each user. So don’t forget this every time you copy the project from one computer to another.

  • Working Directory, this is where your application will launch from when run from Visual Studio. Set it to $(OutputDir)

Include Folders

Next, click on the C/C++ category. If you do not see the same screen as in the screenshot, expand it out and click on general. Here, you will only change one setting, which is the “Additional Include Directories”. You will set this up to point at the include folder of whichever SDK(s) you are using. Multiple folders can be included by separating them with a “;”. Alternatively, doubleclick on the box and you can browse to each of the individual folders. Make sure that all your folders are set up relative to your Solution folder. This will ensure that your project, when copied over, will still be able to find the include files it needs. This means that every single one of the entries here should begin with $(SolutionDir)lib/


  • $(SolutionDir)lib/ogre/include
  • $(SolutionDir)lib/hge/include

Linker Options

Next, expand out “Linker” and click on “General”, which is just under it. Here, just like the include folders, you will tell Visual studio where all the lib folders are by changing the entry “Additional Libarary Directories”. The setup is exactly the same. All entries are seperated by “;”. Examples:

  • $(SolutionDir)lib/ogre/lib
  • $(SolutionDir)lib/hge/lib/vc

Still on the same tab, the next bit is tricky. First, you will want to set the configuration to Debug, so that you only affect the debug build. It may prompt you to save settings, which you should agree to.  After that, change the “Output File” from “$(OutDir)\$(ProjectName).exe” to “$(OutDir)\$(ProjectName)_d.exe”. After that, apply your changes and set the configuration back to “All Configurations”. What this does is make sure that all your debug builds have a “_d” at the end of the exe names, so you can readily identify if your binaries are debug or release.

Additional Libraries

Next, still under “Linker”, switch to the next subcategory, “Input”.  Here, under “Additional Dependencies”, you will list down the .lib files that your SDK requires you to link into your project. These, in a great show of consistency, are not separated by a “;” like everything else, but are instead separated by a single space. Once you have added those in, you are done with project settings and can click OK. Your project is all set up… almost.

Do not forget to copy an .dll files that your SDKs might need into your bin folder. Also, if you need to include any additional assets in your project like artwork or sounds, the bin folder is where it’s all at. That is your base. And that… is all!

No longer United, we make an Ogre out of it.

Posted: March 1st, 2010 | Author: | Filed under: Soapbox | 2 Comments »
Unity 3D

Unity 3D

As the saying goes… it was love at first sight, then I took a second look! You had my first impressions from a previous post. It is indeed a very user-friendly platform for the indie developer working on smaller projects. However, when you scale up, there are several glaring issues.

First and foremost is asset management. When you have a team, or even just more than one person working on a project, you want some way to be able to synchronize your efforts. The defacto tool I’ve been using for this is Subversion. However, Subversion cannot work well with Unity iPhone. A lot of their linkage meta-information is stored in binary files that do not merge well in case of conflict. Unity Pro, for other platforms is supposed to have some switch to enable subversion support. But for the iPhone, we are bone dry.

The solution to this, is Unity Asset Server, which comes in at a hefty $200 per head in addition to your Unity Pro license. From the reviews I’ve been reading, it isn’t that good at doing its job either, making it difficult for me to recommend to my studio head.

The second problem is compilation and import times. As the number of assets grow, it takes a longer time for Unity to grab them and put them within the development environment. Also, the time it takes to compile to device also seems to grow almost exponentially. So not only do I have my developers hovering over one machine waiting to link their scripts in, but those that are actually on it are twiddling their thumbs waiting for the binaries to compile. Not exactly the pinnacle of productivity.

The final nail in the coffin is performance. On the iPhone 3G(S), our small demo level runs at a steady 30 fps, which is all fine and dandy. However, on first-gen or second-gen devices, this drops to a dismal 10 fps. We shudder to think what the bigger levels would run at.

So we bit the bullet and said goodbye to Unity, and all the licensing costs we invested in it, and looked to other alternatives. Shiva, being similar in concept, would most likely be the same deal. Irrlicht has reportedly been successfully ported over to the iPhone and used in a few commercial projects. Unfortunately, these ports are not publicly available, and I’ve no appetite for grinding my own. The SIO2 engine looks ready, but I didn’t quite like the structure and documentation.

In the end, it’s back to Ogre. Even though the iPhone port is on RC1, and getting it set up and ready to work in our production environment took a bit of legwork (so spoilt from plug-and-play SDKs), it seems fairly stable and performs reasonably well. With 20fps as my lowest cutoff benchmark, I could render 20,000 triangles onscreen on a first-gen iPhone. 30,000 for a second-gen. And a whopping 165,000 for a 3G(S).

Legal e-Books

Posted: February 16th, 2010 | Author: | Filed under: Soapbox | No Comments »


So there was much discussion in one of my classes about shifting our 3D programming module from DirectX to OpenGL. While this is by no means set in stone yet, I decided to go out and do some research. And so I went to the store to look for the red book and the orange book. They were exactly what I wanted so I hefted the two-book compedium, then I stopped.

These things are heavy! Who in the modern twenty-first century world would lug such things around? There must be an ebook version somewhere, right? So I went to They had the book, but no e-copies. Neither did Barnes and Nobles. So as per standard procedure, I asked the great Google god. Google god pointed me at all manner of torrents and rapidshare downloads. Ugh, no wonder piracy is so rampant nowadays. Things just aren’t acessible!

There was a site though, called InformIT, that is apparently some spawn of Pearson. Sounds reputable enough. So I went in and took a look. Indeed they were selling the ebooks, and a cheaper price than the regular books too. So with glee, I bought up the orange book. The download came in a pdf format that was instantly accessible when I completed payment. There was no DRM or annoying proprietary formats in the way. So I’m happily going to upload this to my iPod Touch for reading on the go without having to go through some sort of fitness regimen.


Posted: February 3rd, 2010 | Author: | Filed under: Projects | 7 Comments »

Oversight is a stand-alone mod made for World of Warcraft. It is a unit frames Addon specially designed for arena and battleground play to present data in a way that is easier to assimilate by the average or beginner player. It may also find use by advanced players when making videos to better illustrate their strategies and swaps as targeting is made very visible to the user.


Latest Changes in 1.02(a)

  • Fixed issue where in BGs and raids, the team members would be wrongly locked.
  • Updated to be compatible with patch 4.01
  • Temporarily disabled spec detection.
  • No default buff list provided till I have time to weed through the spell ids. Existing buff lists on old characters however, will remain. You can still copy profiles between characters.

Latest Changes in 1.01

  • Pet health bars and bars in general made more responsive.
  • Removed now-redundant Russian translation for buff list.

Latest Changes in 1.0

  • Coloured health bars to turn red with health status
  • Made default buff list local agnostic
  • Bugfix for DRs not always disappearing when expired
  • Bugfix for not all frames updating if the same unit is in multiple frames
  • Coloured player names with their class colours

Latest Changes in 0.91

  • Added option to turn off cast warning sound
  • Bugfix for said warning sound not always going off
  • Bugfix on PvP Trinket indicator to make it locale agnostic
  • Added Russian translation for default buff list. Translation courtesy of Кагасиро – Вечная Песня E


  • Movable, scalable unit frames arranged in a pleasing circular formation.
  • Original Blizzard unit frame artwork, because circles are cool.
  • Enemy frames are party targets during normal use, but are arena opponents when inside an arena.
  • Spotlight targeting system to visibly show who’s targeting whom, with a number of spotlight options.
  • Cast bar for each tracked unit.
  • Aura configuration so that specific buffs/debuffs may be displayed for ally or enemy players. Aura’s may be shown in a ranked list of seven, or may replace the character’s portrait.
  • Configurable Unit Frame highlighting for poison, curse, magic and disease debuffs on friendly players, as well as dispellable buffs on enemy players.
  • Race portraits for all units except pets.
  • Raid target icons display.
  • Spec detection and display.
  • Locking of party member frames so that the same party members are displayed in the same order and same raid target icons when entering battlegrounds or arenas.
  • Sound alert for when the focus target is casting a spell, or when the target is casting a spell if there is no focus target.
  • Diminishing returns tracker that tracks up to six diminishing return types.
  • PvP Trinket tracker.
  • Profile manager to copy configurations from other characters.
  • Extremely low resource usage.
  • Does not depend on the combat log.

Known Issues

  • Diminishing returns will count down on a selected target if the target was previously selected and had a non-expired debuff of that DR type. This is because Oversight has no way of knowing when exactly the debuff expired unless somebody had it targeted at the time.

In Unity we stand!

Posted: January 28th, 2010 | Author: | Filed under: Soapbox | 1 Comment »
Unity 3D

Unity 3D

So one of the projects I’m currently working on that (being so covered in the traditional game-development shroud of secrecy that I cannot reveal anything about lest they deem it necessary to terminate my immediate existence)  uses the Unity engine for iPhone development. I believe there are also hopes that this may expand to encompass the newly announced iPad.

So how easy is it to create games using this new toy? Pretty easy it seems, to begin with anyway. Grab 3D models from your artists and drag/drop them into your assets folder, and they automagically appear in your editor. Match it with the appropriate texture, add a few scripts to implement behavior, and voila, instant game! At least that’s how the theory goes anyway.

How does it measure up in real life? Not so good, though admittedly, it could be due to the limitations of the iPhone edition, as well as my own relative inexperience with the engine. As I suppose could be expected, there’s the performance limitation for the iPhone. We’re limiting ourselves to 400ish polys for the main characters and 100 or less for environmental objects. The terrain engine is unsupported on the iPhone, so our terrain is merely a simple mesh. Also unsupported are shaders (though there’s said to be some emulation thing we haven’t figured out), and things like stencil shadows. Some developers have apparently been devolving to ancient techniques that from the 80’s to produce better-than-blob shadows.

Then there are other unsupported features like networking. Unity comes with full multiplayer support thanks to Raknet (which incidentally is my favorite network library). However, this is not supported on the iPhone platform. There are theoretically .Net sockets, but my junior programmers have opted to write their own plugins in Objective C, so they can incorporate multiplayer bluetooth support as well.

The GUI system is important because this is a major yardstick for the polish of the game. Unity chose the interesting approach of having their GUI system mostly script based. This makes it very possible to create spiffy animated UIs with all sorts of effects only limited by the programmer’s imagination. There doesn’t seem to be a visual editor for it, so the artists are at the mercy of the programmers to implement their visions. To be honest, I like it this way, as artists seldom have the mathematical background to implement the beautiful movements that programmers can pull off rather efficiently. The could do it with a Flash-like editor, but I guess that is something that Unity could eventually evolve towards.

Scripting happens in a choice of Javascript-like or C#-like languages that run on top of Mono. The team has mostly opted for the Javascript approach because it looks more familiar to most. As far as scripting behavior goes, it is pretty good, and I haven’t found anything glaring to complain about. It gets the job done. I’ve yet to see if we can do more esoteric operations, like programmatically attaching meshes to bones, controlling animation cycles and digging into the guts of the engine. How deep can you go in a drag/drop game editor? That’s yet to be tested!

Overall, I am happy but not. It certainly does the job. I don’t feel like I’ll have as much control over the process as I would with a traditional engine, which is to be expected. The limitations for the iPhone version put a severe cramp on our style, but the PC version looks pretty promising from this side of the proverbial fence.