
Restrict function/enums usage based on their GL version
Posted Tuesday, 4 May, 2010 - 15:20 by kvark in(Moved from #1753: Option to drop all legacy OpenGL).
I see it as a subtask of a general problem:
restrict function/enums usage based on their GL version
This can be used for cutting of deprecated features and preventing usage of others whose requirements are not met (e.g. TransformFeedback core requires GL-3.1).
I have no idea how this can be implemented ATM.
As a possible solution to my request:
Insert an assertion (at the beginning of each function) (only for debug mode) with a version check.
The version required by the function is known at compile time. The version of the context should be known as well as user requests it in the run-time.


Comments
Re: Restrict function/enums usage based on their GL version
I don't know how feasible this is: since we don't know if a specific feature is available until runtime, we cannot prevent its usage at compile time. However, what we can do is mark which functions require which OpenGL version (this information is available in the specs) and/or try to mark which enums require which OpenGL version (this information is not available in all cases but might be possible to infer indirectly, i.e. enum Foo is used by methods X/Y/Z, so it requires min-version-of(X, Y, Z)).
OpenTK does throw exceptions for unsupported functions already:
Would the assert cover cases other than those two, above?
Re: Restrict function/enums usage based on their GL version
No, I guess, what you have is pretty enough.
Aside from this, it would be nice to have a separate GL3 namespace.
Re: Restrict function/enums usage based on their GL version
This thread reminds me of an old discussion. Nowadays the situation is a bit more complicated but some points in there still hold.
Re: Restrict function/enums usage based on their GL version
Bump.. What is the status of 1.1 and will there be core assembly without removed stuff?
I would also like to put each API into separate assembly, since I want to reduce the size of the dll's needed. OpenTK is currently 10x size of other stuff and I know it carries mostly stuff I don't use :-|