-
-
Notifications
You must be signed in to change notification settings - Fork 911
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch from OpenTK to custom bindings or future OpenTK 4.0 #68
Comments
The OpenTK team are actually currently working on refactoring the code to make it more modular so you won't need to take stuff you don't need. |
OK good to know. |
Yes, we're currently in the work to modularize and modernize OpenTK. Adressing each one of the points in the issue, here's our current plans: 1, 2 and 3. It is our intention to make the library modular enough that if you want to target, say, OpenGL 4.6 and ES3.1, you can install those bindings and those bindings only. Furthermore, if you don't need windowing/input/etc, you simply just don't install those packages.
You can join our Discord if you want some live chatting on the topic :) |
@Nihlus Thanks for the summary, happy about the direction it's heading! If the project is alive and well, I would be happy to give the new version a try and contribute if it fits our needs. For 5 it might sound extreme, but maybe (slightly) renaming the assembly would avoid those issues (might be a good timing with all the API changes going on)? Keep up the good work! |
@xen2 OpenTK has been showing its age recently, and it is in dire need of updating. Hopefully, we'll be able to provide a product that fits both old and new user's needs. Re: 5 - Yeah, renaming the namespace and assembly has been on the table. I think it might be our only option unless Xamarin helps out. The current working branch - 4.0 - is not currently in a usable state. We're in a period of sweeping API & tooling changes (working on the binding generator right now, myself), and we are not up and running in terms of feature parity yet. |
OK, we should check back in a couple of months maybe, to see how OpenTK 4.0 is evolving. |
Thinking aloud: is is possible Vulkan could eventually replace all use-cases for the OpenGL backend and thus sidestep the issue and reduce the number of backends (as well as effectively netting us a Metal backend as well as a happy side-effect)? I could imagine a Vulkan-only backend (for Linux/next gen Android) and then leverage https://github.com/KhronosGroup/MoltenVK for the Vulkan->Metal mapping to handle MacOS/IOs. Granted this is assuming we care only about next-gen Android devices but given how quickly that market refreshes that might be reasonable? |
OpenTK is aiming to provide Vulkan bindings as well in the future. |
Thanks for that. Note Xenko today uses SharpVulkan (a pretty 'light' dep at ~100K). Perhaps there would be some other advantageous with OpenTK/Vulkan however... I am not familiar with OpenTK. Just wondering on my side if people see a future in which the OpenGL backend becomes redundant (in light of the existing Vulkan backend plus -say- MoltenVK). Or if that is a pipe-dream given the platforms Xenko wants to target or other considerations. |
@jmkinzer I really wish I could get rid of OpenGL right now too, but if we decide to still support most of Android market, it will take quite some time to be mostly Vulkan = Android 7.0+ (right now it's 44%). (even OpenGL ES 2.x (up to Android 4.2) is still 23%! But we'll get rid of that soon, I suppose most of this market segment is not gaming) |
Makes sense - I have absolutely no sense of where the android market is at so good to get some context. |
We've switched to Silk.NET, didn't we? |
Closed as not relevant anymore. |
Just like MonoGame OpenGL.cs and Veldrid OpenGLNative.cs (#59), we might want to switch to our own "single-file" custom bindings for OpenGL.
Reasons:
Note: this is definitely not high priority but wanted to write it down for later or if somebody wanted to take care of this one.
The text was updated successfully, but these errors were encountered: