Slashdot Mirror
OpenGL 3.0 Released, Developers Furious
ikol writes "After over a year of delays, the OpenGL ARB (part of the Khronos industry group) today released the long-awaited spec for OpenGL 3.0 as part of the SIGGRAPH 2008 proceedings. Unfortunately it turns out not to be the major rewrite that was promised to developers. The developer community is generally furious, with many game developers intending to jump ship to DX10. Is this the end of cross-platform 3d on the cutting edge?"
Everyone knows x.0 releases are Beta anyway.
/ducks
OpenGL 3.1 will rock
Is this the end of cross-platform 3d on the cutting edge?"
Probably not. As long as DX remains solely in the hands of MicroSoft; there will be use for other forms of cross-platform 3D. More so as the "none-MS" OSes continue to grow in numbers.
The Long Now Foundation
Is the end of interest in cutting edge 3d? It seems like most of the low hanging fruit in 3d graphics has been picked.
love is just extroverted narcissism
Well, this is just very disappointing to me, for two reasons. First because I was hoping for something new in Linux graphics development. Secondly, because the behaviour of the ARB here isn't really a positive sign. I hope that there is some light in future OpenGL specifications here. If not, what can I use on Linux to have the ability to use all features of modern graphics cards? What about the future platforms like Larrabee? It seems DirectX is going stronger in all these areas, but it being closed source and Microsoft-platform only is a very big problem imho.
Jumping ship to DX10 would be nice, if it were cross-platform. (No, Xbox + PC does not count as "cross-platform".)
Unfortunately for those of us on Linux/Mac, a lot of Windows developers don't care.
Unfortunately for those of you who think you don't care about this, consider that porting an app generally improves it, and can shake out bugs which aren't as apparent on the other platform -- which means potentially less reliable games, even if you're only on Windows.
And unfortunately for those of us who hate Vista, that's kind of a requirement for DirectX 10. At least with OpenGL, those in charge have no agenda to push Vista -- so an OpenGL 3.0 game should run on XP, if it runs on anything.
Don't thank God, thank a doctor!
I'm sorry but I dont believe you and I have not read it myself
the entire GL board seems to be NVidia or ATI....
until there is a game published that uses it then it's kind of pointless to say these kind of things
I mean it's got to be dead after all MacOS uses OpenGL...
regards
John Jones
I have programs that use that library to compile programs, plus I need the associated headers. Some OS's seem to have it and some don't. The latest Mesa release that I checked didn't have them. Perhaps they get installed via Xorg.
jump ship to DX10
And when they do they wander into Direct/Input/Sound/Video/Play/etc. OpenGL does 3D rendering. The rest? Cobble it together from whatever other obsolete scraps are available.
The non-Microsoft "stacks" suck. Bottom line.
The concept of a 2D "layer" still hasn't impinged on the basic SDL API. Couldn't believe it when I learned that.
I guess professional game developers don't care that Microsoft owns the machinery of their livelihoods. They sure aren't contributing to their own independence in any noticeable way.
Heh - Games developers may have that luxury, but 3D/GC vendors certainly don't. So unless someone decides to port DX10 to OSX (*snort*) or Linux (sing it with me now: "render farms!"), OpenGL will continue to have a decently-sized userbase for a very long time.
IMHO, anyone making the claim that they're going to suddenly jump to DX10 is only making noise; nobody is dumb enough to cut off the fastest-growing consumer market sectors.
(...besides, doesn't the PS3 use OGL, or do they use some other home-brewed library set? Not sure there...)
Quo usque tandem abutere, Nimbus, patientia nostra?
Any redesign of the GLSL standard wouldn't make any difference since NVidia was the only brand to support OpenGL 2. Today, almost everything sold uses Intel GMA drivers which only do OpenGL 1. As for new standards bringing new functionality, there are over 1000 Java standards awaiting implementation too.
What do you means DirectX10 isn't cross platform? It runs in all six versions of Windows Vista!
Not much unlike the one XFree86 fell down.
It needs to be forked. We need a fork of the 3D library, much like Xorg was forked.
The fork/rewrite should be more like DX10 than like OpenGL.
The library needs to be able to interoperate with current and future video hardware, so that all hardware acceleration features will be available to applications using the 3D library...
That means providing an underlying interface compatible with both the OpenGL and DX10 ABIs and conventional hardware drivers.
DX-10 is Vista only among other issues.
OpenGL isn't from the open source community, actually. It's "open" is the old "open systems" open, which is rather less open.
While people might say linux uses opengl, a lot of the time it's using mesa, which implements the opengl specifications but is NOT a certified opengl implementation.
(This revised 3.0 might be good news for mesa, as the originally threatened backward-incompatible 3.0, that, perhaps contrary to this slashdot "story" most opengl folk decided they didn't like, looks like it might be implementable without certain patent issues biting).
frankly DX10 blows them out of the water. why don't the openGL guys try to compete on performance and technical merit rather than hiding behind the cross platform shield all the time....
If you mod me down, I will become more powerful than you can imagine....
Part of the reason for DX's success is that nobody else seems interested in developing anything to compete with it. OpenGL is the only cross platform 3D API I'm aware of and it and DX are all that there is these days. GLs problem is that it isn't keeping up with the hardware. The "just use vendor specific extensions" isn't a realistic solution in most cases. Thus GL is suffering and DX is winning by default.
If someone like Apple did develop a good 3D API, it might do well. However nobody seems interested.
It's a specification, can't we diverge and create a new one by developers for developers? I.e. start a new consortium?
Is this the end of cross-platform 3d on the cutting edge?
it isnt. because OpenGL ARB is gonna play it nice, and revise their specs, therefore pleasing developers and therefore GAMERS as much as they can, and fix the matter, wont you now ? dont make us wait.
Read radical news here
DirectX is graphics, input, sound and peripherals interaction.
Opengl can only handle the graphics portion of a game, everything else needs other products. The unified nature of DirectX makes it superior in many ways.
The only bad thing about is that in its pure form its Windows and Xbox only, if we don't count Wine.
A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' - D. Adams
When I was a student at SGI and OpenGL was replacing IrixGL? it was never pushed as cutting edge graphical porn. It was promoted as an easy to use, cross platform graphics language with emphasis on 3D apps that could also be used for games. Which it still is of course. Hands up I don't know what graphical advantages Direct3D has over OpenGL but I do know the games market probably doesn't care. PC games are dying on their arse. Witness the shrinking shelf space for PC games compared to the Wii in the Uk (I don't know about other countries). I have a hunch that OpenGL is good enough for Autodesk and good enough for most gamers.
Really. A lot of people depend on OpenGL.
Rather than grousing about it, how can we make it better?
I never had the impression OpenGL was trying to be a games platform. I think there are two distinct 3D libraries needed. One for actuate rendering, where its ok to take several minutes (or days) to render an image, and then the games platforms. I would rather see OpenGL be mathematically correct and be a great rendering engine. Not a games engine. Then if we need a competitor to DirectX on Linux/Mac, maybe we could persuade Sony or Nintendo to open source their games engines. After all the PS3 and Wii are the main competitors to DirectX. Not sure what the chances are, but maybe open sourcing their environment would put more interest back into PS3 development (which really seems to be lacking).
.
Vista is approaching 20% of the market. Top Operating System Share Trend You can't expect expect Linux ports if entry level DX9l/DX10 outperforms OGL.
...and probably irrelevant in the longer term.
This is not the first time this has happened. GL2 was also supposed to be a cleanup, but turned out to be anything but. This latest fiasco is more significant as a failure of governance than of technology. All the right ideas were there; they were published in some detail over a year ago in the Pipeline newsletters. But the ARB very obviously a) can't agree to get anything meaningful done, and b) now has subzero credibility with developers. It's not coming back from that.
So yes, I think cutting-edge cross-platform 3D is dead for the next 2-3 years. Let's face it, it was never exactly healthy. It's not the end of the world. Linux share is currently growing mostly at the low end, netbooks etc, while the Mac seems to be thriving despite the fact that Apple doesn't give a flying fsck about gaming and never has.
Fast forward a couple of years, though, and things like Larrabee will be hitting the market; embarrassingly parallel hardware that can be programmed with standard languages and tools. The API's role as gatekeeper of functionality will be gone. And suddenly, 3D rendering libs can be written by anyone with the time and expertise, without having to go through Microsoft or the ARB or NV or AMD/ATi or Intel or anyone. Experimentation, competition, cross-fertilization, evolution. Remember Outcast's voxel engine? Seen things like Anti-Grain? This will happen.
(Or, yes, people could just reimplement the DXwhatever API directly, but that would be a little disappointing.)
Today was not a good day, by any stretch of the imagination. But it's not the end.
DirectX 11.0 will be released on nVision 2008, 25-27 augusti.
The OpenGL consortium had to release opengl now to be take the egde. Too bad it had to be "finished" in a hurry.
ATI supports openGL, Intel added full support as well when they implemented DX10 (only one chipset has these so far iirc though).
The apparent failure of OpenGL to provide a significant rival to DX10 sucks though, especially since the DX10 on Vista only might have provided game makers an incentive to jump ship in order to get bleeding edge graphics onto XP systems.
Liberte, Egalite, Fraternite (TM)
What is wrong with OpenGL3.0?. It has no objects?, that is all?. Comparing OpenGL3.0 with DirectX10 is like comparing apples and oranges. Do you mean Direct3D 10?. If you are a serious game developer targeting PS3 and other game consoles you already do not use D3D 10, because D3D 10 only works in Vista, and the Vista market is very small, most Windows users own XP yet. If you are a serious application developer (CAD/sim/etc), OpenGL is the way to go. Also XBox hardware is obsolete for next generation games (no standard harddisk, no blu-ray, no 1080p), Microsoft is not the future, but if you write your game using OpenGL, it will run in windows too.
Microsoft releases a bullshit new DX that only runs in Vista, so all games are 20% slower in it and everyone is happy.
OpenGL dares not to completely rebuild itself, and people get furious, threaten to go to the proprietary, Vista-only load of horse shit.
Ya, that's rational.
Send your spendthrift head of state this
That's an old perpetuated myth, that the value of D3D has anything to do with the satelite APis.
Let's confront it with facts:
- Direct3D is the absolutely dominant component of DirectX, in terms of received and deserved attention by users. As well as R&D effort by MSFT. It's the advancement of D3D that drives MSFT to release every next version of DirectX.
- Each component of DX is a completely indepependent API, sharing only design convention. OpenGL games on Windows use DirectInput for input, perfectly ignoring Direct3D.
- funnily, the satelite APIs are actually being phased out by MSFT. DirectPlay was always thoroughly ignored by the industry. For DirectSound and DirectInput there are replacement already. Not to mention the fate of hardware acceleration of DirectSound in Vista.
D3D and DX are de facto interchangable terms. Get over it.
Not handling sound/input by OpenGL is absolutely irrelevant in discussion about it's applicablity.
Professional apps (CAD/simulators/visualizations...) make up the majority of the OpenGL market and they have to be supported for decades (no, military or airlines do not buy a new training system every two years ...)
So breaking compatibility is deal breaker. This is exactly what OpenGL 3.0 is about. I am developing OpenGL applications for a decade now and all are still running and being used. How many 10 year old games can you actually get working today? God forbid - on Vista? That is the difference.
Also, the "newest features not supported by OpenGL" - how many "newest features" are your typical games actually using? Perhaps one or two and they are optional, because the game must run even on not bleeding-edge hardware (how many games are DX10-only? - commercial suicide ...)
So to wrap this up - the title is EXTREMELY misleading and making up a storm where one doesn't exist.
Sure, *some* developers might be "furious", and maybe it was wrong for Khronos to abandon the original proposal.
In any case, even with OpenGL 2.0 you can do a lot of stuff. Are there games that benefit from using Direct3D instead of OpenGL 2.0? Having done a lot of programming in DX and MDX (before it was rolled in to XNA) and in OpenGL, I really wonder what someone might claim is missing in OpenGL...
I think the features people are "furious" about must be pretty damned esoteric.
If you want to make a game that runs on Xbox, you will be using an advanced version of DirectX 9. Most companies would probably stick to normal DirectX 9 so that they could just be recompiled for Windows XP and Vista. Especially since most gamers are still running XP. Gaming rigs are one of the exceptions to the major computer companies being able to still sell XP.
As for where do I get the information for DX10 not running on the Xbox, read below.
1up reports that ATI has debunked a rumor that Xbox 360 could be upgraded to support DirectX 10 via a patch. "Xbox360 cannot run DX10," an ATI spokesperson told 1up. Currently, Microsoft's console runs an advanced version of DirectX 9, which, according to ATI, features "memory export that can enable DX10-class functionality such as stream-out."
http://www.joystiq.com/2006/08/24/xbox-360-cant-run-directx-10-confirms-ati/
Microsoft, Apple, Google, Amazon what's the difference? All steal money from devs and control with walled gardens.
All I've really seen of the PS3 dev kit is what was on display at GDC. The Sony guys talked about GL ES and NVIDIA's Cg toolchain for shaders, so that's what I posted. This, however, sounds a lot more like what I expected from Sony and is right in line with the PS2 dev kit (emphasis mine):
Sony supply an alternative low level api called libGcm.
If libGcm is what I think it is (macro'd constants to build push buffers + raw DMA access) then pretty much nobody will be using the GL stuff. Coding right to the hardware is what PlayStation development is all about.
Examples: ISO11783 and NMEA2000 (forked from J1939), Embedded C++ (from C++), MISRA C (from C), etc etc
Engineering is the art of compromise.
While the gaming community is growing at an awesome rate, I doubt its the same size, and definitely not bigger than the hollywood industry. Coming from the special effects/render farm industry, I can tell you that every single movie that makes it to the big screen today, is in one way or many, made with products that use OpenGL. The gaming community/developers of course are frustrated that opengl is not dx10, but lets face it, hollywood has an endless budget, and a lot of say. This story does not surprise me, and opengl is still going to be the best cross-platform solution for many (and most) 3d technologies, less gaming.
the lies about interoperability need to be heard
Microsoft's patent claims while claiming interoperability and connection to Novell and sinking of Corel Linux MUST be TOLD!
Since I got hooked on EVE a few months ago, I've barely played anything else. I could rant about why I enjoy it so much but I will summarise that it's basically replaced the pub for me & my friends. Headsets, Eve, fun. Cheaper than spending 3 Fridays out of 4 buying alcohol for sure, and more fun without the trouble of going to crowded drinking holes.
My point is that EvE has a decent linux client, and I can now get by on open source office / coding tools. I have no reason to be using MS at all really.
The Terminal Logic Killboard is just an indication of the fun we've been having.
Quoting the article linked to:
Xbox360 cannot run DX10
This is true. Given that there has been no firmware upgrade, the Xbox 360, as sold today, cannot run DX10.
The Xbox360 has unique features including memory export that can enable DX10-class functionality such as stream-out
That kind of hints that it could.
My bad, though, for making that assumption.
Don't thank God, thank a doctor!
To the extent that renderers can use GPUs, it is via vendor GPGPU stuff like CUDA. nVidia has a renderer called Gelatto that will use their hardware to do the rendering. However it is not going through a graphics API, to do so would be inefficient. That's the whole point of something like CUDA, is to write directly for the graphics hardware. Thus the graphics API isn't relevant to a system using the GPU for such a purpose.
Hurrah for boycottnovell.com It's pithy truthiness, and dilligently accurate reporting are a boon for the Internet!
If someone were to take Gallium 3D, for example, and write a decent API on top of it, then it's not that far fetched for a few of the IHV's to start supporting it elsewhere. Hell I wouldn't be surprised if some industrious individual in AMD or NV's research department is already doing that.
The thing with OpenGL is that it's obscenely difficult to write a driver that runs well because the API is simply a mess. None of the IHVs are happy to have a performance overhead imposed on them (obviously) but they do it because the only alternative (everyone having their own API) is even worse (unless you're Sony, and even they made an effort to put GL ES on the PS3). Current GL extensions are full of things like "if this is enabled and that extension is implemented and you're drawing an X or a Y (but not a Z) then this function's behavior is changed thusly". Hell, even the core GL spec has a ton of stuff like that in it (glEnable, anyone?). That's pretty much the entire reason for DX's success performance wise - Microsoft rips out whatever the IHVs can't make fast on their current/new cards every time they bump the version number. GL drags along concepts that haven't had silicon dedicated to them in nearly a decade, and all of that has to be supported (read: emulated) in new drivers with every new bit of code wasting cycles checking if it should be in compatibility mode.
I think AMD/ATI and NV would be extremely happy if they could get away from maintaining drivers where the first half of nearly every entry point is a tangle of "has my behavior been modified, if so reroute to alternate implementation 112". And they seem to have learned the "what one implements, we all implement" lesson pretty well (PhysX on AMD/ATI for example) so if a new API is good enough to catch any major IHV's attention, the others are likely to follow.
.
FIY:
We collect data from the browsers of site visitors to our exclusive on-demand network of live stats customers. The data is compiled from approximately 160 million visitors per month.
Additional estimates about the website population:
76% participate in pay per click programs to drive traffic to their sites.
43% are commerce sites
18% are corporate sites
10% are content sites
29% classify themselves as other (includes gov, org, search engine marketers etc.. About Our Market Share Statistics
Net Applications stats are global.
Its clients - for reasons which should be blindingly obvious - are interested only in meaningful stats about users, not licenses.
Plenty of people are buying computers with Vista and switching to another OS, or downgrading to XP.
The numbers simply aren't there to support this argument.
Professional apps (CAD/simulators/visualizations...) make up the majority of the OpenGL market and they have to be supported for decades (no, military or airlines do not buy a new training system every two years ...)
So breaking compatibility is deal breaker.
Hmm. If OpenGL is being maintained primarily for CAD developers and other people who require stable, long-term APIs, then perhaps the people who maintain the API should explicitly announce that as their goal.
I'm not trying to be snarky. If the needs of game developers are so incompatible with the needs of CAD developers, why not declare OpenGL for CAD and start a new group to focus on the needs of game developers?
There'd probably be a lot of resistance to that, though. Not to mention the many difficulties involved in assembling a group and producing a spec that the developer community (and their employers) can agree on. But it might be worth it.
Take a look at this extension: http://www.opengl.org/registry/specs/EXT/direct_state_access.txt This is actually quite significant. I think it could form the basis of the object system that was promised but not delivered.
"Politicians and diapers must be changed often, and for the same reason."
Please stop modding up this troll.
That article is 6 years old.
Most of those patents are hardware patents totally irrelevant for OpenGL (or Direct3D for that matter).
Also, Microsoft is not a member of the group that actually writes the OpenGL specification. They have no vote on what gets in OpenGL or don't.
Of course this might give them leverage on some of the hardware vendors (like Nvidia) that will have to implement the new OpenGL standard in the future. But history does not show them trying to use this in any way against OpenGL.
But claiming they "own OpenGL" is nonsense.
I was really looking forward to a new architecture that can stay on the cutting edge. OpenGL seems rather important to companies like Apple which have no realistic way to have DirectX support, without using what is essentially a DX wrapper on top of OpenGL.
Is it possible to fork the OpenGL API in an attempt to arm-twist a new design into it. Perhaps I am overly optimistic, but if an API looks attractive to Nvidia and ATI (and you could get those guys to look at it seriously) wouldn't it be possible to get it accepted?
“Common sense is not so common.” — Voltaire
Nvidia has one option at this point, and that seems to be "go home". Unless they pull something out of their Arse, ATI/AMD and Intel/Intel is going to clean up.
Perhaps they can team up with VIA. The only other option for them is going to be embrace Open Source and build a OpenGL optimized chip, and help build OpenGL with the community.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
In game development OpenGL has been relevant only for few years when DirectX was not available on all Windows platforms so you had to use OpenGL if you wanted to run on 9x and NT. It's not like somebody has been seriously targeting WinNT users as their game's audience but development was much easier under NT. With W2K supporting DirectX in NT environment there was no reason to use OpenGL in commercial mainstream development any more. These "furious developers" are probably some hobbyists, professional developers still using OpenGL are working on Macs or mobile devices and don't care about cutting-edge features since their target hardware would not support them anyways.
Thankfully Intel was smart enough to give up and have hired PowerVR to build the integrated graphics for the upcoming Atom chipsets. X3100 was never going to fit in a mobile world, and, from my perspective, had no hope of ever getting with the times. Their DX10 performance is... ghastly. PowerVR at least will continue to invest in their stack and cares about making a viable graphics product.
You know its bad when the embedded world is more state of the art than 98% of PCs. The same PowerVR tech going into Atom is being put on-die with ARM chips. Intel was about to get paced by a mobile device, before they bought in.
And heres where I think it all comes together beautifully: if Intel doesnt "come to jesus" and stop holding up the entire computer market, I believe AMD will be able to leverage their far superior integrated chipsets to capture huge amounts of Intel's CPU business. OEMs are quite aware that the best bargian CPU in the world is useless without a display subsystem to make use of it, and AMD has been leading the charge on making an ecosystem of integrated chipsets, mobile devices, and really good low end graphics chips. Hybrid Power is a great example of how to leverage a reasonably fast very low power integrated chipset with a high performance video card.
All these details and circumstances aside, the bottom line is that I just cannot imagine the computer industry permitting Intel to keep getting by with such abysmal and useless crap. Its holding everything up, and its gonna change.
Basically they've got tangled in the implementation details and decided to play it safe with OpenGL 3.0 instead of starting from scratch.
========
What happened to Longs Peak?
In January 2008 the ARB decided to change directions. At that point it had become clear that doing Longs Peak, although a great effort, wasn't going to happen. We ran into details that we couldn't resolve cleanly in a timely manner. For example, state objects. The idea there is that of all state is immutable. But when we were deciding where to put some of the sample ops state, we ran into issues. If the alpha test is immutable, is the alpha ref value also? If we do so, what does this mean to a developer? How many (100s?) of objects does a developer need to manage? Should we split sample ops state into more than one object? Those kind of issues were taking a lot of time to decide.
Furthermore, the "opt in" method in Longs Peak to move an existing application forward has its pros and cons. The model of creating another context to write Longs Peak code in is very clean. It'll work great for anyone who doesn't have a large code base that they want to move forward incrementally. I suspect that that is most of the developers that are active in this forum. However, there are a class of developers for which this would have been a, potentially very large, burden. This clearly is a controversial topic, and has its share of proponents and opponents.
While we were discussing this, the clock didn't stop ticking. The OpenGL API *has to* provide access to the latest graphics hardware features. OpenGL wasn't doing that anymore in a timely manner. OpenGL was behind in features. All graphics hardware vendors have been shipping hardware with many more features available than OpenGL was exposing. Yes, vendor specific extensions were and are available to fill the gap, but that is not the same as having a core API including those new features. An API that does not expose hardware capabilities is a dead API.
Thus, prioritization was needed, and we made several decisons.
1) We set a goal of exposing hardware functionality of the latest generations of hardware by this Siggraph. Hence, the OpenGL 3.0 and GLSL 1.30 API you guys all seem to love ;\)
2) We decided on a formal mechanism to remove functionality from the API. We fully realize that the existing API has been around for a long time, has cruft and is inconsistent with its treatment of objects (how many object models are in the OpenGL 3.0 spec? You count). In its shortest form, removing functionality is a two-step process. First, functionality will be marked "deprecated" in the specification. A long list of functionality is already marked deprecated in the OpenGL 3.0 spec. Second, a future revision of the core spec will actually remove the deprecated functionality. After that, the ARB has options. It can decide to do a third step, and fold some of the removed functionality into a profile. Profiles are optional to implement (more below) and its functionality might still be very important to a sub-set of the OpenGL market. Note that we also decided that new functionality does not have to, and will likely not work with, deprecated functionality. That will make the spec easier to write, read and understand, and drivers easier to implement.
3) We decided to provide a way to create a forward-compatible context. That is an OpenGL 3.0 context with all deprecated features removed. Giving you, as a developer, a preview of what a next version of OpenGL might look like. Drivers can take advantage of this, and might be able to optimize certain code paths in the forward-compatible context only. This is described in the WGL_ARB_create_context extension spec.
4) We decided to have a formal way of defining profiles. During the Longs Peak design phase, we ran into disagreement over what features to remove from the API. Longs Peak removed quite a lot of features as you might remember. Not coincidentally, most of those features are marked deprecated in OpenGL 3
OpenGL was never really intended for games. Yes it has some things in common with what game developers want but it was never a solution the way directx is. Unfortunately the alternative OS community (linux, apple, etc) relied too much on opengl as a game panacea, when it is not, and instead of coming up with a real alternative.
How many of you were waiting for the release? There will be many more people happy to still be secure in knowing they can use GL the way they have been.
The issue is very simple; not enough people are getting involved. The reason they cut features is because they didn't have time to write them. If people wanted more features, they should have got involved. Since to be honest, you need to know a lot about 3D graphics hardware to write a good spec like this, almost everyone who could have got involved works for a company who's a khronos member. This is different to the XFree86 situation where the people in charge were actively blocking progress. OpenGL seems to be a bunch of people who are sufficiently senior that they can go to conferences even if their companies don't really think it's worth it, and who personally care about the spec. It's not going to get anywhere until people are turning up because their companies care and want a decent spec.
If DX was made cross-platform, I bet it would be easier for game developers to target other platforms with DX.
Why haven't someone made DX for Linux?
Yes. DX9/10 is absolutely critical to M$ keeping many developers locked to M$Windows. You think they won't be trying to convince uncommitted and new developers that OpenGL is no good with lots of FUD and propaganda?
This release of a new OpenGL version is going to lead to a "marketing" onslaught - it's worth it for an unethical company like M$ to spend hundreds of thousands of dollars for this alone. Just look at how much they spent on OOXML.
Look at all the baffle-them-with-bullshit anonymous and other posters here mysteriously mod'ed up to +4 and +5, in many cases probably by sock puppets. Look at all the posts that repetitively try to imply OpenGL isn't complemented by many other libraries.
M$ has a long history of astroturfing, slashdot included and some marketing scum even like to fraudulently pretend that anonymous posting on behalf of companies is ethical.
OpenGL is perfectly adequate for the vast majority of graphics applications out there, including games, (e.g. Spore). There are already widespread complaints about game designers sacrificing gameplay for graphics. To worry about graphics minutiae now is suspect at best.
---
Beware deceptive astroturfers.
What does the GCM in the Playstation3's libgcm library actually stand for? When I see those letters the only thing that springs to mind is "Game Cube Megadrive", and that can't be right.
May I suggest to look at this explanation posted by somenone who worked on the spec. It gives a list of clues of why the API is in that state.
"nVidia had the supporting hardware first, but rather than make it an extension specific to their drivers, they implemented it and submitted it as a GL_EXT extension - one that everyone should implement. Nobody else did."
Patents?
``The developer community is generally furious, with many game developers intending to jump ship to DX10. Is this the end of cross-platform 3d on the cutting edge?''
Not as far as I am concerned. What it means to me is that we need to go looking for, creating, and rallying behind alternatives. DirectX can't be it, as it would tie us to the whims of a single vendor. OpenGL once was king, but I can't help but think it's failing. Everything I have seen starting with 2.0 has been disappointing. Besides, although I haven't really dug deeply into it, it seems to me that OpenGL's model isn't particularly good for efficient implementation in either hardware or software.
So, to kick it off, here is my wishlist:
- Standardization of a programming interface at the hardware level. How is it that there are hundreds of video card models that all provide the same functionality, but require different code to use it? Let's come up with some programming interface for a set of basic functionality, at least. So that you can put in your video card and have it work.
- Decoupling of the hardware interface from the software API. We don't have to require developers to bend over backwards to fit their program in the way the hardware works. We can have any number of different software APIs we want, and have developers pick the one that suits their program best. Eventually, this will, of course, have to be communicated to the hardware in a way the hardware understands. But exactly how the translation happens and how much of it happens in dedicated (as opposed to general-purpose) hardware need not be standardized.
Eventually, I could see a number of high-level software APIs being standardized, with hardware supporting subsets of those, in addition to the standardized base interface that all hardware supports. So you would get, for example, a low-end card supporting only the standard base hardware interface, with translation of high-level constructs from the software APIs happening in software, and a high-end card accelerating much of this translation by doing it in hardware.
Please correct me if I got my facts wrong.
As a developer I'd like to see OpenGL ES given priority over OpenGL. OpenGL ES matches the hardware much better than OpenGL does.
OpenGL itself could be implemented as a library on top of OpenGL ES. This would move all the legacy crud out of the main driver and make the jobs of driver writers a lot easier (an OpenGL ES driver is a lot smaller than an OpenGL driver).
OpenGL ES could become the basis for Linux graphics drivers instead of OpenGL (why does a window manager need all those OpenGL functions? It doesn't...)
No sig today...
There will be cake...
The cake is a lie...
Sounds more like a computer game than a graphics specification...
"Unfortunately for those of us on Linux/Mac, a lot of Windows developers don't care."
Games are different from other software in that free software isn't a good development model to make blockbusters like Fallout 3, Diablo 3, or Oblivion versus software that is "easier" like Apache, Samba, and the Linux kernel. Maybe since games depreciate?
Game developers eat food. Maslov's hierarchy of needs would put starvation over "caring" even if they did "care" about the /. cottage industry of technological egalitarianism. I think there's a disconnect here between /. and the market. Waving ad misercordium around is good and all unless you think it is going to change capitalistic decisions for throwaway software when the most profitable decision by far is DirectX. Unless you can change the economics, there's no use appealing to sentiment.
If you need text styles to communicate then you don't have a message.
.
Not to mention the fact that Apple is your only source for an OSX laptop In the OEM Windows market, any number can play.
Maybe it is time for OpenGL to be replaced. Trust me, I'm well aware that it would be an enormous burden, but with more and more graphics cards receiving free software drivers, it's more likely now then ever.
You think their products are shit? as opposed to what? obviously you have a vast knowledge on the topic. it sure would be enlightening to hear you expand on your flame. nothing linux or apple has to offer even comes close to providing an alternative. as to the OPs opinion his point is valid. why would that code base ever be ported? there is no incentive unless the platform they are on just becomes massive fail. they used to support unix back in the day. If I had one wish it would be that they open sourced r10 or something. why they would i can't answer but, it sure would be interesting to see what would happen. then you could make some "not shit" and back up that big mouth of yours...
.
But that is going to be a lot of hardware not so very far down the road.
DX10 isn't just graphics - and the first generation integrated DX10 graphics chip sets from Intel and AMD are here now.
32 Bit MS Vista -> 64 Bit Windows 7. DX10 -> DX11.
You can't let OGL slip further and further behind the versatility and performance of what will become the mass market Windows PC - and not see the guys in engineering and the sciences begin to jump ship.
Sorry for flaming. I shouldn't be a dick, even to high UIDs.
OpenGL crusties always behave like dicks whenever their beloved crufty API is questioned. I've seen it time and again, it seems to go with the territory. They like to think that they're modern experts, but in reality they're full-blown Luddites.
I think Gallium's going the right way in trying to raise the level of graphic abstraction. It will give progressive graphics programmers a clean and modern environment to use, while leaving the GL crusties to wallow in their Jurassic backwater and not waste time arguing with them.
now that worked smoother than OpenGL and 10x better than DX
Granted, there are probably large portions of the code that constitute algorithms and data structures that don't need to have GUI-specific code in them. We have all seen designs where GUI calls are dispersed in those algorithms when they can be put elsewhere.
But on the other hand, perhaps as much as half the lines of code in one of these apps has something to do with the GUI or the expression of the data into the graphical display. Suppose your target was OpenGL, but to not get too "locked down" to OpenGL, you abstracted the calls to OpenGL with some kind of wrapper. OK, now the edict comes down from the PHB to change everything over to DX10 or OpenGL 3.XXX, you say, "Piece of cake, I will just rewrite that wrapper."
Fine, but you are probably using the capabilities and perhaps quirks of OpenGL. At some deep level, you are probably tied to the way of thinking OpenGL has about how to do graphics. You have this wrapper, but is most likely one of Joel Spolsky's "leaky abstractions" of OpenGL anyway, and it may be far from trivial to adapt this wrapper to the Next Best Thing.
The other approach you can take is say, "I don't want the fortunes of my CAD/CAM program tied to OpenGL, I will only use a minimal subset of OpenGL that appears to be common to DX and some other things. I won't even wrap to some of the fancier features of OpenGL so I don't get stuck -- if I need those features, I will implement them myself." This is essentially the Sun Java-Swing approach -- they code to the absolute bare essentials of the underlying GUI on whatever platform and they implement the bulk of what a GUI and a widget rendering library needs to do, essentially reinventing what a lot of Windows-GTK-QT-Quartz does in Java code.
You can take the Java-Swing approach and indeed have API-specific code now contained to a small area. You can do this because a large area of your code is essentially your own home-brew buggy reimplementation of a lot of what is in OpenGL. Sun got a lot of criticism for Swing for the low performance for doing this, and implementing Swing I imagine was a major undertaking, but Swing exists and it has been around long enough for incremental improvement to get it to the point of usability for what a lot of people want to do with it.
But to suggest that having OpenGL calls interspersed through half of a CAD/CAM app is "bad design" is perhaps optimistic thinking regarding how cleanly such an app can be separated into modules. The whole point of OpenGL is that it is platform neutral, and that OpenGL is in fact the wrapper to the underlying graphics library on the various ports of your app. So what you are saying is that the developer of a major CAD/CAM package has to have an in-house wrapper to what is already a platform-independent graphics wrapper because use of OpenGL constitutes lock-in to a platform?
Wine will do this, eventually.
Wine uses OpenGL to do the actual rendering AFAIK, it reads the DirectX function calls, but it doesn't interface with the hardware itself, it basically just implements the functions with OpenGL calls.
By the time Wine implements a perfect DX10, maybe Gallium3D stack will be out and enable developers to easily build new API by directly interfacing the hardware using Gallium3D, instead of writing new-API-to-OpenGL wrappers.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
only an idiot would value shape over content. we would both be better off without people like you commenting anyway - its inevitable that your mishap in valuing shape over content would reflect on your world view.
Read radical news here
Most of the people complaining are not OpenGL programmers nor driver developers.
These people simply assume that the changes in the new spec are insufficient to give them that warm, fuzzy feeling inside, without comprehending what actually changed.
Perhaps the changes aren't large enough to warrant a 3.0 moniker. However, with the capability to deprecate most of the fixed-function pipeline now, we will see the slimming down of the API to a manageable size. From there, perhaps, the object-oriented redesign (where object-oriented does not imply C++, since it will most assuredly be plain C) that was originally intended will be implemented.
All problems stem from one company. Microsoft. Microsoft has been the reason that Vista's adoption is 1/2 what it was and it is the reason we have that much of an adoption as it is. What do I mean?
Microsoft is forcing vendors to sell Vista instead of XP. Microsoft is also forcing hardware vendors to implement BIOS hacks to keep transitions from Vista to XP. This is evidenced by many factors, such as the lack of available XP drivers for these new pre-fab pre-installed Vista boxes.
Keep in mind that this is not the case with custom built. Custom built machines can take XP or Vista, or any other.
I remember back a while ago about the Foxconn debacle. I think there's something similar going on here. When you attempt to install XP on various hardware that came pre-installed with Vista you can get the OS installed. But if you attempt to install drivers for those components, if you can find them, there is an almost complete failure to get these components to function.
This is not the case with all manufacturers. It is the case with Gateway and with Toshiba. Both of these manufacturers are forcing Vista installs. It may be with a few chipset packages such as the Intel GM/GL 965. But it is happening.
After a successful install of XP (after verifying that the components work under Vista) and then attempt to install say the wireless, wired, sound, SMBUS drivers, you'll get messages from the installers informing you that the devices aren't present.
You can confirm that this is a BIOS level function due to the fact that if you take a component from a machine that came pre-installed with XP and put it into the new machine where you have removed Vista and installed XP, that component's driver installer will also tell you that the device is not present, even though it was properly installed in another machine.
This clearly is an attempt by Microsoft to mandate to the manufacturers that they are not to support XP any longer even if the customer has chosen to do this on their own.
We did not have this situation when going from Win2k to XP nor from Win98 to XP. It appears to be an issue specifically with going from Vista to XP. It appears to be a bios level hack which creates the situation.
Contact with others has confirmed the situation. Many have reported that this is occuring and the consensus is that it is a mandate by Microsoft to prevent users from running XP on these older machines.
As I said, it isn't all machines. It is a new tactic being implemented on newer hardware in an attempt to force us to stay with Vista.
One has to ask why this is the case. Why on earth is Microsoft so hell bent on forcing us to Vista? Is it some hidden back door? Why would Microsoft care which OS we run given that we have paid them for Vista and paid a second time for XP? What is their motive for mandating this type of issue? Why would they dictate that the sales support for XP has been dropped so quickly?
Something is awry here.
You can lead a man with reason but you can't make him think.
Compile at install time?
One of the benefits of getting rid of the VM is to trim the app footprint down to what is needed.
VMs take forever to load.
It's too bad MS hasn't been split up yet, we might have a chance at getting cross platform .NET and DirectX.
They ARE out to get you simply because They are in it for themselves and they don't care about you.
Doesn't something have to begin in order for it to end?
I have to jump through unnecessary hoops to find dialogs.
Fuckin aye dude.
From now on I'm exchanging the name from Windows Vista to Hoops Vista.
...although Hoops95 had a better ring to it, still, there may just be MORE hoops now than there were 13 odd years ago.
---
Allow, accept, deny, cancel, unallow, undo, resubmit, proceed or uncancel?
It reminds me of doing my second degree in Computer Sceince and all the whining regarding heavy lifting with PDE/ODE and Linear Algebra where most of the dweebs suffered through during their Differential Equations, Linear Algebra and oddly Discrete Mathematics courseware.
I can see this being even more devastating for Gamers only because most of them don't have Mechanical Engineering degrees [my first degree] and they therefore don't have any true background in Statics, Dynamics, Mechanics of Materials, Machine Design, Vibration Analysis, Fracture Mechanics, Thermal Systems Design, so on and so forth.
Wah! OpenGL is being advanced to meet heavyweights across industries that need many of the application backgrounds of aforementioned classes within their simulations without always having to spend millions writing custom libraries, just for their application.
Gaming will even benefit from the resource skills of many engineers getting involved and improving the specs for applied physics and much more.
Seeing this made me smile:
SGI only downspiraled because their management refused to allow hardware to be developed for the PC - they just believed everyone would be willing to pay "UNIX prices" for UNIX hardware. After seeing 3Dfx develop hardware for the PC, SGI's engineers wanted to build a graphics accelerator board for the PC. In the end, their engineers left to form Nvidia.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
... always creates the best possible software solutions.
OpenGL can't get their crap together because they have no goals and no rewards for hitting them.
+++OK ATH
MS's documentation/sdk efforts have always been of greater quality or quantity.
Even the old mac os 7.x docs were basic.
Tho these days, google is the answer to any query.
What about consoles? PS3? Wii?
Reality is defined by the maddest person in the room
Well, on Wikipedia the OpenGL section states that Longs Peak Reloaded and Mt. Evans are improvements to OpenGL 3.0 that were planned to occur sometime after it's release.
OpenGL is open source software. It cannot be destroyed, only improved, so if developers want to help out with adding certain improvements they are more than welcome to. Apparently OpenGL 3.0 needs more work and support so that it can eventually deliver many great improvements including the ones that were hoped for.
Promote true freedom - support standards and interoperability.
I don't catch your content versus engine statement. No I disagree. Content is tied to engines. It's ephemeral.
Actually I'm thinking I have an original point here. Indirectly, because of Moore's Law computer games depreciate rapidly. As you say toolchains may not. SDL is a good example, it's free software and unlike all the stuff you see on linuxgames.com like games based on the quake3 engine it will iterate and not depreciate. Game engines do depreciate. They last about 3 years maybe. Look at the Torque Games Tribes engine. It was state of the art, they tried to start a whole indie market over it, but at the end of the day, game engines only last a few years until they get torn all the way down and started from scratch again. It's Moore's Law speeding ahead too quickly for software engineering to iterate rather than start from scratch. New stuff shows up like shaders or whatnot. I'm not a graphics guru, but I think I have the right idea here.
Games depreciate rapidly. Game engines do too, but not exactly as rapidly. Game toolsets like SDL retain value long enough for free software to succeed.
"Unfortunately, it seems they'd rather try to package up their engine and sell it."
Again, sentiment. How about trees? There's a company that sells the tree generation graphics to all the game makers, check it out. It's profitable. Self sustaining.
tl;didn't proof-read
If you need text styles to communicate then you don't have a message.
I think that about 70% of games are sold for consoles. So you can't say, "there's no point porting it for X" because you probably have to be able to target as widely as possible. In your first post you said,
These "furious developers" are probably some hobbyists, professional developers still using OpenGL are working on Macs or mobile devices and don't care about cutting-edge features since their target hardware would not support them anyways.
That is not true.
Reality is defined by the maddest person in the room
They are managing their image. Their operating systems are the most visible part of what they do as a company. They want people to view Vista as a success, because they want to be seen as a successful and thriving company. This is how most companies handle their iterative releases (make people forget about the previous iteration as quickly as possible). Evidently Microsoft is just getting more creative/abusive about it.