My 1st non-inflammatory post: Is OpenGL a dying API?

[Buuri]

a FEATURE, NOT a weakness of the API.

Just how many Windows jokes can I pull from this..
Really, it's a weakness. When using DirectX one can ASK the hardware (driver) if it supports EMBM for example. Then based on the answer, the feature can be toggled on or off.
Ugin OpenGL, one has to KNOW the specific calls for a specific hardware for the same result. This due to the "feature" of manufactorers allowed to add extensions not commonly excepted.
This leads to some effects that must be noted; OpenGL-game (for example) can only support special features on cards that are out when the game is written. For a new card, one will have to patch the game to get the feature working.
Again, needless to say this is not the case with DirectX/3D.

iD found OpenGL to be usable because, will, it is!

How can you use that as an argument when n^24 more companies use only Direct3D? Because they are proven mindless?

:
B

[C=64]

Really, it's a weakness. When using DirectX one can ASK the hardware (driver) if it supports EMBM for example. Then based on the answer, the feature can be toggled on or off.
Ugin OpenGL, one has to KNOW the specific calls for a specific hardware for the same result. This due to the "feature" of manufactorers allowed to add extensions not commonly excepted.

I'm sorry, but the argument of this point was lost me. You seem to be saying that using a card-specific feature requires card-specific knowledge. Umm... Okay. I'll completely grant you that point. What I don't see is how D3D is not affected by this very same PROBLEM. You are asking the cap bits to find out what the card can do. I ask the string returned by glGetString(GL_EXTENSIONS) to find out what I can do. An excellent example of this is Quake. Quake's lightmaps are effectively processed by multi-texturing. However, if multi-texturing is not available, iD has quake go through the trouble of doing the multi-texturing manually.

Also, if the feature isn't represented by a cap bit, you can't access it at all with D3D. No holds barred in OpenGL, though. If Matrox decides to do voxels and is willing to code up some sort of extension for me to have my evil way with for OpenGL, I'm a happy camper. As long as I use OpenGL, that is.

You must also consider WHY this extension system is necessary. Remember, the OpenGL model requires certain commands to exist. Direct3D does not. That's how a company could release a card, way back in the day, without texture mapping for example, but still be compliant with D3D. OpenGL on the other hand promises that at least a minimum feature set exists. If the hardware doesn't do it, it's the driver's duty to perform the task in software. And really, should all the developers be optimizing their replacement routines for features that may be lacking in a D3D implementation, or should the driver developer do the job once, and maintain it for future hardware platforms to maintain utmost performance. I gladly choose the later.

This leads to some effects that must be noted; OpenGL-game (for example) can only support special features on cards that are out when the game is written. For a new card, one will have to patch the game to get the feature working.
Again, needless to say this is not the case with DirectX/3D. Again, needless to say this is not the case with DirectX/3D.

Umm... you may want to reconsider that statement, in particular that last line. It really doesn't appear to make much sense. Why doesn't a D3D app need to be patched to use a new feature? EMBM, for example, isn't appearing in, say, my copy of Forsaken. Why? Because the developer did not add the functionality for it. A developer does not gain magical abilities they did not intend in an application, whether they use OpenGL or D3D. Its a fact of life. Consequently, any new feature that a card supports that a game wants to take advantage of requires some sort of update to the underlying code. Otherwise, I'd be able to run Commander Keen in full 3D glory just because I've got a G400 .

As a side, I'll grant the notable exception of anti-aliasing, but that's (in theory) simple for a driver to drop in that has access to the frame buffer. But that's a topic for another day. Also, some may say that the T&L boast the GeForce got without having the rewrite quake to handle it was a free feature, but remember, under OpenGL you can ask the GL to do the rotations and lighting for you, so if the driver is willing to make use of some tasty hardware, they are completely free to do so.

How can you use that as an argument when n^24 more companies use only Direct3D? Because they are proven mindless?

Did I once claim anyone in my statements to be mindless? I most certainly did not! How does OpenGL being a useable and credible platform insult anyone's intelligence? I have a great deal of respect and admiration for the effort and talent that goes into producing a game. I'm endeavoring to enter that industry myself upon graduation. Alas, I cannot see the connection of your statement and mine. This statement was in response to a comment where someone claime they only reason that anyone uses OpenGL was because iD uses it, regardless of the technical merits of OpenGL or D3D.

As a side, I've noticed folks repetitvely mentioning that there are features that are in D3D, but in OpenGL. I'm at a loss to find any though... I realize this sentence appears to be flamebait, but in all honesty, I'm truly curious.


Well, enough jabbering. Back to code.

C=64

[Cloudy]

Just to add some missing info, if your graphic adapter can't do some stuff in hardware - DX wise you're lost, in OpenGL on the other hand, you can do everything in software, big big plus to OpenGL here.
OpenGL has a lot of missing features (perspective correction so I'v heard) - correct BUT - SGI, ATi, 3Dfx and a big bunch of other companies excluding Nvidia and M$ are defining a new thing called OpenML which will be portable as OpenGL and will set a new standard thus eliminate Glide (yes 3Dfx will discontinue it) and OpenGL.
I like D3D for many games, but still, take to identical computers and run Unreal Tournament in D3D and OpenGL side by side, then you'll see the difference. As picture quality (matrox) fans, you should like the OpenGL picture quality much much better.

One last point - D3D - Micro$oft only
OpenGL - MacOS, all xNIX, BeOS, Windows etc.

Considering the fact Linux will do to M$ what AMD does to Intel, OpenGL - and later OpenML is the winner.

------------------
Cloudy
Asus P2B-DS, 2 x Celeron 400@75Mhz, 128Mb Ram, SB Live! Platinum,
2 x IBM 4.3Gb scsi,IBM 22GB IDE, Pioneer DVD ROM scsi, G400 32MB DH (Oc to 150/200).

[franksch3]

That Epic is completely turning toward Direct3D with the next iteration of their Unreal 3D engine is a big statement that Direct3D simply fits the needs for game developers better than any other portable API.

At the time of DirectX3 Direct3D was lacking in comparison of OpenGL and very hard to program. DirectX7 however is much more easier to program and I dare to even that far that it is just as simple as OpenGL.

Even more so I like the setup of Direct3D in the way that it is object oriented (using COM) where OpenGL is quite old in the fact that everything must be passed as parameters.

With DirectX8, Direct3D simply supports to much new features which OpenGL is lacking. Direct3D is making 3D programming much more abstract so that more and more can be handled transparantly by hardware acceleration.

[Buuri]

I ask the string returned by glGetString(GL_EXTENSIONS) to find out what I can do.

Yes I know you get the string, but still the point is that there is NO WAY to guess TODAY how nVIDIA will name their extensions for EMBM (for example) TOMORROW. Even if you get the string, you would have to have quite an AI engine to figure out (at run-time) what the extensions might actually do. They are not of standard form exept for the prefix.
The last sentence in my earlier post you quoted ment that if nVIDIA implemented EMBM (again as an example) in D3D driver, the call would have to be exactly the same as for Matrox driver, because Microsoft has if standardized thus making all the EMBM supporting (D3D-) games today going fine with that hardware as well. So programmer needs to pay zero attention to it, while using OpenGL every device is different (read, has calls of arbitrary format decided by the company making it).
I very well realize that is not the case for the most simple features like defining a triangle, but I'm talking about future and future features which I thought this thread was about.

:
B

[Cloudy]

Sorry Franksch3 but you're wrong, read more updated news, Epic is dumping Glide, not OpenGL.

------------------
Cloudy
Asus P2B-DS, 2 x Celeron 400@75Mhz, 128Mb Ram, SB Live! Platinum,
2 x IBM 4.3Gb scsi,IBM 22GB IDE, Pioneer DVD ROM scsi, G400 32MB DH (Oc to 150/200).

[Taz]

Just a thought, maybe the reason game developers seem to prefer DirectX over OpenGL is due to the lack of support most video card manafacturers give to OpenGL when writing their drivers. Having never written anything using either API I can't really say whether that's good or bad, the last games programming I did was in machine code on an Atari ST. In those days you had to write everything yourself there weren't any API to speak off, but then peoples expectations were a lot lower

[Pace]

I thought OpenML is to OpenGL, what DirectX is to Direct3D? Is OpenML a new standard dumping OGL completely?

And I thought that Epic were only dumping OGL - because of the problems they had with it. Glide has been their strong API, with
D3D 2nd (though close to 1st now) and OGL their worst API - why would they drop Glide when it offers such and advantage to 3dfx owners?

And in answer to the thread - it isn't dying - because it never was successful in the gaming arena. Quake was the first I belive (or GLQ) and since then their have been various games based on the Quake series of engines - some adding Direct3D like Half-Life but generally keeping with OGL. The OGL driver problem is an issue - many manufacturers have excellent D3D drivers but OGL has lots of issues across cards. So most publishers will hence program with D3D - because a basic home user does not want to download new drivers or GLSetup to get a game working - if they even know that's whats wrong.

Somebody earlier said that Epic is the only company that springs to mind - but outside the Quake world practically every game uses D3D and DX - even Quake uses DX for all but the rendering. And the top consumer games use DX only:

Looking at gamersx.com we see a list of games: AvP, Daikatana, FF7/8, Half-Life, Nascar 2, Quake X, Shogo - other popular games such as FIFA, Tomb Raider are D3D based - I think that FPSs are going OGL because of the great engines from JC - possibly not because they prefer it.

OpenGL is not dying - but it may soon die (in the gaming arena at least) - unless Linux can really improve it's user friendliness and popularity in the home/enthusiast area. OpenML has strong support too but it's going to need it.

Paul.

[habig]

Keep in mind that gaming on Wintel systems is a pretty narrow subfield of computing! (even if you include free unices like Linux). GL was born on SGI workstations doing heavy-duty graphics stuff like computer animation and AutoCAD. Also note that while there might be ten people playing Unreal for every engineer doing CAD work, that engineer is paying thousands of dollars for his software and tens of thousands for his hardware - it's profitable to keep them happy!

Since that market isn't going away anytime soon, GL and its relatives will continue to be around. Since the API will still be active (and cross platform! I've played quake on Sun and SGI high-end workstations), it will certainly creep back into the occasional Windows games.

[ganyaik]

I haven't programmed none of these APIs yet(will change soon), so I see this problem from the user's point of view...
Does NT4 have D3D HW accelleration? As far as I know it doesn't. How many people use W95/98 for non gaming tasks compared to the ones who use NT4? I think DX is not an option for them. They are quite happy with OGL(if they have).
What I tried to emphasize is that D3D is _very_ platform dependent and used mostly for gaming purposes. That's not the case with OGL.
As you see might from my post I will start OGL programming soon. BTW, what developer tools do you need to write a DX game? I don't think that a simple GCC will be enough...
Chris

[Floyd]

OpenGl is anything but dead...
Firstly, it is the industry standard rather than the "Microsoft" standard... I personally think that Microsofts reign is going to shrink in the near future, making OpenGL again a far more popular API for games. I say Microsoft's reign is ending, firstly because they are losing their court cases, and secondly, because in many Industry Analists opinions (including Bill's arch rival, the head of Oracle, whos name I have temporarily forgotten), PC's will no longer exist as we know them in 5 years...

PCs are far to expensive because they provide features which the majority of the market (ie. business) dont need. PCs are going to be replaced by thin clients, which work are like smart terminals (similar to a UNIX type system with smart terminals) and I believe with this change, Linux is going to gain a much greater share of the market being a FAR FAR more faster and stable OS. Of course, these new thin clients wont have the power to run games, which sees the games industry switching primarily to consoles (I know, I know, for a lot of you that is not a pretty thought). So this makes this argument obselete in 5 years anyway I suppose...

Secondly, Image Quality wise, OpenGL has the potential to shit all over DirectX, and is faster and more stable. If Microsoft weren't such wankers, they would have done what John Carmack wanted in the first place, and incorporated OpenGL into DirectX as the graphics component, but NO, they had to monopolise it just like they did with IE, so now I'm forced to run a Crappy, Slow, Resource Hungry, Buggy, Crashing OS if I want to run games... ah well... such is life.

I've had my rant, feel free to flame....

Floyd

[franksch3]

Floyd,

I agree with everyone that because of OpenGL's platform independance and robustness it is the API of choice for professional 3D programs. That will probably always be that way, so indeed OpenGL is certainly not going to die.

However, we are talking about games in this thread. One of the biggest differences between OpenGL and Direct3D is that Direct3D is catching up very quickly and is probably even wins from OpenGL with DirectX8 when viewing from a gaming point of view.

Microsoft is very devoted to gaming companies and is very willing to work together with them and evolve Direct3D. However, the OpenGL board laughs at the gaming industry and says that they will decide what comes in OpenGL and they will not take any advise from gaming companies. A very good example is Tim Sweeney from Epic which presented a feature for OpenGL to improve on texture management, but which was rejected without cause. He says that is one of the reason why he'd rather use Direct3D for games.

Secondly, the biggest market for games is Windows. Linux users may think that it is otherwise and that it might change rapidly, but that's like believing that dwarves exist. ;-)

Quality wise both API's are exactly the same. They use the same methods for texture effects, etc. so there is no difference at all. That a particular game designed for OpenGL might look better than Direct3D is mostly because Direct3D was hacked in quickly.

OpenGL is certainly not faster than Direct3D at current time. And that is not Microsofts fault but of the driver writers. For games the Direct3D drivers most of the time are more stable and faster than their OpenGL equivalents.

[Meek]

Well, I think and hope (yes, this is an opinion only) that Direc3d will die a painful death together with the Windows monopoly. OpenGL will survive.

M.

[This message has been edited by Meek (edited 19 May 2000).]