I’m not known as a person who particularly likes the .NET framework but I still have to use it. The .NET Framework is basically a massive library of general purpose functions, much like the Standard Library is to C or the Standard Template Library is to C++.
But what if it all would be discontinued?
It’s not an impossibility and rather likely considering Microsoft’s track-record. The millions of applications, libraries and websites created with .NET would be useless.
I’ve been fortunate enough to be part of a VB6 (CGI) to ASP.NET (VB) conversion team and, trust me when I say this, you don’t want to be part of such an effort. These conversions require truckloads of time and money, and if you work for a mid-sized to large corporation, this could easily lead into the millions of dollars.
Now imagine all of your code obsolete. Everything you’ve coded since .NET 1.0. What would you do? Let’s take FoxPro as an example. Microsoft bought FoxPro in 1992 and released a couple of versions under the “Visual”-family of products. The last version was released in 2007 and a statement of Microsoft suggests that this is the last version.
No migration tools to any other language are being provided.
Another product would be J#, which will be retired in 2015. Keep in mind that J# is a fairly recent product and was only released with Visual Studio.NET.
How far will .NET go before a turning point is reached? Consider that .NET was first released publicly in 2002 and will be a decade old in less than four years. Knowing Microsoft, the end is quite possibly much nearer than you think.
Here’s another little snippet that might come in handy in your programmatic travels. I’ll show you an example of usage below, which might also be of interest to you. The code presented is in C, not C++. First, the code to count the amount of digits in an integer:
Edit: Thank you, fixitman for the insightful comment; the code has been fixed to work with non-square arrays as well.
In an effort to produce a better performing multidimensional array, I would like to share the following with you. Say we have a Matrix (or multidimensional array) of 5 x 5 integer elements, M. In order to allocate such an array in C++, we use the following code:
2023 Update: You probably don’t want to use this code since there are likely some serious issues with it. But, fun fact: a major tech company reached out to me to clarify what the license for this is. So, if you want to screw yourself over and use it, let’s say it’s MIT licensed and call it a day.
What: A C++ wrapper around both WINAPI (Microsoft Windows) and PThreads (POSIX threads) functionality.
Why: To abstract cross platform functionality.
Remarks: On windows, CRITICAL_SECTION objects cannot be shared cross-process. This means that the class is tied to your application or DLL process. Comments are in Doxygen/Javadoc style.
Following is a list of the major features that have been announced to be included in Direct3D 11, the next generation Graphics API included in the DirectX SDK. In my opinion, the changes (rather, additions) brought into this API are excellent so far. It seems as if the API has finally grown up and is in no way, shape or form comparable with older DX versions and deprecates OpenGL 3.0 at this point.
I don’t like Visual Basic, yet in many Microsoft shops, VB is still being used especially in combination with ASP.NET. The problem with Visual Basic is that it’s not very strongly typed. Conventions are often thrown out of the window and Senior VB developers often hold their seniority as experience which, is more fiction than fact.
How many more times do I have to see Functions which don’t return anything and should have been declared as Subs.
Or:
Variable 'XYZ' is used before it has been assigned a value.
Or:
Variable declaration without an 'As' clause; type of Object assumed.
Ugh. You’d think that people with 15 years of development experience wouldn’t dismiss this kind of stuff and just do the right thing.
Once upon a time there was a little old API, struggling for its life amongst the giants of software. Little old OpenGL knew that in order to survive it had to adapt to a strange, bewildering and new environment; it was a strange new world indeed. For two years, rumors of old OpenGL’s struggles reached the user-groups and there was much rejoicing indeed. But on one faithful day, August the 11th of 2008, OpenGL perished. Its age and idleness had (as with all things good and bad) caught up with him and slayed little old OpenGL in its path.
After reading the spec and looking desperately for the promised object model, I felt quite like a (self-censored) taking the newsletters seriously and writing about them so explicitly.
For those who haven’t read the specification yet, it’s OpenGL 2.1 plus and minus some stuff, hardly the fruition of two years labor. The anticipation that followed the initial announcement of OpenGL 3.0’s Object Model was tremendous. For the first time in a long time, people started noticing OpenGL again and maybe a place for it in modern multimedia applications such as PC games besides id Software’s titles.
Alas, it was not to be. Woe is me for my old API is truly dead. D3D, hello.
It’s been a while since I posted but this one will make up for it. A messy screenshot of NVIDIA’s 2008 timeline has emerged on Chilehardware (CHW) and reveals that OpenGL 3.0 drivers/implementation will be due in September of this year in a collection called Big Bang II (Big Bang I was SLI).
The words which could not be deciphered are marked with question marks. What this means for OpenGL enthusiasts and developers is that we won’t have to attend SIGGRAPH, NVISION or any other meeting for that matter, since this is basically a confirmation on its own.
Now, let’s hope that ATI will also provide an implementation this soon.
NVIDIA officially announced its new line of GPUs today on their website. Two models from the line have been announced, namely the GTX 260 and the GTX 280.
NVIDIA claims that the cards have a 50% performance increase over the Geforce 8800 Ultra (figures anyone?). Below are some highlighted specs for the high-end GTX 280:
Looking at the few mentioned features on the page (tessellation, multithreaded rendering, compute shaders, Shader Model 5), I’d say OpenGL is in big trouble if they want to catch up.
This weekend I took some time out to reformat my development computer in preparation for Windows Vista. I used Vista before but switched back to XP x64 in less than a week’s time. But heck, after a year and a Service Pack, I was willing to take the chance with Vista.
I wanted to take advantage of the DirectX 10 features Vista exposes since they’re not available on XP but was kind of disappointed with the performance of the API in Vista. It seems to me that the samples provided in the DirectX SDK simply run much slower than on XP.
Granted, I bought the most budget oriented GPU that supports DX10 (Geforce 8500GT 512VRAM) but that was simply because of the reason that I want my projects to be able to run on the lowest budget hardware possible while still being able to access DX10-like features. Dell, in fact, offers the 8400 on their laptops and budget desktop PCs, which is a fair share of the market and should be targeted.
Vista itself seems pretty solid so far; it certainly responds better than a year ago and supports all of my hardware and development tools (VS 2008, AQTime, Intel C++ compiler, etc). The big test will be OpenGL: Will it also have performance drops or stay the same? I’ll see tonight.
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.
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.
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.
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.
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.
NVIDIA has decided to publish the acclaimed GPU Gems book on their website, free of charge. Go to the NVIDIA website to read it. Did I mention it was free? Its free.
There has been a firestorm of discussions on the topic of “Is Direct3D 10 on Windows XP Possible?” This article will attempt to provide an answer to this hot topic. The answer has already been provided by Microsoft’s officials on several occasions but regardless of the manner in which DirectX 10 functions in Vista, would the functionality provided in Direct3D 10 be possible to implement? The official answer is a resounding no for the entire DirectX API, but what about Direct3D 10 which would be the only API of interest here?
What’s the argument?
Like any Direct3D version, Direct3D 10 is an API which abstracts a pre-defined set of functionality (as much as the API supports) of the underlying hardware. Ever since Direct3D 10 came out however, the minimum hardware capabilities were defined by the API rather than the hardware. This was a way to eliminate the old DEVCAPS (Device Capabilities) struct found in Direct3D 9 and below and to push a certain level of standardization or conformance.
If we take a close look at the features presented in Direct3D 10, which is easy since it’s predefined (non-expandable), we’ll notice shortly that none of the features are limited to Vista; neither are they unique to Direct3D in general:
Unified Architecture (programmable pipelines)
Shader Model 4: HLSL Pixel Shader v4.0, Vertex Shader v4.0
Geometry Shaders
Texture Arrays
Predicated Rendering
Instancing 2.0, which is a redo of the previous Microsoft Geometry Instancing
When a notice is made that these features were already available under Windows XP through OpenGL 2 and up, attention will most likely be redirected towards the WDDM, which is the Windows Display Driver Model, unique to Windows Vista.
What’s WDDM?
WDDM (Windows Display Driver Model) is a Windows Vista-only Windows Driver Model for IHVs (Independent Hardware Vendors) to base their display drivers on. WDDM allows the developers to take advantage of several new functions not available in the old XPDM Windows XP Display Driver Model, namely:
Virtualized Video Memory:
Allows the Operating system to (optionally) utilize system RAM if the Video RAM (VRAM) is insufficient.
Application requires a to push some data to VRAM via D3D API calls:
D3D10 User-Mode abstract layer handles event and triggers:
The Kernel-Mode WDDM interface determines:
If VRAM is not full, push onto VRAM stack, else:
Push onto RAM stack.
If the application needs to pop the memory from the stack, it doesn’t have to determine where to pop it from since WDDM handles this process. The stack push/pop terminology is used solely for simplifying the example and doesn’t denote the actual inner workings of the WDDM in any way since this is indeterminable.
GPU Threading:
A GPU process runs as a thread on the GPU and allows CPU-like multi-threading on a regular CPU. This means that you can spaw multiple Direct3D processes on a single GPU, thus WDDM must support the following item on this list.
GPU Interruptibility:
Allows process interruption, which means that you can switch from one GPU process to another without the process losing its context and resources.
Direct3D Surface Sharing:
Allows for a different process to access a D3D10 surface. This is necessary for the DWM (Desktop Window Manager) to function properly to allow for a final Desktop composition.
Other Features:
Allows for a Display Driver restart on failure without requiring a total reboot.
The Main Problem
Since the functionality introduced in WDDM is Kernel-Mode, there is no chance this could be implemented into Windows XP unless a total rewrite of the XPDM is initiated. The reason for this is that developers don’t have access to the underlying hardware directly, only through the usage of APIs such as Direct3D or OpenGL. This conversion of XPDM, naturally, will not happen since Windows XP is being deprecated in favor of Windows Vista.
While there have been attempts at porting Direct3D 10 / DirectX 10 over to Windows XP, this will always continue to be the main problem.
Alternative Solution
Using Direct3D 10 as it is provided in Windows Vista in Windows XP is impossible. Yet there is a possibility to achieve the same graphics quality on hardware that supports it on Windows XP; by using the OpenGL API instead. OpenGL allows the developer to access the same functionality provided by Direct3D 10 by using so-called IHV provided extensions but that’s an entirely different article. Also, note that this would only provide the same features which Direct3D provides and none of the WDDM functionality unless you find a way to emulate the Kernel-Mode functionality in User-Mode in Windows XP.
Over the last week I’ve been annoyed with the capabilities of the Intel 945GM chipset. While this chipset is not widely supported in graphics development, it’s a common chipset that Intel has to offer that comes standard with a bunch of PCs. So I’ve unhooked my Graphics card and attempted to run some of my code through this GPU.
Direct3D seems to work fine, pretty fast too. Pixel Shader version 2.0 seems to be supported through hardware, and Pixel Shader 3.0 through a software device. Now, you’d expect that the OpenGL implementation would have the same capabilities, or at least Pixel Shader 2.0 through hardware.
Turns out that the OpenGL version on this device is OpenGL 1.4 with to my knowledge no support for fragment shaders (GL_FRAGMENT_PROGRAM_ARB). I wonder why this is. The hardware capability is available, why not make use of it?
Valve’s hardware survey at the time of this post still reports that 22,183 people out there have the Intel (ialmrnt5.dll) driver. If so many gamers are using Intel’s chipsets, you can expect the regular end user base to be much larger. Why not give them some updates? Please? :o)
First of all, happy new year to you all even though it’s a bit late. Have some cake.
I’ve been keeping busy with some new “projects” lately, most involve OpenGL and Direct3D but more on this later when I have something to show or share.
Right now I’ve been disappointed with the stability of the new Visual Studio version, 2008. While there are some great new features for C++ programmers, my debugger seems to crash every now and then when debugging native code. I wonder if any of you out there have had the same problems…
Nevertheless, I like the new version and what its capable of concerning native C++.