Repository navigation
OpenTK 5.0 TODO list #1207
Description
Activity
- pinned this issue
on Nov 26, 2020 To see the current status of development see this PR #1238
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
Do you have a plan to be finished ?
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.Reacted by PyroChiliarch and XiaochaoYanReacted by Juan Manuel Romero MartinOpenTK 6.0 will come out in 2030 and 7.0 in 2050
Reacted by Taein KIM, NRTnarathip, Marcin Stasiak, Diogo Gomes, ForeverFlank, Duo Li and Rico ViviersOur 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.Reacted by AstrlJelly, Octo, Anna Sas, Quinton, David Vincent Fischer, lemonchildofthelime, Diogo Gomes, ForeverFlank and Chance SnowRecently, 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?
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.
Reacted by 销锋镝铸
Tasks list
For future updates?
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:
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:
This is ALMOST correct, but there is no information to indicate that
ncorresponds to the length of thebufsarray.3) Add missing metadata:
To fix this, we need to add a
lenproperty to thebufsparameter. This tells us that thenproperty correspondsto the length of the buffer pass in. This change is on the last
<param>line.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