I am working on integrating OpenGL in a Nim project while I am still learning Nim. As I am still waiting on the arrival of the book, I hope I am not asking something that is addressed in the manual but I haven't found yet (although I DO hope there is a solution of course).
But at this moment, it looks like a serious issue between the identifier equality and FFI.
glTexImage2D(GL_TEXTURE_2D.GLenum, 0.GLint, GL_RGBA32F.GLint, 512.GLsizei, 512.GLsizei, 0.GLint, GL_RGBA.GLenum, GL_FLOAT.GLenum, buf[0].addr)
(You can replace the buf[0].addr with nil if you like, result is the same)
I can't get this to compile because of the GL_FLOAT constant. In OpenGL, there is a GLfloat type and a GL_FLOAT constant and I think it is due to identifier equality in Nim that it is interpreted wrong.
If I omit the .GLenum cast on GL_FLOAT, the error message is:
Error: type mismatch
Expression: glTexImage2D(GLenum(3553'u), GLint(0), GLint(34836'u), GLsizei(512),
GLsizei(512), GLint(0), GLenum(6408'u), GLfloat, addr(buf[0]))
[1] GLenum(3553'u): GLenum
[2] GLint(0): GLint
[3] GLint(34836'u): GLint
[4] GLsizei(512): GLsizei
[5] GLsizei(512): GLsizei
[6] GLint(0): GLint
[7] GLenum(6408'u): GLenum
[8] GLfloat: typedesc[GLfloat]
[9] addr(buf[0]): ptr float32
Expected one of (first mismatch at [position]):
[8] proc glTexImage2D(target: GLenum; level: GLint; internalformat: GLint;
width: GLsizei; height: GLsizei; border: GLint;
format: GLenum; type: GLenum; pixels: pointer)
If I add the .GLenum cast:
Error: type mismatch: got 'typedesc[GLfloat]' for 'GLfloat' but expected 'GLenum = distinct uint32'
Both error messages indicate (to me... that's how I interpret it) that Nim thinks I am talking about the GLfloat type, not the GL_FLOAT constant.
Can this be solved? And how?
Should be fairly simple to solve, but first off, which bindings to you use?
Sorry, what do you mean with that question? Do you mean which imports I use? Because that's the basic opengl package installed with nimble.
If you are using this OpenGL binding, GL_FLOAT constant was renamed to cGL_FLOAT: https://github.com/nim-lang/opengl/blob/master/src/opengl/private/constants.nim#L628
Other constants that has a similar name to OpenGL type name are renamed in the same way (cGL_INT, cGL_SHORT, etc).
Oh ok, that's strange, because GL_UNSIGNED_BYTE worked, I never thought of looking for something like cGL_FLOAT. But it works, thanks! I maybe should have checked the sources first before asking here, but the errors didn't make me think that way.
It seems both GL_UNSIGNED_BYTE and cGL_UNSIGNED_BYTE are defined. Meanwhile, GL_RGBA exists, but cGL_RGBA doesn't.
A bit awkward. I totally love Nim, and I am so glad that it has FFI (it's probably a huge part of why it's so attractive), but the way we sometimes need to use it is something to abstract as quickly as possible so you never have to do it again :-).
Thanks!
However, I wonder if FFI could not be improved to solve these things. It is a bit awkward that some constants have to be renamed to solve language choices and others don't, while maybe adding a simple keyword could solve it for everything at once. Something like GL_FLOAT {.value.} and GLfloat {.type.} or something much better.
Or even a keyword to disable the Nim identifier equality for these names so that they have to be exactly as they are declared, so that GL_FLOAT {.exact.} and GLfloat {.exact.} are no longer the same in this case.
In this particular case, I could even see the FFI be smart enough to know that it should not expect a type as a parameter in the call and thus ignore GLfloat and find GL_FLOAT.
Maybe I am saying stupid things, I've only be learning Nim for a couple of days.
But like I said, I think we should be happy to have FFI at all :-)