Well i started with DX (7!) and i really liked it, it was very easy to understand and initialize (kinda) but it was all in VB so is really easy, but now that i was threating with C++, heck DX is HARD to initialize some times, structures and classes are confusing, OpenGL is easy API, just glVertex3f(x, y, z) and that''s all, one single vertex with 1 line of code and 3 variables!

Sure OpenGL 1.1 is an Old Version of OpenGL and IT''S Anoying to check all the list of the ARB extensions (i tryed myself and i get a headche), anyway it should be cool OpenGL 2, with all ARB extensions included and everything updated for new GPUs and CPUs!

Anyway No Comments this time

W-Buffer

DrKappa: "When the same feature is implemented in two separated extensions created by two competiting manufacturers, I don''t know if I''m talking about an API anymore."

Sorry for the relatively pointless post, but that comment immediately reminded me that DX8.0 is NVIDIA''s DX, while DX8.1 is ATI''s DX.

--Buzzy

Let me start with some comments:
- Anything you can do with Direct3D can you do with OpenGL. Saying that D3D is a giant compared to OpenGL does not make sense to me.
- Direct3D was following OpenGL and not the other way around. The original D3D had some bad goals but after that was OpenGL the ideal.
- Today is the development of both D3D and OpenGL driven by the advancements in hardware.
- The rapid improvements of hardware makes the market totally different than it was 92. Cheap graphic cards is very powerfull.

The big question is how the RISC like operations will be supported in future versions of core OpenGL. I do not belive that the D3D hack to do this for the current hardware gives the best answer. It may be a good investment to let it take some time so that the alternatives can be evaluated.

The new hw will be more programmable but I do not see a future there most graphic code is done on such a low level. We will probably get the low level code from the manufacturers and others sources on the internet and use them like library functions. That may also eliminate the need for extensions.

quote:Original post by AlbertoT
"Even Direct3d, the real OpenGL competitor, is now a giant compared to what OGL is."

May be, I am not an expert.
I would ask you a simple question.
Are you able to understand which API has been used to develop a 3d game, just playing it?
My gut feeling is that direct x must have some advantages vs opengl .
It is hard for me to believe that most of professional software houses use direct x,just because of the tremendous Microsoft marketing power.
A comparison giant \ dwerf it seem to me however a bit exagerate.
A part from the above considerations it is a matter of fact that opengl is much, much, much easier to use then direct x and I am sure not to exagerate.
In conclusion the amateur \ shareware game developer comunity definitly need opengl.
I will continue using opengl 1.1 and I do hope the 3d card manufactures will support OGL even in the future

Maybe my comparison giant/dwarf is exagerated.
By the way as I said directX is omnicomrehensive, while ogl is not. Programmable GPUs and other advanced features are supported by directx, while we cannot say the same for opengl. DirectX gets updated every year, while OpenGL is still a revision of the original 1992 API (DirectX had at least 3 major improvements: version 3, 5 and 8).
The future of DirectX is shiny. XBox is a great help.
The future of OpenGl seems misty, as 3dlabs paper points out: OpenGL needs to change as soon as possible.

If it could be true that now a lot of developers are still supporting opengl, maybe directx will be more appealing when having to port games from/to xbox. When programmable gpus will be present in almost every pc used for playing games, opengl could loose other developers.
Maybe it''s not giant/dwarf today, but tomorrow? If 3dlabs distributed such a paper maybe they fear something like that.

quote:Original post by buzzy_b
DrKappa: "When the same feature is implemented in two separated extensions created by two competiting manufacturers, I don''t know if I''m talking about an API anymore."

Sorry for the relatively pointless post, but that comment immediately reminded me that DX8.0 is NVIDIA''s DX, while DX8.1 is ATI''s DX.

--Buzzy

I could be wrong, but as far as I know Microsoft creates vertex and pixel shaders specs. DX 8.0 supported version 1.1 while 8.1 supports version 1.4. To say that RADEON 8500 is the only board supporting vertex shaders 1.4 doesn''t mean DX 8.1 is ATI''s DX.
Then, the same code works on all hardware, while shaders extensions provded by ati and nvidia for opengl aren''t compatible. You have to write code twice.

quote:Original post by DrKappa

Then, the same code works on all hardware, while shaders extensions provded by ati and nvidia for opengl aren''t compatible. You have to write code twice.

As of the EXT_vertex_shader extension, there is a relatively multi-platform extension for vertex programming. Assuming you''re reffering to vertex shaders (shader has more than one definition), and also assuming that both ATI and nVidia agree to support it (which is highly likely).

what troubles me with this proposal is, like Zedzeek also said, that they arent aiming far enough.
Basically everything in there is just trying to resolve current problems, like mess with all the extensions, lack of shader language etc.
But in 1992 when OGL1.0 was finished, they looked much more far ahead. I mean where was consumer hardware that could do all that stuff in base GL then ? But we do have first iterations of hardware with programmable shaders now, so they are playing catchup game, and im afraid its not going to be enough.
For example, this proposal doesnt say anything about scenegraph or higher-order surfaces, both could potentially become hardware accelerated in very near future. Floating point framebuffers, displacement mapping and other methods of geometry compression etc... Im certain these will be included in DX as soon as hardware supports them.
In short, the presentation is a progress but it not by far sufficient to hold its own for another eight years.

"For example, this proposal doesnt say anything about scenegraph or higher-order surfaces, both could potentially become hardware accelerated in very near future."

higher-order surfaces can and should be implemented using vertex programs, and new tesselation algorithms are constantly developed.
OpenGL is a rasterizer API, so a scenegraph won''t be included.