Now DirectX was be Dire ctX (cut by T. Jackson)??.

OpenGL is very easy that Direct3d, but the opengl.dll for many graphics card is *bull ###*. You can play quake 3 in a expensive graphics card but if the company (hw) is poor, then the opengl too is poor.
In Direct3d you can look what it is a hw-implement or software-implement, and you can choice the best route. OpenGl not look if they is hw or software layer!. Supported in OpenGl not is equal to hardware support.





-eng3d.softhome.net-

Hmm...I smell something burning...a flame war? OH NO, THAT''S MY CPU FRYING ITSELF!!! Damn! I KNEW I needed to by a new fan. Gotta run!

OpenGL is better. I don''t know why - it just is!!!

(just want to make a small contribution to a senseless flame war)

Hmm, why am I even saying anything?

I don''t know anything about OpenGL, and I don''t know much about DirectX, either. (I''m just now learning it, because I''m switching my project over to Windows (it was in DOS before), so I can allow for Winsock use.)

Anyway: I hate DirectX, I hate COM, I hate Hungarian notation, and I hate Windows. There, I''ve said it. If anyone wants to flame me, i.e. tell me that I''m too stupid to be a programmer, go ahead; I''m not going to argue with any pompous airbags; you can''t stop me from hating the things I hate. I just hate ''em, period.

To kertropp:

OpenGL supports extensions, this way a feature can be implemented right away.

OpenGL supported all things that D3D7 supports a long time

The only thing D3D has is driver support, and nowadays that''s not an issue anymore

You are comparing 3D APIs with eachother, and then put in game-programming specific WHY!?!?!??! It isn''t DX we''re talking about, it''s OpenGL <-> D3D

so your new list would be:
______________________OpenGL__DX_GLide_importance
-----------------------------------------
available platforms_______8____4____3___/__5x
supported hware___________7____8____2___/__5x
features up-to-date_______10___9____5___/__8x
// THIS ONE DOES NOT COUNT, YOU CAN USE DINPUT / DSOUND ETC WITH EVERY API game-programming specific_6___10____?(6)/__0x
code cleanness____________9____7____?(7)/__9x
-----------------------------------------
________________________236__195____128

so, OpenGL wins

Jrz: Your priorities of what is important in a game are way out, you give the importance of up to date features 8x, but supported hardware 5x. I think it''s a hell of a lot more important that a game works than if it supports the latest (pointless) graphics feature like bump mapping etc. As far as I know the only two cards that use bump mapping are the GeForce and the Matrox G400, and the matrox card''s OpenGL support is terrible.

-- Kazan - Fire Mountain Games --

I believe that was the point of the original chart posting by Kertropp. He was right on with the idea of the chart, and the "importance" column illustrates the fact that this whole argument is completely subjective because OpenGL and Direct3D have different strengths and weaknesses. Whatever criteria is most important to you determines which API is better for you. For someone who cares about cross-platform compatability OpenGL is the obvious choice, but if hardware compatability on the Windows platform is your primary concern then Direct3D is probably what you want. There are some cases where the choice is not so obvious, and the market and both APIs are constantly changing, but it mostly comes down to the developer''s priorities. Why is that so hard to accept for zealots on both sides of the fence?

In response to the original question, NeHe just posted a 2D game programming tutorial using OpenGL on his site: http://www.gamedev.net/hosted/nehe/

David you said everything I wanted to say (About com and windows and etc.). The reason I mainly hate DirectX is I make something, I compile it 50 times to fix all the bugs, and than when I run it, it doesn''t fricking work!. OpenGL is the other way around, compile a program much less times, works most of the time, and if it doesn''t theres a workaround to it. Maybe its just me...

And umm to your 2D problem... I agree to use a quad and texture map it. If you use perspective with ur "2d" you can make some cool stuff like making the bitmap rotate in 3D even though its "2d" like when some tank explodes =)
Or you could just go the ortho way... you try them and choose for yourself.

MODERATOR: Feck this damm thread off, PLEASE!! It''s another damn OpenGL v. Direct3D threads!!

I''m so peremptory...
OldManDave.

I really should know better than to post into a rampant "my API is better than your API" (API envy?) war, but here goes....

Both OpenGL and Direct3D/Draw (its not comparing like with like to compare OpenGL with non-graphics items) have advantages and disadvantages. Its really a matter of choosing whichever one works better for what you need for your specific project.

OpenGL is relatively portable (although some of the driver implementations, under both Linux and Win32 are TERRIBLE - and will make the best code in the world look really, really bad), and is currently the only real cross-platform option. It performs okay (unless you happen to be Id Software, in which case you have enough graphics card industry support to have them edit their drivers to support your way of doing things - Epic had no such luck, and its likely that anybody writing on this board has less influence than Epic!), looks okay, and is relatively straightforward. Since Farenheight fell through, Windows implementations of OpenGL definitely could be better - getting access to full screen rendering is basically a hack, for example. OpenGL''s interfaces generally make sense, and when extensions are available they usually let you use the latest and greatest features (although not very many companies actually release extensions, sadly enough; Nvidia deserve credit for trying). OpenGL automatically uses any hardware transformation & lighting that is available, although OpenGL''s lighting functions are really rather bad and are unlikely to see much use. The big downside to OpenGL (from a game-writing perspective) is that it operates at a much higher level than Direct3D. OpenGL really isn''t written for games, after all, so its no surprise that you don''t get low-down and dirty access to texture memory. Texture swapping under GL can be SLOW, especially if your texture utilization happens to differ from Quake''s!

Direct3D is a little harder to pick up initially (I still think its incredibly easy), and interfaces directly with most hardware on modern Win32 systems. D3D isn''t portable, so you lose the Mac and Linux audience if you write for D3D. D3D is FAST, especially if you take the time to read the SDK (which is really well documented, it has to be said). New versions of DirectX come out about once a year, which is both a good and a bad thing: you have to relearn some of your D3D techniques every year, but on the upside you almost always have access to the latest and greatest features. D3D''s texture manager isn''t bad, and you have enough fine grained control to write your own if you need to. D3D is low level enough to tell you exactly what you can and can''t do, and lets you write alternatives to things that won''t work. Driver support is very good (although some cards will manage to make anything look bad!).

A note on portability: Specific API calls shouldn''t be much of an issue in portability questions. Both APIs rely on pretty standard stuff: matrix transformations, and pumping triangles through a Transform/Light/Render pipeline. The only real differences are the specific calls to load textures, manage texture memory (if necessary - both APIs can do that for you), send vertices to be transformed, perform any vertex lighting (or write to a procedural texture for lightmaps), and finally send into the rendering pipeline. Its relatively easy to write an object oriented interface that simply lets you plug in the desired interface, either at runtime or compile time. The key is understanding the basics, not expecting the API to make your engine good.

A note on COM: I like COM. Maybe I have a Microsoft mindset, maybe I don''t. I can see why others would be confused by it, but the more I think about it the more I realise just what a stroke of genius it is. COM solves MANY problems; by making several versions of an interface available you don''t break all your installed programs when you install a new DLL. Sure, "DLL-hell" can still happen, but the alternative is really rather chaotic, especially in an environment in which source-code release isn''t likely to happen (and isn''t desirable; GNU-Windows would be another Mozilla disaster waiting to happen, IMO - if MS have trouble organizing their own programmers/codebase, just think what it would be like with thousands of "hackers" with their own ideas and little eye on the overall focus would create?????).

So really, its horses for courses on the API front. If you are relying too heavily on an API and can''t understand the other one, then you have problems - whichever API you choose to focus on. Ultimately, they are two expressions of the same problem: how to draw triangles.