Author : Promit Roy
Page : << Previous 3 Next >>
you are specifying a vertex. "3" tells you that the vertex is being specified in 3 dimensions, and "f" means that the arguments are floats. (Note that the number isn't present in most functions, but when it is present it refers to how many components or dimensions the function specifies). To help portability, OpenGL defines custom types, all prefixed by "GL", which may be followed by a "u" for unsigned values, and then a name indicating the type, such as short, long, float, etc. An example type is GLuint.
One final thing to note is that OpenGL syntax for C is much more intuitive and simple than the C syntax for D3D.
Looking at the Header
The header is relatively simple. If you know what a function looks like and what __declspec(dllimport) does, you will understand what the header does. It has defines, then lots of __declspec(dllimport) ReturnType glFuncName( Arguments ); lines.
Strengths
OpenGL has many strengths. OpenGL is very portable. It will run for nearly every platform in existence, and it will run well. It even runs on Windows NT 4.0, which Direct3D doesn't even do (well, it does, but you have to use DirectX 3; do you really want to use a version of Direct3D that is 5 versions old? Also, note that Windows 2000 and XP, which are both based on the NT kernel, can use the latest versions of Direct3D). The reason OpenGL runs for so many platforms is because of its Open Standard. What this means is that any company with a platform who wishes to support OpenGL may buy a license from SGI and then implement the entire OpenGL feature set for that platform.
OpenGL has a wide range of features, both in its core and through extensions. Its extension feature allows it to stay immediately current with new hardware features, despite the mess it can cause. Because the ARB is made up of a diverse group of companies, the features available in OpenGL represent a wide range of interests, and thus make it useful in many different applications.
OpenGL is used for many different things. Its stability and support on a wide range of platforms has a lot of appeal to people in tech sectors outside of the game industry. OpenGL is used in such places as the military, professional 3D modeling and rendering, CAD, and so on. It's recognized as the industry standard for graphics everywhere except the game industry, where Direct3D provides viable competition.
Weaknesses
I mention extensions here too. Though they are powerful, they do make code messy, very much so at times. They also make it confusing with any compiler that doesn't offer reference tracking (browse file). The worst part is, many newer extensions are completely card or vendor specific. Although useful for testing a graphics card's abilities, vendor-specific extensions are not frequently used by commercial applications.
The function naming conventions can seem like overkill at times, since many IDEs have context sensitive help which can show you the parameters that are required, and in any case, if you know how to use a function, you should already know what parameters it takes. In addition, having 12 different names for a function may seem strange to a C++ programmer accustomed to function overloading (of course, since C doesn't support function overloading, there really isn't any way to get around it).
Language Support
Under Win32 platforms, at least, OpenGL uses a standard DLL with export functions. Using it is just like using the regular Windows API. That means that you can use it anywhere in any language at any time. (Unfortunately, I have not had experience with Java. People are rather vague about whether or not you actually need Java3D. It is probably best to check Sun's website for the Java specification on this.)
The Future
There has been a great deal of activity lately regarding the future of OpenGL. 3D Labs has put together a proposal for OpenGL 2.0, which is currently under discussion by the ARB. The reasoning behind this proposal is that the original OpenGL specification looked into the future and set the standard for many years to come. The graphics world has now passed the original specification, and the ARB is just trying to keep up with it. 3D Labs wants OpenGL to raise the bar and once again set the standard for the future. OpenGL 2.0 as described by the proposal offers a lot of truly powerful things for the future. I suggest you read it yourself at http://www.3dlabs.com/support/developer/ogl2/index.htm. Amongst other things, it heals the sad state of the OpenGL extension system by including support for you to rewrite the OpenGL rendering pipeline in a C-derived language, which is far better than D3D's cryptic ASM-like shader language. (You can see I'm very hyped up about it, but don't let that make OpenGL 1.3 seem any less powerful.)
Comments/My Advice
If you plan to go specifically into the games industry, you would be wise to learn both D3D and OGL. That's just how it is now. For any other 3D industry (and I do mean any other industry, OpenGL will take you far. Ultimately, it's a matter of personal preference. And whether you decide to learn OpenGL or Direct3D first, you can always learn the other later, and it's actually very easy to learn one if you know the other.
A Note on Glide
You may have heard of another graphics API, called Glide. Glide was developed by 3dfx. It can work on other graphics cards, but was made specifically for 3dfx chipsets. As a result, it typically runs rather badly on non-3dfx cards. On every game you play that uses Glide, you will read, "Do not use Glide unless you have a Voodoo graphics card, or another graphics card with a 3dfx chipset." I have not used Glide myself, but I am told that programming in Glide is a great pleasure. Unfortunately, 3dfx is dead, and although there are many 3dfx cards still out there, they are quickly becoming outdated and being replaced. Using an API that only targets an audience that is rapidly shrinking really is not a good idea. That's how I feel on the issue. To put this very bluntly, in my opinion, learning Glide is a waste of time because its target audience is far too small! As a final note, the fact that most 3dfx cards support OpenGL to some extent, there is absolutely no point in learning Glide.
Performance and Quality Factors
I've carefully avoided mentioning performance for most of this article. Why? There is a huge debate on the problem. There are many people who claim that OGL is faster than D3D, and of course, the reverse as well. I've been studying performance results: I've considered my own, my friends', and the results of major companies. I have come to the following conclusion: Performance is no longer an issue! The speed for both APIs has come out exactly even for well written programs. The performance can only be gauged per machine, and that by testing. There is no way to predict which will run faster. Like I mentioned earlier though, game programmers are going to have to write for both. It sucks, but that's the way it has to be, for now at least. And if you aren't going into games, well, there was really no debate to what API to learn anyway (OpenGL!). So as far as performance goes, I cannot really advise you. It would be best if you evaluate the two on your own.
I feel that I should still address what exactly it is that affects the performance. If a game is well written, by people who know how to properly use the API, then performance is in the hands of the guys who make graphics cards and drivers. No one else has anything to do with it anymore. What determines performance is how well the API, driver, operating system, and hardware interact. On one of my computers, for example, OpenGL runs somewhat faster. I do know, however, that this is due to an incompatibility between DirectX and WindowsXP and my GeForce MX100/200 card/driver.
The above applies a great deal to quality as well. The APIs don't really have an edge over each other at all. The most important factor in quality, however, is your artwork. A good artist will make even a bad game look fantastic, but the converse applies as well. If you want high-quality, get a high-quality artist.
Software Renderer? That sounds AWESOME!
It's not. What a software renderer does is instead of using your video card's built-in functionality, you have to write all the functionality yourself. As you can imagine, this adds a LOT of extra overhead to your program. Quality is typically worse, and features are usually constricted, unless 1) you are one hell of an awesome programmer, or 2) the renderer is under development by your company. Since the renderer is running alongside your program, usually in the same process, it is much, much slower than hardware rendering. In
Page : << Previous 3 Next >>