CFFI-SDL, we hardly knew you...

Yes, I'm switching to LispBuilder. Even though it doesn't say so on their homepage, it supports both SDL and OpenGL. Just grab it from the svn repo and enjoy.

I've forwarded them my fixes to get it going on the mac, and it runs just fine. Here's the classic gears example for your viewing pleasure:

Even better, there is also a Cal3D binding. A friend of mine, Randy Voet, is having a go at creating some player models for me. If all goes well that means I can skip forward to the next step sooner than expected. If not, I'll have to see what I can do to get the Cal3D models going.

lispbuilder-sdl

I recently got a comment from Luke J. Crook that I should check out, among others, lispbuilder-sdl. Well, I just did, and it seems to work great on my mac (some notes further down).

Lispbuilder-sdl seems to cover pretty much everything I need from SDL, except for the OpenGL stuff. But I will try and see if I can not just use my own OpenGL binding in conjunction with lispbuilder-sdl. My guess is that this should work just fine. If that's the case, then my cffi-sdl project becomes quite pointless, and I'll just offer the lispbuilder guys a copy of my opengl binding for them to include.

A note if you're trying to install lispbuilder-sdl on your mac: I had to modify two things first. One is the cocoa-helper code which didn't find the SDL header on the system. That required a small fix in both the Makefile and the source code. Second was the loading of SDL by CFFI, which couldn't find the library. This is because I installed SDL through Fink, which places it under /sw/lib/. So I added that to the lookup path in the right way, and then everything was just fine.

So once again it seems that most of my work was quite spurious, but hey, live and learn. :-)

Procrastinating

I'm trying to decide what to do next. At the moment I don't feel like doing BSP, MD3 or whatever just for the heck of it. I'd prefer to do the next coding with much more of a purpose, and I'm trying to figure out what that will be.

On a related note (though perhaps not very obviously so), any 3D modelers out there who might be interested in teaming up ? Let me know.

CFFI-SDL now at SourceForge

From today on you can find the code for my SDL binding at SourceForge under a BSD license. The project page is here. (I'll work on a real webpage at a later time.) Here's a quick reminder of what it does:

CFFI-SDL provides a CFFI-binding between Lisp and the Simple Directmedia Layer (SDL). It is similar in scope to CL-SDL, but differs in two main ways:

• CFFI-SDL makes use of CFFI for defining the native bindings, rather than UFFI. Hence also its (otherwise uninspiring) name.

• CFFI-SDL leverages SWIG to generate most of this binding. That is, the actual CFFI code is generated by SWIG from the original SDL headers. This means that co-evolution with SDL does not require a lot of manual labour.

If you're interested, go over to SourceForge and try it out!

Added asdf support

I packaged my code into three ASDF modules. One for SDL, one for OpenGL, and one for the NeHe example (only one sofar). So I can now do a simple (require 'nehe) followed by a (nehe01:run-app) and it runs.

I also found a way to get rid of the hardcoded path reference to the native library I use for doing the Aqua initilisation. I basically ask ASDF for the path CFFI-SDL, and then append the subpath to the right folder. I.e.:

(merge-pathnames #p"sdl/on-cocoa/"
  (asdf:component-pathname (asdf:find-system :sdl)))

I still need to look at the video-info querying. It would also be nice if I could trigger the Makefile from within ASDF as needed. And I'm also thinking of setting up a sourceforge project page for CFFI-SDL, so that anyone interested can get involved.

macrodef event-loop

I spent most of today writing up the new event-loop macro, and I got it to work. Here is a shot of it in action, together with a very basic event loop definition which is driving the graphics in the top right.

If you have taken a look at cl-sdl you'll find that my event loop looks very similar. The most obvious difference is that I treat capture of event values differently. I use keywords to ask for the right value, whereas cl-sdl somehow seemed to figure this out based on the variable names you used. This last was somewhat mystifying to me at the start; I think that the new way is somewhat clearer, if more verbose.

Behind the scenes the macro expansion happens in a very different way. In cl-sdl you'll find a lot of accessor definitions which are then used by the macro somehow. In my setup I basically defined a meta-data structure which is queried by the macro to do the expansion. This means that the details of the mappings and slot accesses are all in one place, and adding new stuff should be pretty straightforward.

Caveats of the current code: there are very few sanity checks, which means you can give it some bad input and it won't even complain. So don't give it any bad input!

Everything is also in need of the right packaging. And I need to find a way to get rid of some hardcoded paths. But barring that I'm pretty close to the end of cffi-sdl hacking.

SDL event loop

I took some time today to get the event loop working. The loop itself was quite straightforward; recognition of the exact event types took some more time.

My next step will be to rebuild a macro for the event loop, much like the one in cl-sdl. The complete hand-written version I have now is not very user-friendly. But at least I can see all the details of how to set it up.

Other note: I still have to take another look at querying the video info. And I have to package everything up using asdf.

cffi-sdl

I'm making progress on my "cffi-sdl" (haven't found a catchier name yet; ideas are welcome). The image above shows the latest version, which is capable of creating the surface on which we'll be rendering. If the surface seems somewhat empty, that's because I'm not issuing any OpenGL calls yet.

I'm taking my time with this, because I want to make sure that things are set up right. I'm having some (minor) problems with the binding though. For instance, SDL_Video.h defines SDL_VideoInfo as follows:

typedef struct SDL_VideoInfo {
 Uint32 hw_available :1;
 Uint32 wm_available :1;
 Uint32 UnusedBits1  :6;
 Uint32 UnusedBits2  :1;
 Uint32 blit_hw      :1;
 Uint32 blit_hw_CC   :1;
 Uint32 blit_hw_A    :1;
 Uint32 blit_sw      :1;
 Uint32 blit_sw_CC   :1;
 Uint32 blit_sw_A    :1;
 Uint32 blit_fill    :1;
 Uint32 UnusedBits3  :16;
 Uint32 video_mem;
 SDL_PixelFormat *vfmt;
 int    current_w;
 int    current_h;
} SDL_VideoInfo;

Note that the flags are defined as single bits in a 32 bit value. SWIG turns this into:

(cffi:defcstruct #.(lispify-sdl "SDL_VideoInfo" 'classname)
 (#.(lispify-sdl "hw_available" 'slotname) :unsigned-long)
 (#.(lispify-sdl "wm_available" 'slotname) :unsigned-long)
 (#.(lispify-sdl "UnusedBits1" 'slotname) :unsigned-long)
 (#.(lispify-sdl "UnusedBits2" 'slotname) :unsigned-long)
 (#.(lispify-sdl "blit_hw" 'slotname) :unsigned-long)
 (#.(lispify-sdl "blit_hw_CC" 'slotname) :unsigned-long)
 (#.(lispify-sdl "blit_hw_A" 'slotname) :unsigned-long)
 (#.(lispify-sdl "blit_sw" 'slotname) :unsigned-long)
 (#.(lispify-sdl "blit_sw_CC" 'slotname) :unsigned-long)
 (#.(lispify-sdl "blit_sw_A" 'slotname) :unsigned-long)
 (#.(lispify-sdl "blit_fill" 'slotname) :unsigned-long)
 (#.(lispify-sdl "UnusedBits3" 'slotname) :unsigned-long)
 (#.(lispify-sdl "video_mem" 'slotname) :unsigned-long)
 (#.(lispify-sdl "vfmt" 'slotname) :pointer)
 (#.(lispify-sdl "current_w" 'slotname) :int)
 (#.(lispify-sdl "current_h" 'slotname) :int))

Note that this time, the flags each take up a single 32 bit value. That is, we've lost the bit-locations for the fields.

The above is annoying, but I think that SWIG can't help it. I've checked the CFFI documentation, but I can't find any mention of dealing with single bits. (I still have to check the mailing lists and website though.) I can redefine this struct myself so that all flags are grouped into a single slot, and then use ldb calls to get the correct parts (this is what cl-sdl does), so it's no showstopper. It's just annoying.

Anyway, it's figuring out all of these little things which takes time to do, but I'm getting closer. The next step is to include the event-loop once the surface has been created, and then I can start doing some rendering. Once I'm there I'll also try to package everything up in an ASDF definition, just to make life easier.

Further experimentation

I'm working on a SWIG generated CFFI version of SDL itself, rather than just the OpenGL parts. Sofar I have a very basic sdl.lisp which seems to compile just fine. I'll try a real test sometime soon.