After a few weeks of hesitating we finally did it. Since the official german Irrlicht community was raided by bots (that is actually pretty annoying...) we founded a new community, cause we noticed that there is still need for it.

Nach langem hin und her haben wirs dann doch gewagt. Da das offizielle deutsche Irrlichtboard schon seit fast einem Jahr konstant durch Bots garaided wird aber dennoch der Bedarf nach einer deutschen Irrlicht-Community da zu sein scheint, geht ein neues Board ins rennen.

Nicht nur ein Kompendium über die populäre Spieleenginge Irrlicht, sondern viel mehr noch ein Leitfaden, der den Leser an den Anfängen mit Irrlicht abholt und ihm zeigen soll, wie man Irrlicht geschickt für die Spieleprogrammierung nutzen kann. Dabei werden die Schwesterprojekte IrrEdit und IrrKlang nicht unberücksichtigt bleiben. Das perfekte Buch für alle Irrlichtnutzer, egal ob sie gerade angefangen haben oder schon lange mit Irrlicht arbeiten.

Not only a Compendium about the famous Irrlicht Engine but also a Guideline from starting at the very beginning to become a real master of the Engine, including all its relatives like IrrEdit and IrrKlang.

So after I stuck quite a long time with my Asus lapop, I recently decided to get me a new, shiny toy. As you can see from the title, my choice is Lenovo this time, with an IdeaPad Y560.

As I'm a Linux user for several years now, one of the first things to do after the purchase was to install my favorite operating system on it. In the following, I want to collect some experiences and maybe hacks required to successfully use Linux on that device - as information for myself and maybe others that also want to install something different than Windows on that laptop ;)

The Situation

The IdeaPad Y560 has an Intel i7 Quad core and comes with 6 GB RAM preinstalled. From the spec, it says, one can upgrade up to 8 GB.

My operating system choice is Fedora (currently version 14), 64 bit with KDE as default desktop.

Installation

At least my laptop had the following initial partitions:

• Windows Boot Partition (200 MB)
• Windows System Partition (around 580 GB)
• Some "driver" partition (around 30 GB); this contained only some Windows drivers and programs
• OEM Partition

The driver partition is set up as a logical drive inside an extended partition, so when using Windows, you actually might see 5 partitions reported.

Despite I usually don't use Windows anymore, I decided to keep it installed in case some of the installed devices aren't going to work with Linux. So, what I did was:

• Making a backup of the driver partition; I assume, one can get these drivers from the Lenovo website as well, but just wanted to keep the files in case something goes horribly wrong ;)
• Next step, I deleted the drivers partition and the extended partition. Note, that it is currently a rather bad idea to delete the (hidden) OEM partition, as it is required to restore the laptop to factory settings (unless your model is delivered with a backup DVD, but mine was not)
• In case you don't trust the Linux installer, you optionally might want to shrink the Windows partition from inside Windows; however, note, that in this case you can only shrink that partition until the first non-movable sectors are located. What - however - might be a good idea is to defragment the partition before proceeding with the Linux installation, at least, if the system has already been used for some time

Now the actual installation can begin. Insert the install CD/DVD/USB stick and reboot. Make sure, booting from the appropriate device is enabled and the device's boot priority is higher as the priority of the hard disk.

At last for me, the following boot procedure was straightforward: Actually, you just need to follow the instructions. I decided to shrink the Windows partition (to 100 GB, so Linux has a total of 480 GB in my setup). The installer will do the rest for you (usually, it will suggest to create a extended partition, where it will create a boot partition and a LVM volume with root and swap partitions). I advice to Use 3 LVM volumes - root, swap and home - for root, I used 20 GB (which is sufficient in most cases, but in case you are unsure you can set it at least to 50 GB, which is enough in any case).

After the copying of the live image to the hard disk, just reboot into the new system and complete installation.

First Impression

After I had quite some trouble with both my tower PC and my Asus laptop in the first time, I was really impressed. Linux works really well in this laptop, and most things seem to work out-of-the-box. So for example, the volume control keys indeed are usable (I especially like the mute button 8) ). WLAN does not need any additional work this time (which still wasn't the case with my Asus laptop, where I needed to install additional kernel modules manually) and graphics also do fine with the open source radeon driver.

What might need some work

Graphics

The radeon driver, which is used by default on Fedora, works quite well. Sometimes, there are some fragments but these are negligible. However, if you want to run heavy-weight 3D applications (games, modelers, etc) or just like to use your desktop's shiny 3D effects, you might want to use the (proprietary) display drivers.
Update:
The pre-installed radeon driver works now well (currently using F15) from a graphical point of view (no glitches, desktop effects working flawless and multiple monitors are no problem, too). However, currently, sound via HDMI seems not to be possible, so if you require it, consider installing the proprietary driver, too.
I recommend using the drivers from RPM Fusion. After enabling their repositories, issue an

If you decided to install the 32 bit version, you don't need to install the xorg-x11-drv-catalyst-libs package for 64 and 32 bit, of course.

Also note that you might consider installing the "kmod" package instead of the "akmod". The akmod's are good in case when a new kernel is installed the appropriate kmod is not yet available (which might result in a blank screen as soon as you boot the next time using the new kernel). In that case, the kernel module will be build when starting the system. However, this increases boot time (so if you want to keep boot times absolutely minimal, better go for the simple kmod variant.

After installation, you should rebuild your initramfs (and make a backup of the old, in case you need to revert):

You should also disable KMS. Edit your /etc/grub.conf: You have to add radeon.modeset=0 to the kernel line. A complete section should then look like this:

Last but not least: If you have manually created and changed the file /etc/X11/xorg.conf, create a backup as well. If this file does not exist in your installation, you don't need to do something here (the file is not required anymore).

For further information and some hacks, there is a blog post which I found to be quite useful.

Setting up dual-head

I usually use an additional monitor attached to my laptop. While configuration via the open source drivers worked flawless (just setup what you want in System Settings -> Display and Monitor, the proprietary driver had some problems. More specifically:
I want to setup one X screen to span both monitors. Usually, I have the laptop monitor configured to be the primary and the external monitor right of the laptop. One is able to set this configuration up via the Catalyst Control Center (start it via su -c amdcccle), however, the changes were not permanent, i.e.:

• the control center instructed me to restart X (which I did)
• after that restart, all was setup as instructed
• however, after a system reboot, the external monitor was always set to be a clone of the first

After a bit playing around with the X configuration, I found this setup to be what I needed:

Sound

In case you don't hear any sound in KDE, don't panic. At least for me, KDE picked the HDMI out as default output. So just go to the KDE system settings (hit Alt+F2 and enter "systemsettings" and hit enter to start it). There, navigate to Multimedia and select Phonon in the left sidebar. Now you can set up default output devices for the defined categories. Make sure, the entry "Internal Audio Analog Stereo" is at the very top of the list of output devices. You can Apply Device List To... to apply the list to all categories. Then, hit Apply to save the changes.

Ambient Light Sensor

The laptop comes with an integrated Ambient Light Sensor (ALS), which is used to automatically adjust the backlight brightness depending on the ambient light level. Up to Fedora 14, this sensor obviously has not been detected (and therefor automatic adjusting was off). However, starting from Fedora 15, the sensor is detected and fully used. In case you don't want/need the ALS: I had to boot into Windows and disable the automatic brightness changes there (Lenovo preinstalled a tool for this, just tap the special button with the battery icon and it should show up, unless you wiped everything away). There, you can disable the ALS (use the button with the gear icon and then there should be an option to disable ALS). This seems to deactivate the sensor hardware-wise (after rebooting, the screen brightness remains constant in Fedora, too).

By the way: In case somebody knows either how to enable/disable the ALS from Linux or the name/manufacturer of the ALS in the laptop... would be nice if you could drop me a message ;)

Currently I'm working on a project. Till now nothing is post about it here. And it won't gonna change the next days, so that I can focus on working on the project. Anyway here is a little preview ...

Endlich wurde der Torpia Combat Analyzor (zumindest in einer ersten Version) fertig gestellt. Enthalten sind ein Editor zum Pflegen der Kampfdaten, welche als XML abgelegt werden und der Analysator, der die Daten anhand der vorher geschriebenen Formel abgleicht und grafisch aufbereitet.

Dieses Tool soll helfen hinter das Kampfsystem von Torpia zu kommen. Dazu werden eine große Anzahl an Kampfberichten gesammelt und eine Formel entwickelt. Der Analysator gleicht die berechneten Daten mit den ermitellten Daten ab und gibt einen Umriss wie nah man sich an der Lösung befindet.

Hey there, it's me again. I know it's been a while since my last post... I also know that there are no excuses for that but I may have a little surprise to appease you.

But not now... I will post some more details saturday evening, so stay tuned ;)

See you saturday

EDIT: surprise surprise ;)

Well, it's been a while since I wrote the last time. Meanwhile I moved (my new apartment is awful) and now nearly everything is tidied up here. Nevertheless, I also did some development work ;)

So first I am glad to mention that a new version of KEmu will soon be officially be released. This new version rewrites a lot of the existing code, making it (hopefully) more stable and the GUI more usable and clear to the user. However, some parts are not yet ported, so you have to wait a bit more.

Additionally, I also had a project at university: The digital pen&paper project.

The Problem

Take some form, e.g. when you are at the doctor. Whatever is written on them basically has to be converted (until now by hand) manually to the computer, meaning: Someone spends a lot of time reading the form and writing the contents once again in a computer program. This could easily be solved by using e.g. tablet computers, however, these are not yet accepted by a broader mass, thus writing in a form which is printed on a sheet of paper will remain the default for some time. The digital pen&paper approach could help here: While one can use the pen (and the accompanying receiver unit) like a normal pen, the unit later can be connected to a computer to have the handwriting data in a digital form, which can be used by a handwriting recognition software to convert it to text, which then can be stored in a database (or where ever needed in the actual use case).

Now, there remains one problem: The files you receive from the unit connected to the pen are like writings on a transparent you use with e.g. overhead projectors: Imagine you have a sheet with a form you put on the projector. Then, you put another sheet on top of the form sheet and write on it. As long as the two sheets remain in that position, the resulting projection looks like what you expect (a form with filled fields). However, if you remove the form...

This basic problem extends to the following cases (there might be more, but these are the main ones we considered):

• What, if either the form sheet or the receiver unit are misplaced (e.g. rotated by some degrees)?
• What, if you have multiple forms (or one form, that spread over several pages of paper)?

These problems show one thing: Having a representation of the bare form and the digital writing (also called "Digital Ink") is not sufficient to automatically convert the information hold by the writing to a computer representation that can be stored in a structured system.

The Solution

We considered one solution: We not only used the digital ink gathered from the device, but also a scanned image from the filled out form. Before you wonder: The image of the form is (standalone) not sufficient to gather all the information. So while it is perfectly possible to recognize the form elements printed on the sheet and even to separate the writing from the background, you currently cannot convert these information automatically to text. This is due to the fact, that handwriting recognition requires not only the actual shape of an object to convert it to text (or a single character) but it needs information about how that shape has been created, i.e. the separate strokes. These cannot be reconstructed from the scanned image.

So our approach is: From a set of ink files and scanned images, find the pairs that belong together. Next, find a projection (i.e. calculate a matrix that is applied to the ink data) such that you once again place the transparent with the form and the transparent on which you've written correctly (concerning our example with the overhead projector).

If you are interested, please have a look at http://www.gitorious.org/kpki2010. There you'll find what we developed over the last months. To give you a short overview:

General Structure

The project consists of several (standalone) programs. Each program does one step in the processing chain. This design is pretty useful: First, it allowed us to separate work. Additionally, every part of the chain thus can be replaced by another program. So rewriting a program or using an existing alternative is no problem. The sub-projects we worked on are:

imagefilter

This program is a command-line image filter (well, as the name suggests...) It's used to create a version of the scanned image that contains only the text data (as black strokes) and background. However, it is pretty generic; internally, it provides several filters. Each filter is a plugin (available as a separate library), thus, the program can be extended and used also in other contexts (not only for our project).

The program uses an interesting approach: It can be seen as a "scripting language for image processing". Each filter can be seen as a command. There are commands for file interaction (i.e. loading and saving), and commands that actually do something with the images in memory. This allows to use several filters consecutively to create interesting effects or generate multiple output images from the same source file in one program call.

As I already said: In our toolchain, the image filter program is used for preparing the scanned images, but it has the potential to be used in other situations as well ;)

img2roi

This tool is used to create a XML representation of the filtered images and rendered versions of the ink files. "roi" is short for region of interest, in our case this is a consecutive region in the image/inkfile (i.e. a letter or number or a whole word, if it is handwritten and there is no space between two letters).

Each region is written to the resulting XML file together with some "meta" information (bounding box/circle, center of gravity, ...). These values can later be used to compare two such XML files (where usually you compare a XML generated from a scanned image and one generated from a rendered ink file).

roimatcher

This tool is used to calculate a matrix which maps all regions from one input region file to the other. In our processing chain, it maps the ink files' regions to the regions in the scanned files. Additionally, it creates a "difference" value, that determines how much the two input region files differ from each other. This value is required to find the correct ink/scanned file pairs. Later more on this.

inktransformer

This tool is used to apply transformations to Ink files (or better: Ink XML files, an intermediate format, as the original Ink format is a proprietary, binary one :\ )

Summing it all up: formextract

This program is a "meta" program: As input, it takes a list of ink files and scanned images. It then uses the other programs to filter and process these files. After calling roimatcher on each ink/scanned file pair, it runs an optimization algorithm (namely simulated annealing) to find an optimal list of ink/scanned pairs. Then it continues on calling the other programs to generate transformed ink files and some XML files that contain the read texts from the ink files.

So, did it work?

Basically: Yes. The results we archived until now are satisfying. When the scanned images are of sufficient quality (i.e. scanned with enough DPI and not spilled over and over with coffee) the transformed ink files look pretty good and the found ink/scanned pairs are mostly correct, too.

Nevertheless; there's room for improvements. So the imagefilter part could use some recognition of figures as well for it's form recognition: Currently, it searches for the surroundings of the form by looking for something red (the color we used for the forms). However, we basically know how the form delimiters look like (dashes and plus signs), so the filter could check whether what it found looks like such a sign and if not, continue).

Additionally, image filtering is currently rather slow. Some improvements would not harm in this area.

Can I test it myself?

Unfortunately: No. While the programs we wrote are all released under the terms of the GNU GPL v.3, the program chain currently requires two additional programs (namely InkManager and InkRecognizer) that we do not own. If you are interested in testing and if you want to re-write this missing parts, just e-mail me (or have a look in the sources to learn how the missing parts are assumed to work).

=-=-=-=-=
Powered by Blogilo

Hi there,

as promised I want to give you a look behind the curtains of intelligent playing. Before that you have to know something 'bout artificial intelligence in general.