[offtopic 4]
quote:
Unfortunately, OpenGL is also mired in platform independence. Platform-specific extensions, windowing kits (wgl, glx, etc) and resource acquisition methods (PFDs, etc) contradict this objective, though admittedly to a lesser extent.
This is certainly true, but I don''t think that it is totally possible to avoid those dependencies when creating a portable API. Especially, if it goes over such a wide range of software/hardware combinations as OpenGL (some of them very exotic). There will always be a platform dependend hook somewhere, the only real solution would be a standarized API hook built into every OS itself. That would change the target of interoperability: not the API would need to be made multiplatform, but the OS/architecture would need to adapt to a standard API. I don''t know if this scenario would really be a better alternative. A lot of people would object to it, for obvious reasons.
quote:
The other big problem with OpenGL''s platform independent objectives - not an integral API problem, but rather a shortcoming in the design process - is that the ARB moves slowly to update the API (which necessitated extensions in the first place, which leads to inconsistencies in syntax and functionality per platform, which contradicts the initial objective).
Hmm, every concept has it''s advantages and shortcomings. And open design brings the problem of internal consistency among different vendors, with different views of the market. IP and patents are another important factor to consider here. Although the ARB extensions could be seen as a kind of incremental API update, too few real important functionality has been standarized. This will change with OpenGL 2.0 (hopefully). On the other hand, consider when OpenGL was first introduced - graphics hardware wasn''t even capable of texture mapping at that time. I think it is still interesting to note, how well it has nevertheless managed to stay up to date with modern features. Although OpenGL 1.x has admittedly lost some of it''s open ideals in that process (NV_*, ATI_*, etc).
quote:
OpenGL is mad cool, though. If and when 2.0 hits, and if it provides solutions (or at least decent attempts at solutions) to these problems, then people like me (read: lazy programmers who don''t care about platform independence) might give it a very serious look. Until then...
You could of course use the opposite argument as well: a programmer that does not have to care about platform independence can focus it''s energy onto other parts of the project
It ultimately always depends on your goals, and target markets. And if everything goes well with the OpenGL 2.0 launch, lots of there above mentioned problems will disappear - and we are all waiting for that.
[/offtopic 4]
/ Yann
