I’ve been out of the .NET loop for a very long time. I would never have thought that it was so easy to get a .NET project up and running on Linux. But, I guess a decade of embracing Open Source at Microsoft changes things. Here are the steps I took to get an OpenGL window up and running on Ubuntu using .NET Core, VSCode, and OpenTK.
Just launched OpenGLBook.com, a website on learning OpenGL 4.0 programming in online book format. The first two chapters are online, new chapters to be released periodically.
John Carmack, of DOOM, Wolfenstein, and Quake fame, has spoken out on the issue of Direct3D vs OpenGL in an interview with the folks at bit-tech. Check out the article here. Note that Carmack is still using OpenGL in his game engines because of cross-platform compatibility reasons, but prefers Direct3D’s more modern API.
It’s sad to see OpenGL in such a state of disrepair that even a contributor (id Software) to the specification denounces the standard.
P.S. Happy π day.
It’s almost weekend, and time for a lighthearted post on the two realtime 3D computer graphics libraries that are available on Windows in 2011: OpenGL and Direct3D. The reason I mention the year is simply because of the fact that two years from now, this information will be as untrue as the Wikipedia article* on this matter due to rapid hardware and software developments. But for now, let’s bash it out.
As an OpenGL junkie I just have to dedicate at least one post to this topic.
By now you’ve undoubtedly heard of OpenGL ES, the OpenGL based library used on embedded devices such as cell phones and gaming consoles. OpenGL ES is what gives many Android based phones and iPhones their 3D gaming capabilities that rival the desktop machines of only a few years ago in terms of power. It seems like these days we’re all carrying a little computer in our pocket.
Artistic License?
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 here, (Edit: It’s official) haven’t read it yet but here it is:
The OpenGL ® Graphics System: A Specification (Version 3.0 - August 11, 2008)
Link to the registry containing the link
Let me know what you think of it, thanks nosmileface!
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).
CHW member KaiserGerhardI has provided a deciphering of the screenshot which provides more information on the contents of the screenshot:
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.
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:
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 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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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:
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.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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.
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.
| Features | OpenGL | Direct3D | XNA |
|---|---|---|---|
| Cross-Platform Support, amount | Yes, numerous | Yes, three | Yes, two |
| Learning Curve | High | High | Low |
| Native Language | C | C | C# |
| Supported Languages | Most Languages | Most Languages | .NET Languages |
| High Performance | Yes | Yes | No |
| License Restrictions | No | No | Yes |
| Support by Developer | No | Yes, paid | Yes, paid |
| Library Platform | Native | Native | Managed |
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?
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:
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.
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:
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.
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)
After waiting for a long time an update has been issued about the OpenGL 3.0 specification. While this is an update, there is still no specification but the promise that the OpenGL ARB is working hard on the spec is below.
You understandably want to know where the OpenGL 3 specification is. I have good news and some bad news. First the bad news. Obviously, the specification isn’t out yet. The OpenGL ARB found, after careful review, some unresolved issues that we want addressed before we feel comfortable releasing a specification. The good news is that we’ve greatly improved the specification since Siggraph 2007, added some functionality, and flushed out a whole lot of details. None of these issues we found are of earth-shocking nature, but we did want them discussed and resolved to make absolutely sure we are on the right path, and we are. Rest assured we are working as hard as we can on getting the specification done. The ARB meets 5 times a week, and has done so for the last two months, to get this out to you as soon as possible. Getting a solid specification put together will also help us with the follow-ons to OpenGL 3: OpenGL Longs Peak Reloaded and Mount Evans. We don’t want to spend time fixing mistakes made in haste.
Here’s a list of OpenGL 3 features and changes that we decided on since Siggraph 2007:
- State objects can be partially mutable, depending on the type of the state object. These state objects can still be shared across contexts. This helps in reducing the number of state objects needed in order to control your rendering pipeline. For example, the alpha test reference value is a candidate to be mutable.
- We set a minimum bar required for texturing and rendering. This includes:
- 16 bit floating point support is now a requirement for textures and renderbuffers. Supporting texture filtering and blending is still option for these formats.
- S3TC is a required texture compression format
- Interleaved depth/stencil is a required format for FBO rendering
- At least one GL3-capable visual or pixel format must be exported which supports front-buffered rendering.
- OpenGL 3 will not have support for the GL_DOUBLE token. This means it will not be possible to send double precision vertex data to OpenGL.
- A format object has to be specified per texture attachment when a Program Environment Object is created. This helps minimize the shader re-compiles the driver might have to do when it discovers that the combination of shader and texture formats isn’t natively supported by the hardware.
- GL 3 will only cache one error, and that is the oldest error that occurred.
- The OpenGL pipeline will be in a valid state once a context is created. Various default objects, created as part of the context creation, will have reasonable default values. These values are such that a simple polygon will be drawn into the window system provided drawable without having to provide a Vertex array object, vertex shader or fragment shader.
- GLSL related changes:
- GLSL 1.30 will support a #include mechanism. The actual shader source for the #include is stored in a new type of object, A “Text Buffer” object. A text buffer object also has a name property, which matches the string name specified in a #include directive.
- Legacy gl_* GLSL state variables are accessible through a common block.
More details will follow soon in an upcoming OpenGL Pipeline newsletter.
Barthold Lichtenbelt
OpenGL ARB Working Group chair
Timothy Farrar over at FarrarFocus.com is creating a unique game called Atom. The reason why I call it unique is that unlike many games out there the content for Atom is 100% dynamic which means that (for example) everything can be set in motion. Here’s a quote from Timothy’s post on GameDev.net:
Atom started with the idea to go back to PC gaming’s roots (low risk investment, experimenting with technology, fun timeless gameplay, taking a wild idea from concept to market), while taking advantage of the power of modern hardware.
[…]
The graphics engine is completely unconventional, 100% dynamic (no static geometry, everything moves), and based on an animated solid hierarchical cellular representation with an “animation bone” for each cell which is linked into a physics/CFD engine which gives life to the world. Rendering is done via a special purpose painters order micro-impostor compositing engine (old-school, not based on polygons!) which also provides realistic motion blur. Content creation is done with a mix of hand controlled procedural generation.
Due to Atom’s unique world representation, you can literally zoom into the molecular structure of anything, even on the inside. This also works in reverse, Atom is able to simplify any structure, and thus has infinite level of detail control. A custom visible surface determination algorithm eliminates overdraw allowing for both wide and telephoto views inside and side any structure no matter how sparse or dense the geometry.
The concept seems very promising, I suggest watching this project grow. Another thing worth mentioning is that the API used to generate the images is OpenGL, not DirectX. Timothy has posted on his blog that SM 4.0 will might be added to the engine. This is good news for XP users since there will be no need to upgrade to Vista if you want to try out this game.
Check out the Atom project here and watch the videos.
Recently I’ve created a post about how id Software will no longer use OpenGL as their primary graphics API for game development. Here’s John Carmack’s response to the rumors:
There is certainly no plans for a commercially supported linux version of Rage, but there will very likely be a linux executable made available. It isn’t running at the moment, but we have had it compiled in the past. Running on additional platforms usually provides some code quality advantages, and it really only takes one interested programmer to make it happen.
The PC version is still OpenGL, but it is possible that could change before release. The actual API code is not very large, and the vertex / fragment code can be easily translated between cg/hlsl/glsl as necessary. I am going to at least consider OpenGL 3.0 as a target, if Nvidia, ATI, and Intel all have decent support. There really won’t be any performance difference between GL 2.0 / GL 3.0 / D3D, so the api decision will be based on secondary factors, of which inertia is one.
John Carmack
Somehow I keep getting back on this topic. Maybe it’s because of the excitement that was involved with the features promised by the idTech 5 engine as presented in the earlier QuakeCon demo.
Today was one of those exciting days for me. I just finished watching a two part video commentary on the development aspect of idTech 5 that was posted on GameSpy. A third video is an interview with John Carmack on the changes that will be occurring within id Software and other issues. The two commentary videos feature commentaries by John Carmack and Matt Hooper from id Software.
Keep in mind that the “lag” that you might notice is because you’re viewing a technical demo of an unfinished product. Another thing that might be worthy to notice is that the OpenGL API is no longer being used as primary graphics API, yet the company is moving towards DirectX as their primary API.
The first video is presented by John Carmack and is about the development of idTech 5 and Rage. The backdrop for this video is pretty much continuous, so you might want to look away to avoid insanity. He speaks about graphics development, Enemy Territory: Quake Wars and other things that might be interesting to developers.
The second video introduces Matt Hooper as a secondary host and talks more about the tools and assets given to the level designers and artists in idTech 5. For an unreleased product, it looks amazing. There seems to be a great (if not massive) improvement over older tools such as GtkRadiant by having a more intuitive user interface. But you can judge for yourself below by watching the videos attached to this post.
The third video announces a new “game” or adaptation of the existing Quake 3 code base and create a free to download online game, hear all about it in the third video.
Edit: as of 2023, it seems that these videos have been lost to the ravages of time.
John Carmack and the id Software company have always been great supporters of the OpenGL Graphics API. Alas, major development with the API stops here for the game developer.
id Software has been working on a new game engine that would “revolutionize” the gaming industry and provide many advanced features. One of its main features is that it can support a constant 60fps on console systems. It was also announced that their new engine will run on: PC, Mac, Xbox 360 and PlayStation 3. Eh, are we missing something important here?
Linux. Linux has always been a supported system when it came down to games from id Software. Yet according to Todd Hollenshead (id Software), id’s upcoming game “Rage” (which will be using idTech5) will be primarily a DirectX 9 game, not DirectX 10, nor OpenGL. Yet OpenGL will be used for the Mac release of both the engine and the game.
This could mean that OpenGL might become very unattractive in the game development community since there will be one less patron to support its Open cause.
One benefit from all this is that the game will be able to run on the Windows XP platform and not solely on Vista as all DirectX 10 games require. This, of course, is no consolidation for the Linux people who will now have to run the game on Windows.