-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Opengl full #4305
Opengl full #4305
Conversation
…lob/master/xml/gl.xml with documentation from https://github.com/KhronosGroup/OpenGL-Refpages/tree/master/gl4. Autogenerated using tool from https://github.com/devel0/netcore-sci/tree/d23959d0fba177382cd23241a6cc51a3ca3356c3/tools/gl-csharp-bindings-generator.
Another possible better solution would to use OpenGL.Net but I found the way proposed in this PR more immediate in terms of integration with current code and I haven't all the knowledge required to consider that integration; this PR effectively only extends available api methods, document and type enum for them. |
You are changing |
I'm sorry, but we can't accept that to be included in the framework itself. We have to support rendering through both OpenGL ES and desktop GL, so the idea is to have a minimum set of APIs that are present everywhere and absolutely required to get things going. Our built-in OpenGL bindings are not intended to be used outside of the framework. The only APIs that should be used by end-user apps are context management (creation, MakeCurrent) and glGetProcAddress. The rest should be done via some exiting OpenGL bindings such as Silk.NET OpenGL.Net and OpenTK. They do support working on top of pre-existing OpenGL context with custom glGetProcAddress delegate. The general plan was to provide integration shims for those bindings, so there would be |
public delegate void GlDeleteVertexArrays(int count, int[] buffers); | ||
[GlMinVersionEntryPoint("glDeleteVertexArrays", 3,0)] | ||
[GlExtensionEntryPoint("glDeleteVertexArraysOES", "GL_OES_vertex_array_object")] | ||
public delegate void GlDeleteVertexArrays(int count, uint[] buffers); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
e. g. this change just breaks the code on OSX. OSX lacks compatibility context support for 3.0+ profile, so functions that are core in 3.0 can't be called via OES-suffixed versions.
@@ -2,7 +2,7 @@ | |||
|
|||
<PropertyGroup> | |||
<IsPackable>false</IsPackable> | |||
<IsPackable Condition="'$([MSBuild]::IsOSPlatform(OSX))' == 'True'">true</IsPackable> | |||
<IsPackable Condition="'$([MSBuild]::IsOSPlatform(OSX))' == 'True' Or '$([MSBuild]::IsOSPlatform(Linux))' == 'True'">true</IsPackable> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's not, in fact, packable on Linux
@kekekeks Thanks for clarification, I totally agree with you. I would be useful to specify in the roadmap what you said here about OpenTKControl, SilkNETControl, OpenGLNetControl just to allow anyone to know directions. Consider that I wrote extension proposed in PR just for my need because I'm new to 3d and I got some trouble without having intellisense for example for a function like glPolygonMode etc, but when I did these for my need I thought that opening a PR could helpful to clarify the question about the infrastructure you described which I eager to see in operation. Thanks for the work you are forwarding about 3d control availability for the AvaloniaUI. |
I wrote a PR #4310 that should fit with needs and its very essential, |
What does the pull request do?
Full GL api as from https://github.com/KhronosGroup/OpenGL-Registry/blob/master/xml/gl.xml with documentation from https://github.com/KhronosGroup/OpenGL-Refpages/tree/master/gl4.
What is the current behavior?
in GlInterface currently there are only some of gl api available without intellisense documentation neither for parameters due to the property get instead of method declaration.
What is the updated/expected behavior with this PR?
How was the solution implemented (if it's not obvious)?
Autogenerated using tool from https://github.com/devel0/netcore-sci/tree/d23959d0fba177382cd23241a6cc51a3ca3356c3/tools/gl-csharp-bindings-generator.
Checklist
Breaking changes
becomes
Fixed issues
none