OpenGL 4.0 Spec Released 166
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."
Patent problems still there? (Score:5, Interesting)
Any chance the patent problems of OpenGL 3 [swpat.org] have been fixed?
Re:Patent problems still there? (Score:5, Informative)
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.
That's not was the Mesa devs say (Score:4, Informative)
> 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: (Score:3, Informative)
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 (Score:5, Informative)
Re: (Score:3, Insightful)
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 (Score:5, Informative)
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 [ngohq.com] 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: (Score:2)
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: (Score:3, Interesting)
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: (Score:2)
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 (Score:5, Informative)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
once performance improves...
They'll change the driver model again.
Re: (Score:2)
>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: (Score:3, Informative)
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: (Score:2)
According to Linux From Scratch [linuxfromscratch.org], 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
Re: (Score:2)
Mesa is how you get hardware acceleration in Linux.
Re: (Score:2)
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: (Score:2)
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 [espacenet.com]) 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 cl
Re:Patent problems still there? (Score:4, Insightful)
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: (Score:2)
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 [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".
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
Re: (Score:2)
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.
Re: (Score:2)
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.
OpenGL on par with Direct3D11 (Score:5, Informative)
Re: (Score:3, Interesting)
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 playe
Re:OpenGL on par with Direct3D11 (Score:4, Insightful)
This jostling for OpenGL to jump over Direct3D in terms of features is ridiculous.
You can't have stable without the beta.
Re: (Score:2)
There are well tested, production ready OpenGL bindings for Java: http://lwjgl.org/ [lwjgl.org]
Java fits better with OpenGL anyway, being cross platform and open in the same vein as OpenGL.
Re: (Score:2)
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: (Score:2)
AA has nothing to do with the gl interface you're using, it's an OpenGL feature (and usually by extension).
Re: (Score:2)
Can you explain then why jogl supports full screen AA while lwjgl doesn't? Shouldn't they be supporting the same OpenGL feature?
Re: (Score:2)
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: (Score:2)
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 pret
Re: (Score:2)
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 (Score:4, Informative)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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 [wikipedia.org]
"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: (Score:2)
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 [sun.com] 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 P [piccolo2d.org]
Re: (Score:2)
Project looking glass was done in Java http://en.wikipedia.org/wiki/Project_Looking_Glass [wikipedia.org]
Even if you look at Wordle ( http://www.wordle.net/ [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
Re: (Score:2)
For some reason it ate part of my text mentioning the iphone and tagged Windows onto the end.
Re: (Score:2)
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 pla
Re: (Score:2)
"PICTURES" extension is likely his mistaken naming for GL_TEXTURE_INTERNAL_FORMAT.
Re: (Score:2)
Re: (Score:2)
There are well tested, production ready OpenGL bindings for Java: http://lwjgl.org/ [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
Re: (Score:2)
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 (Score:4, Insightful)
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: (Score:2)
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html [tiobe.com]
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: (Score:2)
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 (Score:5, Insightful)
Maybe they should change that (Score:2, Insightful)
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 be
change to stateless API abandoned? (Score:3, Interesting)
Having the API retain state is a fundamentally bad idea. As one overview [wpi.edu] 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: (Score:3, Insightful)
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...
So you do you expect the entire (multi-hundred megabyte sized) state of the GPU and its memory to be
Re: (Score:3, Informative)
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.
Mod up! (Score:3, Informative)
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.
Only 4.0! (Score:4, Funny)
DirectX goes all the way to 11.
Re: (Score:3, Informative)
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: (Score:2)
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
Re:Hardware support (Score:4, Funny)
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: (Score:3, Insightful)
It's like Ford's Model-T: You could order in any color you wanted, so long as that color was black.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
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: (Score:2)
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: (Score:2)
>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: (Score:2)
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 ha
Re: (Score:2)
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 (Score:5, Informative)
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: (Score:2, Troll)
Consoles Don't Count? (Score:3, Informative)
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 [vgchartz.com] 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 [wikipedia.org] 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: (Score:2)
Re: (Score:2)
"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: (Score:2)
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 exam
Re: (Score:3, Interesting)
You mean other than the fact that what the PS3 and Wii run aren't really OpenGL but proprietary derivatives of OpenGL ES?
Re: (Score:2)
And even the XBox 360 doesn't use DirectX's sound or input APIs...
Re: (Score:2)
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: (Score:2)
Since when were XInput and XAudio not part of DirectX?
Re: (Score:2)
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: (Score:2)
Hey!
What's your problem with bananas?!
Re:DOA for anything but pro gear (Score:5, Interesting)
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 (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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 [sourceforge.net]
Java3d [sun.com]
DirectX SDK For Delphi [clootie.ru]
DirectX Bindings for Haskell [hatena.ne.jp]
OCaml library that uses DirectX [inria.fr]
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: (Score:2)
Ah - so it'll still be ubiquitous a decade from now, even after Microsoft stops supporting it out of shame? Neat!
Re: (Score:2)
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: (Score:2)
"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: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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 [wikipedia.org]. 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: (Score:2, Insightful)
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 (Score:5, Insightful)
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: (Score:3, Insightful)
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 Capitalis
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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+.
Re: (Score:3, Interesting)
OpenGL tutorial [lmgtfy.com]
Re: (Score:2)
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