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."
I think what the OpenGL ARB are doing is just right: they're introducing as part of the OpenGL standard features that the current crop of hardware vendors can support. In the case of texture shaders, I've only heard of two companies (ATI and NVidia) supporting it in their hardware. Come the time when more vendors support it, I'm sure it'll find its way in the specs.
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?
Developers now have a card vendor neutral way to access programmable shaders (pixel and vertex shaders) from DX8. But does OpenGL1.3 have anything comparable, or do we have to resort to NVidia or ATI extensions? If that is the case, OpenGL will be hard hit unless a standard vendor neutral extension it added soon.
"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."
DirectX is a great standard for 3D graphics.
I've spent many a day playing DirectX games on Linux/BSD/Macintosh/BEOS/OS2/QNX/Amiga.
Oh crap! What am I saying? DIRECTX DOESN'T SUPPORT ANYTHING NON MICROSOFT!!!
Yes that's a standard alright.
Standard piece of BS.
Who would do that? what does DHCP have to do with it? DHCP does not necessarily mean dynamic ip addresses. But, more to the point, why would you tattoe it on yer damn arm? It's perplexing to the point of not being funny.
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.
No, D3D is _only_ a gaming API. It doesn't have a selection mode as OGL has. This is extremely important for good performance in CAD like programs. So your getting crappy performance because it's done in software.
Now that we have the specs, how long before we can expect implementations that actually take advantage of them?
;)
They already do.
--
#include <malloc.h>
free(your.mind);
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
Currently I am trying to develop some software for it. It runs on machine costing $1,000,000 with 20 CPUs. (you may check this page)
Oh, you mean, make learning how to write games way more difficult than it has to be? I guess you have a point.
Hmm... Inventor was opensourced by SGI a while back. Works fine on linux. I'm actually mildly surprised it hasn't made it into the distros yet - it comes with a cool marble-maze-rolling little game, and a wierd lather-tool-thingy in the example prgrams: kept my little brother amused for hours....
Does anyone know what John Carmack thinks of this whole deal? Thanks in advance
[o]_O
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.
It should be pointed out that in DirectX, there is one standard way to do it, but if that standard doesn't exist, then it can't be done.
OpenGL is more flexible in this way. The only problem is that some things need to be migrated from vendor to multi vendor extensions faster. As soon as both Nvidea and ATI have a new feature, it is time for the Gl commitee to hammer out an initial draft for a multi vendor extension I think.
I'm a loser baby, so why don't you kill me.
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.
That makes my 2nd ed. Red Book even more obsolete. :)
-jfedor
So? If you haven't checked, anybody wishing to write software (that used D3D) in a way that is both compatible and doesn't cause any falling back to a software renderer (shudder) will still need to check for capability bits (i.e. does this platform have pixel shaders?) and have a version of the relevant rendering code for each case.
Besides, things like cubemapping and many other so-called "new features" in the 1.3 spec have been part of the de facto standard for a long time (i.e. most drivers worth using ship with them). The 1.3 spec is more like a "here you go, if you have a good enough driver you can market it as 1.3 compliant" gesture on the part of the OpenGL ARB than anything else. It only yanks the minimum supported functionality level higher; the extensions have been around for a long time.
At least in OpenGL, some of the extensions tie in cleanly with others, i.e. you don't have to change everything in order to use paletted textures (just the call to glTexImage2D, actually, and a check for the paletted texture extension [which I hope they've moved into the 1.3 spec, finally]).
Perhaps there are four times as many posts about directx because the people writing using directx are not bright enough to figure out the basics on their own?
Ahhh transgaming, another big idea with a very inactive CVS.
I play Quake 3 in 32 bit color, don't you?
That is somewhat true. However, when I set my desktop to 32bit color, where are these alpha chanels being used? Maybe if windows or linux supported truly transparent windows we would be using 32bit color, but for the most part those extra 8bits might as well be padding.
I heard somewhere that Photoshop can use a 32bit display to accelerate redraws of multilayer images (letting the hardware sort out the transparency). It would be possible using say OpenGL, but I'm not that windows will do this, even in 32bit mode. I really don't have any clue about whether or not the mac would.
I'm a loser baby, so why don't you kill me.
Because it doesn't run on MAC ? Or Linux ?
Division is multiplication. Much as subtraction is addition. And your example isn't done very well; it should be:
(120*30)/(50*2) = 36 or
(120*30/50)/2 = 36.
... (And BTW, it's hilarious)
No shit you're White. Even Blacks don't jump to their own defense the way a guilt-ridden honky like you will.
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.
Profesional gfx tools tend to be developed for commercial unix as well as windos. That means OpenGL. OpenGL also has FORTRAN and pure C bindings - so it's used for scientific visualisations, not everyone likes to code in ms-bastardized C++.
OpenGL is also designed for large triangle counts, and that's what's needed for professional work. Games, the main target of D3D, use lower poly counts, but rely on lots of texturing.
Also, gfx pros are tending towards MacOS X - which has sweet OpenGL.
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
Ummm. no one can. 32 bit color and 24 bit color both use 8 bits for red, green, and blue.
Well, and even if 32 bit used more bits for each color, 24 bit already stores more colors then us mere humans are able to see (typically).
lots of movie graphics are now done in linux as well as SGI. a much bigger market. shiznit.
Yes, and communication would be so much easier if we all just spoke English. And there would be so much more efficiency in car plants if we all drove a red Ford Taurus. And, and, and...
can't remember what pissed him off about D3D
:)
I think he started favoring OpenGL in the days of Quake 1, about the time of the appearance of the Voodoo 1. To support that card (and future accelerators, of course), he attempted to port the Quake software renderer to both OpenGL and DirectX.
He succeeded with OpenGL in a single weekend. With DirectX, however, the API at the time (DirectX 1.0? 2.0?) was crap, or it was poorly documented. So he gave up on it.
I don't really know why he still doesn't use DirectX. Maybe he's just being consistent
-----
Obviousness is always the enemy of correctness. -- Bertrand Russell
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.
I have a GeForce2 GTS 64MB DDR RAM, and I love the way Homeworld: Cataclysm looks. Everything is so smooth and beautiful.
I have 3656.9 Bogomips. How many Bogomips do you have?
And the reason ? It's the API of choice for John Carmack, the main programmer of Quake, Quake 2 and Quake 3: Arena. YES, you can find DirectInput code in Quake3, but can you find a SINGLE LINE of D3D code in ANY of games coming out of ID Software ? No chance in hell.
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 ?
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.
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...
Use HTML or something you ppl!
Slogan: Stop nVidia from blocking 3dfx completely!
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.
ARB_
EXT_
moron. learn to code before you speak.
Hahaha. And those who try to run a business without asking "Who is the market leader" end up sitting in a dark room with their Betamaxes and Amigas ranting to themselves about the injustice of it all. And then they go to their new job and ask "Do you want fries with that?"
someone who does not like that leet taco would miss the story if tiny tim did not post it, and vice versa. Duplication is not as bad as missing things.
Friends don't help friends install M$ junk.
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 ]
SDL's 3D code is just a wrapper around OpenGL for whatever platform you're using, if I'm not mistaken. So the 'future' that you point out is wrappers for OpenGL?
It's the comment from the previous story. The first reply is from the same story.
hahaha! Sure, send 10 or 20x the data down the pipeline. That'll work great on PC architecture!
3dstudio max is better in open gl not because gl is better than direct3d, but because the developers coded it better for that api. Here, the developers chose opengl, and as a result, those of us who want to use direct3d suffer.
last I checked, 3ds max 4.0 is pretty shitty in D3D. Yes, I've tried both on a GeForce 2.
MAX is soooo much better on GL. I've never tried HEIDI or other such. I wonder what Maya would run like in D3D? Not so well, I imagine.
Not everybody reads posts from all authors.
Friends don't help friends install M$ junk.
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.
OpenGL is as good if not better then Direct3D. ... quake3, doom3, tribes2.
think about it, OpenGL spec has not changed in how long and what kind of games are being produced with it?
basically all the best. im not a graphics programmer, but i think its safe to say something is good when the best choose it.
i cant seem to come up with a sig.
It's OpenGL that requires more code and causing headaches...
The only thing that can save them is by implementing Direct3D on their system to get more main-stream customers. Sucks, don't it?
http://www.berlin-consortium.org/
....
...
OpenGL, CORBA and Unicode display server
We'll all be writing 3D super life like games in Python in a while
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.
We should all keep in mind this simple truth: OpenGL is dying.
.008 percent of the graphics library delopment market. Therefore there are (7000/100)*.008 = .56 OpenGL on FreeBSD developers. This is one guy working in his spare time and consistent with the number of OpenGL on FreeBSD Usenet posts.
You don't need to be Kreskin to predict OpenGL's future. The hand writing is on the wall: OpenGL faces a bleak future. In fact there won't be any future at all for OpenGL because OpenGL is dying. Things are looking very bad for OpenGL. As many of us are already aware, OpenGL continues to lose market share. Red ink flows like a river of blood.
Let's keep to the facts and look at the numbers.
Famed OpenGL using developer Jon Carmack states that there are 7000 delopers that are users of OpenGL. How many users of DirectX are there? Let's see. The number of OpenGL versus DirectX posts on Usenet is roughly in ratio of 1 to 4. Therefore there are about 7000*5 = 35000 DirectX users. OpenGL on Linux posts on Usenet are about half of the volume of OpenGL on Windows posts. Therefore there are about 700 developers using OpenGL on Linux. A recent article put OpenGL on *BSD at about
Due to the troubles of SGI, abysmal sales and so on, SGI is getting out of the graphics business and becomming a low end intel box vendor. SGI is still dying and the corpse of OpenGL will soon be turned over to another charnel house.
All major surveys show that OpenGL has steadily declined in market share. OpenGL is very sick and its long term survival prospects are very dim. If OpenGL is to survive at all it will be among games hobbyists, dabblers, and dilettantes. OpenGL continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, OpenGL is dead.
--Shoeboy
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.
Not without OpenInventor.
Adding your own C++ wrappers around OGL blows, and most games written today use OOP. Time to move into the future. Use DirectX or SDL.
Folks, Just because you've had luck with DX8 doesn't mean it doesn't break some DX7 apps on some systems. Do a web search
Frankly, I don't need Windows or DirectX 8 to live a rich and fulfilling life. In fact, I find I'm much happier without them.
OpenGL can be used over X, and displays appropriately for the hardware you have at the recieving end. This is an important factor with any professional 3D software - not just rendering stuff, but CAD as well. If you want to run something on a big box or collaborate with others, you'll want to be able to do things remotely. I was running fairly involved stuff on an SGI Powerchallenge and displaying it on a pentium 75 box with a video card that could have been a lot better.
:)
What would be great would be team based 3D game under X that gives you little windows showing the point of view of the others on your side, just like the views from the marines's cameras in "Aliens." With OpenGL it wouldn't be too much of a hassle to export the views from each machine and re-scale them.
A very important feature would be for the screens to go to static as each team member goes down
I can run DX1 games still on Win2K/DX8 no problem.
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?
Sorry Folks, (I'm ready for the mod down)
This is not a bad thing. While this does not bode well for Linux / MAC users, it does mean good things for the majority of the game playing market -> Windows users.
Back in the day when 3dfx was the big bad daddy, developers who knew how to code for their card made the decision to only support Glide, and if they supported other APIs, they weren't done as well.
Deus Ex is probably the best example of this. It was based on the Unreal engine, which had glide as its primary API. In subsequent patches, epic fixed Unreal so that its Direct 3D played well. Ion Storm did not, and as a result, the game runs like ass on my 1.2 with 512 MB ram and GeForce 2.
Much like modem standards (remember those wars?), user interfaces (sorry, just read someones disertation on why having 12 different window managers under linux is a bad idea), it is not always a good idea to have multiple ways of doing things. If everyone supported Open GL, that would be great. However, todays hardware is written with Direct3D in mind, and it saves work for the developers, as well as making things more consistant for the end user, if everyone would just use it.
Captain_Frisk
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.)
More realistic porn action in our favorite 3d shooters :D
Join the TWIT army now!
My guess is that it's easier for people skimming the homepage of /. to read. ;-)
Except D3D is way better at what it does.
Well, it wasn't listed in the "core features" in the press release, so I doubt it.
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)
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
OpenGL is simply faaaabulous and quite obviously offers the environment only you could dream about on a 21inch monitor, and the latest NVidia card playing the all time, positively best 3D game ever concieved.
Which of course everyone on this board knows, is...
Homeworld!
:-)
You ARE the mothership when you have a 64MB Video card and a 21 inch Sony G500 monitor out there in "The Wastelands" in 4 player internet gaming mode on Won.
The tactical, combat and collaboration OpenGL gives to the game is spectacular.
Nothing is more breathtaking than to radio for Help! to your teammate while your outgunned and outnumbered as the two bastards decide to double team ya. On no! 5 Destroyers and 2 Heavy Cruisers?!! Heeeeeeeellllllllllpppp!!!
^%#@^&%#&
As your Mothership burns and the sniveling little idiots radio in, "Yeah, this guy sucks...."
Only to see them run like scared chickens duley beheaded when that moment comes....
Hyperspace Signature Detected.
No, it isn't just a frigate...
Sweet Mother of Pearl its the entire fleet!
Sweet Jesus! 3 Heavy Cruisers and 8 Destroyers comming out of Hyperspace like the calvery at 1600x1200 in 32bit Open GL mode!!!!
2 Minutes later the two assholes fleets are burning at high res and in 32bit color!
My god its its beautiful.
-hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
Tribes2 is a bomb, even the company that made it thinks it stinks. Quake 3 is nice, but I think UT on D3D is just as nice, DOOM3 ?? is it out or just being developed ?
errr....umm...*whooosh* *whoosh* Is this thing on ?
D3D is better at what it does, namely giving developers headaches, making programs require more lines of code, enriching the Microsoft empire, etc.
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".
Anyway, I personally would like to try out what you mentioned, and see if the better approach is (just between these two mind you) to calculate at the 'other' players end and it be broadcasted out. Or have each machine process it independantly. I figure it depends on the network and proc speeds and could flip between the two based on those system specs alone.
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
The bottom line, like it or not, is the great majority of PC games are targeted for Windows, so the whole portability issue is very low on the priority list for most developers. Throw that away, and what does OpenGL have that makes it superior to DX 8? Carmack embraced OpenGL out of principle and because OpenGL at the time of the original Quake was far superior to DX 3.
Stop insulting developers, especially the succesful ones. If they've done well using Direct X, good for them. If they've done well using OpenGL, good for them again. I wish MS had done the right thing way back when and embraced OpenGL, but they went their usual way, saying BS like "OpenGL is meant for high-end graphic workstations, not games". This at the same time that Quake was kicking butt. Whatever.
Most developers just aren't concerned with Linux or the Mac, or if they are, it's after they have released their title on the PC, and only then if it's successful enough to be worth porting. I don't blame them one bit for focusing on the platform that is *by far* the one that is most used by their target audience. It's called maximizing profits, and they'll use whatever tools are the best to achieve that end.