Skip to content
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

Closed
wants to merge 4 commits into from
Closed

Opengl full #4305

wants to merge 4 commits into from

Conversation

devel0
Copy link
Contributor

@devel0 devel0 commented Jul 16, 2020

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

  • following gl.xml spec some int var should declared as uint
  • most methods have enum group
var oneArr = new int[1];
gl.GenFramebuffers(1, oneArr);
_fb = oneArr[0];
gl.BindFramebuffer(GL_FRAMEBUFFER, _fb);

becomes

var oneArr = new uint[1];
gl.GenFramebuffers(1, oneArr);
_fb = oneArr[0];                    
gl.BindFramebuffer(FramebufferTarget.GL_FRAMEBUFFER, _fb);

Fixed issues

none

@dnfadmin
Copy link

dnfadmin commented Jul 16, 2020

CLA assistant check
All CLA requirements met.

@devel0
Copy link
Contributor Author

devel0 commented Jul 16, 2020

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.
Eventually if useful I can consider to add Attributes to methods describing extension that can retrieved from gl.xml spec file.

@Gillibald
Copy link
Contributor

You are changing int to uint all over the place. I don't think that is really needed and just makes it harder to review this.

@kekekeks
Copy link
Member

kekekeks commented Jul 16, 2020

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 OpenTKControl, SilkNETControl, OpenGLNetControl working on top of OpenGLControlBase and shipped via separate NuGet packages.

@kekekeks kekekeks closed this Jul 16, 2020
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);
Copy link
Member

@kekekeks kekekeks Jul 16, 2020

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>
Copy link
Member

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

@devel0
Copy link
Contributor Author

devel0 commented Jul 16, 2020

@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.

@devel0
Copy link
Contributor Author

devel0 commented Jul 16, 2020

I wrote a PR #4310 that should fit with needs and its very essential,
Hopefully could fit with your requirements to avoid incompatibilities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants