Well ok I'll try. The most obvious difference is I wrapped most of the functions, their signatures use either seqs/strings or openarrays. For example getDroppedFiles returns seq[string] instead of a cstringArray. I prevent some extra allocations wrapping the data allocated by raylib into a CSeq type, that uses destructors.
Types now offer destructors, and that means you need to call closeWindow at the very end. Either use a try-finally / defer or create a Window object that calls closeWindow in the =destroy. I left that decision up to the user as I don't want to pollute the API with a RaylibHandle.
C enums are represented with distinct int32 since there are duplicates and also Nim's enum are not compatible with C sets. Also functions like isKeyPressed use the correct Nim types and not cint.
Type's that hold pointers like Mesh are wrapped like this that enables range checks and prevents copies. Audio and Texture data are not though since they can hold many types of data (void pointers).
You're not wrong, but as the doc say: "Note how the set turns enum values into powers of 2." It means that I could write something like this:
type
Config {.size: sizeof(int32).} = enum
Dummy
FullscreenMode
WindowResizable
WindowUndecorated
WindowTransparent
Msaa4xHint
VsyncHint
WindowHidden
WindowAlwaysRun
WindowMinimized
WindowMaximized
WindowUnfocused
WindowTopmost
WindowHighdpi
InterlacedHint = 16
Notice the dummy value and that the values are not powers of two. But then with signatures like this:
proc isWindowState*(flag: ConfigFlags): bool
proc setWindowState*(flags: Flag[ConfigFlags])
...it means there is no choice and we should use distinct ints.
It's been 8 months but it's time for a new release!
Biggest feature that naylib 1.8.0 brings is an (almost) safe rlgl wrapper and numerous improvements and fixes to the raylib and raymath wrappers. Note that it compiles only with Nim devel but help is appreciated for porting it to v1.6.10.
I am excited to see what games people are going to make with naylib!
- The written from scratch and untested on other platforms, build system was removed. Instructions for using the library are now crystal-clear. Just nimble install naylib. The only downside is, cloning the repo got slower.
- reasings ported to Nim.
- Added proper proc overloads, draw functions are more uniformly named, (no more drawRectanglePro, drawRectangleRec, etc).
- Building with WebAssembly is supported! See core/basic_window_web example.
Overall I think it's easier to use for beginners than the original raylib. Next version might add wayland support and raygui bindings...
Other changes include: error checking for the load* procs and the removal of prefixes from the enums (breaking change). I can't wait to see what you'll create with it! Cheers!
Good luck on the journey <3
You learn more and become more capable as the days go by. Soon you can build things in your mind's eye before writing a single line of code.
A little heads up, v5.1.2 is a release that tracks the upstream 5.1-dev version, it was a while since the last version and we needed a refresh.
And in this release I decided to finally remove the raylib git submodule that takes ages to clone. Now the C header files are distributed with naylib and that means the installation is faster.
I also took care of the pesky raylibDir constant that causes trouble when using emscripten in windows, so that issue should be solved.
For the future I am planning to go ahead and rewrite most of the tooling to use the nim compiler to output the wrapper, but this shouldn't concern users of the library.
Let me know if there're any bugs that were introduced with these changes.