I have been playing with Latrunculi again as of late. With the contracting I have done, it has been a while since I have had the time, but here we go again. I have been working on a Common Lisp branch of Latrunculi (which can be found in Subversion under branches/clisp-branch). The reasons are several. First, there are no real bindings in Chicken to SDL or GTK. There are some half finished, sort of working ones, but I don’t really feel like writing large quantities of binding code. Secondly, I wanted to learn Common Lisp. Thirdly, the threading works, but it is a nasty mess (as is all of the graphics code). Finally, some of Common Lisp’s idioms and built in datatypes are a better match for what I am trying to do (real 2D arrays instead of vectors of vectors, anyone?). I don’t really like using large quantities of SRFI code or bindings that are not compatible with any other implementation, which is another reason that Common Lisp seems like a good choice. In Common Lisp there are fewer implementations, but even the bindings are often compatible across multiple implementations (CFFI and UFFI provide this).
One of the big goals here was to continue using OpenGL for the primary game rendering, but use SDL to load images, display text, and handle windowing. In trunk, I have written my own Targa loader (which does not implement all of the format, as I only wrote enough to load the textures for the game; which means that, when saving them, very specific options have to be set in Gimp for it to work…), created bindings for some obscure texting library (the link for which is dead and it would not have been a long term solution anyway due to its non-commercial license being in conflict with the GPL), and used GLUT for windowing and events. All in all, a mess that I want to clean up. Fortunately, bindings already exist for the libraries in which I am interested in the form of the CL-SDL project. Other goals of Latrunculi involve being cross platform (and that includes Windows) and having the ability to distribute binaries (since few users, even Linux users, compile from source). CLisp and ECL seem to be the best for this, both having Windows versions and compilers. ECL, I understand, has threading so I may use this in the end.
With this background, the task seemed rather easy: load the bindings and go. The catch is that the choice of Lisp implementation was defined primarily by the cross platform compatibility as several implementations (SBCL and CMUCL among them) offer only support for *NIX platforms. Neither CLisp nor ECL have true UFFI support. ECL has a UFFI compatible FFI layer which, on the surface, seems like it ought to make the whole thing easy. However, I have not found an easy way to make use of this feature.
So far, I can see a few possibly good ways to get this baby running:
- Make use of ECL’s UFFI compatible FFI; most likely, this would include modifying CL-SDL’s ASDF package not to depend on UFFI or to depend on ECL’s FFI package or writing some code that “aliases” ECL’s FFI to ASDF:UFFI so that everything else is happy and dandy
- Use the CLisp patches for UFFI and try to get it to run
- Use CFFI’s UFFI compatibility layer to load up the bindings and use them
This sounds harder than it really is, I think. Most likely, a lot of the problems I have are stemming from the precanned nature of using Lisp packages through Ubuntu’s repositories. I am thinking that I will probably try to do this without taking the “easy” way out and using .deb packages. Instead, I will probably try to go from source beginning to end by hand and see if I get anywhere. I wanted to post a final explanation of whatever steps I got to work, but this little outlook may solicit some reaction or, at least, serve to get my ideas out.