My camera: a Canon Powershot S1 IS (bought in the summer 2004)

• Start VMware.
• Plug in camera.
• Windows wizard for camera comes up, next next finish etc.
• Transfer files to VMware host.

Previous attempts at extracting pictures *gasp* without VMware.

• gphoto2 - error
• sudo gphoto2 - error
• su - ; gphoto2
• digikam - error
• kdesu digikam - error (used to work until recently)
• gthumb - error
• sudo gthumb - error
• su - ; gthumb - error

How friggin embarrassing is it that the same usb signal passing through the kernel and into VMware can be correctly processed in VMware, but not in linux?

I've searched high and low for a solution, this problem goes back a year. I've gone through various kernels, various versions of different libraries and applications, and the only thing that used to work was digikam in root mode. For some reason that doesn't work anymore.

UPDATE: After some renewed research (been months since last time I gave up on getting this fixed), it looks like the bug has been figured out. Installing gphoto2-2.2.0 (still marked unstable on x86) finally took care of it.

What a load off. And to think Windows helped fix it. :/

Say you were starting a project to develop a common application, like an email client, a web browser, a chat client, something along those lines. You would be well aware of the existing applications in this space, indeed that was your very reason for writing your own, you didn't quite like any of them. But in your quest to Build A Better World, would you consider re-using elements from existing applications, those elements which were entirely common and for which there was no reason to do otherwise? If you said yes, you're an exception. Because many would not.

Let's look at emoticon themes in different chat clients. Emoticon themes are so simple that defining a theme truly isn't more complicated than making a list of emoticons - and for each one, a list of replacement strings. This is how they do it.

Nothing fancy here.

Kopete's syntax says "look at me, I use xml, I'm so sophisticated".

Most elegant of all, perhaps, defining the emoticons as a native dictionary in Python, which is what Gajim is written in.

Three different clients, different syntax for each. But tell me this, is there any semantic difference between them? No, the all mean the same, they convey the same information, exactly the same. Each of these files has to be parsed differently (Gajim's natively, so the developers don't even have to write code for it), and each has to be written separately. Now, for someone, let's say, who creates an emoticon theme and wants to support these clients, that person has to deal with three different configuration files. Since they are semantically identical, it's not very difficult, but all the same it takes the effort to do it. And these three are just clients which make emoticon themes easy to use, there are others which aren't quite as easy on the user.

So what stands in the way of having one common syntax for this? One common standard? Kopete re-using gaim's format? Nothing. Other than isn't it awesome to write it from scratch?

I was on a quest to find a Windows jabber client That Doesn't Suck, which is a surprisingly tall order. Along the way, I came across Miranda, which looked promising at first. The project's goal, apparently, is to develop a small and easy client. The website makes a good impression, in fact it turns out to be a lot more fetching than the client itself, which isn't beautiful. But enough about looks. I was testing for a certain subset of features, and the first impression was good. Multi protocol client, low memory footprint, small windows, and it seemed to have all the essentials - file transfers, avatars.. hm no emoticons? Turns out Miranda is so small that emoticons are treated as a plugin. I download the add-on, a .dll (not the first thing that comes to mind when you say user friendly) and dump it in the right place. Yes, emoticon themes are supported. I'm interested in that, because I maintain one.

Now, it's bad enough that every client has a different way of dealing with emoticon themes. And these approaches do not vary in what functionality they provide, all of them do the exact same thing. Making an emoticon theme is no more complicated than this:

[default]
angel.png *angel* *A*
biggrin.png *biggrin* *g*
blind.png *blind*

The above is from gaim. It's simply a picture, and a list of replacement strings which activate it. There's nothing more to a theme declaration than this. For the purpose of my emoticon theme, I wrote a few simple scripts which generate these files (which are all similar). Thusly, I wanted to find out how to generate a theme file for Miranda.

I was in for quite a surprise. The declaration itself is very much the same, of course:

; defines-----------------------------------------------------------------

Smiley = ".\OGSmileys.dll", -127, "*biggrin* *g*"
Smiley = ".\OGSmileys.dll", -122, "*blind*"
Smiley = ".\OGSmileys.dll", -111, "(B) (b)"

But what of the smilies themselves? They're in a .dll file! That's right, in Miranda's Smaller, Faster, Easier spirit, they have stored the images in a .dll. This simply means that the same bits are aggregated in a library, there's nothing more happening there, they're not being compressed or processed in any way, just plain stored.

Need I mention that emoticon themes are supposed to be easy to create? It's not supposed to take a coder to do it, it's a feature for users to enjoy, to tinker with, without needing any help.

So for someone who wants to make themselves an emoticon theme for Miranda, they need a compiler! Yes, nothing easier than tossing a few images into a directory and setting up a definition (like the one for gaim), that any schmuck can figure out, no you have to compile the bloody thing. Screw that all the other clients are doing it this way, we don't give a shit, compile it or piss off. Needless to say, for me to find and set up a compiler just for this would be a humongous hassle and no sooner did I discover this interesting little quirk did I dump Miranda altogether.

The Miranda people are so in love with .dll's, that connecting to Google Talk (which is also an add-on), you need to download another .dll. Then you need to install an openssl library as a whole separate install. Yes, ssl also an add-on, who would possibly need that?

UPDATE: Apparently there are other ways to do this.

UPDATE2: Factual errors were discovered after this entry was written, as such I posted the link above, to the Miranda forum, where the clarification was established. However, not unreasonably so, the Miranda people have urged me to clarify the situation right here as well, so as not to misrepresent their client.

Emoticons in Miranda were historically stored in .dll's. That explains why the theme that comes with the plugin is as such. However, that is not the only way to store them, and the emoticon definition example included in the plugin (which I failed to notice), explains the different options, including just using pngs.

It was never my intention to misrepresent Miranda, and while my observation about .dll's was not incorrect, it was incomplete.

Alright so we have things now in graphics that some *raises hand* never thought would be realized. If you play the latest FIFA Soccer, you'll see some pretty accurate detail in the graphics. Players' bodies, facial characteristics, hairstyles, even their signature moves. In fact, if you just look at action shots from the game, you might think it's a pretty damn good reproduction of reality. But one thing that isn't quite right is how these characters move. That's because these models are just a bunch of dots in space, fitted with curves I guess and this makes up a very accurate model of their contours. Then the shapes are covered with mesh, that is bitmaps of some kind, which makes them look like 3D objects with surfaces, rather than just dots. Imagine fitting a towel tightly over a ball, covering it's surface completely. But they are hollow characters, their mass is completely unaccounted for. So when you render still images, they look striking, but when you try to animate these models, you're facing a whole new set of problems.

You couldn't build a real human being with just a shell, so in graphics you can take that shortcut. But when you move limbs around to simulate real human motion, it's not very clear exactly how to do this. What EA Games does is bring in some of these players they want to model, fit them with a large number of sensors all over their bodies, and tell them to move around just like they do when they're playing matches. So let's say you have a sensor at the knee and one at the shin. Now you can register the movement in all three dimensions of these two body parts relative to each other. And with enough points on the body, you get some kind of 4D model of human motion. What you can do now is plot these points where the sensors are on the human body to points on the computer model. You have to define joints to determine which parts move, but after that you can pretty much reproduce the same move that the human does with the computer model of the human. Pretty neat, huh?

If you think that's a big step forward, well there are still lots of problems to solve. A common problem in all kinds of games is collision handling. When two players run into each other, what happens? If you do nothing to handle this, they will just run through each other as if the other player was never there. Collision handling in football simulation games that I've played is still very primitive. Motion of the ball bouncing off the body is very unrealistic and hasn't improved much in years. Player collisions in the form of tackles are also very mechanical. The aspect of interacting bodies adds complexity to the problem, so let's go back to the single body in motion.

There is still a great deal missing in how just the one player moves. The moves don't look real. Even when they are modeled directly after human motion as described, their complexity is still too shallow to look real. I remember playing one of these FIFA Soccer games a few years ago and they chose Edgar Davids as one of their main profiles for that edition. Davids, of course, very characteristic for his dreads, which they modeled pretty damn well in the game. But guess what, even when his head moved, the hair didn't, it was as if he had overdosed on a whole can of industrial strength wax. The hair was completely fixed and moved along with the head, but it wasn't affected by gravity or anything like that. Hair is complex enough to illustrate this point very poignantly.

It comes back to what I said already, the human body is hollow, it has no mass. The surface is rigid, which means that when a player receives a ball on his thigh, the surface of his skin doesn't indent under the momentum of the ball, as it should. Mass responds to forces of nature - a hollow shell couldn't possibly. We are doing quite well with surfaces already, will the next step be to model mass? Just imagine what kind of human motion you could get if you modeled mass as well... hair flowing, muscles moving, ball motion that looks real as the foot connects with the ball and sends it away.. This is how I imagine it's going to work. You divide the mass into parts. Then you assign to each part a certain weight and typical characteristics of this portion of mass, that is how dense it is, how hard it is, and so on. Then you apply functions to these parts and determine their motion on say a grid of points. Much like the way you simulate synthetic materials with finite element analysis. The difference is that these are body parts, not distinct from each other, like the mechanical parts of a car. Then, for the purpose of a game, you have to combine the curvatures of the mass with the surface somehow, so that when muscles are contracted, the shape changes. For this to be accurate, you would probably plot much denser points at the surface of the mass than inside of it when simulating its motion.

What remains is still to define the direction of these forces. A mass modeled this way will respond as an inert body, but what is it that is exerting a force on it from a certain direction? This is the result of muscle motion, which again would have to be modeled somehow in order to get a self-contained solution. But if we leave that aside for a moment and go back to registering human motion with sensors like EA Games do, you would have a pretty complete model of human motion at this point. Just imagine what you could do with this, pretty neat things that haven't been possible so far. It's pretty hard to capture on film how a player shoots the ball, to capture the full complexity of the foot's motion when this occurs within fractions of a second. But if you could register this motion with sensors in a very detailed way, you could then recreate the motion, and add mass models to show how the mass would respond to this motion. In doing that you could make a video of how the foot moves just as it strikes the ball, zoom in on the foot very detailed and observe the actual muscles, the toes, everything. Now that would be some amazing detail.

Is this where we are headed?

The other day I was thinking it would be nice to have a little space below every blog entry that displays past entries from this same category, but in random. So this would be a cool way to explore old entries for someone who hasn't seen the blog before, but no less for me since I wrote that stuff at one point and forgot all about it. It was actually seeing KeyBi's blog that inspired me to do this, cause he has a random posts feature on his.

I used an existing plugin and modified it for my needs to look exactly as you can see at the bottom of this post.

• Random Posts From Category plugin: random_posts_from_cat_1_2.tar.gz

So now it's easier to browse old posts, but this brought out an old problem, namely that entries posted before the migration to WordPress were not input with their comments counted, so although these old entries have comments, WordPress doesn't seem aware of this. I fixed that with the simple script below.

<?

$user = '';
$pass = '';
$db = '';
$host = '';

$link = mysql_connect($host, $user, $pass) or die("kernel panic");
mysql_select_db($db);

$sql = "select ID from wp_posts where post_status = 'publish'";
$result = mysql_query($sql);

$IDs = array();
while ($row = mysql_fetch_row($result)) {
	$IDs[] = $row[0];
}

foreach ($IDs as $i) {
	$sql  = "update wp_posts set comment_count = ";
	$sql .= "(select count(*) from wp_comments where comment_post_ID = $i ";
	$sql .= "and comment_approved = '1') ";
	$sql .= "where ID = $i";
	mysql_query($sql);
}

mysql_close($link);

echo "Comments updated.";
?>