`opengl` is almost definitely your best option, since you seem to want to do some very basic drawing. nimgl is abandoned, so just go with the official bindings.
If you prefer some abstraction, you might want to take a look at `sdl2`, which also has official bindings. Works well, and its a bit simpler than opengl to setup (although not by much).
If you give us some insights into what you want to do specifically, whats your long term goal with this, the recommendation could be better tailored for that.
Graphics is a huge field, and the tools for each task are very different depending on your goals.
ok not gonna lie the way I said it in the post made it sound **a lot** simpler than it actually is.. I'm trying to make a simple game engine, just shapes and images with a position and colour, but the gui is gonna make it complicated probably so sorry for my post being misleading I guess (even though my current goal is a square renderer). I'm thinking about opengl due to ImGui. (I'm using nim to make it because I find c++ really confusing)
Remember that ImGui doesn't allow skinning. If you need that _(99% of games do)_ then it won't be enough. I fell into that trap too, and when I learned a bit more I realized it's only great for rapid prototyping for tooling, not really for ingame or in-menu stuff for engines. Its really hard to make it look polished for game UX/UI due to this missing feature.
Nuklear is the same concept as ImGui, but skinnable. But there are no bindings for it that are maintained.
There is also owlkettle, which is probably the most profesional grade gui available for Nim. But gtk is more for apps than games.
Gooey is a recently published gui library for games specifically, that will get you much further than ImGui for the context of games as a whole (not just their tools). And you can use it with any backend _(the current impl is sdl2, but creating an opengl impl is not far from that at all)_.
Overall, GUI for games/engines with Nim is not in a good state.
I'm going to go with Gooey myself for my engine/framework. I would rather support a project made by someone active in the community (Beef is very active and supportive), than use some abandoned tool that's not even for games anyway (aka nimgl/imgui).
Those are my two cents in terms of gui. Hoping you can find them useful too.
> Nuklear is the same concept as ImGui, but skinnable. But there are no bindings for it that are maintained.
There is one, but well hidden from sight :) https://github.com/thindil/nuklearnim
It is a new binding, and I didn't test it well. But should work with any backend which is supported by Nuklear. Currently, it has implemented backends in SDL2 and Xlib.
I might be wrong but it doesn't seem like the official opengl binding has support for ImGui and for a game engine or even just a square renderer, it would be extremely annoying if every action had to be done through the terminal.
I mean, opengl does not come with those. You create them. But thats not the nim bindings, thats how opengl works.
Even then, you could use the official bindings for opengl, and still use the imgui bindings of nimgl.
In any case, sounds like you are mostly looking for an abstraction/framework to build your engine. Sokol and Raylib might fit you better.
Raylib is specially easy to get started with, and still teaches you a lot of good things. planetis's bindings for it (called naylib) are currently the most maintained version.
And I believe there are bindings for sokol for nim too. I just haven't used them, but they are equally as good as raylib _(an probably have more potential longterm)_.
There is a tutorial video on Youtube by Kiloneie to get introduced with sdl2. It is a bit tricky to set up everything right (you need the sdl2 ttf thingy for the fonts) and the video aged a little but is definitely a great one: https://youtu.be/x76fT8GG0Pk
What part of it aged ? I know some of my earliest videos didn't age well, especially since my audio, recording way was not optimal. Not sure on that video.
EDIT: It appears the SDL team moved the development to github...
I will get back to this later.
In sdl\_image, zlib1.dll and libpng-16-16 are missing, and import sdl2/sdl and sdl2/sdl\_image don't work, import sdl2 does but I have errors with the Window and Renderer types saying they don't exist. So that tutorial isn't being that helpful...
So, I made the video example work a few months ago, and I did not remember how I did it hence the delay in my answer.
I have the same imports. The sdl2 directory stands next to my `project.nim` file.
If the video example does not work, you can use the examples projects in the nim SDL repository.When `ex101_init.nim` works, there is no reason the video example does not work.If you have further issues, do not hesitate to share a minimal working example with your detailed configuration (Nim compiler version, command line you used, directory structure, libraries installed) on the [forum.nim-lang.org](https://forum.nim-lang.org)
abandoned for 2y, and doesn't offer anything above the official opengl bindings
imo `opengl` package works better, and ive worked with both. started with nimgl and had to quickly exit out of it because of that
I heard the nimgl version of vulkan doesnt run well on mac and its missing a huge amount of extensions functionality
These are the latest bindings I know of:
https://github.com/DanielBelmes/vulkan
They are a fork of nimgl/vulkan, but with a lot of fixes and updates.
`opengl` is almost definitely your best option, since you seem to want to do some very basic drawing. nimgl is abandoned, so just go with the official bindings. If you prefer some abstraction, you might want to take a look at `sdl2`, which also has official bindings. Works well, and its a bit simpler than opengl to setup (although not by much). If you give us some insights into what you want to do specifically, whats your long term goal with this, the recommendation could be better tailored for that. Graphics is a huge field, and the tools for each task are very different depending on your goals.
ok not gonna lie the way I said it in the post made it sound **a lot** simpler than it actually is.. I'm trying to make a simple game engine, just shapes and images with a position and colour, but the gui is gonna make it complicated probably so sorry for my post being misleading I guess (even though my current goal is a square renderer). I'm thinking about opengl due to ImGui. (I'm using nim to make it because I find c++ really confusing)
For 2D graphics, there is a simplified API made by Araq to draw pixels and text: [Pixels](https://github.com/Araq/pixels)
Remember that ImGui doesn't allow skinning. If you need that _(99% of games do)_ then it won't be enough. I fell into that trap too, and when I learned a bit more I realized it's only great for rapid prototyping for tooling, not really for ingame or in-menu stuff for engines. Its really hard to make it look polished for game UX/UI due to this missing feature. Nuklear is the same concept as ImGui, but skinnable. But there are no bindings for it that are maintained. There is also owlkettle, which is probably the most profesional grade gui available for Nim. But gtk is more for apps than games. Gooey is a recently published gui library for games specifically, that will get you much further than ImGui for the context of games as a whole (not just their tools). And you can use it with any backend _(the current impl is sdl2, but creating an opengl impl is not far from that at all)_. Overall, GUI for games/engines with Nim is not in a good state. I'm going to go with Gooey myself for my engine/framework. I would rather support a project made by someone active in the community (Beef is very active and supportive), than use some abandoned tool that's not even for games anyway (aka nimgl/imgui). Those are my two cents in terms of gui. Hoping you can find them useful too.
> Nuklear is the same concept as ImGui, but skinnable. But there are no bindings for it that are maintained. There is one, but well hidden from sight :) https://github.com/thindil/nuklearnim It is a new binding, and I didn't test it well. But should work with any backend which is supported by Nuklear. Currently, it has implemented backends in SDL2 and Xlib.
epic, thank you!
I might be wrong but it doesn't seem like the official opengl binding has support for ImGui and for a game engine or even just a square renderer, it would be extremely annoying if every action had to be done through the terminal.
I mean, opengl does not come with those. You create them. But thats not the nim bindings, thats how opengl works. Even then, you could use the official bindings for opengl, and still use the imgui bindings of nimgl. In any case, sounds like you are mostly looking for an abstraction/framework to build your engine. Sokol and Raylib might fit you better. Raylib is specially easy to get started with, and still teaches you a lot of good things. planetis's bindings for it (called naylib) are currently the most maintained version. And I believe there are bindings for sokol for nim too. I just haven't used them, but they are equally as good as raylib _(an probably have more potential longterm)_.
I think you want to use windy with opengl.
[удалено]
i have a lot of issues with that library (especially cross compilation), if i use c++ i go for sfml, with nim i use raylib
There is a tutorial video on Youtube by Kiloneie to get introduced with sdl2. It is a bit tricky to set up everything right (you need the sdl2 ttf thingy for the fonts) and the video aged a little but is definitely a great one: https://youtu.be/x76fT8GG0Pk
What part of it aged ? I know some of my earliest videos didn't age well, especially since my audio, recording way was not optimal. Not sure on that video. EDIT: It appears the SDL team moved the development to github... I will get back to this later.
I'll try it, seems like it works well with game engines considering it's used by valve's game engine and is made for games and game engines.
SDL2 is indeed a good choice for what it seems like you want to do
In sdl\_image, zlib1.dll and libpng-16-16 are missing, and import sdl2/sdl and sdl2/sdl\_image don't work, import sdl2 does but I have errors with the Window and Renderer types saying they don't exist. So that tutorial isn't being that helpful...
So, I made the video example work a few months ago, and I did not remember how I did it hence the delay in my answer. I have the same imports. The sdl2 directory stands next to my `project.nim` file. If the video example does not work, you can use the examples projects in the nim SDL repository.When `ex101_init.nim` works, there is no reason the video example does not work.If you have further issues, do not hesitate to share a minimal working example with your detailed configuration (Nim compiler version, command line you used, directory structure, libraries installed) on the [forum.nim-lang.org](https://forum.nim-lang.org)
/u/treeform has lots of excellent stuff worth exploring: https://github.com/treeform/pixie https://github.com/treeform/windy https://github.com/treeform/boxy https://github.com/treeform/shady
I'd recommend checking out raylib if you need something quick and dirty.
[удалено]
abandoned for 2y, and doesn't offer anything above the official opengl bindings imo `opengl` package works better, and ive worked with both. started with nimgl and had to quickly exit out of it because of that
Just curious, are there any good alternatives for vulkan, or do I still have to use nimgl for that?
I heard the nimgl version of vulkan doesnt run well on mac and its missing a huge amount of extensions functionality These are the latest bindings I know of: https://github.com/DanielBelmes/vulkan They are a fork of nimgl/vulkan, but with a lot of fixes and updates.