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."
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! =)
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.
Until the specs support this kind of functionality.
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.
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.
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...
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
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?
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.)
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
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)
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