Tuesday, November 08, 2005

NeL on Debian testing

NeL is an awesome gaming engine that features collisions, OpenGL, sound and a lot of great features. It can be found here. Yes, it is licensed under the GPL. NeL is the engine behind the impressive The Saga Of Ryzom MMORPG.

Having had so much trouble with Ogre, Neoengine and a lot of other engines on Etch (given the use of GCC 4, and all those projects being developed using GCC 3.3), I tried to build it to no avail. Then it hit me: debootstrap (actually it was suggested to me by someone on IRC). I installed a version of Debian sarge on a chrooted jail and used it to build NeL on Etch.

The detailed instructions are here.

Next on I'm going to try and build Ogre on this chrooted jail.

Tuesday, November 01, 2005

OGRE in Etch

I'm having a lot of trouble compiling OGRE on Debian Etch. In the OGRE site they claim the 4.0 version of GCC will give trouble at runtime, so I forced the compiler to 3.3 before the './bootstrap && ./configure && make' step:

export CC=gcc-3.3
export CXX=gcc-3.3


But the current CVS tree fails to compile (it also fails with GCC 4). The latest Azathoth release (1.0.5) fails to compile on GCC 3. Compilation succeeds with GCC 4, but running any program linked with OGRE causes a segfault. Since there are prebuilt .DEBs for Debian Sid I decided to track the problem, and as expected the same bug is present in the build.

The bug says the problem has been recently fixed, so I downloaded the .DEBs from Sid, which complained for the following dependencies:

libopenexr2c2
libpng12-0
libzzip-dev


I did a:

aptitude install libpng12-0 libzzip-dev

And then crossed my fingers and forced the installation of all the archives:


dpkg -i --force-all libogre5_1.0.5-1_i386.deb     libogre5-dbg_1.0.5-1_i386.deb     libogre-dev_1.0.5-1_i386.deb     ogre-doc_1.0.5-1_all.deb     ogre-tools_1.0.5-1_i386.deb


So far it has worked without a glitch for me. I'm using Anjuta+OGRE and all works perfectly, given that the libopenexr2c2 dependency was not met, but I'm not using the OpenEXR format, so everything should keep working.

Thursday, October 20, 2005

e17 rules

I'm using Enlightenment e17 (CVS version) on debian etch and it certainly rules. There are a few glitches here and there (it is a development version after all) but for not being a release it works quite well.

One of the details it has is with trasparency. The previous versions of Enlightenment implemented a really nifty trick to use transparency (almost every window manager now supports this 'transparency' method), where the windows just make a copy of the area of the background where the window is placed and use it as the background. This works for static apps, but when you start moving windows around you notice the lag on refreshes. Also, this method does not allow for transparent windows to show other whindows behind it.

This is the approach that Eterm uses. But e17 has changed a few things, allowing real transparency in the windows. You can watch it while using an animated background and placing a transparent module (the desktop pager, for example) on top of it. You can see the animation through the transparent window. So transparency does not work in Eterm (debian version and the CVS version), because it needs a 'root' bitmap set on the desktop, and with the new background model on e17 none is set when you load an EDJ background (most applications that simulate a transparent background use this technique).

The only way to simulate transparency on Eterm (or xchat or any other application that uses the classical approach to transparency) on e17 is to apply a static background to the desktop (ie, using e17setroot). You can create a snapshot of your animated background, load it using e17setroot and then load the animated background using the background selector; this way you will have an animated background, and Eterm will seem trasparent.

Engage is very nifty, but I still prefer IBar, since Engage still needs some work. Another feature that I'm missing from e17 is the transitions when changing virtual screens. Right now the only implemented transition is 'vswipe', which just overwrites the content of the screen. There's a 'crosover' transition somewhere in the code, but it's not working (or I'm looking in the wrong place). enlightenment_remote works like a charm, I don't need any other configuration tool.

All in all, e17 is very usable, and easy on the eyes. The fonts look great and the colors used by default are really beautiful, and when people look at my desktop they are impressed. As for stability, I've had some issues here and there, but all of them happened when pushing the edge trying to do advanced stuff. I'm really looking forward for a final release, sometime next year (i hope).