If they want to play my game, they should get a decent computer. And the converse: If they have a high-end system which is powerful enough to smoothly run my software renderer, then logically they must have a very powerful system, which would certainly have a video card with 3D acceleration, so they won't need my software renderer anyway. Ok, there are some advantages to using a software render, though they are few.
Also, the software renderer could turn itself 'off' very quickly. The system I play Half-Life on is extremely powerful; your system might not actually run the software renderer at a decent speed. The Future in General The graphics programming field has sort of flattened out in terms of development of new things.
Everything that is out there is well understood, well documented, and well accepted. But anyway, back to the future. Back to the future? Get it? Ya know I think all eyes should be on the graphics hardware companies. They are doing all the new pathfinding. There is a lot for them to be done, and we have to wait for them, since it's our job to make what they design work. After the eternal Processor Wars, the graphics industry is probably the most interesting thing to watch.
If you are not writing for Windows platforms, then don't use D3D, because it won't run on those platforms. Instead, stick with OpenGL.
If you ARE writing for Windows, well you have one tough decision to make. If you learn one API, it is quite easy to learn the other, since the essential concepts are the same. I personally learned both at the same time please do not question my judgement on this. If you truly cannot decide, I have found a foolproof method of deciding. Find a coin. It doesn't matter what kind, as long as the top and bottom have different pictures on them.
Now choose one side to be "Heads" and the other side to be "Tails". Toss the coin up into the air. When it lands, check which side is face up. If "Heads", learn OpenGL. If "Tails", learn Direct3D. Now what ever API you chose, using whatever method, stick with it! Graphics programming is not easy to learn! You will sometimes find your self in difficult spots and may feel discouraged. But we can't use Direct3D! John Carmack denounced it!
Only, that was during the days Direct3D 5. In a much more recent post on www. Direct3D has to be used by programmers along with OpenGL. I can't take it! Direct3D with all its COM crap and such huge code! If you can't deal with long code like D3D you will do very badly in the game world. The same goes for COM and classes in general. I do however, concede the point that OpenGL will be a lot simpler for most people, at least in the beginning. Or use the Common Files; they are very nice too.
Great Games: What do They Use? I feel that it is only fair to tell you which APIs some games have used. All the Quake games used OpenGL. Carmack wrote those engines; it is called the Quake engine amazing, isn't it? Half-Life wrote support for everything. All XBox games use D3D. Other consoles are not really worth mentioning since they usually use their own custom APIs, though some - like the Playstation 2 - do support OpenGL in various formats.
Chumbalum Soft's Milkshape however, does not. This is a very advanced and very cheap editor; for those on a low budget it is a very good deal at 20 USD. I admit that the above quotes prove little. Even so, it is helpful to have some reference. It is worth mentioning that DirectX also provides many other interfaces for working with sound, input, etc. OpenGL doesn't include any of this functionality, because it is a pure graphics library.
When writing a game, however, you will need these tools. Fortunately, there are many technologies that can be used with OpenGL that provide this functionality.
OpenAL provides a cross platform audio library. Don't confuse this with any of the DirectX components. That to me seems to defeat much of the purpose of using OpenGL. Wrapping up That's about it, really.
There's not really too much else to say on the subject. Hopefully this guide has given you a better idea of which API to use, or at least what to consider when choosing. Oh, yes, contacts. For comments, suggestions, and questions, email me at comments zgx. For mistakes in this article, email me at woops zgx. If you still feel the need to flame me, email me at flames zgx.
NOTE: I cannot receive attachments, so please do not send them! This article is Copyright C , last edited on February 27, Although you are free to save or print out this article for your own use, under no condition may you distribute it to others without written consent of the author which I am, in fact, quite willing to give.
Editor's Note The intent of this article is to provide beginners with an unbiased overview of the OpenGL and Direct3D APIs, presenting the facts so that they can make their own decision about which to use. The author has rewritten the article several times in order to remove inaccuracies and statements which could lead to the types of flame wars we're trying to end with this.
I myself have made numerous changes to it for the same reasons. Still, if you feel that it still contains statements that are inaccurate or that suggest a bias for one API or the other, please let me know so that we can make the necessary corrections. Dave Astle Executive Producer Contributors Many people have submitted suggestions to make this article more accurate and useful. Their names are listed below. It would be interesting if this was rewritten to document the state of play now as opposed to how it was in In OpenGL at least, you have to load and manage textures, and when you draw them you need to get the geometry right.
A wrapper layer solves these issues. That said, using a 3D graphics back-end seems to have more upsides than downsides, so if you ask me, it's well worth the effort.
If your game is simple enough, and you want the game to run well on low-end machines, particularly netbooks and older laptops with no 3D acceleration, or very minimal - older Intel integrated graphics, etc , it's still worth considering a pure 2D framebuffer approach. Understand the concept of premultiplied alpha. Also remember that fillrate is limited. And it's surprisingly easy to reach those limits in 2D. You might not have many polygons, but if you want lots of alpha-blended parallax layers, or particles, or post effects - you can quite easily end up filling as many pixels as a fairly high-end 3D game.
Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group.
Create a free Team What is Teams? Learn more. Ask Question. Asked 11 years, 6 months ago. Active 6 years, 8 months ago. Viewed 5k times. Improve this question.
They are offering hardware acceleration, but in both 2D and 3D. There's a slight difference there. Add a comment. Active Oldest Votes. It was a nice discussion about some important points of OpenGL and DirectX which give you a lot of information about their basic requirement and capacity. Now i will take you through some special features of both software individually.
Now after pointing out the main facts of both software from this article according to you, you can find a solution of your doubt that was which is better API, OpenGL or DirectX? In my point of view, you should try both software so that you can decide which is better on the basis of your own opinion. Here we also discuss the opengl vs directx key differences with infographics and a comparison table. You may also have a look at the following articles to learn more —. Submit Next Question.
With the mainstream adoption of graphics acceleration hardware, the use of one API or another no longer implies the use of a specific optimized software renderer. Instead, the low-level rendering logic is implemented in the graphics hardware and its drivers, and thus is largely the same whether OpenGL or Direct3D is used.
This trend has revealed that neither API possesses an inherent speed advantage over the other. The performance of an application depends instead on the programmer's skill, the quality of the drivers, and the performance of the graphics hardware. OpenGL, originally designed for then-powerful SGI workstations, includes a number of features that are only useful for workstation applications.
The API as a whole contains about calls, but only a subset of perhaps are useful for game development. However, no official gaming-specific subset was ever defined. MiniGL, released by 3Dfx as a stopgap measure to support glQuake, might have served as a starting point, but additional features like stencil were soon adopted by games, and support for the entire OpenGL standard continued.
Today, workstations and consumer machines use the same architectures and operating systems, and so modern incarnations of the OpenGL standard still include these features, although only special workstation-class video cards accelerate them. The specification often drives the implementation of hardware acceleration for these features. Meanwhile, Direct3D developers had to wait for the next version of Direct3D to be released and rewrite their games to use the new API before they could take advantage of hardware-based Transform and Lighting.
The advantage of OpenGL's inclusive, extensible approach is limited in practice, however, by the market dominance Direct3D has achieved. In recent years, games have rarely implemented features until Direct3D has supported them, and graphics cards vendors have been reluctant to implement features that current or upcoming versions of Direct3D will not support.
OpenGL includes a mechanism where any driver can advertise its own extensions to the API, thus introducing new functionality such as blend modes, new ways of transferring data to the GPU, or different texture wrapping parameters.
This allows new functionality to be exposed quickly, but can lead to confusion if different vendors implement similar extensions with different APIs. On the other hand, Direct3D is specified by one vendor Microsoft only, leading to a more consistent API, but denying access to vendor-specific features.
These were once little-known and rarely used, but are now used for DXT texture compression. When graphics cards added support for pixel shaders known on OpenGL as "fragment programs" , Direct3D provided a single "Pixel Shader 1.
Under OpenGL the same functionality was accessed through a variety of custom extensions. In theory, the Microsoft approach allows a single code path to support both brands of card, whereas under OpenGL the programmer had to write two separate systems. In reality, though, because of the limits on pixel processing of those early cards, Pixel Shader 1. For the most part, the only cards that claimed PS 1. The only cards that claimed PS 1. Fortunately, this situation only existed for a short time under both APIs.
Second-generation pixel shading cards were much more similar in functionality, with each architecture evolving towards the same kind of pixel processing conclusion. As such, Pixel Shader 2. An issue has arisen between Direct3D and OpenGL recently mid-to-late , with regard to support for Microsoft's new operating system, Windows Vista. The Vista OS has a feature called Desktop Compositing which is similar in concept to Mac OS X 's Quartz Compositor that allows individual windows to blend into the windows beneath them as well as a number of other cross-window effects.
The new OS's rendering system that allows this to function operates entirely through Direct3D; as such, every Windows application is automatically a Direct3D application. The ICD driver model used in prior versions of Windows will still function however. Note that this functionality only truly matters for applications running in windowed mode. Full-screen applications, the way most people run games, will not be affected. Desktop compositing wouldn't affect them regardless, and the user won't notice that windows that the user can't see have had desktop compositing deactivated.
Microsoft has also updated their own implementation of OpenGL. This was a software OpenGL implementation which was frozen at version 1.
0コメント