Behind The Scenes

Published Date
01 - Feb - 2006
| Last Updated
01 - Feb - 2006
 
Behind The Scenes
Most of us have our favourites when it comes to games. A few of us are crazy enough to spend big bucks on oodles of RAM and a top-of-the-line graphics card, just to be able to play 3D games-others are content with Solitaire! If Solitaire is your thing, we should warn you that this article could induce sleep; those of you who swear by games such as FarCry, Doom 3, Half-Life 2 and Call Of Duty 2 will find the following informative.

Think about your favourite 3D game. Now think about all the complexities that go into programming it. First and foremost, you have textures and shadows and lights and water effects and… the list is endless. Games today come up with breathtaking scenery, and this is expected of any big title worth its salt. Add to this mix the even more complex physical properties that each object needs to exhibit while you're playing the game, and you have a maddening amount of mathematics, coding and rendering that the graphics chip and CPU have to do in parallel.

Today, only very small bits of scenery are two-dimensional images, if at all. Most of the awe-inspiring fantasy worlds you see in games are made up and rendered on the fly by your graphics subsystem.

Let's not even get into the whole computation of AI for enemies and friends-how they move, whether they duck and hide or attack, and about the best path they need to take to be able to attack you! The fact is, games are as complex as programs come today, and are becoming real resource hogs - you need tons of hard disk space, memory, and a 3 GHz machine to play the latest titles, not to mention a graphics card that costs in excess of Rs 20,000.

Now imagine if game developers had to code for each and every command, each and every difficulty level, and for each video resolution and effect! And not just code for each operating system, but also for each graphics chipset model! We hope you get the picture: think mass suicides in Silicon Valley and game companies…

Perhaps the best feature of OpenGL is the way it seamlessly integrates with almost any operating system-from UNIX to Linux, the BSDs, and all versions of Windows.

APIs
Thankfully, a software coder's life is made easier with the help of Application Programming Interfaces (APIs), which standardise commands that are sent to the hardware and software so a coder just needs to know what command his software is supposed to send, regardless of the make of hardware and software being used.

Think of it as a translator: you want to say something in English to people who only speak a certain dialect of Bengali. The translator is well versed in all dialects of Bengali, and can translate anything you say to any Bengali-speaking person from any part of the globe! That's sort of what an API does-it helps programmers code in "English," instead of in a different language, depending on the thousands of permutations of hardware and software across the globe.

To elucidate, an API enables both software or game developers as well as hardware manufactures to standardise the commands, code and drivers, so that life is easier for everyone. Now APIs are used everywhere, even between an OS and a software program. For example, you need to have the Windows API to be able to make a software program for the Windows operating system!

However, this article is not about APIs in general. We're focusing only on the APIs that are used for 3D graphics-whether in graphics software such as Maya or 3ds Max, or 3D games such as Doom 3, F.E.A.R. and Half-Life 2.

A 3D Graphics API consists of everything that comes between a game and the system hardware. This includes the input software, the OS libraries and even the hardware device drivers. So, a 3D API would take commands from a game or graphics program (programmed using that same API, of course) and translate its input requirements and output data so that the hardware (graphics card, CPU, etc.) can understand what's needed of them.

Those who have heard of 3D Graphics APIs will have definitely heard of OpenGL and DirectX (or Direct3D, more appropriately). Let's dig a little deeper into how it all began.

OpenGL
OpenGL started off as Iris GL, a graphics API developed by Silicon Graphics Incorporated (SGI), for the UNIX operating system. In 1992, SG opened up the API for the public, so people could program using this API, and renamed it OpenGL. Remember, OpenGL gets its name from "Open Standard Graphics Library," and is not open source software as many people mistakenly believe. Open Standard means that anyone can license the API and program for it, but no one is allowed to modify it-a stark contrast with Open Source software norms!
OpenGL is developed and maintained under the governance of an Architectural Review Board (ARB) that is made up of companies such as 3DLabs, Apple, ATi, Dell, IBM, Intel, nVidia, SGI and Sun Microsystems. There are more members, but without any voting rights to steer the development of the API, so we won't name them here. Visit www.opengl.org for more information on the partners, and even the minutes of every meeting that has been held thus far!

Perhaps the best feature of OpenGL is the way it seamlessly integrates with almost any operating system-from UNIX to Linux, the BSDs, and all versions of Windows. There's also an official open source implementation of OpenGL called the Sample Implementation (SI), which is completely free for anyone developing open source software or games. Read more about this at www.sgi.com/ products/software/opengl/license.html.

OpenGL began, and still is, a low-level graphics library specification. It deals with primitive geometry such as lines, points, simple polygons, images, and bitmaps, to create larger 2D or 3D rendered images. Using OpenGL, programmers can easily use simple commands to render these polygons and shapes by the graphics card's frame buffer. The API was designed to be used with the C and C languages, but currently also supports Java, FORTRAN, Ada, and more. For those who don't know what all this is about, don't worry, just take a look at the box Jargon Buster to get quick meanings for all the jargon you'll encounter here.

Since OpenGL is independent of the operating system's windowing system, it can be easily used on any platform. A windowing system is a component of the OS that handles things such as window management, colour mapping, and event handling. So basically, OpenGL works on any platform because it interfaces with the windowing system of, say, Windows, or X11 for Linux, and passes commands on to the windowing system. It does the same with the system event handler and the input mechanism. All this results in simple and short codes that are easy to troubleshoot and maintain or change.
Direct3D
Most of you have probably never heard of Direct3D, though a lot of you will have heard about Microsoft's DirectX. DirectX is basically an API suite that contains libraries for audio, input and graphics, all rolled into one. Comparing OpenGL to DirectX, however, is like comparing water to oil, so we'll only talk about the graphics API within DirectX, which is called Direct3D.

The history behind Direct3D is interesting. Back in the days of Windows 95, Microsoft noticed that all game APIs were written with the older Disk Operating System (DOS) in mind. Microsoft wanted to increase native support for games within Windows, which was easier said than done. Windows has many abstraction layers, and this caused problems for coders trying to write graphics software and games. Coding was a nightmare.

Sometime in 1995, Microsoft took note of a small UK-based firm called RenderMorphics that was developing a 3D rendering software called Reality Lab. Once Microsoft was convinced that Reality Lab was just what it needed, it acquired RenderMorphics in February. Reality Lab went on to be renamed Direct3D, and thus began Microsoft's very own 3D API.

To say the beginning was rocky would be an understatement. Since OpenGL was already established by now, was way easier to program for, and was much better and less buggier, it's no surprise that Direct3D got a lot of flak in the beginning. Microsoft's first version of DirectX was numbered 1.0, and contained Direct3D and DirectDraw, for 3D and 2D rendering respectively. However, the release was buggy, slow, and still a lot harder to code for than OpenGL.

It was only with DirectX 7.0 that Microsoft's API was embraced wholeheartedly by game developers. With DirectX 8 and beyond, Microsoft rectified earlier irritations and introduced a set of precompiled code classes that they called Common Files. What these files did was hide all the complicated commands-such as code for listing the capabilities of the hardware. For example, even drawing something as simple as an animated 3D circle can involve hundreds (or even thousands) of lines of coding, even after using older APIs. The Common Files helped by reducing the lines of code required for such common tasks.

The biggest advantage of the DirectX suite of APIs is its seamless integration into all Microsoft operating systems and other platforms such as Xbox. Another advantage is the fact that it's a suite of APIs, so game programmers working with DirectX APIs can code their games for both audio and 3D graphics.

Most importantly, however, is the way DirectX is standardising everything and levelling the playing field for graphics cards manufacturers and game developers alike. Some time ago, you couldn't play most games on lower-end systems, but now, thanks to DirectX, you are able to play the latest games on any DirectX compliant card-the resolutions and imaging settings will have to be set lower on lower-end cards, but at least you can play the games!

Another great innovation brought about by the DirectX family of APIs is the Unified Shader Structure. What this does is let graphics chipsets use the same transistor to do either pixel shading or vertex shading, depending on the API's needs. This definitely gives DirectX (or Direct3D, rather) a definite advantage over OpenGL!

The drawbacks to the DirectX APIs are also the areas in which OpenGL excels.

To begin with, DirectX is not "open" in any way, so any change in the API comes solely at the discretion of Microsoft. Though not necessarily a bad thing, you do have to wait for Microsoft to implement suggested changes, even if a lot of developers are quite capable of doing so on their own.

Although the Windows OS is by far the most popular across the globe, ruling the roost with sheer numbers, not all developers want to limit their games to a single OS. id Software, for example, has always built games that run on just about any OS, and thus have always been in the OpenGL camp. Direct3D also needs a lot more coding than OpenGL from game developers. However, a lot of improvements in the DirectX API as well as the enhanced integration with the operating system mean that more and more games are being made for Windows only. And let's face it: Microsoft's dominance in the OS business doesn't hurt-a lot of game developers today do not consider investing time and money in coding for other OSes a viable option, and are quite happy targeting the masses by coding only for Windows using DirectX/Direct3D.

General Purpose Graphics Processors 
Graphics Processing Units (GPUs) are very powerful processors, and nothing illustrates this more than the fact that they outdo today's best CPUs from behemoths such as AMD and Intel on a flop-by-flop comparison. In fact, the latest from the nVidia and ATi stables, the 7800 and X1800 respectively, actually severely hammer the fastest CPUs out there-a 7800 GTX achieves about 200 billion floating point operations (flops) a second, while a 3 GHz dual-core Pentium performs just about 20 billion.
It was only a matter of time before someone put 2 and 2 together and arrived at 22! The latest hype of General Purpose GPUs (GPGPUs) is derived from the thought that, "If I have this monster of a GPU, and I'm not playing games all the time, why can't the GPU assist the CPU and make my computer even faster than it already is?"
A valid point! However, it's the architecture of a GPU that lets it down when it comes to general purpose computing. Basically, the example below will illustrate how a GPU is used:
CPU:    "Calculate this!"
GPU:     "Sir yes sir!"
CPU:    "What if I take that number I gave you
    1.4 billionths of a second ago and
    raise it to the power of this new
    number… what do you think?"
GPU:     "Huh?"
Basically, a GPU is optimised for point-to-point operations, and they have very low memory caches, simply because games and 3D rendering just does not require anything more.
So will the GPU ever replace the CPU? Nope! But nothing stops a GPU from helping out now and then!
A CPU can process a couple of threads in parallel, which is contrasted by the latest GPUs, which have 24 pipelines, essentially meaning that they can process 24 threads at a time. If, somehow, we could link the CPU and GPU directly with a PCI-Express communication bridge, and if the CPU and API software could decide whether or not a certain task was better suited for the GPU, you could actually get better performance.
This is the concept of GPGPU implementation, and work is on in full swing using both OpenGL as well as DirectX to try and achieve this. Getting into the nitty-gritty of the changes in the architecture for both CPUs and GPUs as well as the APIs is beyond the scope of this article, but if you're really interested in learning a lot more about this concept, visit www.gpgpu.org for more information!

Platforms
As with most competing technologies, both OpenGL and DirectX have their own fan followings. A lot of open source developers cannot think of using anything but OpenGL, while most game developers seem to be using DirectX as the API of choice. So long as there is a choice of operating systems, one can be sure that both will continue to co-exist. What might change is the popularity of each API.

Since DirectX is a Microsoft-proprietary technology, a lot of game developers have to use OpenGL in some form or the other in order to be able to release games for the console segment, specifically Sony's PlayStation series. However, with the increase in popularity of the Microsoft Xbox series, game developers can now choose to stick to DirectX and have a presence in the console market.

The future, in terms of PC gaming, might pose problems for OpenGL though. Especially important is the soon-to-be-released next generation OS from Microsoft - Vista. The problem is that Vista uses a 3D graphics engine even to display its regular Desktop windows and a lot of other enhanced effects. It's obvious that Vista, by default, will use DirectX to do its work for it. Actually, Microsoft is calling the new graphics engine Windows Graphics Foundation (WGF), which will perhaps just be DirectX 9.0c renamed. However, there are also claims that Vista will finally ship with WGF 2.0, or DirectX 10 if you like!

Now comes the terrible news for OpenGL: Vista will supposedly run Microsoft's own version of OpenGL (1.4 is the popular speculation) in a layer above WGF (or DirectX). So experts are expecting at least a 50 per cent drop in performance with games written for OpenGL. Though none of this is confirmed, because Vista still hasn't been released yet, it might see game developers such as id Software being forced to code their games on DirectX as well as OpenGL.

Jargon Buster 
Graphics library: A graphics library is a collection of functions that control the output video. These functions can be linked into a program or games to achieve tasks such as initialising video memory, displaying images on the screen, changing colours, etc.
Frame buffer:A frame buffer is the part of memory on a display card that stores the information about what should be displayed on the screen. For example, after rendering video from a game, the graphics card stores every rendered screen in the frame buffer, which is then sent to the monitor or display device when requested. Think of it like and Outbox in your mail client, where mails are stored while they are in the process of being sent!
System event handler: An event handler is a command that's associated with an object. Say, for example, a button on a Web page: you specify a code that basically says, "Do X when this button is clicked". This code is the event handler. Within your system, the same principle is applied for all commands received by a program, the operating system or even the hardware.
Rendering: Rendering is simply the changing of digital information to a human viewable output. Everything from the text you type to the games you play needs to be rendered from ones and zeroes to viewable content. The word rendering, however, is mostly used when describing 3D applications or games, where it means putting together a lot of images to form video.
Pixel shading: Current generation graphics cards have programmable pixel shaders that enable you to calculate the exact colour and texture effect for every pixel displayed on a screen. Even at a resolution of 1024x768 @ 60 Hz, that's 4,71,85,920 computations per second! Using an example from nVidia's site: "Characters now have facial hair and blemishes, golf balls have dimples, a red chair gains a subtle leather look, and wood exhibits texture and grain."
Vertex shading: A vertex is a point on a shape where edges meet. So, a triangle has three vertices-each corner. A vertex shader applies affects and textures to a variety of predefined vertices in an image. This is what helps you get realistic looking waves, because they're not just lines or curves coming towards you, but also have a 3D depth. This is also how games can use lighting effects to determine how to distort a shadow of a moving object, or show the distortion of light coming from around a corner!
Graphics engine: This is a software that takes commands from a program or game and creates images and text, which are then channelled to the graphics driver and hardware.
Raster images: This is an image that's made up of a collection of dots. Bitmap images are raster images and are meant to be displayed on a screen.
Vector images: A vector image is an image that's produced on-the-fly by using mathematical formulas to draw it. Vector images can be scaled up or down without losing any quality, because a graphics engine always has to create the image before being able to display it.

Vista is capable of unloading everything that isn't necessary while playing a game, which includes many services and even the desktop environment

Vistas Of Tomorrow
You should have gotten a good idea about what 3D APIs are and a basic idea about how they work. The main concern for most developers today is whether their OpenGL skills will cease to be an asset in the near future. Alas, this is a question that can only be answered once Vista is released later this year.

Another interesting development is that Microsoft wants to improve the way games are installed on PCs. If we go by popular online hearsay, the WGF will enable us to install games and start playing them in a matter of seconds, as compared to the many minutes it takes to just install games, even on the highest-end PCs. And, unlike with Windows XP, Vista will pass on graphics processing to the GPU directly, without ever disturbing the CPU.

Also, Vista is capable of unloading everything that isn't necessary while playing a game, which includes many services and even the desktop environment-like end-tasking Explorer.exe and then launching a game to prevent wastage of resources. Vista is also touted to come with support for Pixel and Vertex Shader 4.0 (we're barely past version 2.0 currently) so as to future-proof its graphics API.

Whatever the outcome of the API wars, as PCs become more powerful, games get heavier than ever, and our expectations from them increase, some changes will be required within APIs as well as the OSes. Vista seems to bring about such changes, and its WGF standard might change the way all programs are developed, not just games! This is because if Vista becomes the OS of choice (which it probably will), the interface design of every single program will have to be done using raster images instead of the vector images used today! This means that designing even a simple program tomorrow might be more akin to what game designers do today! Whatever the outcome, be prepared for a lot better looking programs, games, and the look-and-feel of Windows as a whole.



Team DigitTeam Digit

All of us are better than one of us.