Code.Fu: Quickly testing if a positive integer is a power of 2.

If you are a graphics programmer you will often need to test if an integer is a power of 2. To do this you can exploit a neat trick using binary arithmetic. This trick will work with all positive integers.

Lets say the number you are testing is 4. Take a look at the simple binary arithmetic below:

  4 --> 0100‬ (binary)
- 1 --> 0001
  3 --> 0011

  4 --> 0100
& 3 --> 0011
  0 --> 0000

In short, you subtract 1 from the number and do a binary ‘AND’ of the result and the original number. If the number is a power of two, the result you get will always be 0.  The only exception is 0 itself, which will return 0 in the above operation. Depending on your application you may or may not want that.


#define bool int /*remove this line for C++*/

bool is_powof_2(int x)
  return ((x & (x-1)) == 0);

bool is_powof_2_excl_0(int x)
  return (x != 0) && ((x & (x-1)) == 0);


def is_powof_2(x):
	return ((x & (x-1)) == 0)

def is_powof_2_excl_0(x):
	return (x != 0) and ((x & (x-1)) == 0)

Visual Studio Community Edition (Free).

Microsoft has released free Visual Studio Community Edition. It’s basically a free full featured Visual Studio IDE (apparently with everything included) that can be used to make all kinds of apps. I was even surprised to find support for Python and Git included. Even more surprising was the Apple and Android logos in the “supported platforms” section!


Direct3D 10/11 coming to Linux … What about games?

No, April 1st is still more than 6 months away, and yes you heard me right — Direct3D versions 10 and 11 are indeed coming to Linux. How is this even possible?  Well it is possible, since nouveau moved on to Gallium 3D which allows Direct3D API (actually any API) to be exposed via a front end called a state tracker. Interestingly (, and there seems to be a lot of confusion going about on public forums) Direct3D will be a Native API under Gallium, much like OpenGL is currently. It won’t be a something that emulates Direct3D by using wrappers around OpenGL — meaning you will be able to write and compile Direct3D code directly on Linux or BSD based systems that support the nouveau driver. Initially I was a bit skeptical of such an approach since Direct3D API is integrated with Win32 API, but the author seems to have solved this by using Wine headers. I don’t know the pitfalls (if any) of such an approach, but it seems to have worked for him and would seem a logical path to take (instead of breaking API compatibility). He clearly outlines the motivation behind doing the Direct3D port, and kudos to him for doing something that was but inevitable given a no show of Longs Peak.

Naturally a native Direct3D implementation will allow game developers to write code that is cross-platform and even allow existing engines/games that use Direct3D versions 10 and higher to be ported across to platforms that have a Gallium driver. W00t! This is amazing, almost too good to be true isn’t it? But before we gamers jump in joy, there are still a few things that have to fall in place before things can get up and running with regards to Direct3D on Linux. First and foremost is support. Hardware vendors like Nvidia and AMD must support Gallium in their drivers, or OSS drivers must be written (and are being written) to take their place. This is paramount since without such an interface, no front end API (Direct3D or OpenGL) will be able to use hardware acceleration via Gallium. Second, and more importantly, the guys at Redmond must allow such an implementation of their Direct3D API. An API itself can’t be copyrighted. The author seems to have steered clear of any Microsoft code, so theoretically this shouldn’t be a problem. But then again I am no legal eagle, so I can’t really say anything w.r.t. this. There have been rumors that there are patents on sections of Direct3D. I am not sure what that means, or for that matter if it is even possible to patent sections of an API/Library. But, things could get potentially messy if Microsoft were to place a cease and desist on this new development. I doubt this would happen, but you never know.

I have to agree, having Direct3D as a native API via Gallium does open up a lot of possibilities for OSS platforms that have severely lacked games. Accelerated graphics on most systems apart from Windows have had little choice up until now with OpenGL being the only real option. But does this really mean that all of the games that are developed and are being developed will be ported to Linux and other OSS platforms? That’s an interesting question and the answer isn’t quite that simple. Lets look at the macro picture of the industry. For AAA games the PC platform isn’t a priority. Most (maybe all) AAA games are today made with consoles in mind. Yes there maybe a PC port, but it’s the consoles that are the main priority. Most (if not all) gamers that play AAA games on the PC do spend a bang on their systems and most of them already have Windows as their main OS. Some do have *NIX systems but even these few have a Windows partition that they keep around specifically for games. Porting any software to a new platform isn’t a trivial task. Even with the best coding practices and methods, it requires a lot of resources — which aren’t free. Everything from coding, testing, maintaining build setups, writing install scripts and many other things requires time and money. For  a AAA game, or for that matter for any game or software, a port to a new platform should show a robust ROI (return on investment). That’s where the crux of the problem lies. There aren’t that many *NIX gamers out there, and if there are, the big studios aren’t seeing them!

Then there are the casual games, which also is a big market for games. Casual games represent a very different kind of audience. A typical casual gamer is a non technical person who doesn’t even understand what a hardware driver is, let alone jargons like Gallium, Direct3D, OpenGL or for that matter Linux. Most casual gamers will have nothing but a moderately powerful laptop with on-board Intel graphics chips — which came with Windows pre-installed. This is the kind of player that expects the game to install and run with a single click. They don’t understand driver updates or DirectX versions. For them it matters little which API is better or worse or which platform supports which API and which doesn’t. Apart form these two broad segments, there are a whole lot of players who will play radical indie games and this is probably where Linux ports has found some success. This gamer is the tech savvy computer geek who runs Linux as his/her primary system and isn’t afraid to fire up the console now and then. I must say, some radical indie games have found success in this area. But, these games are far from cutting edge. They maybe very good games, but you don’t expect Crysis like graphics from them, and it matters little what API is used or if the underlying API runs 5% slower when your game is not going below the 30FPS barrier.

There have been lots of debates about OpenGL vs Direct3D. I refrain to go into that. However, having a choice of accelerated graphics API for platforms other than Windows is definitely good all around. Direct3D versions 10 and 11 are well designed APIs, closely tied to current generation hardware. But will all this translate into more ports of games to Linux and BSDs is still an open question. The community as always will play a vital role and only time will tell how things pan out.

DirectX 11 hardware is here.

It’s almost time for Windows 7 and along with that the first lot of DirectX 11 class hardware has started to appear. This time the first off the block was, surprise surprise, ATI. The 5800 series cards were released a couple of days ago and there are already impressive reviews about the new cards all around. I am sure it wont be long before Nvidia, which has been uncannily silent, comes out with their line-up. So it is safe to assume that there will be DirectX 11 class hardware on the shelves going into Windows 7 release (Windows 7 RC already has DX 11 support and will also be available for Vista soon). It will however, still take a few weeks more for the initial euphoria to settle, and we should see prices of the cards drop around the holiday season, and probably that is when I will go in for an upgrade as well. I have been running the HD 4850 for some time now and thus far it’s proving to be sufficient, not only for gaming but also for my programming needs. The HD 4850 has been surprisingly good given it’s price point and one would expect the same from 5800 series given the already positive reviews.

There are a couple of things that are in favour of DirectX 11. The first is the API itself. DirectX 11 offers more than just a simple evolutionary upgrade (more here). DirectX 10 was mostly a non event. The enormous success and the longevity of XP and the XBox 360 ensured that the 9 version of the API far outlived  most expectations (and probably will continue to live for some time to come). The story of DirectX 10 is also intrinsically connected to Vista. Vista’s low adoption meant not enough people were running a DirectX 10 capable software platform, which Microsoft stubbornly refused to port to XP for whatever reasons. Even though 10 class hardware was available during Vista’s reign, nagging hardware issues and poorly implemented drivers meant DirectX 10 never really caught on like 9 did.

That brings us to the second point in favour of DirectX 11 — Windows 7. XP is old, and I mean seriously old. I am still running a 2004 copy of XP on my machine and though it’s doing it’s job admirably, it’s due for an upgrade. Windows 7 seems to have gotten over those little annoying quirks of Vista which we hated and shouted so much about. My hunch is most people who have stuck with XP will probably upgrade too. Maybe not on immediate release, but 2-3 months down the line when things settle in, after those initial bugs have been addressed and more and more reviews of the OS come out; 7 should slowly see wider adoption. With Vista it seemed like things were rushed into and hyped up. In contrast Microsoft has been careful with Windows 7. The RC of Windows 7 has been somewhat of a “soft launch” and though I haven’t myself had the chance to try it out, it would seem (from reviews and from what people are saying) Windows 7 is much better off than what Vista was. So it’s fair to assume that 7 will catch on more than Vista and in the process DirectX 11 will “get on” to the Desktop.

Does it mean DirectX 11 will be the defacto API for coming games? For that lets look at the games developed today. Yes most of the games that are developed today are still developed primarily for  DirectX 9.0 class hardware. Why? Consoles that’s why. You do see AAA titles advertise DirectX 10 and 10.1 support, but even those games are developed with DirectX 9.0 class hardware in mind. Yes some features here and there, usually eye-candy to impress your overzealous graphics fanboi can be found, but the engine and tech itself is designed for platform compatibility. Which ironically means not all of the features of the newer DirectX versions are exploited.  As I said before, DirectX 11 is more than just a simple upgrade to the API, it’s also a new way to do things. But since the older hardware still has to be supported, compromises have to be made. There are probably no AAA titles exclusively for the PC, so even if PCs all around were to have DirectX 11 support, it’s not until the consoles catch up will you see all the cool things the newer API has to offer come to the fore.

There is little doubt that version 11 of will make games look better. But there is so much more to the API than just improving looks for games. Many of the features in the new API mirror hardware changes that have taken place, like moving away from the fixed function pipeline, the evolution of GPUs as massively parallel compute devices. All this does mean that DirectX 11 is an API to look at seriously. But how quickly will games start using all these features? I guess only time will tell.

A new game with a new engine.

Holy cr*p! It’s been like 40 days since I have posted anything! That’s probably the longest the blog has gone silent. Well, that’s partly because I have been working on a new game and yes a new game engine. The new game will not be a 3D game but a 2D game. No, I haven’t abandoned the O2 game engine, to the contrary the O2 Game engine has had quite a few updates to it. So why another game engine?

Long long ago (, maybe not far far away) when I was designing/prototyping the O2 engine, I had plans for it to be a 2D and a 3D game engine. Overambitious? Yeah, maybe. But tell me who hasn’t had overambitious design plans?  Anyway, during that time a lot of design went into the 2D part. I even went ahead and created a mock prototype of 2D game builder UI. In any case, that was soon put on the back burner since we started in earnest on the 3D game. The design however, lingered in the archives, until I had the time to revisit it after the Doofus game was completed. Instead of letting the design rot, I decided to peruse and finish the 2D part.

A couple of problems immediately arose when I had a re-looked. The O2 engine is designed to be a 3D engine and a lot of abstraction has been made to ensure that the engine does 3D properly and efficiently. That’s not really required for 2D. 2D is a lot less complicated than 3D and most of the sections of the 3D game engine felt over-engineered when considered in the context of 2D. Most of the book-keeping required for 3D is down right unnecessary for 2D. In the end the two designs were a significant overlap, so I decided to rehash the 2D concept using similar design but start over from the engine core. Basically meaning, a rewrite of a significant section of the game engine code.  To my surprise the process was completed far sooner than anticipated, and that too without significant regressions. Yes the new engine uses a lot of same code-base as the O2 engine, but the engine itself is very different from the 3D engine.

Next came the game. There was an old prototyped 2D game (more details soon) that was lying with me for ages. Most of the game was polished up and ported to the new engine (lesson: Never throw away your old experimental code; ever. 😀 ),  and that’s about it. I am pretty happy with the results of my 2D experiment thus far. Completing a game is a complicated process. It requires a lot of things to come together and work correctly. True, 2D is lot easier than 3D, but there is still work to be done finishing the game and I hate to give out a release date just yet (, because of the fear of being proved abjectly wrong yet again 😀 ) .

Is online gaming technology the future of social networking?

Yes we are all hooked on to Facebook and Twitter, maybe some of us more than others, but what does the future hold for social networking? It’s interesting, but if you were to look at it, online virtual worlds are becoming a lot like social networking sites. I was reading Shawn Fanning’s remarks on online games and it got me thinking about social networking in a virtual world. His technology Rupture attempts to connect gamers together via a common API/Interface. Your typical online game will probably feature quest and sub-quests; not your typical social networking activities. That said, the idea of having “social networking” in a virtual word is not something new. Second Life is probably the best example of how future social networking could be. To me a future 3D social networking virtual world would be something that I can log on to and create applications for. Something like a 3D Facebook, something having it’s own API that can be coded to. While Second Life does offer some capability to create your own content, what is needed is probably much more. How about allowing me to create my own little game in a 3D world? Maybe a full online game inside the service itself, something along the lines of a Facebook app/game. Ah! That would be amazing indeed!

Not all social networking users are actual gamers — but in a way they are. Most people will often end up playing those small little games or interact with others apps which give you an often ridiculous score that users like to brag about to other users/friends/community members. “Ooh lookey here, I have an IQ equal to Einstein” or “Joe Facebooker got 2,000,000 points on SomeApp” are all too common. People like to compete — and at the same time also like to interact, join communities. What current SN sites do is allow people to build communities and groups easily and rapidly — the two most important aspects for a success of an online game! With the advent of sites like Facebook, literally 100s of online games and apps have found easy adoption without needing to worry about things like server programming, latency, hosting, hardware, and you name it. The list goes on. However the most important thing they have cashed in on is an easier way to build communities for their products. Creating an online game/app today is not an easy task, besides the obvious engineering difficulties it is equally difficult to build successful community around an online game/app. Some future service that abstracts all these aspects and allows people to easily and rapidly build apps and games would probably be the social networking virtual world of tomorrow.


Last night I was clearing the hard-dive to free up much needed space and I happen to run across an old zip file and in it was my older experimental engine — something I was working on long before I began work on the O2 Game engine. Well you can’t really call it an engine — it’s what you call; a bunch of experimental code hacked, stretched, hammered and stitched together to produce something that can be displayed on the screen 😀 . A more appropriate name would be a prototype or a demo. I was looking at the code and couldn’t help but wonder how I could comprehend anything inside those bunch of lines back then. To my surprise, the code still complied pretty easily on the new VC 8.0 Express. The app runs at 500+ FPS on the HD 4850 at 1280×1024, back then (, if I remember correctly) it ran at 40-50 FPS on a Riva TnT at 640×480.

experiment 1
Quake 3 Level – missing textures and shaders appear white.

Experiment 2

Another Quake 3 Level in the prototype engine.

Cool ain’t it. Well sorta, but lets take that with a pinch of salt. First, those levels that you see are some really cool Quake 3 Levels that I had downloaded off the internet. They are not created by me. I had written up a Quake 3 Level loader for the demo and albeit incomplete, was pretty good at loading most Quake levels. The lighting was obviously Quake 3’s internal Lightmaps. The collision system was rudimentary and navigation (running around in the level) was a huge problem. There were times when the collision system would completely fail and one would fall through the floor into the dark abyss below. MD3 animation was crap, so there were no players in the level, though I remember I was working on a skeletal animation library later on, but I guess I never integrated it with this piece of code. Oh well!

Baby steps I would say. Obviously I learnt a lot from hacking around that piece of code. But could I have created a game with that? The answer is — No I would not have. With all that was achieved, you wouldn’t be able to pull together anthing more than a short cool looking demo — period! The code is too haphazardly written and has no structure and I would only term it as research and learning material. Even then it’s a bit nostalgic to see some of your old code run 🙂 , and man it still does look cool at higher resolutions!

The world of 2D.

Well as I have said in my earlier  post I am currently working on some tech related to 2D gaming. Actually, working against the clock to finish the current project, which on all accounts is somewhat of a diversion from my main goal. However it has also given me time to retrospect and understand how things are in the world of 2D gaming (when compared to 3D). No, it doesn’t mean I am giving up on 3D, actually most of the tech I am using is from the O2 Game Engine, custom fitted to the 2D technology I am working on. Basically 2D is 3D with a fixed Z. People generally move from 2D to 3D but I seemed to have moved the other way around. The whole experience is kinda funny, because I can now truly appreciate how things with 2D really are.

Building quality 2D games is a lot easier than building quality 3D games. Actually creating 2D games is an order of  magnitude easier than 3D, or so I have heard 😀 . Having said that, the foundations of both technologies are extremely similar. Most of the tech I have designed for 2D is almost a reflection of the O2 Engine. True, it is not as complicated as the 3D engine, but majority of  the higher level design is similar to what was already put into the main 3D engine. I had initially decided to use the 3D engine as is, but the O2 engine is just far too complex for 2D. There were too many things that didn’t feel right for simple 2D. So it made sense to use an already existing third party 2D engine and parts of the O2 game engine to build the higher level framework that was missing. Simplicity was the deciding factor, since the primary focus of the tech is quick 2D game development and prototyping.

The second and most compelling reason was time. The project has be finished quickly in a matter of weeks so majority of the focus has been on using and integrating already existing tools and libraries. The project on the whole is simple, but it has a complex UI and involves integration of a lot of  libraries with a lot of functionality exposed via the UI, making the game builder UI the major challenge (more than the engine and the tech).

The project is still very much under development. I will post some screens and more details as soon as we hit alpha stages.

New Project.

I was a bit hush hush about my current activities, but I guess it’s OK to talk about it now that the project has been put on track. I am not revealing too many details as yet, but I can tell you what it is going to be. Well it’s actually a smaller project considering the my previous one (Doofus Longears – The game), lot easier in complexity and pretty small in size. Yes, it is related to games and gaming and involves a game, but it’s not a 3D project — it is 2D. Well it is 3D under the hood since it is based on Direct3D but it rarely uses the third dimension so it’s not 3D per say. The entire project involves creation of a game, which I must say is pretty trivial, but more than that it involves the creation of a generic game builder software, the work for which is already under way. The name of the entire thing is still under wraps, but you should see it come out in later entries.

The engine is an already written, accomplished 2D engine — no I am not writing the engine this time. The major job is to create an elaborate game builder (GUI), a designer, a scripting engine (Lua in this case) on top of the engine and integration of the engine and the scripting system into the game builder and designer. The game will be built on top of the scripting engine and should be pretty simple to make once the game builder and the scripting systems are in place and properly integrated. The game builder is designed to be generic enough to make any kind of 2D game (arcade, adventure, platformer, puzzle,…)

So — Yes, I am taking a holiday from our engine for a while, I hope only for a little while. I have been up to some interesting R&D which I hope I can integrated into the O2 Engine soon. It’s been a long time since I worked on a 2D game, almost 7 years now since I wrote a 2D pacman clone. The game had 3 levels and crappy graphics, makes me laugh looking at it now. But hey — that’s how you learn.

As it stands today, a fair amount of  progress has been made on the GUI side of things. A lot still remains to be done with integration, but 2D games are lot simpler than 3D ones so I hope and can tide over this project pretty soon. More details about the project and the game builder will be out in due course. I will post some screens of game builder when the game engine is integrated and there is at least a semblance of a game running inside it.

Going data-driven.

As you probably already know, the first Doofus game was released a few weeks back, and though I haven’t fully shaken off the lethargic hangover that accompanied the game release; I am slowly coercing myself  to get back to daily chores. After every project one must look back and take a note of hits and misses of the project development cycle (Causal Analysis). That’s what I have been doing for the past few days, and though there have been lots of those (hits and misses), one of the important lesson I have learned from the whole experience of making the game is the importance of data-driven programming.

Most of the tedious and time consuming activities during development turned out to be simple manipulation and ordering of code. Placing scene-nodes, structuring the scene-graph, ordering render batches, grouping shadowing objects, and the list could go on. Things like these took up ridiculous amounts of time. In the game  all this is done through code — when this could easily have been solved by a more data driven approach. I must admit there were times during development of the project when I yearned (almost cried) for a more flexible system. The problem was a lack of script driven programming, or should I say, a lack of a more data-driven system on top of the engine. Everything with the engine is currently done in C++, except maybe the configuration files. I hate it when you have to recompile 20-30 files just because you had to move a local variable to a class member. This does happen, especially for classes that have a long list of data variables and/or the ones that operate and integrate game data. We had initially planned on integrating a script and data-driven system into the engine, but that was later push down the priority of things to be done — and ultimately pushed out from the release due to lack of time and resources. Through not verbatim, that’s probably the story with every dev project out there that has to keep up with at least some sort of deadline.

In data-driven programming, data controls the flow of the program. Data is not just used to define an object state but also used to control the program flow, sometimes externally. Data-driven programming means writing generic code that consumes data and modifies it’s behavior depending on the structure of  that data. The concept of data driven programming is not new. UNIX utilities  have traditionally been data-driven and many applications use data driven designs. A web browser is a good example of a data driven application. It consumes a web page and modifies it’s behavior based on the structure of the web-page code, in this case HTML. Markups are again an excellent examples of data that encodes structure within itself (XML).

Well, there is a lot to take away from the current project. The engine will be made more data driven in the future, that’s for sure. The game also allowed me to pinpoint exact areas where a data-driven approach is needed. Many of those places wern’t immediately obvious during design.