OpenGL 4.0 Spec Released

tbcpp writes "The Khronos Group has announced the release of the OpenGL 4.0 specification. Among the new features: two new shader stages that enable the GPU to offload geometry tessellation from the CPU; per-sample fragment shaders and programmable fragment shader input positions; drawing of data generated by OpenGL, or external APIs such as OpenCL, without CPU intervention; shader subroutines for significantly increased programming flexibility; 64-bit, double-precision, floating-point shader operations and inputs/outputs for increased rendering accuracy and quality. Khronos has also released an OpenGL 3.3 specification, together with a set of ARB extensions, to enable as much OpenGL 4.0 functionality as possible on previous-generation GPU hardware."

Comments

Patent problems still there?

[H4x0r Jim Duggan]

Any chance the patent problems of OpenGL 3 have been fixed?

Re:Patent problems still there?

[binarylarry]

It's not really a huge problem in practice.

All the major graphics IHV's provide that extension anyway. It would nice if it was in GL's core spec, but since it's included for any device that matters, it's not a practical concern.

Re:Patent problems still there?

[Anonymous Coward]

what about the fact that software patents are not valid in EU? Cant Khronos just release the spec in EU and screw US?

Re:Patent problems still there?

[ZaphDingbat]

I keep hoping I can get half textures/framebuffers in Mesa. SGI or Microsoft still has the patent on that one.

Re:Patent problems still there?

[Anonymous Coward]

I keep hoping I can get half textures/framebuffers in Mesa. SGI or Microsoft still has the patent on that one.

Don't worry, Microsoft (R)(TM)(C) has patented many half-assed things in an effort to create synergy and deliver a more popular* customer experience.



* More popular does not necessarily mean better. c.f. botnets

Re:Patent problems still there?

[N Monkey]

what about the fact that software patents are not valid in EU? Cant Khronos just release the spec in EU and screw US?

What makes you assume "software" solutions to technological problems are not patentable in the EU? Have a look at probably any computer related patent (e.g picking the first one from ARM I could find) and I suspect you will find both "apparatus" and "method of" versions of the claims. The latter generally refers to a software-based implementation of the invention.

Now, the issue is whether something is obvious and/or trivial and there are certainly a number of granted US patents which have some outrageous claims that haven't got past the EPO examiners.

Re:Patent problems still there?

[amorsen]

What makes you assume "software" solutions to technological problems are not patentable in the EU?

It says so right in the law... However, the European Patent Office are able to read between the lines and divine what the lawmakers REALLY meant, so they allow software patents.

So far there is (AFAIK) absolutely zero case law about software patents in the EU, so the courts haven't decided whether EPO's reading is correct. Companies seem content with doing their patent fights in the US. Why bother with dealing with a troublesome case making a precedent in the EU when the defendant is likely selling the exact same software in the US where software patents have been involved in numerous cases?

Re:Patent problems still there?

[tepples]

what about the fact that software patents are not valid in EU? Cant Khronos just release the spec in EU and screw US?

No, because Khronos doesn't have the cash to sponsor every US resident's emigration.

Re:Patent problems still there?

[Anonymous Coward]

Surely they could release the full spec in EU and the one without patent in US. Why cripple the whole world when it's just the US that cripples itself?
It should be enough for Khronos (not all of its participants) to move to EU and let the EU gov to do the fight like Airbus vs EADS (meaning lasting ages and without resolution).

Re:Patent problems still there?

[Hurricane78]

You mean: Microsoft’s problem of nobody taking them serious, and everybody doing it anyway, without MS being able to do anything about what they “believe” they have? (Remember: The companies implementing and supporting OpenGL can simply shut off Windows from their cards, end cooperation, and kill MS in the blink of an eye.

Stop buying into every shit and criminal makes up to gain power over you!

Re:Patent problems still there?

[cbreak]

Who cares what the courts decide?

The law states "No software patents". That's it. All courts can do is apply the law.

Re:Patent problems still there?

[N Monkey]

What makes you assume "software" solutions to technological problems are not patentable in the EU?

It says so right in the law...

Where? Citation please.

If one goes to the UK Patent office page (governed by EU laws) which states what can and can't be patented you will find that it only says you can't patent "some computer programs".

If, however, an invention meets the criteria in that it relates "to how something works, what it does, what it is made of, or how it is made." then it is fine (assuming, of course, it is inventive and non-obvious)

Ask yourself what is the fundamental difference between a piece of silicon which solves problem "X" (perhaps using dedicated/hardwired logic) and a piece of silicon which solves "X" but also uses a set of CPU instructions to do it?

Re:Patent problems still there?

[amorsen]

If one goes to the UK Patent office page [ipo.gov.uk] (governed by EU laws) which states what can and can't be patented you will find that it only says you can't patent "some computer programs".

Exactly like the EPO's reading of the law.

If, however, an invention meets the criteria in that it relates "to how something works, what it does, what it is made of, or how it is made." then it is fine (assuming, of course, it is inventive and non-obvious)

Then the specific exclusion of computer programs in the law makes no sense.

Like I said, the EPO (and as you point out most national patent offices) reads the law one way. Lots of people, apparently including the European Parliament (because they actively refuse to remove the exclusion of computer programs), read it the other way. The courts haven't spoken and likely won't anytime soon.

OpenGL on par with Direct3D11

[Thunderbird2k]

To give an idea to non-OpenGL developers, OpenGL 4.0 closes the feature gap with Direct3D11. If you want to use OpenGL 4.0 you need to wait a couple of weeks before drivers will be out. In case of Nvidia, the drivers will be launched together with their new GTX4*0 GPUs which are the first Nvidia GPUs with Direct3D11/OpenGL 4.0 support. AMD might release new drivers before Nvidia since their hardware is Direct3D11 capable already.

Re:OpenGL on par with Direct3D11

[Anonymous Coward]

Be careful when you tout it as being "on par with Direct3D 11". That claim would also imply that there are mature, well-tested .NET bindings available that allow for all of the new features to be used. I sincerely doubt that this is the case.

Re:OpenGL on par with Direct3D11

[calibre-not-output]

Does your post imply that .NET is mature? Or well-tested? I almost spilled my coffee..

Re:OpenGL on par with Direct3D11

[binarylarry]

There are well tested, production ready OpenGL bindings for Java: http://lwjgl.org/

Java fits better with OpenGL anyway, being cross platform and open in the same vein as OpenGL.

Re:OpenGL on par with Direct3D11

[JamesP]

There are well tested, production ready OpenGL bindings for Java: http://lwjgl.org/

HOW ABOUT NO

Java fits better with OpenGL anyway, being cross platform and open in the same vein as OpenGL.

You owe me a new keyboard.

Ok, to be serious now, I can't think of a worse match to OpenGL than Java

You need to work with pictures, access to buffers. Also, speed.

Re:OpenGL on par with Direct3D11

[binarylarry]

You need to work with pictures, access to buffers. Also, speed.

Oh, I've used OpenGL quite a while, in a few languages. I haven't ran across the "PICTURES" extension. Could you kindly point out the api doc on that one? I'm very interested now, because you sound like a very competent programmer.

"Access to buffers," you mean VBO's? lwjgl seems to support those. And Java supports in VM buffers, as well as out of VM native buffers via NIO. Maybe I'm off here, you seem to be a pretty up to date and with it programmer.

Oh and speed, you must have missed that memo: Java is pretty fast now, faster than statically compiled OO for sure.

Re:OpenGL on par with Direct3D11

[Anonymous Coward]

LOL? I hope you didn't really buy into that marketing BS...

Re:OpenGL on par with Direct3D11

[thePowerOfGrayskull]

But in the context of "no .net bindings means it's not ready", Java bindings are perfectly relevant. Too, I haven't noticed any performance issues using opengl in Java.

Re:OpenGL on par with Direct3D11

[JamesP]

You need to work with pictures, access to buffers. Also, speed.

Oh, I've used OpenGL quite a while, in a few languages. I haven't ran across the "PICTURES" extension.

What I meant is loading a picture and using it as a texture.

"Access to buffers," you mean VBO's? lwjgl seems to support those. And Java supports in VM buffers, as well as out of VM native buffers via NIO.

Interesting. Still, you're going to need to read a model from a file or create its geometry.

Oh and speed, you must have missed that memo: Java is pretty fast now, faster than statically compiled OO for sure.

Yeah, but I wouldn't advocate Java for 'real time' apps also the kind of geometry processing OpenGL requires. (which is what you'll probably be doing apart from the OpenGL triangle demo)

Please type 'java floating point' into google and check the first article

Re:OpenGL on par with Direct3D11

[Khyber]

"PICTURES" extension is likely his mistaken naming for GL_TEXTURE_INTERNAL_FORMAT.

Re:OpenGL on par with Direct3D11

[binarylarry]

What I meant is loading a picture and using it as a texture.

Oh, so how does this even matter from a language/platform/execution standpoint? In the case of loading a texture from disk, you're going to be limited by IO wait anyway, which means even something like Bash would work initiating the transfer and waiting while it's finished.

Interesting. Still, you're going to need to read a model from a file or create its geometry.

Again, you're talking about IO wait, which isn't really limited by your application's execution speed anyway. I'm sure you knew that though, you seem like a very experienced and capable programmer.

Yeah, but I wouldn't advocate Java for 'real time' apps also the kind of geometry processing OpenGL requires. (which is what you'll probably be doing apart from the OpenGL triangle demo)

Your application doesn't usually "process" geometry, in any sane application you just send off a big chunk of data to the server and the OpenGL implementation handles it from there. Regardless, Java is fast, so if you're generating the geometry it's fine anyway. Java lets you use OO development techniques and still get great performance and it works fine for "real time" applications.

Please type 'java floating point' into google and check the first article

I hate to be the one to break this to you, but floating point is fraught with all types of these issues. It's not a data type to be used for any application requiring exact calculations, which is why fixed point alternatives exist.

Besides that, OpenGL is going to mangle your floats and turn them into yet another representation on the GPU server side anyway.

I mean look at SIMD with something like SSE on an x86 chip. It will also *mangle* your floating point values, chomping off lots of data and return skewed values. It's just the nature of floating point.

Re:OpenGL on par with Direct3D11

[Anonymous Coward]

Regardless, Java is fast, so if you're generating the geometry it's fine anyway.

Lots all credibility right there.

Java lets you use OO development techniques and still get great performance and it works fine for "real time" applications.

Wow just like C++ and C#, both vastly superior languages to Java. You sound like a fucking salesman.

Re:OpenGL on par with Direct3D11

[postmortem]

on par or 'copy'? Interestingly how OpenGL in last 10 yrs is playing catch up game with directX. all these features were developed by AMD, Nvidia and Microsoft for directX, and now just made available for OpenGL.

Re:OpenGL on par with Direct3D11

[nobodylocalhost]

or jogl, but AA is a pain in either, and literally crawling in jogl. in lwjgl, it's rather corse. You can still see pixelated edges.

Re:OpenGL on par with Direct3D11

[binarylarry]

C++ a superior language? LOL WUT?

C# is slightly better than Java, but it's basically Java with some nicer features tacked on.

Re:OpenGL on par with Direct3D11

[Anonymous Coward]

Where is the multithreaded command buffer creation ?

Re:OpenGL on par with Direct3D11

[binarylarry]

AA has nothing to do with the gl interface you're using, it's an OpenGL feature (and usually by extension).

Re:OpenGL on par with Direct3D11

[TheRaven64]

You seem to have misunderstood how OpenGL is meant to work. It is intended to standardise existing features; that's the entire point. Individual vendors add extensions, developers test them, and the useful ones are added to the next version of the spec.

Re:OpenGL on par with Direct3D11

[JamesP]

What I meant is loading a picture and using it as a texture.

Oh, so how does this even matter from a language/platform/execution standpoint?

Libraries. Format conversions. Also, try doing live texture manipulation (which is the basis of 3d-desktop effects for example)

Interesting. Still, you're going to need to read a model from a file or create its geometry.

Again, you're talking about IO wait, which isn't really limited by your application's execution speed anyway. I'm sure you knew that though, you seem like a very experienced and capable programmer.

No. What about conversion of geometric models, prunning, etc

Your experience shows through.

Java lets you use OO development techniques and still get great performance and it works fine for "real time" applications.

Talk is cheap, and marketing speak even more so.

Besides that, OpenGL is going to mangle your floats and turn them into yet another representation on the GPU server side anyway.

That's not the problem, and actually Java mangles things for a good reason. But it slows things down and it takes control from the developer , like the fp control word.

Re:OpenGL on par with Direct3D11

[Hurricane78]

Only a loser would make his goal to get on par with the competition. Because at the time when he would reach that goal, the competition would already have moved on.

I want them to put DirectX to shame! New! Revolutionary! Impressive! Putting MS in the position to catch up!
Because when MS is in that position, they are known to fuck up. (They make the same error of not trying to surpass the competition.) ^^

Design a spec, that is every graphics card designer’s, every game developer’s and every player’s wet dream!

It’s like car racing: If you concentrate on the car in front of you, you will fall back. If you stop caring for him, and concentrate on your own goals and the track in front of you, you’ll suddenly find yourself left of him, passing by. :)
(The same is true for concentrating on cars following you.)

Re:OpenGL on par with Direct3D11

[binarylarry]

Libraries. Format conversions. Also, try doing live texture manipulation (which is the basis of 3d-desktop effects for example)

Java has more libraries and a larger developer community than any other programming language or platform on the planet. Fucking google it, I'm not your mama.

"Live texture manipulation" is all done on the GPU with render to texture effects anyway. It's much slower to do it on the CPU, even if you're doing it in assembly written specifically to take advantage of the hardware.

No. What about conversion of geometric models, prunning, etc. Your experience shows through.

"conversion of geometric models" this is something you do offline anyway, even if Java was slow (which it isn't) it wouldn't matter from a "real time" or OpenGL perspective. I'm not sure what "prunning" is but it's probably because I haven't yet reached your level of programming mastery.

Talk is cheap, and marketing speak even more so.

So when I debunk the moronic, retarded things you say, that makes it "marketing speak." LOL, you're a pro.

That's not the problem, and actually Java mangles things for a good reason. But it slows things down and it takes control from the developer , like the fp control word.

What exactly is the problem then, I fail to see what you're even talking about in regard to OpenGL?

You seem to have no real understanding of performance, real time, java or even any programming concepts or techniques beyond trivial applications.

You are amazing.

Re:OpenGL on par with Direct3D11

[nobodylocalhost]

Can you explain then why jogl supports full screen AA while lwjgl doesn't? Shouldn't they be supporting the same OpenGL feature?

Re:OpenGL on par with Direct3D11

[binarylarry]

If you have issues, come to irc #lwjgl on freenode. There are a lot of people there that can help you out (with jogl or lwjgl).

Re:OpenGL on par with Direct3D11

[Hurricane78]

There are well tested, production ready OpenGL bindings for Java: http://lwjgl.org/

HOW ABOUT NO

Wow, how well though-out properly founded, intelligent and logic arguments... ehrm... How about, you’re a dick!?

Java fits better with OpenGL anyway, being cross platform and open in the same vein as OpenGL.

You owe me a new keyboard.
Ok, to be serious now, I can't think of a worse match to OpenGL than Java
You need to work with pictures, access to buffers. Also, speed.

I have worked with OpenGL on Java. There is a ridiculously low overhead for the wrapper library. And in case you didn’t know it: For anything other than Swing GUI stuff, Java is nearly on par with C++.
Which is impressive, for a language that has all the checks and bounds built in, preventing errors that will fuck up your puny C/C++ game at every chance it can get. Build in those checks, and you will be slower than Java!

But you know which languages are really the best for OpenGL?
OCaml and Haskell!
C/C++ is a dinosaur. The COBOL of our days. But as nasty / error prone to code, as Visual Basic.
It literally feels dirty, to go to C/C++ after having worked in Haskell.

Re:OpenGL on par with Direct3D11

[JamesP]

Java has more libraries and a larger developer community than any other programming language or platform on the planet. Fucking google it, I'm not your mama.

I know that of course.

Still, funny how most game developers are not using Java. And most sites. And most desktop apps.

I'm not sure what "prunning" is but it's probably because I haven't yet reached your level of programming mastery.

http://en.wikipedia.org/wiki/R-tree

"Live texture manipulation" is all done on the GPU with render to texture effects anyway.

No

You didn't read what I wrote. "3D Desktop effects" do you know what that is? Do you know what that involves? And I don't mean the 'rotating cube' part, that's easy.

No, you're with the head so deep inside Java land it's not even funny.

Re:OpenGL on par with Direct3D11

[JamesP]

Which is impressive, for a language that has all the checks and bounds built in, preventing errors that will fuck up your puny C/C++ game at every chance it can get. Build in those checks, and you will be slower than Java!

But you know which languages are really the best for OpenGL?

I would have to say C/C++ even though you are right about the checks (but there are ways to check your C++ program)

But I'd say Haskell's probably something to be looked into, since you mentioned it.

Re:OpenGL on par with Direct3D11

[bonch]

C++ is absolutely superior to Java. It's an industry standard language for a reason.

Re:OpenGL on par with Direct3D11

[samkass]

You obviously have a huge bias against Java for emotional reasons, but may I point out that extremely comprehensive 3D desktop effects existed in Java with Project Looking Glass long before they became standard fare on Windows. From Nasa WorldWind to Jake2 to JSatTrack and a zillion custom (usually vertical) apps, a lot of folks have dispelled the myth that Java is slow for 3D work. In addition, there are plenty of people doing 2D scenegraph work in Java to create some fairly revolutionary UI's, such as Project Piccolo. It's actually more than fast enough to keep a GPU occupied.

Why don't more desktop packages use Java? Not sure, but it's not due to speed. I use OpenOffice, Eclipse, and XMind on a regular basis and there's a lot of Java in there. I've played online Java games, although they tend to use Flash a lot these days.

Re:OpenGL on par with Direct3D11

[bonch]

It literally feels dirty, to go to C/C++ after having worked in Haskell.

Give me a break. C and C++ aren't going anywhere, and barely anybody is using OCaml or Haskell, especially not for OpenGL applications. You sound like another amateur Reddit poster who thinks C is hard because it has pointers. C is simple, fast, and elegant.

In the real world, outside of the buzzword-laden, blog-driven, pseudo-academic world you were spawned, C and C++ remain the dominant languages for commercial application development. That includes Objective-C on the iPhone.

Re:OpenGL on par with Direct3D11

[Forkenhoppen]

This jostling for OpenGL to jump over Direct3D in terms of features is ridiculous.

You can't have stable without the beta.

Re:OpenGL on par with Direct3D11

[Anonymous Coward]

Those bindings don't support OpenGL 4.0 yet. Their OpenGL 3.x support isn't great, either.

I think that's basically the point the GP was making. We can use D3D 11 and its new features for real apps right now. We can't do the same with OpenGL 4.0 (or even 3.x) regardless of whether we're using C#, Java, or some other language.

OpenGL 4.0 shouldn't be described as equivalent to D3D 11 until it can be used just as readily as D3D 11 currently can be used.

binarylarry, do you also post as sopssa and TripMaster Monkey? Did you have to stop using those accounts because you ruined their reputations?

Re:OpenGL on par with Direct3D11

[thetoadwarrior]

One of the biggest games online uses Java and 3D. http://www.runescape.comwindows/ Mobile will likely be running in Java.

Project looking glass was done in Java http://en.wikipedia.org/wiki/Project_Looking_Glass

Even if you look at Wordle ( http://www.wordle.net/ ) which isn't 3D but it's a fast loading, fast running slick applet. It shows you in the hands of the right people Java is at least as capable as Flash (more so imo) but it has a bad reputation for anything fun.

Unfortunately Java had such a shitty beginning with applets which weren't perfect and when they were being used it was generally for something god awful and ugly. That has scared a lot of people from developing applets or using applets.

I get the impression as well that developers just assume Java should do everything easier and when it doesn't just wipe your ass for you they claim it's broken and bloated. Sure it has an ass load of libraries but you still need to know how to code and optimise in Java just like any other. It's not Flash by any means.

Flash is a lot easier to get something working for inexperienced people because for a starter there are no threads and while any serious Flash app will likely be done strictly in actionscript, you can get quite far as a newbie pointing and clicking in a gui and writing less code than you would in Java.

Doing something Doom in Flash would still be a major task but for the 900 billion games that are basically "how far can you throw the baby, kitten, whatever" or "punch the guy's balls, woman's face, etc" you can do that more easily in Flash than Java and due to the restrictions it will generally run better because you can't do something like fuck up threads.

Re:OpenGL on par with Direct3D11

[Anonymous Coward]

C++ a superior language? LOL WUT?

Considering it does everything Java does and more, and faster, yes, it is.

Re:OpenGL on par with Direct3D11

[thetoadwarrior]

That link should be http://www.runescape.com/

For some reason it ate part of my text mentioning the iphone and tagged Windows onto the end.

Re:OpenGL on par with Direct3D11

[binarylarry]

Where exactly have I glorified Microsoft like sopssa?

And lwjgl's 3.0 support is fine, 4.0 JUST GOT RELEASED, so it's obviously not going to be ready yet.

Where do you fucking morons come from? jesus...

Re:OpenGL on par with Direct3D11

[JamesP]

Project Looking Glass vas very promising, interesting to know it's in Java.

You can do the high level stuff in Java, that's not the problem, Desktop Effects are more taxing on the GPU itself.

From the point of view of Java there, it's merely dealing with a few polygons, most of the heavy lifting is done by the GPU and the underlying window manager.

Why don't more desktop packages use Java? Not sure, but it's not due to speed

Speed is only a small issue in the matter of user experience.

For example, Flash, besides all its problems manages to be much more popular than Java as an applet platform. And i'd say it's easier (for developers) to develop in Java (the JDK is free after all).

From the point of view of the language/environment itself, Java doesn't have first-order functions, lambda functions, has an extremely complicated (and bloated) library, etc Even C# has some of those, and the library is a breeze

But what I saw are project after project failing BECAUSE of Java. (ok, because of developers/manager who picked Java where it's not suitable) , still...

Re:OpenGL on par with Direct3D11

[SplashMyBandit]

I like C and C++ after having programmed for a decade with them. However, the real weight in development is in Java - although it's use has decayed to that of C in recent years due to the bifurcation of new languages in recent years. Just look at:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Incidentally, I use JoGL for a lot of OpenGL projects I used to use C++ for. I find I'm more productive and the OpenGL runs just as fast (since it's mainly on the GPU anyway).

Re:OpenGL on par with Direct3D11

[multi io]

You didn't read what I wrote. "3D Desktop effects" do you know what that is? Do you know what that involves?

Drop shadows? I always thought they do that with fragment shaders.

Re:OpenGL on par with Direct3D11

[JamesP]

What I meant is having the windows rendered to a texture in the video card.

Re:OpenGL on par with Direct3D11

[NoSleepDemon]

The problem, of course, is that Runescape looks absolutely hideous.

Hardware support

[Anonymous Coward]

Since graphics cards are marketed with the DirectX version they support: OpenGL 4.0 = DirectX what?

Re:Hardware support

[binarylarry]

It's most similar to D3D 11.

DirectX is a larger set of development technologies and apis (most of which has been deprecated). Direct3d is it's "direct" analog to OpenGL.

Re:Hardware support

[somersault]

That's kind of like asking "Windows 7 = Ubuntu what"?

They might do similar things, but they do them in different ways*. IMO OpenGL is always going to be better unless DirectX becomes more cross-platform friendly, but then again I'm not one of those idiots that cares more about graphics than gameplay.

But to vaguely answer your question based on what others are saying here: OpenGL 4.0 is close to Direct 3D 11 in terms of features though.

*I have to say that while I have played about with OpenGL in the past, I have never tried Direct3D, so I can't say how different they actually are.

Re:Hardware support

[tepples]

IMO OpenGL is always going to be better unless DirectX becomes more cross-platform friendly

Direct3D is already cross-platform: Windows, Xbox 360, Zune, Windows Phone 7 Series. Among these is the only video game console open to indie development.

Re:Hardware support

[binarylarry]

It's like Ford's Model-T: You could order in any color you wanted, so long as that color was black.

Re:Hardware support

[Khyber]

"OpenGL 4.0 is close to Direct 3D 11 in terms of features though."

not quite - OpenGL still has the edge in the fact you can always program in extra features - D3D is a set featureset and SUCKS, mainly because it's NOT direct to hardware like OpenGL is or 3dfx GLide was. most of it is purely dependent upon your CPU speed and thus one of the main bottleneck of D3D gaming is the CPU hardware, not the GPU.

Has been a problem since Unreal Tournament. Hasn't been fixed since then. Likely never will due to Microsoft's wish to dominate everything.

Re:Hardware support

[hduff]

You can't use "cross platform" unless it ports to OSX or Linux or other non-Windows platforms. OpenGL is cross-platform; Direct3D is not. The term you're looking for is "Windows platforms only". Nothing wrong with that; just be honest in your characterization of it.

Re:Hardware support

[tepples]

The term you're looking for is "Windows platforms only".

But my point is that plenty of studios, not just Microsoft, can still make a lot of money by targeting "Windows platforms only". True, this leaves out people who have only a Mac and a Wii and people who have only a Linux box and a PS3, but most gamers have at least one Xbox 360 console or Windows gaming PC. The only console that legitimately runs indie games is one of these "Windows platforms".

Re:Hardware support

[Plaid Phantom]

The XBox 360 is most certainly not the only console which gives access to indie developers. I know of a number of games in or coming to WiiWare straight from indie developers. World of Goo, for one.

Re:Hardware support

[tepples]

Nintendo requires a new Wii developer to have previous published commercial titles on another platform as well as a "secure office facility", a hurdle that most micro-ISVs cannot clear. 2D Boy had to pretty much cheat Nintendo in order to qualify for a Wii devkit without the overhead of having to lease an office.

Re:Hardware support

[javiercero]

It is hard to figure out what your "point is" if you're going to keep changing it.

I thought you were talking about cross platform issues, and now it is about game studios. Uh?

Re:Hardware support

[Forkenhoppen]

In D3D's defence, they had a number of optional features in D3D9, but developers really got to loathing the caps, so it was mostly abandoned for D3D10+.

As to D3D9's 'set functionality', it's true that Microsoft tried to lock down what you could add to the API. But you should check out Aras' D3D9 cheat sheet for hacked-in functionality. While there aren't any easy vectors for adding extra functionality to D3D9, that hasn't stopped ATI and NVIDIA from offering stuff through some of the weirdest and ugliest hacks imaginable. (Let's have a round of applause for the tesselation factor and point parameter render states, shall we?)

That having been said, I wholeheartedly agree that OpenGL has provided a much cleaner approach to extensibility of the API.

Re:Hardware support

[Randle_Revar]

>Direct3D is already cross-platform: Windows, Xbox 360, Zune, Windows Phone 7 Series.

Direct3D is already cross-platform: Windows kernel, Windows kernel, Windows kernel, Windows kernel

That doesn't sound that convincing, somehow

Re:Hardware support

[Anonymous Coward]

That's kind of like asking "Windows 7 = Ubuntu what"?

The answer is "Karmic Koala" ;-)

Re:Hardware support

[Anonymous Coward]

I'm sorry but you can't change the definition of "cross platform".

Yeah, it sucks but that's the way it is.

Re:Hardware support

[Anonymous Coward]

I believe his characterization was meant to be funny, not honest.

Re:Hardware support

[Anonymous Coward]

You'd be surprised. Windows Phone 7 uses OpenGL-ES. Direct3D for Windows Mobile was abandoned a long time ago.

DOA for anything but pro gear

[Gothmolly]

DirectX won, because it does sound and HID input handling, and because its on every PC sold to every mouthbreathing, Best Buy shopping, banana eating customer.

Re:DOA for anything but pro gear

[binarylarry]

Yeah, that's why Valve just ported their games to Mac, which only supports OpenGL.

Because it's DOA for anything but "PRO GAMERZ."

Re:DOA for anything but pro gear

[Again]

DirectX won, because it does sound and HID input handling, and because its on every PC sold to every mouthbreathing, Best Buy shopping, banana eating customer.

I wouldn't be so quick to say that DirectX won. The xBox 360 is the only current generation console which uses DirectX.

Re:DOA for anything but pro gear

[aristotle-dude]

DirectX won, because it does sound and HID input handling, and because its on every PC sold to every mouthbreathing, Best Buy shopping, banana eating customer.

OpenGL is used on PS3, linux and OS X. It is also used on any game in windows that is cross platform compatible where they did not bother implementing a DirectX engine. Every platform now has HID handling and you can use OpenAL if you want to have the same sound effects engine on windows, OS X and possibly linux.

Now that Valve is porting Steam and related games to OS X and consequently OpenGL, expect to see more activity surrounding OpenGL.

Re:DOA for anything but pro gear

[Anonymous Coward]

thats not what Valve said

Re:DOA for anything but pro gear

[Anonymous Coward]

Except they didn't drop DirectX support from their games or engine. Their engine just now supports both DirectX and OpenGL.

Re:DOA for anything but pro gear

[Anonymous Coward]

and you can use OpenAL if you want to have the same sound effects engine on windows

Especially Windows Vista and 7 since DirectSound acceleration doesn't exist anymore LOL

Re:DOA for anything but pro gear

[Dan667]

consoles don't count.

Re:DOA for anything but pro gear

[Lunix Nutcase]

OpenGL is used on PS3, linux and OS X.

So the loser of the next-gen console wars and two OSes with minority market shares? zOMG SUCCESS!!

Re:DOA for anything but pro gear

[Lunix Nutcase]

And before I get modded down by someone missing the point of my comment, there are much better examples to show that OpenGL has won over Direct3D than the poor examples used by the person above.

Re:DOA for anything but pro gear

[TheRaven64]

Added to that, OpenGL ES, which is almost a direct subset of OpenGL (it adds a couple of things, but you can quite easily write code that is both valid OpenGL ES and OpenGL), is present on almost all mobile devices. If you want to write a 3D app or game that runs on a mobile phone, you use OpenGL ES. I think Wince has a DirectX implementation of some kind, but it has such a tiny market share that it's largely irrelevant.

OpenAL is also cross-platform; there's a software-only implementation that runs very nicely on Linux, *BSD, and Solaris; it's not just Windows and OS X. Creative provides OpenAL acceleration on a few other platforms, but I don't think anyone else does - there's not really much point these days in offloading sound processing, CPUs are more than fast enough.

Re:DOA for anything but pro gear

[Anonymous Coward]

DirectX is only on a couple of platforms, all of them created by Microsoft. Sure just one of those platforms grossly outnumbers all of the OpenGL platforms.
(OpenGL ES is not really OpenGL, so you can't count the millions of GLES enabled cell phones)

Re:DOA for anything but pro gear

[binarylarry]

Modern OpenGL (3+) has it's roots in OpenGL ES. Many of the changes and cleanups happened in OpenGL ES first and were later applied to OpenGL.

So you really should count OpenGL ES.

Re:DOA for anything but pro gear

[Anonymous Coward]

consoles don't count.

Why?

Because nobody develops graphic software for consoles?

Re:DOA for anything but pro gear

[91degrees]

DirectInput, DirectSound and Direct3D don't require each other. You can replace any of these components without affecting the others.

And I've yet to see a PC that doesn't support OpenGL.

And why so dismissive of Pro gear? This is a decent sized market.

Re:DOA for anything but pro gear

[Anonymous Coward]

Heh, actually I wrote 80% of Direct3D for PS3 when I was porting a game across. It only took a couple of weeks. I wouldn't be surprised if others have done the same ... having the same API on all three major platforms is a boon.

Of course, my employer then decided to add an abstraction layer on top of that ... even though the abstraction layer was the same on all platforms ... go figure.

Re:DOA for anything but pro gear

[Lunix Nutcase]

Well even using the PS3 as an OpenGL platform is somewhat inaccurate because what PS3 runs is a derivative of OpenGL ES and Nvidia's CG programming language. But if you wanted to show that OpenGL has won, you can easily point to every Windows box as it's pretty much impossible to find a video driver these days that doesn't have OpenGL support.

Re:DOA for anything but pro gear

[Lunix Nutcase]

You mean other than the fact that what the PS3 and Wii run aren't really OpenGL but proprietary derivatives of OpenGL ES?

Re:DOA for anything but pro gear

[Khyber]

"there are much better examples to show that OpenGL has won over Direct3D than the poor examples used by the person above."

Not to an average joe, who wouldn't give two flying fucks about your latest CAD program.

Re:DOA for anything but pro gear

[Khyber]

WRONG.

OpenGL ES 1.1 is defined relative to the OpenGL 1.5 specification and emphasizes hardware acceleration of the API, but is fully backwards compatible with 1.0.

In fact, most of the changes to ES happened in GL first.

Re:DOA for anything but pro gear

[Lunix Nutcase]

Not to an average joe, who wouldn't give two flying fucks about your latest CAD program.

Who the fuck was talking about CAD? All you have to do is point them to mobile phones and Windows. Both are vastly huger OpenGL platforms than the PS3 and either Linux or Mac OS X could ever hope to be.

Re:DOA for anything but pro gear

[Anonymous Coward]

Wow, you have no idea what you're talking about, no ? OpenGL ES 2.0 drastically cut on what was exposed from ES 1.1. It took that turn because programmability is not really the same model as fixed function (something GL 2.0 tried to hide). Now... Wait a bit, and suddenly, GL 3.1 comes and deprecates stuff. What exactly ? have a look at the list of things that got removed for ES 2.0 to find out (and yes, this is an exageration).

Re:DOA for anything but pro gear

[Anonymous Coward]

If directx hasn't won, why do people always talk about how with every new release of opengl it closes the gap or implements features that directx has already had. If opengl was winning don't you think that microsoft would be trying to implement features into directx that opengl had for a while? The headlines would be directx 11 finally implements octoplet skin mapping a feature found in opengl 3.for over a year.

Re:DOA for anything but pro gear

[Anonymous Coward]

Most Average joes don't give a fuck about 3d acceleration on phones. Just speaking as one that used to sell phones to other average joes. They care that it plays their mp3s, makes their phone calls, and lets them send sms to their naughty little bitch, NOTHING ELSE.

Re:DOA for anything but pro gear

[Khyber]

You're a moron - direct from the OpenGL ES page:

"OpenGL ES 2.0 is defined relative to the OpenGL 2.0 specification"

As in OPENGL CAME FIRST, ES GETS DEFINED BY GL.

Clearly stated directly on the front fucking page of ES.

Re:DOA for anything but pro gear

[ultranova]

DirectX won, because it does sound and HID input handling, and because its on every PC sold to every mouthbreathing, Best Buy shopping, banana eating customer.

DirectX is indeed widely used on Windows, since it handles more things. OpenGL handles just graphics, but is cross-platform; with SDL it's close enough to DirectX that it's often used. And of course you could use OpenGL for graphics and DirectX for everything else.

I like the current situation where the two coexist and force each other to evolve to stay competitive. It's a bit like AMD forced Intel to get off its ass and make good and cost-effective processors again. We'll see if NVidia is able to respond to ATI/AMD's challenge too; but at least we won't see similar stagnation as with 3Dfx after initial Voodoo.

The only good thing about capitalism is that competition forces companies to get off their ass and evolve. A pity it doesn't work anywhere except the tech sector.

Re:DOA for anything but pro gear

[ceoyoyo]

"OpenAL is also cross-platform; there's a software-only implementation that runs very nicely on Linux, *BSD, and Solaris; it's not just Windows and OS X"

OpenAL is built into both OS X (since Tiger) and the iPhone OS (it is the recommended way of doing game/positional audio) and a Google search suggests Creative supports Windows.

Re:DOA for anything but pro gear

[TheRaven64]

Yes, that's what I said...

Re:DOA for anything but pro gear

[Lunix Nutcase]

And they supposedly will care about 3d acceleration anywhere else? Why the fuck has this boiled down to what an average joe thinks? The point remains that the examples used above are piss poor examples of OpenGL winning for a number of reasons.

Re:DOA for anything but pro gear

[Anonymous Coward]

No well-optimized PS3 game uses the shitty OpenGL implementation. Most games construct native GPU execute buffers directly and write to the mapped GPU registers to submit work (via the "libgcm" library). You can instantly double your frame rate doing this.

In fact, many actual developers did develop OpenGL engines, and had to re-write them, because of Sony's ridiculous PR on this matter.

Re:DOA for anything but pro gear

[binarylarry]

You're a moron, you've obviously some kind of fucking opengl newbie.

Re:DOA for anything but pro gear

[hduff]

Some citations will help your argument.

Re:DOA for anything but pro gear

[Tubal-Cain]

If directx hasn't won, why do people always talk about how with every new release of opengl it closes the gap or implements features that directx has already had.

DirectX wins when this stops happening.

Re:DOA for anything but pro gear

[Hurricane78]

Also, don’t forget, that mobile computers (phones, game consoles, etc) exclusively use OpenGL (ES). So porting games between them is much nicer if you start with OpenGL.

And OpenGL has an interface for pretty much every language known to man. Python, Perl, Object Pascal, Java, OCaml, even Haskell!
And for all those languages, nobody wants to implement a DirectX wrapper library. Since you can’t use it on any platform other than Windows anyway. And so it’s an annoying waste of time.

In the long run, DirectX will go the way of Internet Explorer 6.

Re:DOA for anything but pro gear

[makomk]

And even the XBox 360 doesn't use DirectX's sound or input APIs...

Re:DOA for anything but pro gear

[Brian Feldman]

and you can use OpenAL if you want to have the same sound effects engine on windows

Especially Windows Vista and 7 since DirectSound acceleration doesn't exist anymore LOL

Yeah, sound processing is really quite intensive for a modern computer with some cores lying mostly unused by most video games even without sound turned on.

Re:DOA for anything but pro gear

[shutdown -p now]

Actually it does, it's just that people only know of older APIs (DirectInput & DirectSound). Newer versions of DirectX also include XInput and XAudio, which are the same both on PC and on Xbox (and, presumably, on other future MS "game-enabled" platforms).

Re:DOA for anything but pro gear

[ceoyoyo]

Ah... latent dyslexia acting up. I read that as "it's just not Windows and OS X."

That's what happens when you move your office to the pub for the day. Sorry.

Re:DOA for anything but pro gear

[MachineShedFred]

Hey!

What's your problem with bananas?!

Re:DOA for anything but pro gear

[Lunix Nutcase]

And for all those languages, nobody wants to implement a DirectX wrapper library. Since you can’t use it on any platform other than Windows anyway. And so it’s an annoying waste of time.

Oh really?

DirectPython
Java3d
DirectX SDK For Delphi
DirectX Bindings for Haskell
OCaml library that uses DirectX

In the long run, DirectX will go the way of Internet Explorer 6.

Such has been claimed since the mid 90s and all who have claimed such have been wrong over and over.

Re:DOA for anything but pro gear

[Lunix Nutcase]

Since when were XInput and XAudio not part of DirectX?

Re:DOA for anything but pro gear

[oatworm]

In the long run, DirectX will go the way of Internet Explorer 6.

Ah - so it'll still be ubiquitous a decade from now, even after Microsoft stops supporting it out of shame? Neat!

Re:DOA for anything but pro gear

[javiercero]

The irony of it all is that in the tech sector, a lot of the evolution and advancement come from people who are in it because they love technology and scientific research, not just because of monetary rewards

In fact I know people who love so much what they do, they will point blank tell you they do it most definitively not for the money since they don't get paid anywhere near the amount that their time and effort would deserve.

Which sort of proves that most of the assumptions by those in love with Capitalism are at best incredibly dishonest. If people were guaranteed a relative level of stability (guaranteed housing, health care, food, and education) while being allowed to concentrate on what they love, you'd see humanity advancing by leaps and bounds. But then, the aim of Capitalism (and most other "isms") is not human advancement, but rather a closed loop cycle of concentration of capital, since that very same capital is both the means and the end.

Sorry for the tangent...

Re:DOA for anything but pro gear

[steveha]

Which sort of proves that most of the assumptions by those in love with Capitalism are at best incredibly dishonest. If people were guaranteed a relative level of stability (guaranteed housing, health care, food, and education) while being allowed to concentrate on what they love, you'd see humanity advancing by leaps and bounds.

I find your enthusiasm charming, but I consider it rather naive.

Who will provide the housing? If I don't like the housing, do I have the "right" to turn my nose up at it and demand better? Who will decide whether I deserve better housing?

Who will provide the health care? Everyone wants an infinite amount of health care; how do you ration it? If you pay the doctors well, where will you get the money for it? If you don't pay the doctors well, how do you get good ones?

Who will provide the food? Sometimes I like a fancy steak dinner; how often will I get one, and who decides?

But never mind these questions; let's get down to the important ones. Where on Earth, and when, has this been tried and shown to work?

The USSR was structured something like what you are describing. In theory, Communism gave to each as they needed. In reality, the economy was so bad that the USSR had a negative GDP: they were subtracting value. They took valuable iron ore and turned it into lousy Soviet steel. Then they took the lousy Soviet steel and turned it into lousy Soviet automobiles. The people were hungry, the health care was abysmal, and pollution was horrible.

The Pligrims tried something like what you described when they first arrived in America. It didn't work out.

In this country, in Chicago, there were massive "projects" built to provide housing for the poor. It didn't work out.

It turns out that people work both harder and smarter when they benefit from their work. And top-down-planning economies cannot possibly keep up with a a chaotic free market (and the creative destruction associated with it).

It is often argued that pure capitalism is heartless and cruel. But pure communism and socialism have even worse horrible disadvantages. If I'm going to live under pure anything, I'm going to choose the capitalism.

So, I'm happy that you have this faith in the innate goodness of humankind. But sorry dude, I don't think it's going to work.

steveha

Re:DOA for anything but pro gear

[makomk]

They weren't part of DirectX back when the XBox 360 was launched. The only reason they are now is that Microsoft decided to replace the existing DirectX audio and input code with the XBox 360 APIs - DirectX uses the XBox 360 audio and input APIs rather than the other way around. Which is absolutely no help to anyone that has code using DirectX for audio or input on the PC that predates the Xbox 360.

Re:DOA for anything but pro gear

[DaVince21]

Don't compare to DirectX. Compare to Direct3D.

HOT DAMN!!!

[Anonymous Coward]

My life is finally complete. ;-)

Is there a OpenGL 3.x book?

[Anonymous Coward]

Is there one now or on it's way? Im only interested in the non fixed pipeline api part.

Re:Is there a OpenGL 3.x book?

[binarylarry]

They've been out for a while, check the out the Superbible (covers everything), the Red book (covers the client side API) and the Orange book (which covers GLSL, the OpenGL shading language).

Re:Is there a OpenGL 3.x book?

[Anonymous Coward]

Is not the superbible for opengl 2.1?

How much is different on the non fixed side between 2.x and 3.x that the SuperBible book dont cover?

Re:Is there a OpenGL 3.x book?

[binarylarry]

I'm sorry, yes it appears the Superbible hasn't been updated (but I'm positive about Red and Orange).

The differences are mainly superficial in terms of how you provide geometry to the GPU and the shading language itself. Buffer objects work the same way, shaders work much the same but some terminology has changed.

It's mainly been streamlined and not revamped from scratch.

The fixed function api doesn't exist in 3+.

michael

[Anonymous Coward]

Your website is difficult for a Chinese like me!It is too professional!I have a new website:http://www.4yummy.com/ please give me some suggestion

That's not was the Mesa devs say

[H4x0r Jim Duggan]

> it's not a practical concern.

According to the references linked from that en.swpat.org page, it seems the developers of the free software Mesa project think it's indeed a practical concern.

Re:That's not was the Mesa devs say

[binarylarry]

How many products are shipped with Mesa as an important, primary component?

If you're using OpenGL, 99% of the products are going to want real hardware acceleration, not Mesa.

Mesa is a great project though, don't get me wrong.

Re:That's not was the Mesa devs say

[TheRaven64]

Mesa is used in a lot of X.org drivers. It provides the OpenGL state tracker for Gallium3D, so it will be used a lot more in future.

Re:That's not was the Mesa devs say

[ultranova]

How many products are shipped with Mesa as an important, primary component?

If you're using OpenGL, 99% of the products are going to want real hardware acceleration, not Mesa.

According to Linux From Scratch, Mesa is used to as the userspace component of OpenGL acceleration in X.org, at least with DRI drivers. In other words, if Mesa doesn't have it, FOSS drivers in Linux won't have it.

Of course the real solution is to move the project over to software patent free part of the world, rather than meekly remove the "offending" portion, but still...

Re:That's not was the Mesa devs say

[binarylarry]

Yeah, but anyone using OpenGL with X is going to be using either the Nvidia proprietary drivers or ATI proprietary drivers.

The OSS offerings do not provide nearly the same level of performance, unfortunately.

So again, from a real world practical standpoint, Mesa isn't in use anyway.

Re:That's not was the Mesa devs say

[malloc]

Yeah, but anyone using OpenGL with X is going to be using either the Nvidia proprietary drivers or ATI proprietary drivers.

The OSS offerings do not provide nearly the same level of performance, unfortunately.

So again, from a real world practical standpoint, Mesa isn't in use anyway.

Unless you meant to say "OpenGL 3.0" This is absolutely not accurate. Has your "real world" been isolated to workstation CAD and/or heavy gaming users? Those are the only groups where binary non-mesa drivers are used almost universally, but they are a minority. Intel, which has over half the graphics market only uses mesa. Your default Fedora and upcoming Ubuntu 10.4 installs use mesa for both amd and nvidia chips. AMD actively supports the open driver and is working to make that the main driver.

The continued development on gallium points to mesa gaining more traction. I think the trend is for binary drivers to become less and less common in the future.

-Malloc

Re:That's not was the Mesa devs say

[Ltap]

But it will be. Ultimately, once performance improves, the OSS drivers will supplant the proprietary ones. Then this will become a concern.

Re:That's not was the Mesa devs say

[binarylarry]

I hope you're right, I'm not for the proprietary drivers at all.

But gallium and the open source drivers aren't really ready for prime time, they're theoretical. I'm talking about practicalities. Right now, the open source drivers only exist to keep X running long enough to get the proprietary drivers installed.

No one is going to need S3TC compressed texture support for things like compiz anyway.

Re:That's not was the Mesa devs say

[Kjella]

AMD actively supports the open driver and is working to make that the main driver.

They are working on an open driver yes, but they are not looking to replace the proprietary driver in the foreseeable future. For a number of reasons - not least of which is the tons of optimization work going into the main driver - they expect the open source 3D performance to top out at 60-70% of Catalyst by keeping a simple structure. That is much better than than the difference between accelerated and unaccelerated though which can be <1% of the performance.

Re:That's not was the Mesa devs say

[Anonymous Coward]

Mod parent up!

Re:That's not was the Mesa devs say

[malloc]

But gallium and the open source drivers aren't really ready for prime time, they're theoretical. I'm talking about practicalities. Right now, the open source drivers only exist to keep X running long enough to get the proprietary drivers installed.

[emphasis mine]

Again, except for the majority of users! The default mesa drivers let you run Quake 3, composite your desktop, and do whatever 90% of desktop users want. It's only the "I want to play the latest game with max fps" and the "I'm rendering 100 million vertexes / frame in CAD" people that need to change to a binary driver.

No one is going to need S3TC compressed texture support for things like compiz anyway.

(FYI, the latest mesa actually supports S3TC this in the same way MP3 is. Too bad we have to wait till 2017 for patent expiry.)

Re:That's not was the Mesa devs say

[Randle_Revar]

Mesa is how you get hardware acceleration in Linux.

Re:That's not was the Mesa devs say

[Randle_Revar]

>Yeah, but anyone using OpenGL with X is going to be using either the Nvidia proprietary drivers or ATI proprietary drivers.

I'm not. I use Intel drivers right now, and before that I was using ATI OSS drivers, and sometime this year (hopefully) I will be using ATI OSS drivers again (probably with a 5000 series). I know of plenty of other people that are using OSS 3D drivers.

Also, Gallium3D should ultimately help performance a lot.

Re:That's not was the Mesa devs say

[Randle_Revar]

Gallium isn't ready yet, but for the classic stack it depends on which card you are talking about. Intel is OSS only, and works fine (discounting GMA500, which isn't really theirs), and a great many ATI cards (r100-r500) work just fine with full 3D on the OSS stack. Even r600/r700 is pretty good these days (for example, ioquake3 apparently works fine on r700 aka 4000 series).

Re:That's not was the Mesa devs say

[GenP]

once performance improves...

They'll change the driver model again.

Re:That's not was the Mesa devs say

[mojo-raisin]

Incorrect. Proprietary drivers are no longer required for Real Work.

I use the OpenSource Radeon Drivers with Mesa 7.7 to do lots of work with PyMol. It has all the performance I need, is stable and glitch free.

From what I've read, Mesa 7.8 is just around the corner, and will be even better.

Open Source Accelerated 3D has arrived.

Re:That's not was the Mesa devs say

[FedeTXF]

AMD's intentions when realeasing the specs might not have been replacing the proprietary driver, but I don't see why a group of people from all over the world could not make the open driver as good as the already not so good closed one. If the infrastructure is there, with the specs you can do the same kind of tricks in both drivers.

Re:That's not was the Mesa devs say

[Anonymous Coward]

No.

Apple

[zonker]

I wonder if/when 4.0 will be supported by OS X?

Re:Apple

[zonker]

Redundant? Really? How is this redundant when 4.0 for Mac wasn't mentioned by anyone else? Good job moderating...

Consoles Don't Count?

[medv4380]

Really?

Given that the PC gaming market is really a joke compared to the console market I think DirectX is really rather meaningless.

When the Top 50 selling games world wide contains only 3 PC games The Sims, World of Warcraft, and Starcraft it's time to say that DirectX for the PC is over rated.

Since the Wii and PS3 use a custom modified version of OpenGL for their hardware I'd also have to side with OpenGL as at least being relevant to professional games.

Re:Consoles Don't Count?

[Dan667]

Other underpowered devices like the iphone are not being considered so it does not make to worry about consoles. If you think a metric with Duck Hunt in it is an accurate representation of the market that is pretty sad. Almost no metrics consider MMO sales/subscriptions, which is where PC gaming has moved to.

Re:Consoles Don't Count?

[blahplusplus]

"Given that the PC gaming market is really a joke compared to the console market I think DirectX is really rather meaningless."

It's a joke because most PC games are bad ports of console games, Note the top games are all good games (with perhaps the exception of WoW). Too many PC games were just garbage, and lots of PC games could have done better if they were not released unfinished.

Re:Consoles Don't Count?

[Trogre]

Yes, the PC game market isn't hauling in as much coin from the masses as the console market, but I don't think game sales have much to do with either quality of the content or general use of 3D applications. I don't for example see Google Earth mentioned anywhere and that's most likely one of the most popular 3D applications on PCs today.

OpenGL is great and all, but let's not pretend Direct3D is somehow lacking in any area other than interoperability (though that is the very reason I won't use it).

One example - take any decent PC game less than two years old, and run it on a mid-range PC that's less than two years old, on a 1080p 40" TV (the standard gaming setup these days). Then try comparing it to the closest match on a current-generation games console. QED.

So..

[Anonymous Coward]

How does one get into using OpenGL?

Anyone have some links to tutorials? I'm ok with C++, and would be willing to learn a different language if it will let me play around with cross platform game dev.

Any references and help would be great.

Re:So..

[medv4380]

You need to find an SDK for the language you want to use opengl.org should be a good starting point. That and you're graphics card needs to support the version you want to develop for.

Re:So..

[Chatterton]

OpenGL tutorial

Re:So..

[Anonymous Coward]

The NeHe tutorials you round-about linked to are somewhat out of date and don't really give a good introduction to the new programmable pipeline. In any case, writing a game from scratch using OpenGL is a massive waste of time when you have plenty of good, portable 3D engines that do it all for you, and are available under a wide variety of licenses.

Re:So..

[Chatterton]

Yes NeHe tutorials are out of date on the last OpenGL specifications. But we don't ask tutorials to be on par with the last specifications. Tutorials like the NeHe ones must be simple and progressive in complexity to make them very good for someone who doesn't know anything about OpenGL.

Do you remember when at school you first learned to divide and the teacher learn you the 4, 6 and 50 where divisible by 2 but not 5? And then later when you have mastered these kind of division, he learned you the notion of decimals and made 5 divisible by 2? Why learning programmable pipeline before learning what is the OpenGL pipeline and mastering the non programmable one?

You need to learn to walk, the run and perhaps at the end learn to fly. It must be done in this order. Programmable pipeline, shaders & al are for those who can already run and what to learn to fly.

As a side note:
Learning OpenGL is not a requirement to use a 3D engine. But, I think you are better armed to use a 3D engine when you know at least a little bit of OpenGL and make you in a better position to grasp the use of these kind of tools.

Compatibility?

[Anonymous Coward]

Can I use version 3 if I need to support older cards, for example by checking support and not using unsupported features? Or am I stuck with OpenGL 1.1 and extensions in that case?

change to stateless API abandoned?

[Eric Smith]

3.0 was supposed to introduce a stateless API, but didn't. Now 4.0 apparently hasn't either. Have they decided that it's a bad idea, or that it's too difficult, or what?

Having the API retain state is a fundamentally bad idea. As one overview points out, "Nearly all of OpenGL state may be queried". (emphasis added)

It would be much better if there were OpenGL context objects that encapsulated the state, and were explicitly passed into API calls. I was completely dumbfounded when I first looked at API and saw that it didn't work that way.

Re:change to stateless API abandoned?

[IgnoramusMaximus]

Have they decided that it's a bad idea, or that it's too difficult, or what?

I am a bit fuzzy here on the idea of "stateless" API that deals with inherently state-oriented hardware such as GPUs with their frame buffers, pixel processors, massive texture memories and what not...

It would be much better if there were OpenGL context objects that encapsulated the state, and were explicitly passed into API calls.

So you do you expect the entire (multi-hundred megabyte sized) state of the GPU and its memory to be duplicated in system RAM and somehow auto-magically transmitted back and forth with each operation? Do elaborate.

Re:change to stateless API abandoned?

[JesseMcDonald]

I expect that the idea is that instead of calls like glClearBuffer(...) which take their context from the program's global environment, you'd have calls like glClearBuffer(context, ...). The point of this would be to make it easier for a given program to work with multiple contexts at once, e.g. for mixing render-to-texture with normal rendering. (Note: I am not an OpenGL expert, by any means.)

I'm certain no one is suggesting that the GPU become stateless, just the API.

Re:change to stateless API abandoned?

[Anonymous Coward]

Most of the data in the GPU memory is textures, vertex buffers, and shader fragments. None of these have anything to do with state.

The stateful parts of the OpenGL API are things like the current value set in glColor, the contents of the matrix stack, and lighting parameters. A lot of this stuff never even crosses into GPU memory in the first place, it is handled on the CPU by the OpenGL libraries. And a lot of it has been removed in newer versions of the API.

Re:change to stateless API abandoned?

[IgnoramusMaximus]

Most of the data in the GPU memory is textures, vertex buffers, and shader fragments. None of these have anything to do with state.

That is actually a very definition of a "state", i.e. each call to "upload" a texture, vertex etc alters the state of the GPU. That state is preserved between calls, i.e. it is persistent from the point of view of the API.

The stateful parts of the OpenGL API are things like the current value set in glColor, the contents of the matrix stack, and lighting parameters. A lot of this stuff never even crosses into GPU memory in the first place, it is handled on the CPU by the OpenGL libraries. And a lot of it has been removed in newer versions of the API.

That is merely the non-GPU portion of the state of the API. Sure, that portion can be removed but the fundamental state-oriented properties of the GPU cannot be so easily gotten rid of and so in the end the API as a whole will remain stateful no matter what you do.

Maybe they should change that

[Sycraft-fu]

Part of the reason for DX's popularity is the support for the latest tech. The reason for that support is that MS works with the GPU makers. They have discussions back and forth. MS tells the hardware makers what they want to introduce in the new DX specs, the hardware makers tell MS what kinds of features they are working on and so on (you have to remember that they are already in early development of next gen chips before current ones come out, chip development is a lengthy process). By working on this beforehand you can have a situation where DX supports the latest cards, and generally comes out about the same time. Quite useful.

Perhaps the OpenGL devs need to start doing that, rather than just sitting around until hardware launches and then playing catchup.

Re:Maybe they should change that

[Anonymous Coward]

Perhaps the OpenGL devs need to start doing that

Just out of interest, who do you think are sitting on the OpenGL ARB?

Re:Maybe they should change that

[Anonymous Coward]

It's part of the standard before anything more than a techdemo running on a extremely limited set of cutting edge cards uses the features.
Why does it matters if it's just catching up?

Re:Maybe they should change that

[Anonymous Coward]

the khronos group releases the opengl specs.
http://www.khronos.org/members/promoters
if you look closely, you will find amd nvidia and many others.

Only 4.0!

[johno.ie]

DirectX goes all the way to 11.

Re:Only 4.0!

[Anonymous Coward]

OpenGL = everywhere
DirectX = Windows only

Mod up!

[n dot l]

I expect that the idea is that instead of calls like glClearBuffer(...) which take their context from the program's global environment, you'd have calls like glClearBuffer(context, ...). The point of this would be to make it easier for a given program to work with multiple contexts at once, e.g. for mixing render-to-texture with normal rendering. (Note: I am not an OpenGL expert, by any means.)

I'm a game developer. I work with OpenGL. This is exactly what's meant when people bitch about OpenGL being stateful. That and the selector states, which make it annoying to write libraries that target OpenGL and work together nicely.

Re:Mod up!

[IgnoramusMaximus]

What you guys are talking about is more independent rendering pipelines that can be utilized in parallel with each other (and results of which can fed back into the main pipeline as textures, stereo views and what not) rather then "contexts" or "stateless" API. The GPU still contains all the "state" data, i.e. the current textures, light positions and what not that are used in the final "render" call for each pipeline, but you simply want to access them independently...

None of this alters the fundamental state-based nature of the GPU.

Re:Mod up!

[n dot l]

No, nobody wants a "stateless OpenGL" in the way you seem to be taking it. That would be stupid. "Stateless API", in the context of OpenGL, refers to the removal of the excess state that the API imposes.

For example, take binding two textures and disabling a third. In DirectX (example, not actual compiling code):

myDevice->SetTexture( 0, myFirstTexture );
myDevice->SetTexture( 1, mySecondTexture );
myDevice->SetTexture( 2, NULL );

There. Done. Yes, myDevice is storing "state", but it stores only state which is relevant to the operation of the GPU. Now, the same thing in OpenGL:

glActiveTexture( GL_TEXTURE0 );
glEnable( GL_TEXTURE_2D );
glBindTexture( GL_TEXTURE_2D, myFirstTexture->glId );

glActiveTexture( GL_TEXTURE1 );
glEnable( GL_TEXTURE_2D );
glBindTexture( GL_TEXTURE_2D, mySecondTexture->glId );

glActiveTexture( GL_TEXTURE2 );
glDisable( GL_TEXTURE_2D );
glBindTexture( GL_TEXTURE_2D, 0 ); //not redundant if you care about texture lifetime

That's right, OpenGL has me use one function to store an index in a global, thus modifying the operation of other functions. That sort of garbage is everywhere in OpenGL, and it's incredibly tedious to constantly deal with. It also makes it really tough to interoperate with libraries that need to touch the GL state, since you have to be really careful about what the state is going in and how it's been changed coming out.

It also refers to the most ridiculous bit of OpenGL state, which is the context (OpenGL's equivalent of Direct3D's Device object). In Direct3D, if I need to output to more than one window, I can create multiple swap chains and drive them with the same device. If I need to output on two independent video cards, I simply create a Device object for each one, load my textures into both, and then simply draw to both as I wish.

In OpenGL the only way you can accomplish either goal is to create a new context object (since a context is bound to the output). Contexts can't be used until you bind them to a thread, and switching contexts is an expensive operation. Using more than one (even when you link them together to share resources) is almost always an exercise in frustration.