Skip to content

Conversation

ghost
Copy link

@ghost ghost commented Apr 15, 2014

All of the OpenGL interface should now be present (symbols for 1 or 2 minor versions were missing before).
Automatic error checking has been added, and is enabled by default. This seems like a reasonable change, but it's possible to omit any additional code by defining NoGlAutoErrorCheck. enableGlAutoErrorCheck(bool) can be used to control this at run time, provided that NoGlAutoErrorCheck hasn't been defined.

I'll be documenting these changes soon.

ghost pushed a commit that referenced this pull request Apr 17, 2014
@ghost ghost merged commit cec7b4e into nim-lang:master Apr 17, 2014
@fenekku
Copy link

fenekku commented Jun 2, 2014

While waiting for the documented changes, I observed the following:

  • src/glext.nim, src/glu.nim, src/glut.nim, src/glx.nim and src/wingl.nim all still attempt to import GL which should be opengl now.
  • import opengl used to be enough to pull in data/procs from opengl.nim, glu.nim,... Now these must be imported explicitly
  • The automatic error checking makes any use of glBegin()...glEnd() raise an exception by default since checking for OpenGl errors inside these calls is invalid. To solve this one has to call enableAutoGlErrorCheck(false) initially which is bothersome work by default.
  • The definition of gluErrorUnicodeStringEXT in glu.nim raises an exception: could not import: gluErrorUnicodeStringEXT
  • All the procs that can take an array of values, e.g. glColor4ubv(v: ptr GLubyte), take a ptr. I know this is due to the translation of the original C function to Nimrod, but adding for instance proc glColor4ubv(v: TGLVectorub4)allows one to pass safe Nimrod arrays to the functions. Actually I don't know how else to pass a vector of values to such a function otherwise.
  • The ptr version of some TGL* types are missing e.g. missing definition of PGLfloat for TGLfloat.

All of these remarks are with respect to how things were when the opengl module was part of the Nimrod compiler and not on its own. I might be offbase here though as you have clearly spent more time on this than me 😉. Nevertheless I solved some of these things crudely in my fork to the point where what I wanted to do initially now works. Some of these solutions can be generalized - if they are the right ones 😁.

@ghost
Copy link
Author

ghost commented Jun 2, 2014

I think the reason why I omitted the pointer aliases was because it seems pretty certain that the convention is going away soon. I might put them back in though and maybe deprecate them at a later time.

The OpenGL spec does contain array length data in most cases, so I'll add type-safe overloads eventually, but what you need to do now if you have a seq or an array is pass the address of the first element (stuff[0].addr), or some other element if necessary.

It seems like a good idea to keep the various subsystems in separate modules, though I'm not sure if they contain all the necessary symbols. Also, I don't think they need access to any opengl symbols, so I think those imports can be omitted.

@fenekku
Copy link

fenekku commented Jun 3, 2014

Thanks for the .addr tip. The pointer convention was still used in glu.nim, that's why I mentioned it - I wasn't too sure on the status of the convention either. There are also still some cross references of types defined in opengl.nim used in other modules - glu.nim for instance.

Thanks for clarifying this.

@ghost
Copy link
Author

ghost commented Jun 3, 2014

yeah, of course. lots of types being re-used..

@ghost ghost deleted the interface-update branch May 24, 2017 16:02
This pull request was closed.
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.

1 participant