Slashdot Mirror
OpenGL 1.3 Spec Released
JigSaw writes "The OpenGL Architecture Review Board announced the new OpenGL 1.3 specification (1.8 MB pdf). In OpenGL 1.3, several additional features and functions have been ratified and brought into the API's core functionality. New features include Cube map texturing, multisampling, new texture modes that provide more powerful ways of applying textures to rendered objects, compressed texture framework etc. Let's all hope that GL can catch up with Direct3D now, as with the latest DirectX8, Direct3D has done some big steps towards feature-set, speed and even non-bloatiness when it comes to coding for it, while OpenGL 1.2 was released more than 2 years ago and it did not offer as much."
Umm what ?? I have games that ran on DX5 and the run just fine under DX8. I think you may have misunderstood what someone said. In my experience as a die hard gamer DX is VERY backward compatible. Not to say that OPENGL is not good, I use OPENGL for some games and DX8 for others. It really depends on the individual performance. As a consumer MORE CHOICES IS GOOD.
errr....umm...*whooosh* *whoosh* Is this thing on ?
A lot of people without a clue will scream and cry that OpenGL is faster, easier and can do more, but frankly, if that was the case, more people would use OpenGL in the games they write. OpenGL is a nice api and I use it a lot, my library DemoGL is based on it, and if OpenGL dies it will break my heart, but when I think realisticly, OpenGL is practically dead on Windows: the ICD connector DLL (opengl32.dll) isn't updated by Microsoft, documentation SUCKS compared to D3D, and f.e. ATi's OpenGL driver is horrible, making developing OpenGL software much harder than D3D based software.
Never underestimate the relief of true separation of Religion and State.
>>Is anyone complaining?
What's interesting is your nick. See, Be people have written their OS precisely to dispose of old garbage like Unix API.
>>POSIX is perhaps the most successful OS API in history.
Notice that most OS's are not Posix compliant, not Linux, not Windows, not Mac, not Be, not Atheos, not Hurd. Full Posix compliance is hard to find.
You can copy parts of the image to a texture (glCopyTexImage/glCopyTexSubImage), which is very fast, and then map the texture to a billboard (which is fast, too). And you can use more than one texture, of course.
EagerEyes.org: Visualization and Visual Communication
GL is modular and relies on extentions. This produces a far more stable API and allows for the latest bleeding edge tech.
Comparing DX or better D3D to GL is like comparing UNIX to Windows. You can either allow modular ententions or rewrite the API every release, whus breaking backwards compatibility for no reason. GL ext from ATI and Nvidia are much easier to use for development that D3D imho.
Only moogles may disagree. We still love you dan! =)
Tell you what. Take about 5 or 6 images of the same size 32 bit RGBA, keep them fairly simple. Now mathematically blend them together in various ways, such as multiplying, adding, etc. Now look at the result. This causes an effect known as "banding" pretty easily.
Take those same graphics and convert each channel to a float between 0 and 1 and do your blends like that, clamping at 1.0 and 0.0 if necessary. When you convert back to 32 bit color, the image will probably not show the artifacts found in the simply blended version. You can achieve the same results by using a higher precision framebuffer in a 3D card, be it 64 or 128 as some people are suggesting.
While the human eye is only capible of seeing about 10 million colors (I think that's the right number?), 16.7 million plus an alpha channel isn't enough when you do too many blends simply because each blend lowers your precision.
Also GLX (or whatever Irix called it when you went between machines) was never very fast. People would always complain to me that their program was slow, and I would discover that they had accidentally rsh'ed into another machine. In some ways it would have been preferrable if it didn't work at all, so people would know immediately not to do that.
It is too bad but I would have to say this is not a selling point of OpenGL anymore.
Microsoft will support it eventually in a year, as they want DirectX more. Apple will probably have it on MacOS X by the end of the year, while Linux will be a somewhere in between.
Ahhh transgaming, another big idea with a very inactive CVS.
Until the specs support this kind of functionality.
This is hilarious. The articles are within 2 posts of each other on the developers page. LOL!
Lawrence Lessig is my personal hero.
When it comes to 3D you and everybody else can, thats because 24 bit color only has 8bit integer precision/color. With todays games evry pixel on the screen is rendered from many textures, lightmaps, bumpmaps etc. This gives errors when there only is 8 bit precisions.
John Carmack (Id software) have stated that more precicion is needed on future GFX cards.
Consider this
In floatingpoint math.
120/50*30/2 = 36
In integer math that answer would be 30 (calcing from left to right)
From what I understand the cards nowadays uses integer math.
If history is any judge in 10 years from now we will not be able to believe that we watched such crappy specs and liked them.
Gamer 1 " Good god this quake 3 is SUCH 24 bit color, how could they stand it?"
Gamer 2 "Totally!"
Papa Legba come and open the gate
That's the horrible thing in OpenGL land: you have to check out extensions, lookup what do they do, look in crappy written PDF files how to use 'em. And then find out that feature isn't implemented AT ALL on other cards. Like register combiners, or the nvidia proprietry shader extensions. If you use 'em in your code, forget it on an ATi board. It's nice nVidia's engineers thought they rule the world and have implemented the features in OpenGL anyway, but in the long run, it only hurts them: there is no consistent model for f.e. register combiner functions or vertex/pixel shaders in OpenGL: for each vendor you have to dig deep in the vendor's extensions docs. And I can tell you: that isn't funny anymore. Ever tried to look up a decent 2 page doc that describes nicely and without presentation sheets from Marketing how f.e. cubemapping has to be implemented? Thankfully there is now an ARB extensionset that does this. But don't expect from nVIdia they'll give you a nice document that describes it nice and easy. Like the d3d docs.
Never underestimate the relief of true separation of Religion and State.
Now that we have the specs, how long before we can expect implementations that actually take advantage of them?
As to this issue of Direct 3D having a bigger feature set et al., this is only a worthy argument if we are talking MS-Windows. Outside of the Windows platform Direct 3D means nothing, since it isn't available there. OpenGL is currently the only cross-platform solution worth mentioning (please correct me if there is another). IMHO, the SDL game API made the right move in using OGL for it graphics, since the last thing we need is yet another graphics API that is just about supported. Maybe one thing that will help OGL, especially in games, is if more noise was made about it.
Jumpstart the tartan drive.
But what I was trying to say is that when you a 32bit bitmap, and a 24bit bitmap, and you display them on a display set to 32 bits you will see the exact same image as if you displayed them on one set to 24 bits. Of course when you are doing image blending you ned more depth for each color, but that isn't really what's ment by 24-bit color and 32-bit color, that's just how the math is done. The bit depth of 24 or 32 bit colors means nothing to how the image is actually displayed in teh end. just as to how it's calculated if you do blending and other stuff on the way to the screen.
Thanks for the great reply.
You are right. Microsoft isn't a hardware vendor. They are a software vendor which is simply the other side of the API. There is no good argument that an API should be specified by either side, so long as it is done in consultation with the other.
I agree that using DX is trusting Microsoft to do the "right thing" by hardware companies, but I'd also argue that it is well within their interests to do just that. If they invent a spec that just sucks then they are only harming their own APIs acceptance by the game industry as a whole - hardware and ISVs. Microsoft has been very fast to incorporate the latest hardware advances in DX and to work closely with the hardware vendors to ensure they converge on an interface that is manageable and uniform.
Remember DX8 has been available to ISVs for over a year now, even long before the nVidia specs on the GF3 were available. DX certainly gives you the time advantage over OpenGL. Waiting for the ARB spec to come out isn't the best solution for a game designer who wants to get their game using the latest hardware as soon as possible. A game developer who wrote to the DX8 spec could be sure their game will have life on the top level cards produced by all hardware manufacturers simply through MS's weight in the marketplace.
I'll happily grant that the OpenGL extensions for the GF3 are going to be much more closely aligned to the hardware than DX8 pixel shaders are. I'd expect that to be the case seeing they are vendor designed extensions for their own chipset.
What it seems to come down to if you want the latest and greatest hardware support in your software (assuming you are a Windows-only designer) is to either support the latest DX and trust Microsoft to have the weight to pull the hardware designers into line (a pretty sure bet), or support OpenGL vendor extensions and hope the vendors don't change them, implement different ones or settle on a totally different ARB extension and write different code for each card you plan to support.
It makes DX very attractive if you are a Windows developer, especially given the fact you are almost certainly using other DX components to handle audio, input and force feedback.
Fear: When you see B8 00 4C CD 21 and know what it means
Microsoft says "Okay, do it this way".
>>>>>
Is this really such a *bad* thing? K & R wrote the UNIX API and said "do it this way." Is anyone complaining? IEEE standardized the API into POSIX and told people to "do it this way." POSIX is perhaps the most successful OS API in history. Somtimes, a nice standard is just better than some additional freedom (especially when that freedom is for hardware developers, which aren't highest on my ethics list).
A deep unwavering belief is a sure sign you're missing something...
3.0, as far as I know... the original story can be found from many places (here, for instance - look at the appendix in the end).
That's what ARB extensions are for.
:P
Standardized extentions which aren't necessarily part of the spec, but, they work the same accross implementations. I don't think it'll be too long before we see some sort of standardized shader extension. But then, if you have to write microcode for the vertex shaders etc. then don't you have to do that over anyways unless the cards are binary compatible with their shader processors. I don't know about you, but I wouldn't trust DirectX to take my optimized per-vertex code and translate it to a different shader language set.
...but then what do I know
Ummm. no one can. 32 bit color and 24 bit color both use 8 bits for red, green, and blue. The extra 8 bits are used for alphablening or just to align the color to something the computer can copy faster. With 3d cards the bit depth is important because of the way colors are combined with textures and all kinds of funky stuff, but after all the rendering is done 24 bit and 32 bit are exactly the same.
But the "evil" API Direct3D is already (mostly) available for Linux. Haven't you heard of trasgaming (http://www.transgaming.com/)?
They are currenly working on D3D port to WINE.
(If you don't know, their license is not fully "free", but they will make it "free" when they get enough "support".)
[ By the way, I don't think opengl will die anytime soon. Because "serious" graphics work is not only "games". have you used SGI? they do not support D3D or whatsoever ]
Give OpenGL some credit here. In some ways, it's D3D that has to catch up. Here's how it was discribed to be by a Very Smart Person who works with nVidia a lot. nVidia comes to Microsoft saying "we want these features", Microsoft says "Okay, do it this way". The engineers at nVidia get frustrated about being limited by Microsoft's model and implement new features anyway and put them in OpenGL extensions. So, D3D has a better spec (arguably), but OpenGL has access to all the features.
If you go with OpenGL you have to write your program for each different vendor extension that comes out. Honestly, what are the chances of ATI or PowerVR ever supporting NV_texture_shader or NV_texture_shader2?
I'd put the chances quite high if it's a decent spec. Perhaps it might not be called NV_texture_shader in a year's time, it'll be ARB_texture_shader, and as an ARB-mandated extension will end up being supported by every sane driver with the required hardware support. You can bet that the NVidia drivers will still support the old NV_texture_shader as well though.
This is the way the OpenGL spec grows. Manufacturers are free to go ahead and implement whatever features they'd like or need in OpenGL, and they implement them as vendor-specific extensions. If someone else needs that functionality for their driver, well, before you know it the vendor-specific extension will become ARB-mandated, and probably pored over and refined a little by all the OpenGL board in the process - a board which consists of all the major 3D hardware and software manufacturers. Shortly after, most drivers will support that. Eventually the ARB extensions will probably be integrated into the next OpenGL base spec, as just happened with OpenGL 1.3.
So, there's no one single vendor controlling the spec. 3D vendors can be as creative as they want. Only if a feature becomes used on several different 3D architectures does it become a standard. Your code will continue to run fine on architectures where you used the vendor-specific extensions, as the vendor will almost certainly keep the original functionality around indefinitely as well as supporting the ARB-mandated version of it. If you want, you can go back a little later and use the ARB extension instead in your code, and the functionality becomes available to everyone.
By using DX8 instead of OpenGL you know that effects designed for the NVidia pixel shader will magically just work on the next-generation Radeons. At the same time, you're handing over control of the whole API to Microsoft, which does not make 3D chipsets, and you're stuck with their idea of how the pixel shader ought to work, as opposed to an API for it designed by the company that makes the chipsets, and then later (if it's successful), reviewed and revised by everyone important in the industry. I won't even start on the cross-platform issues.
Your choice.
Do you even read your own site?
Je t'aime Stéphanie
NVidia OpenGL bad-ass extenstions
NVidia DX8 SDK
both contain very similar stuff you'll find i think, and I've always found OpenGL to be a better interface anyway. DX8 is night and day better than DX7 or before, but still carries a bit of the bloat around the middle that DirectX is famous for...
It still (after what about three years?) has yet to make it into WindowsNT/2000. I don't think MS is going to take this opportunity to update their ICD with all those Professional/CAD-like plane extensions that are rumored to be getting incorporated into DirectX 9.
Unfortunately, this is a bit like saying, "C++ can do anything D3D 8.X does, given proper libraries and hardware support." The purpose of a standardized API is, well, having a standard. If five different vendors implement extensions for a vertex shaders, each using five different extensions used in different ways, what's a developer to do?
Hahaha, if you believe those trolls actually produce product then I want to sell you some 'warm' land in russia. APIs don't have market share or profits. That's the problems with kids raized on MS products. They ask "Who is the marker leader?" when they should ask "Who has the best solution?".
Please grow up, before you anger the real developers.
> This is not a bad thing.
Yes it is. Instead of just writing directly to [OpenGL] api for all 3 platforms (Win32,Mac,Linux), I now have to use a wrapper (assuming you don't support consoles, which not ever game developer can/does.)
Of course most PC game developers are just using DX so this doesn't effect them AT ALL.
> it does mean good things for the majority of the game playing market
Gamers don't care which (graphics) API a game uses.
> However, todays hardware is written with Direct3D in mind,
That's not true. The GeForce cards expose more of their functionality under OpenGL then D3D.
I believe you mean "the majority of today's PC hardware have better support on D3D then OpenGL." And, yes, you are right.
The point is, though, that even if OpenGL was vanquished tomorrow, us game developers STILL have to support at LEAST *3* API's: One on PC (X-Box), PS2, and Gamecube. (X-Box is basically DX8, but I won't know 100% for sure until we get our dev boxes.)
2 of those are Carmack games. He loves GL (can't remember what pissed him off about D3D, maybe he'd like to tell us?)
Tribes2 is multi-API. So are some other biggies (Unreal Tournament comes to mind.)
APIs do have market share, and it's an ever-ascending spiral once one gets entrenched. If I want my game to take advantage of that huge installed base of nvidia and ATI cards then I write for DirectX. If I want my new video card to produce good benchmarks with popular games (and therefore sell) then I work hard on the DirectX support and windows drivers. OpenGL is just an afterthought.
In the ruthlessly Darwinist gamer/graphics market the answer to "who is the market leader" and "who has the best solution" is usually the same, as long as you consider that "best solution" does not mean "most sensible and powerful API". From a developer's point of view OpenGL may very well be better but it just isn't where the money is.
(And BTW, I am not the author of the parent to which you replied. That's a not-even-thinly-disguised recycled anti-BSD troll.)
More realistic porn action in our favorite 3d shooters :D
Join the TWIT army now!
Thanks for the info . That's very informative. Please do tell, though, what's the difference between a "spec" and a "specification" that makes it worth repeating?
Even Slashdot wants to hide some things
You apparently are missing the fine points of the term "cross-platform" as found in the Microsoft dictionary. In this context, "cross-platform" means both Win9X family and WinNT family. From what I understand, Win2k now ships with DirectX, so that makes DirectX "cross-platform".
Now that the Win9X line is scheduled to wither, and the WinNT line is to be the One True Solution with the release of WinXP, the term "cross platform" becomes irrelevant, just like "Office" without the "MS " prefix. Of course at some point in the future, "cross-platform" may need to be resurrected, with the release of the X-Box or WinCE-9.3.
On a slightly more serious vein...
The issue of "implementations that actually take advantage" crossed with OpenGL extensions that may differ from vendor to vendor is a bit of a red herring. After all, not all cards are going to have these new whiz-bang features. Someone enlighten me if Direct3D still has the accursed "capability bits" that are under-architected for telling true capabilities, and may leave a game falling back on software rendering without warning - unless the game is 'written to the cards' in the first place.
IMHO, the newest games will be written to a reasonable common denominator, then with a few extra modes, first to a "better common denominator", and finally to the full feature set of a few of the newest cards. This isn't a "write once, run on any Direct3D with the BEST eye-candy" situation by any means.
The living have better things to do than to continue hating the dead.
I have said it before (yes, an OpenGL troll), and I'll say it again: OpenGL can do anything D3D 8.x does. It just does it in a different way.
OpenGL uses extensions, so you don't have to rev the version number to add funtionality, you only have to have supporting drivers (and/or hardware).
That is why OGL hasn't been rev'ed in so long, it didn't need it, so you can provide a stable API for the developers.
It is just cleaner to have this new stuff "built-in", so they do it every now and then.
room101 -- how much can you stand before they break you?
(they always break you eventually)
Then, there's this very nice company called EpicGames. It created Unreal and Unreal Tournament (while trying to push Glide) and are now doing Unreal Warfare. These guys provide nice competition to ID Software and YES, they use Direct3D. Now take a modern computer with an NVIDIA card (chances are you already have one anyways) and play some Quake2 and Quake3...See the framerates ? OK... Now start up Unreal/UT, select D3D as the renderer and...do I really have to tell you how low will your FPS go ?
The fact is, the renderer in UT produces much better looking results than in Quake, and is designed for larger maps too. It also handles mirrors, etc. much better. It even has procedural texturing built in. So this isn't a valid comparison; UT runs slower because it does MORE. (And looks better for it)
Start-up Half-Life, the most popular online 3D FPS game at the moment (due to CS), try switching back and forth between the OpenGL and D3D renderers and compare the framerates. I know some of you are going to scream that HL is based on the Quake engine, etc, but just to let you know, only 20% of the HL engine code come from Quake.
Clue; most of that 20% is the RENDERING CODE, which is still largely OpenGL based. They have a wrapper layer between OpenGL and DirectX for the DirectX output. That's where the slowdown comes in. (For example, surfaces don't have to be decomposed into triangles in OpenGl; in DirectX they have to be... and in HalfLife, none of the surfaces are decomposed into triangles by preprocessing the data - which is why it's slower; OpenGL drivers are optimized for this kind of work... but they're doing the conversion themselves).
Simon
Coming soon - pyrogyra
Contrast this with D3D in DX8. If the hardware doesn't support acceleration of this feature, would it do it in software? If it did, would users want it? Is there a way to choose that if a feature is implemented only in software, that it not be used at all?
It depends; yes, you can tell it not to do it if you want, programmatically. But ultimately, this is why games have render engine feature options screens. So you can turn off stuff your system can't handle, or handles badly.
Of course, you have to design for it - and this is NOT a problem that is DirectX specific - the same issues also apply to OpenGl.
Simon
Coming soon - pyrogyra
why not hope GL1.3 exceeds DX8 to make it more attractive to developers. We needs these guys seeing GL as a standard they can count on. It's really a messed up situation when a proprietary API is deemed a "standard".
The problem with extensions is that at least with DX8 you can write a pixel shader program once and expect it to work on any cards that support that version of the pixel shader (1.0 if you want to be conservative).
If you go with OpenGL you have to write your program for each different vendor extension that comes out. Honestly, what are the chances of ATI or PowerVR ever supporting NV_texture_shader or NV_texture_shader2?
One of the main aims of DirectX was to avoid the situation in the days of games under DOS where a game developer would have to write different code for each different target video card. Through the use of vendor extensions, OpenGL does no better than DOS did - requiring the developer to figure out exactly which cards he is going to support and writing to those extensions individually, also sacrificing future compatibility if the next generation of cards support different extensions.
Writing to DirectX gives some degree of future-proofing your application as forward compatibility of the core API is preserved through revisions of DirectX. Sure this may carry a bit of "bloat around the middle" but that's the price you pay for compatibility.
Of course, if you aren't writing for Windows you're stuck with extensions.
Fear: When you see B8 00 4C CD 21 and know what it means
Then, there's this very nice company called EpicGames. It created Unreal and Unreal Tournament (while trying to push Glide) and are now doing Unreal Warfare. These guys provide nice competition to ID Software and YES, they use Direct3D. Now take a modern computer with an NVIDIA card (chances are you already have one anyways) and play some Quake2 and Quake3...See the framerates ? OK... Now start up Unreal/UT, select D3D as the renderer and...do I really have to tell you how low will your FPS go ?
I really wish that people like you would stop talking about things you know nothing about. Unreal Tournament is limited by the CPU, not the graphics card because it uses a slow visibility-determination-scheme that favorizes its software renderer. Remember that UT is based on Unreal which was in development long before 3D Hardware came about.
It's NOT slow because of D3D, as the next version of the engine (where this issue is fixed) will prove.
Even Carmack will tell you that.
A witty