December 06, 2008

Magic Touch

I'm learning to program for the iPhone, so that I can help out some of my students with their work. I thought that programming something marginally useful to me would make it more fun, so I went for a Magic The Gathering card lookup thingy... For your pleasure (and my bragging rights) here are some screenshots:

Right now it will find cards by name or type, and will return the latest edition of the card. If there are more editions, it will show you a nice list of them, and you can pick one to see what the card looked like in that edition. All of this is done by querying the website behind the scenes.

October 19, 2008

Quake 3 BSP loading (WIP)

I woke up this morning and I felt like doing some BSP rendering... in Java though. Yes, I'm forsaking Lisp for now, and returning to that partial 3D engine in Java that I was working on before. No I do not suddenly consider Java to be better than Lisp; Lisp is still the cooler language. The main reason seems to be that I have a much more comfortable development environment for my Java code than I did for my Lisp code. Lesson learned: the success of a language is only partly defined by its features; the surrounding "ecosystem" also plays a major role. Yes I know I could be using something like LispWorks and enjoy the comfort, but I don't want to. It's not open, unless you agree to a somewhat limited environment. I much prefer the Eclipse philosophy where non-commercial software developers are not treated like second rate citizens.

So anyway, I looked around for some apropriately licensed Java code to start off from. When I didn't find anything, I just decided to start coding the loader myself. Sofar I've got the plane and node records loading, based on the unofficial Quake 3 Map Specs. I'm also using info from "rendering Quake 3 maps" to help me decide which parts of the file to load first.

No big promises that I'll be finishing this code soon though. :-)

October 16, 2008

Good news, bad news

The bad: I'm putting my 3D Lisp engine on hiatus. I still haven't found the right vibe to continue with it. It's partly to do with the uncomfortable development environment I've got going, but also with wanting to get something going that's more for the end user. I.e. not just a 3d engine. Anyway, we'll see what happens if and when the vibe returns.

The good: I will become a dad somewhere in the middle of next year ! This has taken most of my spare-time thoughts, as you can imagine. Apart from the obvious meanderings, I'm also wondering if I could not make something which will benefit him/her. A lot of kids these days naturally know how to use a computer, but not how to make it their own. They are only able to make it do what other people have provided for, not make it do whatever they want it to do. (This is why I think that learning some programming language should be a compulsory part of modern day schools.) I know of some projects in this area (e.g. Alice), but I haven't really seen anything that "just makes sense".

Anyway, for now I'm transforming this blog a more general purpose ranting mode. I'll try to find my muse, and see where life takes us.

August 30, 2008

Still alive...

...but low on whatever it is I need to do some programming in my spare time. I'm not cheating, though, and have not started work on some other programming challenge. I will stick to Lisp and 3D until I've made it through the year.

August 10, 2008

Lazy weekend...

'Nuff said.

I have been checking out the cal3d documentation though. It seems to be pretty straightforward. I hope to give it a try sometime later this week.

August 03, 2008


I'm trying to get Cal3D running from within Lisp. I installed Cal3D on my mac, then tried lispbuilder-cal3D. Both of them seem to load ok. But then when I try lispbuilder-cal3D-examples there is a dependency on lipsbuilder-openrm. So I've been trying to get openRM compiled correctly, and it compiles, but the dylibs I'm creating won't load...

Not sure what I'm doing wrong. And not really interested in putting much effort in openRM, as I'm not going to use it anyway. I'm done with scenegraphs; they have their uses, but not for what I'm going for. I'll take another shot at it a bit later, and check my options.

[update] Have taken another shot, but no success yet. I think my dylibs are being created correctly now, but I can't be sure. The error in Lisp says that dlopen failed, but nothing more detailed for me to go on. I've had enough of it for today anyway...

July 31, 2008

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.

July 29, 2008


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. :-)

July 26, 2008


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.

July 19, 2008

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!

July 16, 2008

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.

July 12, 2008

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.

July 11, 2008

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.

July 05, 2008


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.

July 01, 2008

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.

June 28, 2008

Proof-of-concept CFFI-OpenGL running

The above image shows a run of NeHe tutorial 1 making use of the CFFI binding for OpenGL rather than the UFFI binding that's in the original cl-sdl. It's the only one I have tested sofar, but it seems I'm on the right track.

June 27, 2008

Status report

I haven't had much time to spend, but I did get a version of gl.lisp and glu.lisp in CFFI and mostly autogenerated by SWIG to compile without errors. It still needs to be tested in practice, and I first have to check out how to best do this as I need to grab a rendering context and window through SDL...

On the upside, I have done some "real" Lisp programming: the foreign function names are now lispified in Lisp itself.

June 21, 2008

swig -cffi

So I installed SWIG and tried out the CFFI mapping, and it seems to work beautifully for the gl.h header (still have to try the others). I initially had some problems with SWIG seemingly discarding hexadecimal values for constants, but this was due to Mac OS X having an older version of SWIG which I was unwittingly using instead. The latest SWIG works just fine and the generated code looks perfect.

I'll do some more tests, and then figure out what my new plan should be.

June 18, 2008

Spurious work ?

While looking around for info on function pointer types in UFFI, I found CFFI (a newer project with similar goals) and fetter/Verrazano, which generates CFFI/UFFI from C/C++ header files!

I have some reading to do! Until I've delved into this a bit further, my own generator script will be on hold. If fetter is mature enough I'll dump my own script, and use it instead.

I wish I had found this when looking at UFFI a month ago...

[edit] Even better, SWIG supposedly also is able to generate CFFI code. I'll definitely need to try out that one!

glu.lisp progress

Haven't had much time to spend on it, but I think my generator now covers glu.h. I still need to check its coverage by taking measurements as with gl.h. And then, of course, I need to test it for real.

I'm mostly worried about the typing differences between the generated glu.lisp and the original. The original replaced all occurrences of quadric with (* void). The generated version, on the other hand, leaves them be but adds a define-foreign-type mapping quadric to (* void). My guess —hope really— is that this will have the same effect, but I don't understand enough of UFFI to be sure.

There is also a function pointer type that I don't know how to handle yet. I'll have to take a look at the UFFI documentation.

June 16, 2008

Started on glu.lisp

I have done some preliminary work on generating glu.lisp from the glu.h header on my system. It's not doing too badly (misunderstanding only 76 lines out of 340), but there are lots of procedures it doesn't "get" yet. I will also have to take a closer look at the types being defined in gl.h. If the generation works, this will be extra valuable, as the original glu.lisp is quite minimal. It means I'll be able to cover quite a bit more of the available functionality.

I'm spending more time on this than I had hoped, but I still think it's valuable. My first feature of the engine will likely be character models, making use of the CAL3D library. If so, then I'm already hoping to apply the generator to CAL3D to set up the bindings.

[edit] I have most all procedures covered now. I still need to take a closer look at the type mappings, though.

[PS] As for the peasant magic: I finished dead last. :-)

June 14, 2008

't Works

Succes! I got my version of cl-sdl running using the generated UFFI bindings for gl.lisp instead of the original ones. I tried some of the demoes, and things seem to be fine.

Allowing for overrides took about half an hour of work. I then spent another half hour fixing some other problems relating to names of parameters. But that was basically it.

Next up, I'll take a look at using the generator for glu.lisp as well. But that won't be for today. I have some peasant magic planned this afternoon. :-)

June 12, 2008

Here are the results of the Belgian jury...

The above graph shows the (condensed) results of the measurements. For each kind of foreign definition in cl-sdl's "gl.lisp" (constants, routines and types) you can see the number of identifiers which are not used (in blue), the number of identifiers which are used and covered by my generator (in yellow) and the number of identifiers which are used but which my generator does not cover (in red). As you can see, only a very small percentage of all identifiers is causing problems; nine identifiers in all. They are: light-fv, fog-fv, fog-f, scale-f, translate-f, fog-i, rotate-f, material-fv and tex-parameter-i.

Possible choices before me now are (1) to refactor cl-sdl to have these nine identifiers match those generated by my script, or (2) to have my script treat these nine identifiers as exceptions defined by the user. The first choice entails updating 139 use-sites in cl-sdl, the second an extension to my generator script. I think I'll go for the latter solution as I expect it will involve less work.

I'll be keeping the analysis scripts around, as it will allow me to check when my generator is covering all the cases. It also doubles as a very basic coverage calculation tool, which might also prove interesting down the line.

June 11, 2008

Taking measurements...

I decided to try to quantify the naming scheme problem, so I'm in the process of setting up some analysis scripts. The scripts are virtually complete; it's now really mostly a matter of processing the results. I also think that I can reuse most of the analysis scripts to automate the update of cl-sdl. This should save on time, manual labour, and make sure of better results. But, again, first comes taking a closer look at the extent of the problem.

June 10, 2008

Naming schemes

I had a first try at substituting the original gl.lisp in cl-sdl with my generated one, and, of course, it failed. So I started taking a look at what differences are left between both, and here is a nasty one: cl-sdl uses an inconsistent naming scheme. Mine, on the other hand, is very strict due to its automated nature. Here is an example: cl-sdl lispifies "glGetIntegerv" into "get-integerv" on the one hand, and "glLoadMatrixd" into "load-matrix-d" on the other hand. My generator script always uses the first variant, and would turn "glLoadMatrixd" into "load-matrixd". This is simply because it doesn't recognise the final "d" as a separate item. I think I'll check the cl-sdl codebase to see if both variants are being actively used. The gl.lisp file seems to favour the second variant (as would I), and so, if the first one is hardly used I can just update those so that the naming scheme becomes uniform. I will then also have to update my script to use this naming scheme, which will require some extra input from the user to figure out where to place the extra dashes... Because of that complication, it might also be worthwhile to just standardise on the first, be it uglier, variant. But if the second variant is more widely used, then I'll have a lot of updating to do... I also need to start thinking on whether the extra work is justified. I still want an up-to-date opengl binding, and using the generation approach still seems a smart thing to do. Having a consistent naming scheme is also a good thing. I just hadn't counted on having to update the use-sites.

June 06, 2008

sdlstub is autoloading again

I did some tracing and found that the foreign library was, in fact, getting loaded as it should. I then started working on the idea that placing my own library in between the initialisation might have screwed it up somehow. So I did some rearranging, as well as adding explicit dependencies between the libraries. I found the right incantations after about half an hour, and now... it works.

Next up is to finally try that uffi generation script of mine, and then start doing some real 3D programming.

June 05, 2008

sdlstub still won't autoload

I have been trying some variations, but I still can't get the sdlstub dylib to autoload as it should. The strange thing is that it seems to autoload the sdl library just fine, as well as the sd-aqua fix library I set up. There is no difference in code for loading any of these other than the values used, which I think are quite correct...

June 01, 2008

(require 'sdl-demos)

So, another day, another step forward, and... another step backward. Let's start with the good news: I integrated my sdl-cocoa bugfix into cl-sdl, which means that I can now skip some tedious manual steps that I had to do before. That's when I started going over the different demos to make sure that everything is still ok. Here are captures of the ones which worked: Looks nice right ? OK, so they're no Unreal 3 demos, but it's still nice to see them running. Unfortunately, there are about as many demos which do not run as there are which do. For those I'm getting an "SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR: Attempt to call an undefined alien function". With the help of the traceback I can see that something is going wrong with the load-bmp function. I have had bitmaps loading in earlier experiments, but I haven't tried it since starting this blog. So I guess I'm of on another wild duck hunt... [edit] I managed to get the textures to load. Here is a screenshot of (nehe:run-tutorial 9): I think something is going wrong with the loading of the foreign library. I have to do a manual uffi:load-foreign-library; if not, I still get the earlier error. I'll have to take a closer look at why it won't load the right library all by itself anymore.

May 31, 2008

ASDF now compiles my cl-sdl

The title says it all really. I "fixed" the cl-sdl library up to the point where I can do an asdf:compile-op without triggering the debugger. I had to install some extra SDL libraries, and I had to fix a Makefile for the stubs cl-sdl uses. And, of course, there is still that mysterious symbol redefinition I mentioned in the previous post. But that was it.

May 26, 2008

ASDF progress

Things have slightly slowed down, mainly because I have been focusing on something for work (an island-based Cobol parser, if you're curious). I have fixed the warning in the sdl component, and now asdf compiles it just fine. I still don't get where the warning is coming from though. It complains about a duplicate definition of "cd-status", but if that's so then I don't find the second definition. I do see both a foreign type and a foreign function named cd-status, but disambiguating those doesn't help. The warning only goes away when I rename the label for the foreign function. Anyway, I'm now planning to check the other parts of cl-sdl (I already did the sdl-img component, which required installing the sdl-image library). Once I've gone through all of them I'll add my own fixes and start testing the uffi-generator script for real.

May 20, 2008

ASDF weirdness

Why is it that

(asdf:operate 'asdf:compile-op :sdl)

fails, when

(compile-file "/path/to/cl-sdl/sdl/sdl.lisp")

succeeds ? The weird thing is that I see the same compilation of the same file except for a final:

;/path/to/cl-sdl/sdl/sdl.fasl written
; compilation finished in 0:00:00
COMPILE-FILE warned while performing # on
#<cl-source-file sdl="">.
; compilation unit aborted
;   caught 1 fatal ERROR condition
;   caught 2 WARNING conditions
;   printed 20 notes

I know the file compiles just fine. Hell, even when things go wrong it still says it wrote out the fasl. So it must be something with asdf. Unfortunately, I have no idea where to start looking...

[edit] I read somewhere that "asdf regards a full warning as an error". There are indeed two warnings, so maybe that's what is tripping things up. Two options then: try to fix the warnings, or figure out how to change this behaviour in asdf...

[edit] Here is a message I found stating the "warning is error" behaviour. It's really counterintuitive; which is to say that every other compiler I have ever used treats warnings just as warnings. Ah well. It seems the best option is to fix the warnings, so I'll start looking into that.

May 17, 2008

Forking cl-sdl

Yes, the title says it all: I'm going to work on a custom version of cl-sdl. Hold your "shenanigans", because I will do it in the easiest way possible. First question is why do it at all ? Well, I want to integrate my sdl/aqua fix (see previous post) into cl-sdl, but that's not really a good reason. A much better reason is that cl-sdl is not being actively maintained anymore. The last release stems from end 2002, and the mailing lists are virtually dormant. OpenGL support is stuck at version 1.2, with a comment on 1.3 but no further development. This last fact is especially bothersome as I want to use any OpenGL functionality I have available on my machine, not just what cl-sdl is offering. The most important reason however, is to fix the installation problems I have had. I'll need this when I want to start sharing my engine with other people. If they can't even get the OpenGL binding going then I'll have a hard time getting them to test my real code. So how to do it easily and keep the effort at a minimum ? As for integrating the sdl/aqua fix and correcting the installation, I think that is just a one-time investment and I should just do it. The bigger bother is keeping the package to move along with new versions of OpenGL, but I think I can automate much of that process. You see, at the core of cl-sdl are UFFI bindings which basically offer a lispy description of whatever is in the OpenGL library. Someone needs to make this description and then you can use whatever is in that library. Really cool, but maintaining that description can be quite bothersome. It should however be possible to generate most of that description automatically. Simply parse the relevant header file and translate it into the equivalent UFFI code. This is what I have been experimenting with, and it seems to be quite doable. Sofar I have a tool which processes most of the gl.h header, and which generates a UFFI which is close enough to what is in cl-sdl to be almost indistinguishable; except that it now also has OpenGL 1.3 functionality. This is giving me good hopes of getting it working, and will mean that when there is a new OpenGL header I can just rerun my tool and I'll be instantly up-to-date. (As a possible bonus it might be possible to use the same generator script against other headers which will allow me to interface with many other interesting C libraries. There's nothing I need right away, but it might prove a time-saver in the future.) The todo now is to finish of a first version of the tool and then verify that its output still produces a working cl-sdl.

May 12, 2008

I got my fix

Isn't it beautiful ? Ready Lisp showing Aquamacs connecting to an sbcl repl which is running the basic cl-sdl test. Seems to work just fine, though I did notice that any messages printed by the app don't show up until after you close the window. This doesn't happen when running it straight in the terminal.

May 11, 2008

_NSAutoreleaseNoPool troubles

So, thanks to a quick reply from John Wiegley (who makes Ready Lisp), I was able to get sbcl running from within the terminal. If anyone else wants to know how to do this here is the magic incantation (assuming "/Applications/Ready" as the pwd):

./Resources/sbcl/sbcl --core ./Resources/sbcl/i386/lib/sbcl/sbcl.core-with-slime

If you're on powerpc you'll need to replace the i386 with powerpc. And I also suggest aliasing this command in your .bash_profile to make it friendlier. Back to my problem: when trying to run the sdl-demos I get the following (familiar) messages:

2008-05-11 09:13:30.048 sbcl[195:10b] *** _NSAutoreleaseNoPool(): Object 0x121a20 of class NSCFNumber autoreleased with no pool in place - just leaking

This is the same problem I saw when trying to get cl-sdl working on cmucl. It basically has to do with SDL and Cocoa. Cocoa needs special initialisation which SDL only provides for main methods. As there is no "main" method here, the initialisation does not happen and the demos don't work. So the next step will be to see if my old solution to this problem still works.

May 10, 2008

Technical problems already ?

Some initial background: my intent is to use a (possibly customised; but that's a future post) version of cl-sdl. This is basically a uffi binding to SDL, which provides the windowing, event-handling and, most importantly, OpenGL capabilities. I have already played with cl-sdl once from within cmucl (a Lisp implementation), doing a very basic heightmap renderer. Basically a port of NeHe tutorial number 34. Getting cmucl and cl-sdl to work together on my mac took some doing but it worked nevertheless. This time I have opted for sbcl rather than cmucl, for one simple reason: Ready Lisp. This is a complete package which has sbcl, aquamacs and slime working right out of the box. Pretty cool actually, and it saves me from having to set it all up myself. Anyway, as sbcl is related to cmucl I was pretty confident that I could get cl-sdl back up and running. Not so... When I try to install cl-sdl through asdf it downloads just fine, but during compilation I get an error saying that sdl-ext references sdl:get-video-info but that sdl does not define this. This is utter stupidity as sdl defines it just fine. My guess here is that there is a build-order problem. You see, it compiles sdl-ext before compiling sdl, and so yeah the symbol may not be there yet. So next I resort to doing manual compile-file invocations, doing things in a better order. Guess what, no complaints anymore. So something is definitely going wrong in this asdf. I didn't have this problem in cmucl... But still things go wrong. While I can now require sdl, opengl and sdl-demos without problems, when I actually try to run one of the demos slime loses the connection with the repl... What I guess might be going on this time is that the demo is trying to open a window, but that because of the way aquamacs/slime is connecting to the repl this might not be possible. So I would like to start sbcl up from within a terminal and try running it that way. This is what worked fine in cmucl. Of course, first I have to figure out where Ready Lisp is keeping its version of sbcl. Probably somewhere in its app package, but I'll have to look. So no joy yet. Nor any pretty pictures of triangles floating in mid-air. :-)

May 06, 2008


I'm a self-confessed computer geek (see, I just confessed to it), and as with most such geeks I love programming. I will program anything and everything that interests me, and there lies the problem: there's too much of it, and I don't finish anything. I usually get stuck architecting and implementing stuff I don't end up using (look up "axe sharpening" and "yak shaving"). And then I slow down with the overall project, and I'm eventually left with another piece of abandonware. I'm tired of ending up with nothing to show for myself when I undertake these projects, so I'm issuing myself a challenge: over the course of the next year (with this post marking the start date) I will work on one project and one project only. Mimimal yack shaving, minimal features, and good-enough code will be the motto. The project I'm choosing is one for which I already have some experience, and for which I know there's a lot of good resources to help me out: a GPU-accelerated 3D engine (yes, I know there are loads of those out there, but there will be a slight twist to mine; keep on reading). Here are the features I'm going for (and these features only):

  • Support for one format for indoor scenes (one of the BSP formats most likely).
  • Support for one format for outdoor scenes (octrees, CLOD, or some such).
  • Support for one format for characters (will likely be MD5, though I may go for one of the older formats).
  • Support for one format for static models (Milkshape obj perhaps).
  • Support for basic skyboxes (just to make the scenes complete).
  • Support for mixing any of these in any way I want (I already have a comprehensive design document on how to do this).

For hardware acceleration I will be using OpenGL. No DirectX; I'm on a Mac so that's not an option. And I won't be setting up my engine so that I can later easily choose one or the other (I don't care about that anyway). Windowing will most likely make use of SDL, mostly because there's a lot of documentation and help for it, and because it will help me stay multi-platform. Now for the twist. I have started a similar project once with a friend where we used Java as the implementation language. I really don't want to use Java anymore. It was once good-enough for me, and it's still the language I'm most fluent in. But I've had enough. So instead I'm going to do my 3D engine in Lisp. ***Pause to let readers catch their breath. With me again ? OK.*** Honestly, I don't think this is much of a shocker, but I know some of you may find it strange anyway. Seen as I can't find any 3D engine in Lisp I'm guessing it is somehow not an obvious pick for most of you. Still, I'm hoping this will count as something new and interesting to more people than just me. As for art/assets, I will stick to what I can find freely online, though I will allow myself to reuse some of the assets I made for my Java engine. I can tell you now that this restriction will likely be even more of a challenge for me than the technical stuff. Even not doing anything on the design for this blog is making me itch... Just to be clear about this: I will consider my project a success when I'm one year further on and I have kept my focus on this project and this alone. That is: no other projects were started (though, of course, I won't count anything I'm doing for work, nor anything which I'm working on to help out someone else), and this one has not been abandoned. Not implementing all features will not count as a failure (as I have no idea how much time each feature will take nor how much time I will have overall), but spending too much effort on unlisted features will. Now for the blog-part and you, the reader. In order to keep myself focussed on my goal I'm setting a task of minimum of one post per week listing what I did or did not do during that week. You will get the right to call "shenanigans" whenever you feel I'm straying too far from the challenge. I'm hoping you won't need to but, then again, if I knew for sure I wouldn't be needing this blog/challenge anyway. And with all that, here's hoping I won't fall flat on my face. :-|