Ok, no more “caps”… If you wanna show your OGL2.0-compatible drivers and graphic card, you MUST complain the FULL specification. What about this? For example…
If you dont provide displacement mapping, congratulations…your graphic card IS NOT ogl2.0 compatible
I think this is good to the programmers cuz ANY ogl2.0-compatible tagged hw should expose some COMMON capabilities, not like the current “paradigm” ( that is… if device->Caps.VertexShaderVersion>1 blah blah else… ). When a new “paradigm” appears ( for example, vs/ps4.0 ), you can name it ogl2.1…
What do you think about this?
[This message has been edited by santyhammer (edited 01-29-2004).]
If you dont provide displacement mapping, congratulations…your graphic card IS NOT ogl2.0 compatible
Then name a consumer-level card that is even 1.0 compliant. Only recently have accumulation buffers existed in hardware, and we still don’t have selection buffer support.
You can’t apply “supported-in-hardware” tests for OpenGL versions. This is by design.
Originally posted by Korval: Then name a consumer-level card that is even 1.0 compliant. Only recently have accumulation buffers existed in hardware, and we still don’t have selection buffer support.
Well isn’t it time that it would be supported by hardware.
It is my oppinion that OGL2 should not be limited by backward compatibility.
Well isn’t it time that it would be supported by hardware.
Are you asking for selection buffer support to be removed from the spec, or for it to be put into hardware? The latter isn’t going to happen; there’s no desperate need for it, and it would take up too much silicon on modern consumer cards to warrent it.
Originally posted by Korval: Are you asking for selection buffer support to be removed from the spec, or for it to be put into hardware? The latter isn’t going to happen; there’s no desperate need for it, and it would take up too much silicon on modern consumer cards to warrent it.
If it’s not supported and no one uses it then why should it exist.
Useless stuff should be trown out and all the basic stuff should be required for OpenGL2 to run, like multitexturing and fragment/vertex programs.
If it’s not supported and no one uses it then why should it exist.
Because there exists OpenGL implementations that do support it? OpenGL isn’t restricted to NVIDIA/ATI, nor is it restricted to consummer-level hardware.
When a new “paradigm” appears ( for example, vs/ps4.0 ), you can name it ogl2.1…
Some alternative APIs do is this way. OpenGL does it some other way. Realisticly, you (as the coder/user) will have to do the same amount of work. The neat thing about the OGL paradigm is that new features can trickle back to old parts (VBO and ARBvp on the TNT, for example).
[This message has been edited by al_bob (edited 01-31-2004).]
The examples from the original post are from an “alternative API” project, where many features are provided only if the appropriate Caps is set. As opposed to a feature being present with a limitation, i.e. GL_MAX_LIGHTS, lights are always available in the GL, but how many is a Cap.
OpenGL does have a minimum specification for these variables: GL_MAX_LIGHTS must be at least 8; GL_MODELVIEW_STACK_DEPTH must be at least 32; GL_PROJECTION_STACK_DEPTH must be at least 2; among others. Any driver which does not provide the minimums shouldn’t be allowed to call itself compliant.
Suppose, a driver provides GL_MODELVIEW_STACK_DEPTH of 1024, but the hardware allows but a single matrix. Each push and pop to the stack is done by transferring the appropriate matrix between a software array of 1023 elements. Providing the hardware’s capability in this case, would allow a (naive) programmer to prevent a program from running because the programmer doesn’t believe it is capable enough. (So in 50 years when a CPU runs a software reference driver, in which nothing is hardware accelerated, nothing will run. (As a complaint, I have some games that required Window 98, not 98SE, because the game checked the windows version against a specific value.))
OR worse, suppose the hardware has 1024 matrix slots, but the driver only exposes 32 of them, because the driver uses the other 992 slots for private use. In this case, the hardware is more capable than the driver. So otherwise valid programs will not run correctly.
OpenGL2 drivers should have some minimum capabilities, but should try to avoid the instance where a feature is present or not depending on some value(except in the case of extensions).