Category: programming

Wiimote fun

Some while ago, I was considering to buy a gyroscopic mouse from Gyration for my future Media Center, but I’m becoming more and more convinced I should simply buy a Wiimote instead 🙂

There are lots more possibilities while still fulfilling the original needs. The Wiimote IS a gyroscopic mouse but adds the following advantages:

  • IR blaster / receiver (1024×768 resolution!!) 4 point tracking @ 100Hz
  • relatively cheap! (40 EUR)
  • speaker
  • joystick and more buttons than standard mouse
  • on-board storage
  • programmer / hacker friendly
  • go play multiplayer on a friends console 🙂

After looking at all the neat programs Johnny Lee put together, I guess you understand I can’t wait to try this out myself 😉 Also, be sure to check out his blog and numerous videos floating around the web.

First time I heard of the cool wiimote possibilities was when reading a post of Xfennec, in which he made a simple showcase of the possibilities with libwiimote using his favorite 3D engine Raydium. Be sure to check out the vid. I was really impressed back then, but of course Johnny did a lot more impressive stuff, the guy is a legend by now. Johnny does not use the libwiimote lib, but rather the dotnet WiimoteLib (I mention this ref especially for andrasj 😉 )

I have to admit that at first glance the .net lib seems more attractive due to its event based mechanism (internally, it does an async read on a stream in a loop though). The C lib looks a bit more basic but very easy to get started.

DIY gadgets

I was quite astonished to read about this BUG platform: “an open source, web-enabled, modular software + hardware platform”. This kinda says it all. 🙂 It’s still in beta, but they are targeting Q4 2007 right now to release their BUG-base, the core product, featuring an ARM microprocessor and all kind of interfaces you might desire (notice the MPEG4 HW encoding/decoding support!). Like this featurefest is not enough yet, you can extend the base station with all kind of modules: “GPS, Digital Camera / Videocam, Touch-sensitive Color LCD Screen, Accelerometer, Motion Sensor”, you name it! Before you stop drooling over the hardware specs, save some drool to drool on the software specs. 🙂 They have it nicely running on an OSGi framework! Extension galore. Judging by the screenshots, I have the impression they are running it on the eclipse framework which is an extension of OSGi (Paul, correct me if I’m wrong ;)).

This really seems the ultimate “toy for boys” or “Lego Mindstorms for adults” 🙂 at least in a geeky world 😉

Reminds me of this site/magazine where creating DIY gadgets is just daily routine.. 🙂

Qt designer bug

Step 1: Start Qt Designer. Open your form. Qt designer hangs. Kill that stuff.
Step 2: Restart, but open another form. Qt Designer works just fine.
Question your sanity and repeat step 1 to see whether the hanging was just a glitch in the Matrix. Be stumped to see that it hangs again.
(Possible extension: create your favorite permutational combination of step 1 & 2 and repeat into infinity 😉 )

If this scenario seems familiar to you, then certainly read on…

Remember my little QtWorkbench issue I blogged about? Well, it seemed, the story got a tail too (that’s why I had to blog that first before I could say this =)).

During my struggle for correct compilation, I had modified the windowModality flag of my QMainWindow to Qt::Modal, in a desperate attempt to guide my app into the “Right Thread”. 😉
If I had modified that flag at any other point, I would have noticed the problem immediately, but being preoccupied with my QFtp thread problem at that time, I never went back to Designer and didn’t notice..
I know, it’s a stupid of me, but I still think it’s kind of a bug in Qt Designer. If you shouldn’t change the window modality of a main window, then they shouldn’t let you. 🙂 Moreover, you can’t change it back since as soon as you open your form, the form gets simulated in real-time and the dead-lock occurs. Or maybe even eventloop hijacking, sounds more l33t. 😛
Luckily, the gui is stored in plain XML, so you can just delete that section and you’re all set.

IDE wars: the battle for Qt

In my search for the best open source Qt-compatible IDE (for Windows, as for Linux, you don’t have to search ;)), I eventually settled with Code::Blocks. Don’t ask me why anymore, it’s been too long. 🙂 (I do remember testing QDevelop and Qtclipse). But if you have a look at CB, you will see it for yourself: a very stable, clean and versatile IDE. Qt support comes in the form of an (unofficial) plugin: QtWorkbench.

First of all, getting this plugin to work was REALLY a PITA (It involved compiling CB from SVN which was a challenge on it own), but very recently the author seems to provide some binaries which should make the experience all the more pleasant. 🙂 I was so happy when I first got it running, that I really didn’t care about half a dozen plugins being lost in the build process. 😉 (I never took it up again, who needs plugins? 😛 ;)) What’s more, code completion just worked and QtWorkbench created my .pro file all by itself.

After the honeymoon moment was over, I really got some nasty trouble though. Compiling debug simply did not work because apparently I don’t have the Qtdesignerd.dll and QtW insists on including it in the project file. So let’s remove it outside the autogenerated block like this:

CONFIG -= designer

Okay, first hurdle taken. Another hurdle was unfortunately a whole less obvious.
Continue reading IDE wars: the battle for Qt

Yet another 3D engine?

Back in the ‘old’ days, I once (actually thrice =)) wrote my own 3D engine just to find out Ogre did all of that and more. 😉 Naieve as I was, I was surprised to find a very similar design in it. 🙂 Still, at that time, it was more or less justified to roll my own because ogre was still growing up and I needed to implement a kind of volumetric texturing technique which was quite unconventional which made it not suitable as a plugin/extension for an existing engine. And as for everyone, for me too, it was great fun to make it from scratch. 🙂

The situation nowadays is a bit different. You would need to come up with a very good reason if you would like to convince someone you need to write yet another open source engine. It’s a fact that the open source 3D engine market is quite well established by now. Just take a look at projects like Ogre, Crystal space (go Jorritbelgian flag small! ;)), Irrlicht, Cube, …

Still, people DO seem to be able to find reasons. 🙂 Enter a world of dragons: the DragEngine. I think it’s an interesting approach which is typically inspired by open source roots (a closed commercial game does not have immediate interest in the flexibility that the DragEngine provides, or at least not to that extent (imho)). It’s definitely a project I want to follow-up, even just out of curiousity where it will end up. Because, let’s face it, it’s quite an ambitious project, developing its own tools/components from top to bottom.. I’m a bit surprised I never heard of it before, so that’s why I’m promoting it a bit now. 🙂 Keep up the good work!