Just tested with Nim v 0.15 and pushed to github:
https://github.com/ngtk3/nim-chess2
Transposition table should increase playing streng remarkable -- I have not yet manage to win a game :-)
The old nim chess is still available, it consumes less ram.
Random observation: the exe size of this chess game is 35,828 bytes (with nim --d:release --opt:size and then upx -9qqq --ultra-brute) (not counting the UI dynamic libraries).
This of course is no record, but still pretty impressive, given the relative code readability, UX quality, and play strength.
Your compilation instructions would probably be nicer if, instead of depending on absolute paths and symlinks, there would be a Makefile like this:
board: board.nim engine.nim
nim c -p:../nim-gio/src -p:../nim-atk/src -p:../nim-glib/src -p:../nim-gdk3/src -p:../nim-gtk3/src \
-p:../nim-gtksourceview/src -p:../nim-gobject/src -p:../nim-cairo/src -p:../nim-cairo/src \
-p:../nim-pango/src -p:../nim-pango/src -p:../nim-gdk_pixbuf/src board.nim
So that people can simply type
make board
I can compile it on OSX, but it fails to start with
could not load: libgobject-2.0.dylib
Not sure why it tries to load that since it is GTK3. Any advice?
Thank you all for testing.
I have just fixed position values for knight vs bishop, so total value of these two is really equal in average. And I scaled the total position values, so computer may in very rare cases give away a pawn for a very good position.
@dom
So what is your advice concerning inline. And no, not all, the 3 biggest procs are not marked inline. My observation was some time ago, that inline pragma gave advantages. But I guess that was still with gcc 4.7. Do you think gcc 5.4 is smart enough, so it does not need inline hint?
@flyx
2.0 is OK indeed. For GTK3 we have indeed glib2 and even plain cairo and pango. So unfortunately it is difficult to install all my GTK3 related wrappers with nimble due to name conflicts. I am still hoping that gtk2 will die finally. But there seems some aporia users left. Appending a "3" to all my wrappers would generate more confusion, so I had to append "salewski", but that is ugly.
$ head -30 gobject.nim
{.deadCodeElim: on.}
when defined(windows):
const LIB_GOBJ* = "libgobject-2.0-0.dll"
elif defined(macosx):
const LIB_GOBJ* = "libgobject-2.0.dylib"
else:
const LIB_GOBJ* = "libgobject-2.0.so(|.0)"
So name "libgobject-2.0.dylib" is wrong for your box. But the "2" should be corret I guess. Sorry can not help yet.
Thanks for your makefile, will consider adding that to the package.
Good job, but why are you inlining every single procedure?
My observation was some time ago, that inline pragma gave advantages.
This is definitely because Nim still doesn't know about static keyword and compiler generates less effective code. This is why inline helps much.
I hope C backend will be improved in future. This is not issue, but using static for not exported procs could increase performance and produce smaller binaries.
P.S. Can I access to this and all its deps with nimble?
As Flyx reported in IRC, unfortunately this chess game does not work on mac OSX currently, lib gobject can not be loaded. For windows it may work, but installing GTK3 developer files on windows seems to be hard for some people still.
@RPG
Nimble install for GTK3 related package does not work currently due to name conflicts with legacy gtk2 packages. For Linux you may copy and paste above script and execute it in a shell, or you may try the make script from flyx above.
@Variount
Of course default gcc with -O3 gives very large executables. GCC with lto enabled can reduce size drastically, in most cases clang with lto enabled give smallest executable, which may be a bit slower. There where postings in this forum how to enable lto.
@dom concerning inline
Have just done a test with Nim 0.15 gcc 5.4 and default O3 flag.
The code as currently at gihub with all the inlines gives:
nim c -d:release board.nim # executable size: 175032 # response on e2-e4: depth 8, 9.66 seconds
with all the inlines removed:
nim c -d:release board.nim # executable size: 152768 # response on e2-e4: depth 8, 9.80 seconds
So gcc 5.4 does really a good job even without static keyword in C sources
I am not sure if Nim 0.15 or gcc 5.4 gave the improvement, but that is indded better as my early tests with gcc 4.7. So I will remove the inline pragmas soon.
On the other hand: When I take the version with all proc inlines removed, and add one inline again, for example for tiny proc baseRow which is called 4 times, executable size is reduced to 152720.
Nim chess 2 is now available in version 0.3.
https://github.com/ngtk3/nim-chess2
Memory usage is reduced by a factor of two, so that playing on a laptop with only 2 GB is really no problem. And endgame is improved, even king vs king/bishop/knight should work fine and fast now.
We need at least latest Nim v 0.15.2 because proc clear of module tables is used now.
Not much tested yet.
Version 3 is now available!
https://github.com/StefanSalewski/nim-chess3
Ram usage is reduced to about 340 MB, and I tried some other improvements.
Not much tested yet.
Nimble install is still not possible, but for Linux a copy and past of the provided instruction followed by a "bash thisScript" works.
The old versions are still available at https://github.com/ngtk3.
<shamelessSelfAdvertisement> You could write a nice 3D renderer for the game state, with this library: https://github.com/krux02/opengl-sandbox </shamelessSelfAdvertisement>
But be aware I did not define a fixed mesh format nor an .obj loader because of it. So the initial renderer would use cones and spheres etc. But it would definitively a useful project for my library that would not be too much effort to implement.
Yes, I already saw your nice OpenGl work (and also that of other Nim developers) and it would be some fun doing some OpenGl coding. But I have no experience with OpenGl yet, and playing chess with a 3D view is harder than plain 2D.
What do you think about the new Vulkan API? There was a Nim wrapper some time ago already, and there seems to be a fine tutorial at https://vulkan-tutorial.com/
I did not try Vulkan yet, but I read a lot about it. More control and so on. And a unified API for both mobile and desktop. Even more things that you can do wrong and get a black screen without feedback is not really somethign I am looking forward to. My library is trying to get exactly this part away from OpenGL. Maybe because of this, my approach would be especially helpful for Vulkan developers, but I cannot tell without actually trying it out. Also I read articles on how to get Vulkan like performance with modern OpenGL techniques. Eventually I think Vulkan is very important for GPU developers, because implementing Vulkan might be much easier than implementing OpenGL (but they already did implement OpenGL so that factor doesn't not really count at this moment). And Vulkan might be very important for the big engiens like Unreal Unity and Source. Simply an environment where money and time to develop does not matter that much if it provides more performance.
So my answer to that is, let the dust settle. Don't be the first one who jumps on Vulkan and regret it later.