Why OpenGL 3.0 is Important

May 15, 2008 10 minute read

Some questions have come up in regards to my last post, The Ghost of OpenGL 3.0, and one of them keeps popping out on top: Why do we need OpenGL 3.0 and What’s wrong with OpenGL 2.1? This post will attempt to take you through the pre-published materials on the OpenGL API, version 3.0 and show you the major changes and differences. Or you could simple jump to the answer and conclusion without reading the features provided by OpenGL 3.0, if you don’t feel like getting informed.

Terms used:

• Mutable: something which can change shape or form.
• Immutable: something which cannot change shape or form.
• API: Application Programming Interface, an interface designed to allow transactions with a library or application.

Hardware Evolution

Besides being a graphics API, OpenGL sets a standard for IHVs (Independent Hardware Vendors) to comply with. By doing this, we can be sure that a certain type of hardware is compliant with a specific set of demands, not unlike what Microsoft has been doing with DirectX 10 and higher, albeit not an open standard. For example, OpenGL 2.0 formally introduced the GLSL (OpenGL Shading Language) which was not available in 1.5, thus forcing IHVs to implement the capabilities according to the OpenGL standard.

A comparison with the Direct3D side of things would be the enforcement of Direct3D 10.1 compliance by setting a mandatory requirement of 4x anti-aliasing.

OpenGL 3.0 is said to be able to function on OpenGL 2.1/DirectX 9 level hardware, so basically anything from the GeForce FX series and upwards (supporting High Level shaders).

The Software Side

The OpenGL logoMost of the readers here are programmers, so the hardware side of the OpenGL standard will probably be less interesting to you than the features OpenGL 3.0 will bring. We all know that the OpenGL 3.0 specification has not yet been finalized, so all material discussed here is subject to change and compiled from various sources which I will list at the end of the post.

Objects

One of the major changes that OpenGL 3.0 will introduce is the usage of objects. Yes, the specification is still specified through the C programming language which natively does not support the OOP (Object Oriented Programming) paradigm but a way around this is being implemented.

The objects themselves are similar to native C structs which are used for creating user-defined data-types. Please note that I refrain from using the word class since a class is a data-type on its own, not found in the C programming language nor used in combination with the OpenGL API.

So far, four object categories have been announced, namely:

• Templates
  • Put in simple terms: a placeholder for the definition of a specific object type. Attributes can be set to fulfill the creation of a specific object type. For example, to create an “image” object, one must first create a template object with specific parameters for the creation of the image object, set the attributes required for the object and pass it to an image object constructor function, e.g.: glCreateTemplate(GL_IMAGE_OBJECT); returns a GLtemplate object, after which attributes are applied, glCreateImage(variable to GLtemplate object); returns the handle to an image object (see Data Objects below) constructed according to the attributes supplied to the image template. Templates may be modified at any time since they are defined and stored on the client-side.
• State Objects
  • State Objects are simple objects containing a specific set of attributes applicable to multiple objects. State Objects are partially mutable once created, meaning that only certain aspects of the object can be altered after it has been constructed. Data Objects
  • The example given above at Templates talked about an “image object” which contains image data, stored in a Data Object. These objects have an immutable structure but the data is mutable. These Data Objects get stored VRAM (or RAM depending on the implementation) and can be shared amongst multiple contexts. Examples of Data Objects are Image Objects and Buffer Objects.
• Container Objects
  • The best way to describe a Container Object is by the example of the VAO (Vertex Array Object). The VAO represents a piece of geometry by describing an array of vertices stored in memory and may not be referenced amongst multiple contexts. The Container Object contains a mutable attachment (VAO: Vertex Buffer) and immutable attachment properties.

This new object-based system seems to be the biggest part of the restructuring of the standard and it certainly opens up a new realm of possibilities for IHVs/driver implementers. By abstracting the objects to the server-side, the underlying driver code can be optimized to handle the new data-types more efficiently. The more the API pushes to the server-side, the better the performance can potentially be optimized.

Asynchronous Transactions

While this basically falls under the “Objects” heading, it’s a feature worth mentioning alone. In an effort to improve parallelism, Object creation calls are asynchronous. This means that during the time that an object is being created, a valid handle to the object has already been returned for usage, even before the object’s resources have actually been allocated.

What this means is that more commands can be executed on the client side while the server-side takes care of the execution thus resulting in a faster command chain.

Backwards Compatibility

The OpenGL API has always been backwards compatible throughout its revisions and OpenGL 3.0 will not be an exception. Plans have been made to retain backwards compatibility with the current OpenGL 2.1 standard without breaking older applications.

Another feature, which has not been set in stone, is the manner of interoperability between OpenGL 3.0 and 2.1 which would allow an OpenGL 2.1 application to attain an OpenGL 3.0 rendering context.

Goodbye, Fixed Function Pipeline

OpenGL 3.0 removes the fixed function pipeline which was eradicated in the Direct3D API in version 10. This means that many parts of a normal graphics pipeline are now programmable. This is a huge shift towards the future of a fully-programmable graphics pipeline which would be the definitive step in perfecting a graphics API.

The removal of the so-called “fixed function” pipeline means that all graphical output has to be defined through the “programmable pipeline” though a mechanism often called “Shaders.” Shaders are programmed in a language called the OpenGL Shading Language (GLSL or glslang) or through an intermediary language such as Cg. Shaders not only allow for shading the geometry but also the transformation of its vertices (vertex shader) and individual pixels (fragment shader).

If you’ve read the heading above this one, you’ll notice that OpenGL 3.0 is backwards compatible with older versions which support the fixed pipeline functionality. OpenGL also supports these functions but internally these are transformed into the form of shaders.

OpenGL version “Mount Evans”, which will be released after OpenGL 3.0, will support the functionality provided by Geometry Shaders which allows for the manipulation of “pieces” of geometry and generation of new geometry as well. This allows the programmer to take advantage of currently available hardware-accelerated functionality such as tessellation. Even though this functionality is said to be provided after 3.0 has been released, it is likely that this functionality will be provided with the formal release of OpenGL 3.0 instead.

So, what’s wrong with 2.1?

By now you might have noticed that I haven’t exactly formally answered the question “What’s wrong with OpenGL 2.1?” The answer is: There’s nothing wrong with OpenGL 2.1.. informally. OpenGL 2.1 is a very capable API which could support many of the features that OpenGL 3.0 incorporated. The big difference is of course that the functionality in OpenGL 3.0 will be a formal standard while the 3.0-like functionality in OpenGL 2.1 is provided through IHV-developed OpenGL extensions which may differ from one and other.

The above, and the fact that the new API works with Objects, is causing the anticipation. OpenGL 3.0 will formally push the API into the next-generation era and will finally be able to compete with Direct3D 10, which is why OpenGL 3.0 is important.

Conclusion

As said above, OpenGL 3.0 will push the API into the next generation. In my personal opinion, the new structure of OpenGL 3.0 could severely compromise the position of Direct3D in the Microsoft Windows gaming market since the functionality provided with OpenGL 3.0 will also work on Windows XP, unlike Direct3D 10. Vista is still being viewed upon as somewhat of a quirky Operating System and many developers and users are sticking with XP for the time being.

I’d like to conclude by saying that this post does not present all of the new published features in OpenGL 3.0, rather it lists the features which I find most compelling about the new API. Also, I’m not affiliated with the Khronos Group in any way so everything you read here is non-official and compiled from various online sources, talking about the unfinished and proposed API. Last but not least, I don’t guarantee the correctness of the article, nor the correctness of the sources used — correct me if I’m wrong about something.

Some old Comments

Taken from the original, now lost blog post comment section:

Korval says; 16 May 2008 - 13:01

Nobody really says that GL 3.0 isn’t important. But the fact is that it’s too late. There was a pretty good window of opportunity for a new and improved GL API to swoop in and garner attention among PC game developers. That time has passed. Vista adoption is up, which means that D3D10 usage will be up. The break between Vista/XP and D3D10/9 (ie: if you use XP, you can’t have D3D10 features) was a good opportunity that the ARB has squandered.

Furthermore, if the GL ARB couldn’t get this done last year, why should we believe them this year? The fact is that the ARB has failed, monstrously. They did it before back when they were working on render-to-texture. They spent 2 years on something that shouldn’t have taken more than 6. The younger GL programmers may not remember the days before VBO, but it took an awfully long time to get VBOs as well; until then, we had to rely on a bunch of vendor-specific extensions.

I love the ideas behind GL 3.0; I even wrote my GL 2.1-based rendering abstraction layer based on those ideas. But the fact is that it’s very, very late. And even that wouldn’t be so much of a problem if they could just tell us WHY it’s late. But they won’t. Which means it’s either IP or some stupid argument about something that matters very little. And if it’s the latter, then that means that the ARB is so worried about making a mistake that they won’t actually produce anything. Which makes them ineffective.

For 1 year, the ARB was good about updating us on their progress. And then they stopped. That shows a blatant lack of respect for us the potential users of OpenGL. So why should we respect them back?

–

Dave says; 19 May 2008 - 4:38

I think exactly the same to #Korval.

Every version of DirectX has the great disvantage of relying on a binary format for method calling and structs memory layout that is completely incompatible between major versions.

OpenGL has a smarter design in the sense of using raw C functions (instead of virtual C++ like methods) and almost no C structs.

But it is released with a functional equivalence to DX almost 2 years before. Otherways, using non-standar extensions is a nightmare.

Current OpenGL version has a lot of inconsistences, and a lot of legacy unusefull methods.

But the modern design of DX is not the only advantage over OGL, but a consistent DirectX SDK with a compact documentation and a pletoria of examples.

–

Aras Pranckevičius says; 19 May 2008 - 13:06

I don’t mind D3D changing the API with each major revision. API itself is nothing; it’s really easy to rewrite “the same stuff” to another API. Underlying hardware is still the same, so if the API is not Completely Stupid, it’s not a big deal.

What I do mind though, is whether API and everything related to it (drivers) work. OpenGL fails miserably in this regard, with it’s approach of “let’s let each IHV make their own bugs in the whole stack!” it’s just horrible. FBOs? GLSL? Argh!

Another thing that I don’t mind that much is all the legacy APIs/extensions. There’s probably ten ways to submit vertex data, while in fact there should be vertex buffers only. And even then, VBOs in GL don’t match up what was available in D3D for years (updating a portion of VBO without additional memory copy, anyone?).

So in my view GL3 does not bring anything new to the table. Ok, maybe it will be simpler for IHVs to implement, which would take care of some bugs in the drivers. But what they should really do is force a common stack upon everyone, and make only the lowest-level driver be a responsibility of IHV.

NVIDIA PhysX SDK + more

May 14, 2008 less than 1 minute read

As you might know, NVIDIA has recently purchased Ageia, makers of the PhysX real-time physics SDK. Since then, NVIDIA has taken over the development of the SDK and a new version of the SDK is now available for free in binary form from the NVIDIA website, click here to go to check it out. A special license for the source code version of the SDK can be acquired for a mere $50K.

In other NVIDIA news: two new free book releases are now available on the NVIDIA website, namely: The Cg Tutorial and GPU Gems 2 which are two incredibly useful books. NVIDIA is on a roll, and looking at the manner in which freebies are coming in lately, I’ll be the last one to stop ‘em.

The Ghost of OpenGL 3.0

May 8, 2008 2 minute read

OpenGL 3.0 seems to become more and more of a promise that’s bound to be broken; like a friend who promises you to give back the money you loaned him, always tomorrow.

The expected API promises many new features, enhancements and is the first total rewrite of the existing OpenGL Standard. The API promises an interface compatible with the next generation of computer graphics programming and is set to compete with Microsoft’s DirectX 10.

Well, that’s the plan at least. OpenGL 3.0 has been delayed tremendously since its scheduled release in October of 2007. On October 30th of 2007, ARB member Barthold Lichtenbelt (NVIDIA employee) made an official announcement on the OpenGL.ORG forums claiming that the release date was postponed until further notice because “[the OpenGL Working group] don’t want to spend time fixing mistakes made in haste.”

The announcement settled fine with most of the OpenGL community since at least there was news. But after 7 months of neither news nor updates, some of the community is giving up on (or dismissing) the possibility of a new API at all.

But is it really possible to give up on OpenGL? The API is pretty much the only viable hardware accelerated option on platforms other than Microsoft Windows, and even on Windows many developers are reluctant to switch from XP to Windows Vista in order to take advantage of Direct3D 10.

The Khronos Group have been putting out updates on the other software which they maintain the standards of with the exception of their most popular/anticipated one, OpenGL.

So what does that mean? Either OpenGL is being actively developed on and public discussion is prohibited per NDA, or development has halted and there is reluctance in releasing the bad news. My hopes are up for the former option since the OpenGL API is without a doubt the most flexible Graphics API available today.

Of course, there is a third option which is quite scary and different. Khronos has been publishing information on a new API called OpenKODE which bundles several APIs in a DirectX-like manner of platform abstraction. Maybe the OpenGL API will become a part of this which would set back the development even more, but this is (as are the other options) a wild guess.

If there’s one thing to consider, it’s the fact that OpenGL is a standard (a definition), not an implementation. Which means that the actual source code for 3.0 would have to implemented by: A. the independent hardware vendors or B. the platform developers. So even if the OpenGL 3.0 API would be released today, the actual libraries wouldn’t be available yet since the implementation would be missing.

All in all, I think we’re still very far away from seeing a workable OpenGL 3.0 implementation that’s supported ‘cross-platform. For now we’ll just have to do with OpenGL 2.1 or Direct3D 10, which in many cases, is a limited set of options that’s impossible to choose from.

Direct3D, OpenGL and XNA Fieldguide

April 11, 2008 9 minute read

A common novice’s question in context with graphics programming is which API should I use?, Direct3D versus OpenGL or which API is better?. Getting familiar in the Graphics Programming world can be tough since many subjects don’t have definitive answers. This article attempts to clear up some of the mysteries surrounding the APIs and compare them as far as it is possible. The individual APIs discussed in this document are Direct3D, OpenGL and XNA. If you’re new to Graphics Programming in general, read the Graphics Programming article to get a clear understanding of what exactly these APIs do.

This article is not intended to explicitly tell you which Graphics API to use, rather it simply explorer the features and limitations of the APIs discussed.

About Graphics APIs

The following sections explain what a graphics API is, what it does and what influences a Graphics API. The points here are simplified to provide a basic understanding.

A Graphics API is not

The following two section define what a Graphics API is not. If you’re looking for the topics provided here, some suggestions are made for you to continue your search.

…a Game Engine

To be clear about what’s being discussed here: Direct3D, OpenGL and XNA are not game engines. A game engine is a library or program dedicated to delivering high performance interactive 3D graphics, sound, networking, etc. A Graphics API is simply a low-level mechanism to deliver visual content to a computer’s screen. Some examples of game engines are Delta3D, NeoEngine and the C4 Game Engine.

…a 3D Engine

While 3D Engines such as Ogre3D, Irrlicht, et al implement Graphics APIs, they usually provide access to higher-level functionality such as loading models, mathematical functionality and scene management. The graphics APIs don’t provide such functionality but allow the user to create the functionality themselves through API functions provided.

Graphics APIs Usage

After reading the previous section, you might wonder what a graphics API does since it doesn’t create games or manage a scene. Think of a Graphics API as a way to talk to your graphics hardware. A Graphics API allows you to tell your hardware to draw a pixel at location X in a human understandable format.

The Difference between the APIs being the syntax of the way you talk to the hardware. To draw a pixel, API A might require you to type DrawPixel(left, top); while API B requires you to say PutPixel(left, top);. Another difference might be the way the API is initialized and made functional in the context of the code.

The Display Driver’s Role

The display driver’s role is to translate API and operating system functions into a hardware interpretable format. To understand how the process works, here’s a simplified list with the steps involved from the program to the hardware:

• Program sends an instruction to the API
• API sends the instruction to the Display Driver
• Display Driver sends the instruction to the operating system
• The operating system sends the instruction to the CPU
• The CPU sends the instruction to the graphics hardware

Display drivers require to be updated every now and then. This is because the driver is the intermediary piece between the API and the hardware and is a piece of software, which like all software might contain bugs. Another reason for these updates might be because of added or updated functionality for a specific Graphics API.

Without the presence of a display driver or nonsupporting hardware, an API will likely fall back to a software implementation which means that all API routines will be executed by the CPU. This means that hardware acceleration will not be supported and the execution times are likely to be much higher.

API Image Quality

Contrary to popular belief, APIs rarely (if ever) affect the quality of the final image. To understand why, one must envision the different APIs talking to the same piece of hardware. When API A says DrawPixel(x,y); the hardware receives this as an instruction in machine code and executes this. When API B says PutPixel(x,y); the same instruction will be executed with the exact same machine code.

If a difference in image quality does exist, it is most likely due to the way the display driver interprets the command sent and transforms it into machine code for the graphics hardware to consume or because an API performs an automated transformation beyond the user’s control.

When comparative images show up, it is best to avoid arguments and simply ignore the statements being made since APIs have no control over how the hardware display an image. The only factors in the image quality are the quality of the artwork, the ability of the hardware and the amount of hardware integration (the amount of hardware functions) the graphics API provides.

API Performance

While image quality barely plays a role when considering an API, different APIs can certainly have performance differences. This is usually because of the amount of abstraction occurs between the API and the hardware. Abstraction simply means the amount of functional layers between the API and the hardware. Performance leans heavily towards the amount of code that’s being processed, so in many cases more code equals lower performance.

Introduction to the APIs

The OpenGL API

The OpenGL API is certainly the oldest graphics API between the three discussed in this article. Conceived in 1992 by Silicon Graphics as an open standard for graphics hardware instructions across multiple platforms, it has proven to withstand the test of time being virtually implemented on all major operating systems.

The Direct3D API

The Direct3D API is a proprietary graphics interface for Microsoft platforms such as Microsoft Windows and the Xbox platforms. It was conceived in 1995 for the Windows 95 operating system as part of the Windows Game SDK, which was later renamed to DirectX. Direct3D currently handles all 3D and 2D instructions within the DirectX SDK.

The XNA Framework

The XNA Framework is the youngest of the APIs discussed here, being released in 2007. XNA is an interface built on top of the DirectX SDK and provides high-level Object Oriented functionality for video games. XNA is currently only available in the C# programming language since it’s a managed library based off the Microsoft .NET framework. XNA currently only works on the Microsoft Windows and Xbox 360 platforms.

Comparing the APIs

Cross-Platform Support

When a program will solely run on a single platform, the choice between APIs is usually fairly clear. But it is likely that a product, whether it be a video game or professional software, has to be supported on various platforms.

Currently, the OpenGL API is the only API supported on most major platforms including Microsoft Windows, various Linux distributions and Macintosh. The OpenGL API cannot be operated on the Xbox and Xbox 360 platforms, but can be used on the PlayStation 3 platform.

The Direct3D API will only run on Microsoft platforms such as the Xbox, Xbox 360 and Microsoft Windows but can be emulated on Linux platforms through Wine which reroutes Direct3D API calls to the OpenGL API.

The XNA Framework is currently only supported on Microsoft platforms that can run the .NET framework which is limited to Microsoft Windows XP, Windows Vista and the Xbox 360.

Ease of Use

All three APIs are fairly simple to use with XNA being the simplest API and Direct3D being the most complex API in terms of code syntax. Since Direct3D and OpenGL are both native C libraries, the interface provided does not implement any classes or namespaces.

XNA on the other hand is strictly a .NET platform enabled Framework which means that it cannot be used by native languages, only by managed languages but implements classes and namespaces. XNA also includes a myriad of helper functions and libraries and is fully compatible with the .NET framework.

This means that while OpenGL and Direct3D both are closer to the hardware and can be ported to a higher level language, the time it takes to develop an OpenGL or Direct3D application will be higher than that of an XNA application. The trade-off is explained in the next section.

Performance

Since OpenGL and Direct3D are C-based APIs, they are closer to the hardware and implement fewer levels of abstraction. This means that the performance differences between Direct3D and OpenGL are minimal. Any significant performance differences are likely to be the result of the way the display driver interprets the API commands.

The XNA Framework on the other hand is a .NET library which invokes native Direct3D calls to be used on the virtual machine in which the .NET Framework operates. This high level of abstraction can cause performance issues and it is recommended to use the XNA Framework solely for lower performance applications.

Features

APIs are usually limited by the amount of features they implemented at the time of release. This causes the developers of the API to update the API, increase the version number and release a newer version. DirectX/Direct3D is limited by such restrictions, yet updated versions of the SDK are being release routinely every three months.

The OpenGL API includes an extension mechanism which allows independent hardware vendors or end-users to implement their own features whenever a driver is released or with a next generation of graphics cards.

The XNA Framework is based on Direct3D version 9 and can only include the functionality provided by this API. If a newer version of Direct3D is released, the XNA Framework will have to implement the new functionality afterwards. This causes the library to be one to several versions behind current standards.

Support

The OpenGL API is a community supported and developed product and currently has a new version scheduled for 2008, OpenGL 3.0. The OpenGL API is not often updated, 2.1 being the latest version from 2006 and development has fallen behind schedule as OpenGL 3.0 was supposed to be released in 2007.

The DirectX API is both community supported and professionally supported. Professional support requires at least an MSDN subscription to access the support features. A new version of the DirectX API is released every three months.

The XNA Framework is also both community and professionally supported, similarly to DirectX. XNA releases are announced in advance but doesn’t have a set update schedule.

Popularity

The Direct3D API is extremely popular with Windows and Xbox platform developers where the gross of the game development occurs. Since Direct3D is developed by Microsoft, it lends itself well towards Microsoft’s platforms.

The OpenGL is popular amongst both professional graphics developers and game developers, although its usage in video games has declined somewhat since the early 2000’s. It is the only available option on non-Microsoft platforms for hardware accelerated graphics.

The XNA Framework is very popular with hobbyist programmers and lends itself well towards learning how the concepts of both 3D and 2D programming works. Yet, only a few professional titles have been released using the XNA Framework.

Licensing

An important aspect of releasing software are the license restrictions which an API might implement. Both the OpenGL and Direct3D APIs have a licensing model which allows a developer to use the APIs in a commercial product without restrictions.

To release commercial software which implements the XNA Framework 2.0, a license agreement must be agreed upon between the developer and Microsoft which prohibits the usage of the network code provided by the XNA framework. The XNA Game Studio may not be used to create commercial titles for Xbox 360 but commercial Windows titles may be released. To distribute titles on the Xbox 360 platform, a $99.00 fee must be paid in order to be able to access the functionality provided by the XNA Creator’s Club.

Bitwise Programming in C

April 3, 2008 6 minute read

This article explains Bitwise Programming in C, a common practice in most programming languages. While bitwise operations might seem like a dark art at first, it really isn’t that scary. You simply need to know when to apply these operations and for what reasons to use them.

The article discusses bits (calculation, workings) in section one previous to the actual operators so that an understanding is made on how bits operate.

About Bits

To understand how bitwise operations work, we must first understand how bits work and what bits are. Bits are usually explained as being either a number one ( 1 ) or a number zero ( 0 ), which translates into a logical TRUE or FALSE, or ON or OFF.

Bits tell the CPU (Central Processing Unit, or processor) to be either in a state of ON or OFF for a specific time-frame. This time-frame is defined by the speed of your processor and can be pseudo-calculated like so:

If the processor is 33MHz, 33,000,000 individual bits can be processed in a single second since 1Mhz = 1,000,000Hz and 1 bit = 1Hz. This means that a modern machine of 3.0 GHz is capable of processing 3,000,000,000 (three billion) bits per second. Keep in mind that this does not mean that every single bit is a processor instruction, instructions depend entirely on the processor’s architecture.

Number Representation

Binary numbers, or Base 2 notation, can only represent their numbers in sets of ones and zeros as we found out before. The number one (1) represented in binary code like so (32 bits, spacing for readability):

00000000 00000000 00000000 00000001

But numbers are normally represented in sequences of eight or four numbers, if there is too much zero-padding, which is a what this article will continue to practice.

0001

Base 10 to Base 2

Since (most) humans are taught to think in Base 10, binary does not come naturally. Often a conversion or calculation to the appropriate Base is required. Converting a Base 10 number (123 in this case) into Base 2 goes as follows:

123 ÷ 2 ≡ 61 r 1
61 ÷ 2 ≡ 30 r 1
30 ÷ 2 ≡ 15 r 0
15 ÷ 2 ≡  7 r 1
7 ÷ 2 ≡  3 r 1
3 ÷ 2 ≡  1 r 1
1 ÷ 2 ≡  0 r 1

Even though it’s calculated like this, the binary number for 123 is not 1101111 but 1111011 which is the number read from the last calculation to the first. At the first calculation we notice that 123 ÷ 2 ≡ 61 r 1 instead of 61.5. The notation 61 r 1 simply denotes that the number divided was not a round number and we received a remainder of 1. To calculate the remainder:

1 ≡ 123 % 2

or

1 ≡ 123 mod 2

Base 2 to Base 10

The following calculation is used to convert a Base 2 number into a Base 10 number:

1 × (2 ^ 6) ≡  64 +
1 × (2 ^ 5) ≡  96 +
1 × (2 ^ 4) ≡ 112 +
1 × (2 ^ 3) ≡ 120 +
0 × (2 ^ 2) ≡ 120 +
1 × (2 ^ 1) ≡ 122 +
1 × (2 ^ 0) ≡ 123

When to use Bitwise Operations

So far we’ve established that a computer uses a Base 2 system for calculation but haven’t explored why this is important to a programmer. The simplest usage example would be the usage of flags which will be the example used throughout this article.

#define SETTING_ONE    1 // 0001
#define SETTING_TWO    2 // 0010
#define SETTING_THREE  4 // 0100
// etcetera

In several APIs these settings are combined with the bitwise OR operator like so:

unsigned int uiflags = SETTING_ONE | SETTING_TWO | SETTING_THREE;

This usage allows the combining of settings into one single variable, to see how this works exactly, read the next sections.

Bitwise Comparing

Bitwise OR

Bitwise OR in C is expressed as a single pipe, |, not to be confused with the boolean or, ||, takes two or more integer values and combines their bits. For example the sample code:

#define SETTING_ONE    1 // 0001
#define SETTING_TWO    2 // 0010
#define SETTING_THREE  4 // 0100
 
int main ( void )
{
    unsigned int uiflags = SETTING_ONE | SETTING_TWO | SETTING_THREE;
    return 0;
}

Would result in the variable uiflags to contain 0111, or in Base 10 notation: 7. Because:

0001
0010 OR
0100 OR
---- ≡
0111

You might wonder what the difference would be compared to:

unsigned int uiflags = SETTING_ONE + SETTING_TWO + SETTING_THREE;

To show the difference, imagine the following program:

#define SETTING_ONE    1 // 0001
#define SETTING_XXXXX  3 // 0011
 
int main ( void )
{
    unsigned int uiflags = SETTING_ONE | SETTING_XXXXX;
    return 0;
}

The progam does not return the Base 10 number 4 as would be expected with the + operator, but the value 3. This because:

0001
0011 OR
---- ≡
0011

This means that the OR operator combines two binary values, but does not add them together arithmetically. Remember that with bitwise OR, 0001 OR 0001 does not equal 2 but 1.

The return value of OR will only be zero if both compared bits are zero: 0000 OR 0000 equals 0.

Bitwise AND

The bitwise AND operator in C, &, makes everything a bit more interesting. Also, this is not the same operator as && which is a logical operator. This operator allows you to check if a bit has been set in a certain place in two variables, for example:

0100
0111 AND
---- ≡
0100

Which returns a non-zero value which can be view upon as TRUE if a comparison is being made.

1010
0101 AND
---- ≡
0000

Returns false since none of the bits’ locations correspond to each other. If we take our code from the OR sample, and combine it like so:

#include <stdio.h>       // for EXIT_* definition codes
#define SETTING_ONE    1 // 0001
#define SETTING_XXXXX  3 // 0011
 
int main ( void )
{
    unsigned int uiflags = SETTING_ONE | SETTING_XXXXX;
 
    if ( uiflags & SETTING_XXXXX ) // does uiflags contain the flag?
    {
        return EXIT_SUCCESS; // uiflags contains the flag
    }
    else
    {
        return EXIT_FAILURE; // does not contain the flag
    }
}

Bitwise NOT

The NOT operator in C, ~, is a simple one which requires less explanation than any other operator. The NOT operator simple negates the bits set. Example:

NOT 0001
-------- ≡
    1110

Which in Base 10 notation would be NOT 1 ≡ 8 This allows you to retrieve the exact opposite settings of the values given.

int main ( void )
{
    #define FAST     1;  // 0001
    #define QUANTITY 2;  // 0010
    #define SLOW     4;  // 0100
    #define QUALITY  8;  // 1000
    unsigned int highSettings = FAST | QUANTITY; // 0011
    unsigned int lowSettings  = ~highSettings;   // 1100, SLOW | QUALITY
    return 0;
}

Bitwise XOR

The XOR operator, ^ in C, is another interesting operator which compares two sets of bits. Unlike the other operators, XOR checks if the bits in the position are the same and returns zero. If they are not the same, it returns one. This process is called “exclusive or”, meaning that it excludes equal values and includes differing values.

0110
1101 XOR
---- ≡
1011

This means that if you compare two values which are equal, the result could be cast as a boolean false.

1011
1011 XOR
---- ≡
0000

Or in C code:

int main ( void )
{
    #define FAST     1;  // 0001
    #define QUANTITY 2;  // 0010
    #define SLOW     4;  // 0100
    #define QUALITY  8;  // 1000
    unsigned int highSettings = FAST | QUANTITY; // 0011
    unsigned int lowSettings  = SLOW | QUALITY;  // 1100
    unsigned int difference1  = highSettings ^ lowSettings; // 1111
    unsigned int difference2  = highSettings ^ highSettings; // 0000
    return 0;
}

Using XOR on a value of itself will always return a boolean cast FALSE.