Okra (Common Lisp bindings for the Ogre3D engine) hasn't seen a lot of work lately. It covers my current needs and I've mostly been off to other projects. However, there's good news from the Ogre camp: there's now a community effort to create a C API!
I can only hope the API will have settled down before I return to using Ogre.
ILGE 2010 Post-mortem: Engine Troubles over Tentacle Planet
Progress
I have made very little progress since the last report, mainly due to the little time that was available to me. Only two things were done:
The source code was cleaned up a little.
A windows binary was made (OpenGL only).
In the short term I will not work on ETOTP anymore but perhaps for ILGE 2011 or another challenge or expo I'll continue where I left off.
What Went Right
Making wrapper functions in C for Ogre's C++ methods and adding them to ECL from C using ECL's API. I used this approach because the inverse (making the C wrapper code from Lisp) gave me segmentation faults and didn't get me very far about 2 years ago. (Note: this was using ECL functionality, not CFFI for which there's Okra.)
Compiling a C program on both Linux and Windows that was (dynamically) linked to ECL, Ogre and OIS. This C program can, for example, start a game right away and quit back to the OS but it can also provide a CL REPL (like ECL's si:toplevel) so one can interactively play with a 3D scene. Since it's just a plain CL one can load extra packages and perhaps start Slime.
What Went Wrong
Compiling a statically linked binary on Linux. This didn't go as easily as I had hoped and was starting to eat into my time budget.
ManualObjects and shadows. I had to resort to Ogre's prefab entities to get shadows working the way I wanted in the time that I had available.
What I Learned
ECL is a really good option for embedding a CL implementation in C(++) programs. Juanjo has been working on ECL for years now and he's still going strong. Questions on the mailing-list are generally answered within hours.
One doesn't just add "-static" to a build rule and be done with it :-)
Perlin noise is usable to animate objects with. Definitely for prototyping since it's so easy and quick to implement.
I develop on Linux but the build is checked and tested on Windows using MinGW and MSYS. Either MSYS 1.10 or 1.11 was used, it doesn't really matter. The MinGW release that was used is TDM-GCC 4.4.1 but I see there's a 4.5.0 release out now.
Ogre SDK 1.6.1 for MinGW (there's no later 1.6.x SDK for MinGW). You can try the 1.7.x SDK for MinGW since the Ogre API is pretty stable, but I can make no guarantees that it will work.
ILGE 2010: Engine Troubles over Tentacle Planet, part 2
1 Progress
Since the last report I've added: a controllable spaceship, bullets, tentacles and I made an unsuccessful attempt at producing a Linux binary.
For the controls I use the OIS library. I was already familiar with this due to my clois-lane library. The controls work but don't feel quite right yet and need some minor adjustments.
Adding bullets was straightforward. The most time was put into the tentacles and the attempt at making a statically linked Linux binary.
The tentacles are Ogre prefab cubes plot along a Bézier curve. The P1 and P2 control points and the P3 end point are assigned a new x,y,z coordinate each frame. This coordinate is picked by walking through 3D Perlin noise with a random movement vector for each point. (The vector was created randomly at creation time, it's stays the same from frame to frame.)
The code is a huge mess by now and it is getting in the way. Next priority should be a clean-up.
2 To Do
[X] rolling terrain (high)
[X] controllable spaceship (high)
[X] improve controls (low): The controls aren't quite there yet,especially moving left and right.
[X] bullets (high)
[X] cmake file (low)
[X] basic tentacles (high)
[X] shootable tentacles (high)
[X] collision detection: spaceship vs terrain (high)
[X] collision detection: spaceship vs all other entities (high)
[X] tentacles that shoot small spores (medium)
[X] roaming (bigger) spores that attack the player (medium)
[X] some minor GUI elements showing the score, highscore and FPS. (high)
[X] make binary release for Windows (medium)
[X] spaceship needs to cast a shadow in the terrain to judge heights(high): Solved this by using prefab entities instead of a manual object.
canceled: make binary release for Linux (high): This is just too much of a hassle. The Ogre package for Debian didn't come with static libraries and compiling it myself with "–disable-shared –enable-static" didn't produce them either so this is going to take too much time.
Eventually I managed to build static Ogre libraries but ran into other problems when compiling with "-static". Statically compiling is something I have no experience with and this looks like it is going to take too much time for the ILGE 2010.
For Linux it seems distribution by deb and rpm packages will be the best solution. (What a revelation!)
3 Source
The code for the latest version isn't available yet since it is a horrible mess. Keep watching http://www.aerique.net/software/etotp/ (not up yet) if you're interested.
3.1 Linux Dependencies
ECL (10.4.1) configured "–with-cxx". (Feel free to try without it, I haven't.)
ILGE 2010: Engine Troubles over Tentacle Planet, part 1
Introduction
I've finally managed to scramble together a good couple of hours to work on my ILGE 2010 entry. At this rate it will be doubtful whether I'll have a minimal game by the end of this month :-(
The first item that can be checked off the to-do list: rolling terrain. The video is low quality and stutters but this is due to me using sub-optimal software to capture my desktop. The program actually runs very smoothly on both systems I've ran it on (a Samsung NC10 netbook and an Intel P4 2.8Ghz desktop).
The video shows the planet on which this game is played. It is a standard heightfield created using Perlin Noise (with the CL Black Tie library) which keeps scrolling down endlessly until the player dies.
Goal
Explore the usability of Ogre and C++ from Embeddable Common Lisp (ECL) using functionality specific to ECL as opposed to using the CFFI approach used by Okra. (Since Okra's CFFI approach needs to compile a small C wrapper library to access Ogre's C++ functions anyway.)
I will be ignoring any licensing issues that might come with releasing a binary that's statically linked to ECL and Ogre for now.
Development Environment
My development environment is Debian Linux. Testing will also be done on Windows (Vista unfortunately) in the future but that hasn't happened yet.
Dependencies
ECL 10.4.1
Ogre 1.6.4
OIS 1.2.0 (not used yet)
ECL has been compiled by myself but Ogre and OIS have been installed using Debian's package manager (you need libogre-dev and libois-dev).
I have not used Ogre 1.7.x yet but since Ogre's API has been pretty stable in the past it might just work without any changes.
TO-DO
In chronological order:
[X] rolling terrain
[X] controllable spaceship
[X] basic tentacles
[X] bullets
[X] shootable tentacles
[X] tentacles that shoot small spores
[X] roaming (bigger) spores that attack the player
[X] collision detection: spaceship vs terrain
[X] collision detection: spaceship vs all other entities
Don't know when:
[X] some minor GUI elements showing the score, highscore and FPS.
I'm slowly moving from using global variables to stuffing everything into a scene-class instance so that will account for any duplication you might see.
