OpenTK 5.0 TODO list

[varon]

Tasks list

• Color overloads [only needs a few manual overloads for GL.ClearColor(ColorX)
• Add typesafe gl handles.
• Fix the native method _ postfix (something is not working correctly here right now. Not sure what it is)
• Move to Opentk.Mathemathics.Half
• Write apple stuff for GLHandleARB
• Documentation for all the overloads (This probably requires a tick list by itself as we havent even started on this step yet)
• Merge master into the otk 5 branch to get all the math fixes pushed to both branches.
• Fix all warnings and FIXME's in the generator and the generated code.
• Lots of field testing
• Fix any spec errors we might find (this is reoccurring and will probably never be completed).

For future updates?

• New windowing system

Source Location

The source code for the new generator is currently located at:

https://github.com/frederikja163/opentk/tree/generator

How to contribute to the OpenTK 5.0 Bindings Generator

To help with XML issues

There are mismatches between the XML version of the spec and the official documentation.
These cause the bindings generator to generate incorrect values or less convenient types than we expect.
These issues mostly are missing metadata about how parameters and information relate to one another.

To improve this, we need to fix the upstream XML version of the spec.

Fixing XML Guide:

Using the example function: glNamedFramebufferDrawBuffers

1) Look up the OpenGL function signature in the reference documentation.

The parameters section contains the information we're concerned with.
For example, see: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glDrawBuffers.xhtml

Pay attention to the parameter listing:

framebuffer
    Specifies the name of the framebuffer object for glNamedFramebufferDrawBuffers.
n
    Specifies the number of buffers in bufs.
bufs
    Points to an array of symbolic constants specifying the buffers into which fragment colors or data values will be written.

2) Look up the OpenGL Function signature in the Khronos XML specification:

This is available here: https://raw.githubusercontent.com/KhronosGroup/OpenGL-Registry/master/xml/gl.xml
It's a huge file, so download it into a text editor and use Ctrl+F (Search) to navigate to the function you want.

We're concerned mostly with the <command> section.

at the time of writing, this looks something like this:

<command>
    <proto>void <name>glNamedFramebufferDrawBuffers</name></proto>
    <param class="framebuffer"><ptype>GLuint</ptype> <name>framebuffer</name></param>
    <param><ptype>GLsizei</ptype> <name>n</name></param>
    <param group="ColorBuffer">const <ptype>GLenum</ptype> *<name>bufs</name></param>
</command>

This is ALMOST correct, but there is no information to indicate that n corresponds to the length of the bufs array.

3) Add missing metadata:

To fix this, we need to add a len property to the bufs parameter. This tells us that the n property corresponds
to the length of the buffer pass in. This change is on the last <param> line.

<command>
    <proto>void <name>glNamedFramebufferDrawBuffers</name></proto>
    <param class="framebuffer"><ptype>GLuint</ptype> <name>framebuffer</name></param>
    <param><ptype>GLsizei</ptype> <name>n</name></param>
    <param len="n" group="ColorBuffer">const <ptype>GLenum</ptype> *<name>bufs</name></param>
</command>

4) Now, make a PR to the Khronos Repo with your changes.

This repo is available here: https://github.com/KhronosGroup/OpenGL-Registry

To help with code issues:

TODO

FAQ:

Is there any documentation on the XML tags?

Yes there is. A full PDF is available here listing all of the properties and what they mean:
https://raw.githubusercontent.com/KhronosGroup/OpenGL-Registry/master/xml/readme.pdf

[NogginBops]

To see the current status of development see this PR #1238

[NogginBops]

This issue is severely out of date, to find out the current state of OpenTK 5 have a look at the project board here: https://github.com/opentk/opentk/projects/10

[boyfriday]

Do you have a plan to be finished ?

[NogginBops]

Work on OpenTK 5 is progressing slowly.
I'm working on may things at once and because of that I don't get as much work in on OpenTK 5 as I want. There are one or more PRs open that should be merged soon, and then we can release a new preview.

[RDdevv555]

OpenTK 6.0 will come out in 2030 and 7.0 in 2050

[NogginBops]

Our unofficial motto has been "this decade" for OpenTK 5 so...
But I will say that it's getting closer, recently a lot of work was merged into OpenTK 5 so it's definitely on it's way.

[XiaofengdiZhu]

Recently, there is a pull request(glfw#2654) in glfw. It adds Android platform support. I know OpenTK uses glfw, so can OpenTK 5 supports Android completely?

[utkumaden]

This is an old issue, but I'll give you an answer just in case.

The plan for 5.x is to ship a new experimental platform abstraction layer, as well as our in house platform library. If GLFW adds Android support, then there will be OpenTK support out of the box, even if partially. Currently only the OpenGL works, and it requires you to implement GetProcAddress for the OpenGL functions on your own.

If you would like to learn more, you can talk to us in our discord server as well.