nimgl / nimgl Goto Github PK

Proper signature:

proc igPushStyleColor*(idx: ImGuiCol, col: ImVec4): void {.imgui_lib, importc: "igPushStyleColor".}

the use of assert in examples make it skip initialization code when compiled with -d:danger it should be changed to doAssert that never get skipped.

• Please tell us about your environment:
  • OS: Windows
  • Bindings: [GLFW]
  • Backend: [ C and CPP ]

Note: for support questions, please use stackoverflow or irc. This
repository's issues are reserved for feature requests and bug reports.

• I'm submitting a ...

  • bug report
  • feature request
  • support request => Please do not submit support request here, see note
    at the top of this template.

• Do you want to request a feature or report a bug?

• What is the current behavior?

• If the current behavior is a bug, please provide the steps to reproduce and
  if possible a minimal demo of the problem

• What is the expected behavior?
  GL_TIMEOUT_IGNORED
  GK_TIMEOUT_IGNORED_APPLE

should have valid values.

• What is the motivation / use case for changing the behavior?

Nim 1.0 doesn't allow uint64(0xFFFFFFFFFFFFFFFF)

Instead, used this:
GL_TIMEOUT_IGNORED*: uint64 = 0xFFFFFFFFFFFFFFFF'u64
GL_TIMEOUT_IGNORED_APPLE*: uint64 = 0xFFFFFFFFFFFFFFFF'u64

• Please tell us about your environment:

  • Version: [1.0.0 ]
  • OS: [ Windows]
  • Bindings: [ OpenGL]
  • Backend: [ C and CPP ]

• Other information (e.g. detailed explanation, stacktraces, related issues,
  suggestions how to fix, links for us to have context, eg. stackoverflow,
  docs.gl, documentation etc)

This seems an issue with Nim 1.0, with prev version was working correctly.

Testing imgui on windows with cimgui.dll built with mingw32-make.exe.

import imgui
igText("Hello World")

get below error.

Traceback (most recent call last)
c:\nim\imgui\main_imgui.nim(3) main_imgui
SIGSEGV: Illegal storage access. (Attempt to read from nil?)

I think it is related to cimgui.dll - what is best way to build this.

Hi,

VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR is missing vulkan binding, not a serious bug but vulkan validation
layer complains when it is not provided to create swapchain.

• I'm submitting a ...

  • bug report
  • feature request
  • support request => Please do not submit support request here, see note
    at the top of this template.

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Unable to compile

• If the current behavior is a bug, please provide the steps to reproduce and
  if possible a minimal demo of the problem
  I am translating the following example from the original imgui documentation to nim:
  https://github.com/ocornut/imgui/wiki/Image-Loading-and-Displaying-Examples
  (See under the section: Example for OpenGL Users)

My code:

import nimgl/imgui, nimgl/imgui/[impl_opengl, impl_glfw]
import nimgl/[opengl, glfw]
import nimgl/stb/image

proc loadImage(out_texture: var GLuint, width: var int32, height: var int32) =
  var image_width: int32 = 0
  var image_height: int32  = 0
  var image_data = stbi_load("/Users/deepakg/proj/test.png", image_width.addr, image_height.addr, nil, 4)
  echo(image_width, ",", image_height)

  var image_texture: GLuint
  glGenTextures(1, image_texture.addr)
  glBindTexture(GL_TEXTURE_2D, image_texture)
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR)
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR)


  glPixelStorei(GL_UNPACK_ROW_LENGTH, 0)
  glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, image_width, image_height, 0, GL_RGBA, GL_UNSIGNED_BYTE, image_data)
  stbi_image_free(image_data);
  width = image_width
  height = image_height
  out_texture = image_texture

  echo("Image_texture: ", image_texture)

I get a couple of compiler errors. First with:

  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR)

Error: type mismatch: got <GLenum, GLenum, GLenum>
but expected one of: 
proc glTexParameteri(target: GLenum; pname: GLenum; param: GLint): void
  first type mismatch at position: 3
  required type for param: GLint
  but expression '9729'u' is of type: GLenum

and then with:

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, image_width, image_height, 0, GL_RGBA, GL_UNSIGNED_BYTE, image_data)

 Error: type mismatch: got <GLenum, int literal(0), GLenum, int32, int32, int literal(0), GLenum, GLenum, ptr cuchar>
but expected one of: 
proc glTexImage2D(target: GLenum; level: GLint; internalformat: GLint; width: GLsizei;
                 height: GLsizei; border: GLint; format: GLenum; `type`: GLenum;
                 pixels: pointer): void
  first type mismatch at position: 3
  required type for internalformat: GLint
  but expression '6408'u' is of type: GLenum

• What is the expected behavior?
  The code should compile.

• What is the motivation / use case for changing the behavior?
  I was able to work around them by declaring a local GL_LINEAR as a GLint with value 9729 and a local GL_RGBA as a GLint with value 6408 and passing them to these functions instead.

I think that

• either GL_LINEAR/GL_RGBA need to change to GLint or
• the function signatures for glTexParameteri/glTexImage2D should accept GLenum.

• Please tell us about your environment:

  • Version: [ 1.0.0 ]
  • OS: [ MacOS ]
  • Bindings: [ OpenGL | ImGui ]
  • Backend: [ C ]
  • Nim Version: [1.0.0]

• Other information (e.g. detailed explanation, stacktraces, related issues,
  suggestions how to fix, links for us to have context, eg. stackoverflow,
  docs.gl, documentation etc)

related to cimgui/cimgui#113

Can we add the bindings for non UDT too, so we don't crash anymore ?

(We will fix windows in this case)

Vulkan bindings have wrong float sizes

for reference:
glfw/glfw@0be4f3f...master

Hi NimGL maintainers! Thanks for all of the hard work that's been poured into these bindings, especially by you @lmariscal ! They're really a huge boon to the game development community!

Having said that, I've come across a number of pretty big issues in the Vulkan and GLFW bindings that I think need addressing.

The bindings aren't correct in a number of places - for instance dispatchable handles (VkInstance, VkPhysicalDevice, etc...) should be pointers to opaque types, not sixty-four bit signed integers. You can see this if you take a look at vulkan_core.h in the VK_DEFINE_HANDLE macro or if you check out the vulkan specification it states it there too.

For non-dispatchable handles, sixty-four bit unsigned integers should be the type when the platform isn't in this list:
#if defined(__LP64__) || defined(_WIN64) || (defined(__x86_64__) && !defined(__ILP32__) ) || defined(_M_X64) || defined(__ia64) || defined (_M_IA64) || defined(__aarch64__) || defined(__powerpc64__)

And then depending on the compiler and C++ language level being compiled against, VK_NULL_HANDLE's definition varies...

The passC pragmas for vcc in glfw.nim are wrong - they use -D which is going to be ignored by vcc because vcc is really just cl.exe and cl.exe takes in compiler defines with /D.

Right now if you compile for vcc with the cpp backend, you won't even be able to get a simple example working on Nim 1.4.8 because the generated C++ is bad because the bindings are incorrect.

There are also compiler defines that are missing which are expected by GLFW according to the docs. https://www.glfw.org/docs/3.3/vulkan_guide.html#vulkan_include for instance...

I think there are a lot of issues like this spread throughout the codebase. I'd be happy to help work with you guys to identify them - but if so I think it'd be more productive if we set up a channel to communicate with somewhere instead of github issues. Happy to talk on discord or wherever... If you'd prefer I can file separate Github issues for all the issues I encounter, but to be honest I can't spend all my time trying to figure out all the places the bindings are wrong, so I would most likely just file issues for the things I'm aware of, and then continue working on my own bindings, because these are unusable for me.

One idea I just had was - I could fix the bindings themselves and then leave fixing the generator up to you guys. That or I could just give you guys a copy of my bindings once they're complete and we could do it that way too. I'm writing mine by hand as I encounter identifiers that are unresolved - but eventually I imagine they'll reach completion - it just might be around the same time my game's renderer is finished, and even then I can't promise they'll be complete :P Anywho, lmk what yall think!

Please ping me on discord (@gumber) or reply here if you'd like to chat! Happy to do so whenever :D Hope you all have a great weekend!

Hi there, currently the submodules for cimgui and glfw use ssh url. This means installing from nimble requires ssh keys need to be already setup or you receive authentication error. I think they should be changed to use https.

Hi, I've tried to no avail to use 1.0, but I get this segfault:

C:\Users\kraptor\.nimble\pkgs\nimgl-#1.0\nimgl\imgui\impl_opengl.nim(243) igOpenGL3RenderDrawData
SIGSEGV: Illegal storage access. (Attempt to read from nil?)

Offending lines are:

        if pcmd.userCallback != nil:
            pcmd.userCallback(cmd_list, pcmd.addr)

I checked the userCallbacks, and are populated and pcmd.addr is pointing to ImDrawCmd... so no idea what's going on. If I comment that line, it works but there are lots of mising text, etc.

I fixed this compile error with this PR but it is not merged to nimgl/nimgl repository.
nimgl/imgui#2

• I'm submitting a ...

  • [*] bug report
  • feature request
  • support request => Please do not submit support request here, see note
    at the top of this template.

• Do you want to request a feature or report a bug?
  bug

• What is the current behavior?
  I got compile error from backend g++ compiler

f:/project/nimgl/src/nimgl/private/cimgui/cimgui.h:1781:18: error: 'ImGuiSettingsHandler' was not declared in this scope
 1781 | typedef ImVector<ImGuiSettingsHandler> ImVector_ImGuiSettingsHandler;
      |                  ^~~~~~~~~~~~~~~~~~~~
f:/project/nimgl/src/nimgl/private/cimgui/cimgui.h:1781:38: error: template argument 1 is invalid
 1781 | typedef ImVector<ImGuiSettingsHandler> ImVector_ImGuiSettingsHandler;
      |                                      ^
f:/project/nimgl/src/nimgl/private/cimgui/cimgui.h:1783:18: error: 'ImGuiGroupData' was not declared in this scope
 1783 | typedef ImVector<ImGuiGroupData> ImVector_ImGuiGroupData;
      |                  ^~~~~~~~~~~~~~

• If the current behavior is a bug, please provide the steps to reproduce and
  if possible a minimal demo of the problem

nim cpp examples\timgui.nim

• Please tell us about your environment:

  • Version: [ 1.1.3 ]
  • OS: [ Windows]
  • Bindings: [ OpenGL | GLFW | ImGui]
  • Backend: [ CPP ]

/.nimble/pkgs/nimgl-1.0.0/nimgl/vulkan.nim(20, 3) Error: unreachable statement after 'return' statement or '{.noReturn.}' proc

OSX.

Note: for support questions, please use stackoverflow or irc. This
repository's issues are reserved for feature requests and bug reports.

• Do you want to request a feature or report a bug?
  Bug report

• What is the current behavior?
  segfaults

• If the current behavior is a bug, please provide the steps to reproduce and
  if possible a minimal demo of the problem

import nimgl/vulkan
discard vkInit()

• Please tell us about your environment:

  • Version: 1.0.0
  • OS: Linux
  • Bindings: Vulkan
  • Backend: C

• Other information (e.g. detailed explanation, stacktraces, related issues,
  suggestions how to fix, links for us to have context, eg. stackoverflow,
  docs.gl, documentation etc)

/home/kieran/.nimble/pkgs/nimgl-1.0.0/nimgl/vulkan.nim(9265) vkInit
/home/kieran/.nimble/pkgs/nimgl-1.0.0/nimgl/vulkan.nim(8694) vkLoad1_0
/home/kieran/.nimble/pkgs/nimgl-1.0.0/nimgl/vulkan.nim(29) :anonymous
SIGSEGV: Illegal storage access. (Attempt to read from nil?)

• Workaround
  deleting the line that causes the crash result = vkGetProcAddress(procName) leads to a fallback loading which works correctly.

I've updated all deps for my projects lately and found lots of crashes, due to NimGL expecting cimgui version 1.70 and I was pulling 1.71 in my build scripts.

Would be nice to update NimGL to support 1.71 if possible.

Thanks!

Trying to compile the front page green screen example results in :

Error: expression 'setKeyCallback(w, keyProc)' has no type (or is ambiguous)

With latest Nim (0.19)

• I'm submitting a ...

  • bug report
  • feature request
  • support request => Please do not submit support request here, see note
    at the top of this template.

• What is the current behavior?
  App crashes with error

• If the current behavior is a bug, please provide the steps to reproduce and
  if possible a minimal demo of the problem

  • Change assert to doassert in imgui demo ( as assert won't work in danger )
  • Run imgui demo

• Please tell us about your environment:

  • Tested both on devel and last stable nim version
  • OS: Windows
  • Bindings: ImGui
  • Backend: CPP

• Other information (e.g. detailed explanation, stacktraces, related issues,
  suggestions how to fix, links for us to have context, eg. stackoverflow,
  docs.gl, documentation etc)

\nimcache\nimglimgui_r\stdlib_system.nim.cpp: In function 'void raiseExceptionAux__na8C8pUZ9cLQWVwk35l5vfw(Exception*)':
\nimcache\nimglimgui_r\stdlib_system.nim.cpp:4215:9: error: 'e' was not declared in this scope
 4215 |   throw e;
      |         ^

CPP coverted

N_LIB_PRIVATE N_NIMCALL(void, raiseExceptionAux__na8C8pUZ9cLQWVwk35l5vfw)(Exception* e_0) {
{	{
		if (!!((localRaiseHook__EIvMhANBvB9cp2Ezvt29cADg == NIM_NIL))) goto LA3_;
{		{
			NIM_BOOL T7_ = localRaiseHook__EIvMhANBvB9cp2Ezvt29cADg(e_0);
			if (!!(T7_)) goto LA8_;
{			goto BeforeRet_;
}		}
		LA8_: ;
}	}
	LA3_: ;
	{
		if (!!((globalRaiseHook__JbO1ti4ULxrw54m4zNPbpA == NIM_NIL))) goto LA12_;
{		{
			NIM_BOOL T16_ = globalRaiseHook__JbO1ti4ULxrw54m4zNPbpA(e_0);
			if (!!(T16_)) goto LA17_;
{			goto BeforeRet_;
}		}
		LA17_: ;
}	}
	LA12_: ;
	{
		if (!(e_0 == currException__9bVPeDJlYTi9bQApZpfH8wjg)) goto LA21_;
{		throw;
}	}
	goto LA19_;
	LA21_: ;
	{
		pushCurrentException(e_0);
		throw e; // this is out of scope
	}
	LA19_: ;
	}BeforeRet_: ;
}

• I'm submitting a ...

  • bug report
  • feature request

• What is the current behavior?
  Fails to compile STB because there was a space in the path to STB (observed in the linked image). Note this occurs only when I try to import nimgl/[glfw, opengl] and nimgl installation itself was succesful.
  

• What is the expected behavior?
  That it is able to correctly use paths with spaces.

• Please tell us about your environment:

  • Version: 0.3.6
  • OS: Windows
  • Bindings: Using OpenGL and GLFW.
  • Backend: Default C

• Other information
  https://github.com/nimgl/nimgl/blob/master/src/nimgl/stb/image.nim
  I think the error is traced to line 15 of the above file, and maybe (escape) quoting the path might fix this issue.

Hijacking this issue to upload media.

Need someone who knows avoid CI.

VkColorComponentFlagBits {.size: 4.} = enum
  VK_COLOR_COMPONENT_R_BIT = 1, VK_COLOR_COMPONENT_B_BIT = 2,
  VK_COLOR_COMPONENT_A_BIT = 4

missing VK_COLOR_COMPONENT_G_BIT
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkColorComponentFlagBits.html
since its generated, i assume that other enum definitions might be broken too

I fixed it in my local copy by referencing the proper symbol:

proc igMenuItem*(label: cstring, shortcut: cstring = nil, selected: bool = false, enabled: bool = true): bool {.imgui_lib, importc: "igMenuItemBool".}

Note: for support questions, please use stackoverflow or irc. This
repository's issues are reserved for feature requests and bug reports.

• I'm submitting a ...

  • bug report
  • feature request
  • support request => Please do not submit support request here, see note
    at the top of this template.

• Do you want to request a feature or report a bug?

bug

• What is the current behavior?

Wrong function definition

• If the current behavior is a bug, please provide the steps to reproduce and
  if possible a minimal demo of the problem

The definition of glfwGetMonitors makes the function uncallable, as an UncheckedArray[T] cannot be stored directly as a var/let variable.

The current definiont of glfwMonitor should be like this, if not there is no way to call the function:

proc glfwGetMonitors(count: ptr int32): ptr UncheckedArray[GLFWMonitor] {.importc: "glfwGetMonitors", cdecl.}

Note the use of ptr

• Please tell us about your environment:

  • Version: latest
  • OS: Windows
  • Bindings: GLFW
  • Backend: CPP

• Other information (e.g. detailed explanation, stacktraces, related issues,
  suggestions how to fix, links for us to have context, eg. stackoverflow,
  docs.gl, documentation etc)

This is a technically two issues... the first is trivial to fix.

The trivial issue
Attempting to compile the included cimgui example using -d:imguiSrc=1 fails. (My understanding is this bakes cimgui into the exe so there is no need to have a shared lib)

> nim c -d:imguiSrc=1 timgui.nim
...
Error: unhandled exception: cannot open: private/cimgui/cimgui/cimgui.cpp [IOError]

This is because the path is not quite correct. Correcting this line to private/cimgui/cimgui.cpp fixes the trivial issue.

Second issue
Try to compile again with the above fix, and you get errors like this

Error: execution of an external compiler program 'gcc -c  -w -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/home/jeremy/Programming/nim/nimgl/src/nimgl/private/cimgui -DCIMGUI_DEFINE_ENUMS_AND_STRUCTS -DSTB_IMAGE_IMPLEMENTATION -I/home/jeremy/Programming/nim/nimgl/src/nimgl/stb/../private/stb -D_GLFW_X11 -g3 -O0  -I/usr/share/nim -o /home/jeremy/.cache/nim/timgui_d/nimgl_timgui.c.o /home/jeremy/.cache/nim/timgui_d/nimgl_timgui.c' failed with exit code: 1

In file included from /home/jeremy/.cache/nim/timgui_d/nimgl_timgui.c:10:
/home/jeremy/Programming/nim/nimgl/src/nimgl/imgui.nim:1653:15: error: conflicting types for ‘igShowDemoWindow’
 1653 | proc igShowDemoWindow*(p_open: ptr bool = nil): void {.imgui_lib, importc: "igShowDemoWindow".}
      |               ^~~~~~~~~~~~~~~~
/usr/share/nim/nimbase.h:186:44: note: in definition of macro ‘N_CDECL’
  186 | #    define N_CDECL(rettype, name) rettype name
      |                                            ^~~~
In file included from /home/jeremy/.cache/nim/timgui_d/nimgl_timgui.c:12:
/home/jeremy/Programming/nim/nimgl/src/nimgl/private/cimgui/cimgui.h:939:17: note: previous declaration of ‘igShowDemoWindow’ was here
  939 | CIMGUI_API void igShowDemoWindow(bool* p_open);
      |                 ^~~~~~~~~~~~~~~~

I'm not entirely sure what is going so I'm not going to try and guess. I'm pretty new to nim. I hope this can be resolved though. Thanks.

• I'm submitting a ...

  • bug report
  • feature request

• What is the current behavior?

NimGL links all these unnecessary libraries when compiling GLFW:

Excerpt from the GLFW changelog:

• If the current behavior is a bug, please provide the steps to reproduce and
  if possible a minimal demo of the problem

Just use NimGL's GLFW wrapper.

• What is the expected behavior?

NimGL should only link to libGL and maybe pthread.

• What is the motivation / use case for changing the behavior?

By linking to all the X11-related libraries we're only pulling in unnecessary hard dependencies to executables. This might prove running NimGL executables difficult on Wayland-only environments. Also, requiring users to install all of those libraries is just plain inconvenient in the long run.

• Please tell us about your environment:

  • Version: 1.1.5
  • OS: Linux
  • Bindings: GLFW

• Other information (e.g. detailed explanation, stacktraces, related issues,
  suggestions how to fix, links for us to have context, eg. stackoverflow,
  docs.gl, documentation etc)

The solution should be simple; replace the current line with this:

{.passL: "-pthread -lGL".} 

By the way, linking to libm is unnecessary as Nim links it by default.

This might be a weird one, since English isn't my native language it would be a big favor if you could let me know any language related issue. Either by making a comment in this issue or by making a PR with the fix.
Thanks!

Some identifiers use incorrect (old?) names and cannot be imported from cimgo.so, in particular I found:

• igTreeNode (cimgui library contains igTreeNodeStr and igTreeNodePtr instead)
• igTreeNodeEx
• igPushID

Hello when trying to compile the imgui sample I have the following error:

.nimble/pkgs/nimgl-0.3.5/nimgl/imgui.nim(422, 13) Error: invalid pragma: unchecked

Thanks for the lib

Note: for support questions, please use stackoverflow or irc. This
repository's issues are reserved for feature requests and bug reports.

• I'm submitting a ...

  • bug report
  • feature request
  • support request => Please do not submit support request here, see note
    at the top of this template.

• Do you want to request a feature or report a bug?
  glGenVertexArrays(1, some.addr)
  glGenBuffers(1, some.addr)

In current state you can only pass addr for one buffer/array. But in c++ you can pass also array of buffers

• What is the current behavior?
  type mismatch: got <int literal(1), ptr seq[uint32]>
  but expected one of:
  proc (n: GLsizei, arrays: ptr GLuint){.stdcall.}

• What is the expected behavior?

Possibility to pass arrays
var some = seq[uint32]
glGenVertexArrays(5, some.addr)
glGenBuffers(5, some.addr)

• Please tell us about your environment:

  • Version: [ 0.3.6 | 1.0.0 ]
  • OS: [ Linux ]
  • Bindings: [ OpenGL ]
  • Backend: [ C ]

• Other information (e.g. detailed explanation, stacktraces, related issues,
  suggestions how to fix, links for us to have context, eg. stackoverflow,
  docs.gl, documentation etc)

Translate imgui demo window from cpp to nim in order to show only nim users how it works and examples with nim data types.

First of all, my English is pretty bad. My native language is Spanish.

I have only been able to test on windows, sorry.

I have encountered a problem with Window content scale. Both the getWindowContectScale function and its callback give wrong values.

Ex:
Scale Window: x = 5.284266862267036e-315 y = 5.284266862267036e-315

This functionality is very important to me. Neither SDL nor SFML implement it well, only GLFW.

I am using your library because it is the only one that is updated and works very well.

I leave here a small code for you to check and if it is possible to solve this problem. I have tested directly in C and have no problem and it shows the correct values.

import nimgl/glfw

assert glfwInit()

var window = glfwCreateWindow(300, 300, "Test Scale Window")
window.makeContextCurrent()

proc cb_scale_window(window: GLFWWindow, xscale, yscale : float) : void {.cdecl.} =
  echo "Callback -> Scale Window: \tx = ", xscale, "\ty = ", yscale

discard window.setWindowContentScaleCallback(cb_scale_window)

var x_scale, y_scale : float

while window.windowShouldClose() == false:
    glfwWaitEvents()
    window.getWindowContentScale(addr x_scale, addr y_scale)
    echo "Loop -> Scale Window: \tx = ", x_scale, "\ty = ", y_scale
    window.swapBuffers()

I have two monitors:

• 1080p scaled to 100%
• 4K scaled to 150%

This function, especially the callback, is to report the scale that the monitor has configured when the window changes from one monitor to another.

It can be checked even if you only have one monitor.

The results of the callback should be as follows:

100% -> 1.0
125% -> 1.25
150% -> 1.5
etc.

I've also tried defining glfwDLL to use the GLFW library that I have installed in MSYS2, but the same thing happens.

GLFW official documentation for Window Content Scale: window_scale

• Version: nim 1.2.0 and nimgl 1.1.2
• OS: Windows 10 64 bits, 1909
• Binding: GLFW
• Backend: C

This helpers would help integrate users code with the binding library, also adding easier ways to communicate Nim data types.

Note: for support questions, please use stackoverflow or irc. This
repository's issues are reserved for feature requests and bug reports.

• I'm submitting a ...

  • bug report

• What is the current behavior?
  My old code used to work to get the width and height of the current screen with, but now it shows weird numbers:

var monitor = glfwGetPrimaryMonitor()
var videoMode = getVidMode(monitor)
echo videoMode.width # This shows "6945968"
echo videoMode.height # This shows "0"

So I tried using getMonitorWorkarea, but this code:

monitor = glfwGetPrimaryMonitor()
var x, y, width, height: int32
monitor.getMonitorWorkarea(x, y, width, height)

throws this error during the link stage of C compilation:

C:\...\nimcache\impulse_engine_d\@mimpulse_engine.nim.c.o:@mimpulse_engine.nim.c:(.text+0x1ebc): undefined reference to `glfwGetMonitorWorkarea'
collect2.exe: error: ld returned 1 exit status

• What is the expected behavior?
  Either the videoMode.width and videoMode.width should show the correct values or getMonitorWorkarea should compile and work as expected.

• Please tell us about your environment:

  • Version: 1.0.0
  • OS: Windows
  • Bindings: OpenGL | GLFW
  • Backend: C

I'm getting this when I try the imgui example on macOS (10.14.6):

  Verifying dependencies for [email protected]
    Reading official package list
   Checking for nimgl@>= 1.0.0
      Info: Dependency on nimgl@>= 1.0.0 already satisfied
  Verifying dependencies for [email protected]
   Building nimdsp/nimdsp using cpp backend
     Error: Build failed for package: nimdsp
        ... Details:
        ... Execution failed with exit code 1
        ... Command: "/Users/spacepluk/.nimble/bin/nim" cpp --noNimblePath -d:NimblePkgVersion=0.1.0 --path:"/Users/spacepluk/Hacking/nimgl/src"  -o:"/Users/spacepluk/Hacking/nimdsp/nimdsp" "/Users/spacepluk/Hacking/nimdsp/src/nimdsp.nim"
        ... Output: Hint: used config file '/Users/spacepluk/.choosenim/toolchains/nim-1.0.4/config/nim.cfg' [Conf]
        ... Hint: system [Processing]
        ... Hint: widestrs [Processing]
        ... Hint: io [Processing]
        ... Hint: nimdsp [Processing]
        ... Hint: imgui [Processing]
        ... Hint: strutils [Processing]
        ... Hint: parseutils [Processing]
        ... Hint: math [Processing]
        ... Hint: bitops [Processing]
        ... Hint: macros [Processing]
        ... Hint: algorithm [Processing]
        ... Hint: unicode [Processing]
        ... Hint: impl_opengl [Processing]
        ... Hint: opengl [Processing]
        ... Hint: dynlib [Processing]
        ... Hint: posix [Processing]
        ... Hint: impl_glfw [Processing]
        ... Hint: glfw [Processing]
        ... Hint: logo [Processing]
        ... Hint: native [Processing]
        ... /Users/spacepluk/Hacking/nimdsp/src/nimdsp.nim(24, 7) Hint: 'io' is declared but not used [XDeclaredButNotUsed]
        ... CC: ../../nimgl/src/nimgl/imgui/impl_opengl.nim
        ... CC: nimdsp.nim
        ... Error: execution of an external compiler program 'clang++ -c  -w -I/Users/spacepluk/Hacking/nimgl/src/nimgl/private/cimgui -DIMGUI_DISABLE_OBSOLETE_FUNCTIONS=1 -D_GLFW_COCOA -D_GLFW_USE_CHDIR -D_GLFW_USE_MENUBAR -D_GLFW_USE_RETINA -DGLFW_EXPOSE_NATIVE_COCOA -DGLFW_EXPOSE_NATIVE_NSGL  -I/Users/spacepluk/.choosenim/toolchains/nim-1.0.4/lib -I/Users/spacepluk/Hacking/nimdsp/src -o /Users/spacepluk/.cache/nim/nimdsp_d/@mnimdsp.nim.cpp.o /Users/spacepluk/.cache/nim/nimdsp_d/@mnimdsp.nim.cpp' failed with exit code: 1
        ... /Users/spacepluk/.cache/nim/nimdsp_d/@mnimdsp.nim.cpp:140:15: error: flexible array member 'Data' of type 'ImDrawChannel []' with non-trivial destruction
        ... ImDrawChannel Data[SEQ_DECL_SIZE];
        ...               ^
        ... 1 error generated.

Nim Compiler Version 1.0.4 [MacOSX: amd64]
Compiled at 2019-11-27
Copyright (c) 2006-2019 by Andreas Rumpf

git hash: c8998c498f5e2a0874846eb31309e1d1630faca6
active boot switches: -d:release

This is my first contact with nim though, so I might be doing something wrong.

Getting this error with nim devel, works after commenting out lines 361 - 365 in opengl.nim, trying to make GLenum(uint32) from negative value.

GL_NEXT_BUFFER_NV*: GLenum = GLenum(-2)
GL_SKIP_COMPONENTS4_NV*: GLenum = GLenum(-3)
GL_SKIP_COMPONENTS3_NV*: GLenum = GLenum(-4)
GL_SKIP_COMPONENTS2_NV*: GLenum = GLenum(-5)
GL_SKIP_COMPONENTS1_NV*: GLenum = GLenum(-6)

I git cloned the repo and running test.nim which imports the triangle.nim.

I think the test example is out of sync with the API, I fixed a bunch of the errors, but I am still having issues:

triangle.nim(87, 59) Error: type mismatch: got <sType: VkStructureType, queueFamilyIndex: uint32, queueCount: int literal(1), pQueuePriorities: ptr float32>
but expected one of:
proc newVkDeviceQueueCreateInfo(sType: VkStructureType = VkStructureTypeDeviceQueueCreateInfo;    
                                pNext: pointer = nil; flags: VkDeviceQueueCreateFlags = 0.VkDeviceQueueCreateFlags;
                                queueFamilyIndex: uint32; queueCount: uint32;
                                pQueuePriorities: ptr float): VkDeviceQueueCreateInfo
  first type mismatch at position: 4
  required type for pQueuePriorities: ptr float
  but expression 'pQueuePriorities = addr(queuePriority)' is of type: ptr float32

                           queueFamilyIndex = queueFamily, queueCount = 1,
                           pQueuePriorities = addr(queuePriority))

triangle.nim(87, 59) Error: type mismatch: got <int literal(-1)> but expected 'uint32'

triangle.nim(542, 41) Error: type mismatch: got <array[0..3, float32]> but expected 'array[0..3, float]

triangle.nim(587, 3) Error: undeclared identifier: 'vkPreload'

triangle.nim(589, 18) Error: type mismatch: got <VkInstance>
but expected one of:
proc vkInit(load1_0: bool = true; load1_1: bool = true): bool
  first type mismatch at position: 1
  required type for load1_0: bool
  but expression 'instance' is of type: VkInstance

expression: vkInit(instance)

• What is the current behaviour?
  Compile errors.

• Please provide the steps to reproduce and if possible a minimal demo of the problem

nim c -r .\test.nim

• What is the expected behaviour?
  I see a triangle

• Please tell us about your environment

  • Version: #head
  • OS: Windows
  • Bindings: Vulkan
  • Backend: C
  • Nim Version: [1.4.8
  • Compiler used: GCC

I'm submitting a bug report.

• What is the current behavior?
  On Linux, windows internal to an ImGui main window are jumpy when vertically resizing the top level native frame for the app. This issue also occurs in the native C++ ImGui, and is described in issue ocornut/imgui#2926.

• If the current behavior is a bug, please provide the steps to reproduce and
  if possible a minimal demo of the problem

Use the test demo. Comment out line 13,

  glfwWindowHint(GLFWResizable, GLFW_FALSE)

Try to resize the main window frame up/down.

• What is the expected behavior?

Internal window position is static/stable. I have coded a workaround based on an implementation in the ImGui issue 2926 referenced above.

• What is the motivation / use case for changing the behavior?

I would like to have resizable windows. I would be happy to generate a PR if you would like to allow the test app window to be resizable. At the very least others will see this issue and workaround. :-)

• Please tell us about your environment:

  • Version: [ 1.1.5 ]
  • OS: [ Linux ]
  • Bindings: [ ImGui ] (which uses OpenGL and GLFW)
  • Backend: [ C ]

• What is the current behaviour?

NimGL generates enums with holes, which is "unsafe".

I see 3 solutions here:

1. Disable the warnings for the modules, for now. Should work as far as those enums are used as flags.
2. Fill the enums with unknown/empty values. This is the simplest solution, to not to break compatibility but adds lots of 'fake' symbols, which is undersirable, IMHO.
3. Replace the enums that are used only as flags with constants. This breaks API compatibility if enums are used as {.pure.} enums and used as EnumType.EnumValue, instead of EnumValue. This may cause collisions, therefore prefixes for enums should be used. For example, for the ImguiHovereredFlags example, instead of ImguiHoveredFlags.AnyWindow it mus generate somthing like ighfAnyWindow.

I'm not sure what's the best solution here :(

• Please provide the steps to reproduce and if possible a minimal demo of the problem

See ImGuiHoveredFlags, for example.

• What is the expected behaviour?

Compile without warnings.

• Please tell us about your environment

  • Version: [ 1.3.2 ]
  • OS: [ Linux ]
  • Bindings: [ ImGui, but potentially any other bindings ]
  • Backend: [ C | CPP ]

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, docs.gl, documentation etc)

Building with nim, verbosity set to 1, you get:

/home/kraptor/.nimble/pkgs/nimgl-1.3.2/nimgl/imgui.nim(2748, 51) Warning: conversion to enum with holes is unsafe: ImGuiHoveredFlags(0) [HoleEnumConv]
/home/kraptor/.nimble/pkgs/nimgl-1.3.2/nimgl/imgui.nim(2748, 51) Warning: conversion to enum with holes is unsafe: ImGuiHoveredFlags(0) [HoleEnumConv]
/home/kraptor/.nimble/pkgs/nimgl-1.3.2/nimgl/imgui.nim(2816, 68) Warning: conversion to enum with holes is unsafe: ImGuiPopupFlags(0) [HoleEnumConv]

• What is the current behaviour?
  Currently VkNonDispatchableHandle is defined as being a sixty-four bit integer

• Please provide the steps to reproduce and if possible a minimal demo of the problem
  Look at vulkan.nim, line 42

• What is the expected behaviour?
  According to vulkan_core.h, lines 53-59 it should be an unsigned sixty-four bit integer when pointers aren't being used for handles:

#ifndef VK_DEFINE_NON_DISPATCHABLE_HANDLE
    #if (VK_USE_64_BIT_PTR_DEFINES==1)
        #define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef struct object##_T *object;
    #else
        #define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef uint64_t object;
    #endif
#endif

• Please tell us about your environment
  Not relevant

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, docs.gl, documentation etc)

The vulkan_core.h header makes this pretty clear that it should be a uint64 and not a int64

I solved this issue but wanted to mention it for others on Windows 10.
Have choosenim 0.4.0 installed.
Installed nimgl via nimble :
Nimble install nimgl.

Run your green window example (via VS code)
Get this error ..
.nimble\pkgs\nimgl-1.1.0\nimgl\private\glfw\src\win32_platform.h:69:20: fatal error: dinput.h: No such file or directory

To fix follow these instructions (which updates gcc version from here dom96/choosenim#129 (comment)).

Delete %userprofile%\.choosenim\toolchains\mingw32 folder
Download https://nim-lang.org/download/mingw32-6.3.0.7z
Unpack it into %userprofile%\.choosenim\toolchains\
gcc --version now prints 6.3.0

Green window example now runs.

Note: for support questions, please use stackoverflow or irc. This
repository's issues are reserved for feature requests and bug reports.

• I'm submitting a ...

  • bug report
  • feature request
  • support request => Please do not submit support request here, see note
    at the top of this template.

• What is the current behavior?
  importing nimgl throws this during compilation:

C:\...\.nimble\pkgs\nimgl-0.3.6\nimgl\opengl.nim(69, 39) Error: -1 can't be converted to uint64

• If the current behavior is a bug, please provide the steps to reproduce and
  if possible a minimal demo of the problem
  Just importing nimgl creates the error

• Please tell us about your environment:

  • Version: [ nimgl 0.3.6 | Nim 1.0.99 [Windows: amd64] ]
  • OS: [ Windows ]
  • Bindings: [ GLFW ]
  • Backend: [ C ]

• I'm submitting a ...

  • bug report
  • feature request
  • support request => Please do not submit support request here, see note
    at the top of this template.

• Do you want to request a feature or report a bug?

Feature.

I've been trying to follow along this Vulkan tutorial, but doing it all in Nim. So far it's been not bad, but the Message Callback section setup hasn't worked well for me.

Right now, this block of code doesn't compile:

proc setupDebugMessenger() =    
  if not enableValidationLayers:    
    return    
    
  let createInfo = newVkDebugUtilsMessengerCreateInfoExt(    
    sType = VkStructureTypeDebugUtilsMessengerCreateInfoExt,   #  doesn't exist in `nimgl` right now..., so I can't setup debug message callbacking
    messageSeverity = (VkDebugUtilsMessageSeverityVerboseBitExt.int or VkDebugUtilsMessageSeverityWarningBitExt.int or VkDebugUtilsMessageSeverityErrorBitExt.int).VkDebugUtilsMessageSeverityFlagsEXT,
    messageType = (VkDebugUtilsMessageTypeGeneralBitExt.int or VkDebugUtilsMessageTypePerformanceBitExt.int).VkDebugUtilsMessageTypeFlagsEXT,              # Note: validation bit doesn't exist in nimGL
    pfnUserCallback = debugCallback.PFN_vkDebugUtilsMessengerCallbackEXT,    
    pUserData = nil    
  )    

Also having to cast all of the flags to ints first to do the bitwise operations, then case them back is quite clunky. On top of that, constants/defines such as VK_TRUE/VK_TRUE don't exist, but VkBool32 is available. VK_NULL_HANDLE is another one.

• What is the current behavior?

Doesn't compile

• What is the motivation / use case for changing the behavior?

Being able to debug is nice.

• Please tell us about your environment:
  • Version: 1.1.3
  • OS: Linux
  • Bindings: Vulkan
  • Backend: C

I was able to compile my code, but not run it until I installed the LunarG Vulkan SDK. Do I maybe need to have that SDK installed first? Then when I do the nimble install nimgl, it does some system scanning and then adds stuff based on on dev. environment?

Hi,

I see that a few GLFWMonitor procedures/types are missing like:

• type GLFWvidmode
• procedure glfwGetVideoMode
• most of the other stuff from: https://www.glfw.org/docs/latest/group__monitor.html

What I need is to get the current monitor resolution, is there another to way to get this?

Thanks,
Matic

nimble install nimgl
nim c -r ng.nim //"Green Window" Example

Hint: used config file 'I:\WindowsLibrary\Terminal\nim-0.19.4\config\nim.cfg' [Conf]
Hint: system [Processing]
Hint: widestrs [Processing]
Hint: io [Processing]
Hint: ng [Processing]
Hint: glfw [Processing]
Hint: logo [Processing]
Hint: opengl [Processing]
Hint: strutils [Processing]
Hint: parseutils [Processing]
Hint: math [Processing]
Hint: bitops [Processing]
Hint: macros [Processing]
Hint: algorithm [Processing]
Hint: unicode [Processing]
Hint: dynlib [Processing]
CC: vulkan
CC: win32_init
CC: win32_joystick
CC: win32_monitor
Error: execution of an external compiler program 'gcc.exe -c -w -mno-ms-bitfields -D_GLFW_WIN32 -II:\WindowsLibrary\Terminal\nim-0.19.4\lib -II:\WindowsLibrary\Terminal\nim-0.19.4 -o C:\Users\foser\nimcache\ng_d\vulkan.c.o private/glfw/src/vulkan.c' failed with exit code: 1
gcc.exe: error: private/glfw/src/vulkan.c: No such file or directory
gcc.exe: fatal error: no input files
compilation terminated.

mb glfw not that required,

when i did:

nimble install glfw
it requires username and password
I've tried to find anything that match nim-glfw and then downloaded it

Hey there, I'm wanted to try out nimgl but I've run into the following problem compiling a simple test application with nimgl 0.3.2 from nimble! Maybe I'm holding it wrong?

$ nim c -r game.nim
Hint: used config file '/home/chr/.choosenim/toolchains/nim-0.19.4/config/nim.cfg' [Conf]
Hint: system [Processing]
Hint: game [Processing]
Hint: glfw [Processing]
Hint: logo [Processing]
Hint: image [Processing]
Hint: os [Processing]
Hint: strutils [Processing]
Hint: parseutils [Processing]
Hint: math [Processing]
Hint: bitops [Processing]
Hint: algorithm [Processing]
Hint: unicode [Processing]
Hint: times [Processing]
Hint: options [Processing]
Hint: typetraits [Processing]
Hint: strformat [Processing]
Hint: macros [Processing]
Hint: posix [Processing]
Hint: ospaths [Processing]
Hint: opengl [Processing]
CC: game
CC: stdlib_system
CC: nimgl_opengl
Hint:  [Link]
gcc: error: /home/chr/.cache/nim/game_d/vulkan.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/x11_init.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/x11_monitor.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/x11_window.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/glx_context.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/xkb_unicode.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/linux_joystick.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/posix_time.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/egl_context.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/osmesa_context.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/posix_thread.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/context.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/init.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/input.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/monitor.c.o: No such file or directory
gcc: error: /home/chr/.cache/nim/game_d/window.c.o: No such file or directory
Error: execution of an external program failed: 'gcc   -o /home/chr/dev/nimgame/game  /home/chr/.cache/nim/game_d/stb_image.c.o /home/chr/.cache/nim/game_d/vulkan.c.o /home/chr/.cache/nim/game_d/x11_init.c.o /home/chr/.cache/nim/game_d/x11_monitor.c.o /home/chr/.cache/nim/game_d/x11_window.c.o /home/chr/.cache/nim/game_d/glx_context.c.o /home/chr/.cache/nim/game_d/xkb_unicode.c.o /home/chr/.cache/nim/game_d/linux_joystick.c.o /home/chr/.cache/nim/game_d/posix_time.c.o /home/chr/.cache/nim/game_d/egl_context.c.o /home/chr/.cache/nim/game_d/osmesa_context.c.o /home/chr/.cache/nim/game_d/posix_thread.c.o /home/chr/.cache/nim/game_d/context.c.o /home/chr/.cache/nim/game_d/init.c.o /home/chr/.cache/nim/game_d/input.c.o /home/chr/.cache/nim/game_d/monitor.c.o /home/chr/.cache/nim/game_d/window.c.o /home/chr/.cache/nim/game_d/game.c.o /home/chr/.cache/nim/game_d/stdlib_system.c.o /home/chr/.cache/nim/game_d/nimgl_glfw.c.o /home/chr/.cache/nim/game_d/nimgl_logo.c.o /home/chr/.cache/nim/game_d/nimgl_image.c.o /home/chr/.cache/nim/game_d/stdlib_os.c.o /home/chr/.cache/nim/game_d/stdlib_strutils.c.o /home/chr/.cache/nim/game_d/stdlib_parseutils.c.o /home/chr/.cache/nim/game_d/stdlib_math.c.o /home/chr/.cache/nim/game_d/stdlib_bitops.c.o /home/chr/.cache/nim/game_d/stdlib_algorithm.c.o /home/chr/.cache/nim/game_d/stdlib_unicode.c.o /home/chr/.cache/nim/game_d/stdlib_times.c.o /home/chr/.cache/nim/game_d/stdlib_options.c.o /home/chr/.cache/nim/game_d/stdlib_typetraits.c.o /home/chr/.cache/nim/game_d/stdlib_strformat.c.o /home/chr/.cache/nim/game_d/stdlib_macros.c.o /home/chr/.cache/nim/game_d/stdlib_posix.c.o /home/chr/.cache/nim/game_d/stdlib_ospaths.c.o /home/chr/.cache/nim/game_d/nimgl_opengl.c.o  -lm -lrt -pthread -lGL -lX11 -lXrandr -lXxf86vm -lXi -lXcursor -lm -lXinerama   -ldl'

I'm on Ubuntu 18.10, I had to install the xorg-dev meta-package to get to this point since GLFW requires some X headers.

For reference, my test file is (pared down from the example in the README):

# Testing OpenGL stuff
#

import nimgl/glfw
import nimgl/opengl

assert glfwInit()
let w: GLFWWindow = glfwCreateWindow(800, 600, "NimGL", nil, nil)
if w == nil:
  quit(-1)

w.destroyWindow()
glfw.glfwTerminate()

• What is the current behavior?

It fails while trying to build my imgui based nim project using a nim version greater than 1.06 (I think, 1.4+ for sure)

• Please provide the steps to reproduce and if possible a minimal demo of the problem

I've yet to try the C version (I did not compile cimgui) but the CPP build returns

error: invalid argument '-std=gnu++14' not allowed with 'Objective-C'

Here is my compile command just in case some flags are missing/not supported:

nim cpp --threads:on --outdir:dist/bin -r src/mtb/bin/test_imgui.nim

• Please tell us about your environment

  • Version: 1.4.2
  • OS: MacOS
  • Bindings: OpenGL & GLFW & ImGui
  • Backend: CPP

• Other information (e.g. detailed explanation, stack traces, related issues, suggestions on how to fix, links for us to have context, eg. StackOverflow, docs.gl, documentation, etc)

Is there a way to use the metal backend I'm not sure how this could be done using Nim?

If compiled with -d:release mode nim and c compiler compiles okay but doesn't execute.

At https://github.com/lmariscal/nimgl/blob/master/src/nimgl/imgui.nim#L410 carray* {.unchecked.}[T] = array[0..0, T] doesn't work with current devel. Nim now has another way of declaring an unchecked array:
carray* [T] = UncheckedArray[T]

I'm writing an issue because I don't know if this will cause backwards compatibility to break or something like that.

at least

vkStructureTypeXlibSurfaceCreateInfoKhr
vkStructureTypeXcbSurfaceCreateInfoKhr
vkStructureTypeWaylandSurfaceCreateInfoKhr
vkStructureTypeAndroidSurfaceCreateInfoKhr
vkStructureTypeWin32SurfaceCreateInfoKhr

which is confusing because structures themselves are present, so only way to create them is to cast a number to enum.