Time for another little game review, this time it is Peter Jackson's King Kong: The Official Game of the Movie turn. Short summary, its a good game. It is not great and it is not another The Chronicles of Riddick: Escape from Butcher Bay (i.e. awesome), but what the game does it does quite well. At the beginning of the game you arrive in the role as Jack on Skull island, things go a bit awry and you are left on the island to do some exploration. In terms of controls the game goes quite a minimalistic route, you basically have only two buttons to worry about, with the left trigger you hold up your gun up and aim, while with the right trigger you shoot if your gun is up. If you don't hold the left trigger you don't shoot but instead punch or grab things. Having to raise the gun before being able to shoot is a nice mix that gives the game a little realism that is missing in most other FPS. You also have the ability to focus on your NPCs with the A button, either to exchange weapons with them or to say a few words, it is a nice touch, even so I would have prefered it when the game would automatically focus on the NPC (ala Ico) instead of leaving the targeting to yourself, this would have helped in a few situations where the NPC get lost.
The major gameplay consists for most part of survival, i.e. you travel trough the jungle and have to fight against the animals that you find there. The fighting doesn't always happen with guns, but also a lot with spears. And you don't always have to fight them, sometimes it is enough to distract them by throwing something eatable near them that will keep them busy while you walk by. At times the animals will also fight against each other, which while nothing new (Doom1 had that already), it is nice to see a world that also acts on its own instead of only acting against the play. In addition to this you also have the ability to burn down bushes, which either kills the animals near by or frees a past you have to walk. Search for leavers and fire is used for puzzles in some situations.
Beside the survival part that plays more or less like a normal FPS, the game also features a third person part in which you play King Kong himself. These parts play similar to a classical beat'em up combined with a bit of swinging and climbing. While the control isn't perfect, it works quite well, considering that Kongs anatomie and walk cycle is quite a bit different then the normal human one. The ability to grab or let go Ann is used for some smaller puzzles.
The difficulty level is quite nice. I single hit will bring you into a 'red state' (for lack of a better name) from which you recover in a few seconds, but if you are hit in the 'red state' you die. This makes you quite vulnurable, but also forces you to be careful, which is a good thing. Tons of reset points gurantee that even with these two-hit-kills you never have a problem with frustration.
What the game fails to do is providing a decent story. That little story that you have is pretty much completly told through in-game dialog, while nicely done, it pretty much doesn't tell you anything about what is happening elsewhere or why you are on that island in the first place. So you just run around through the jungle trying to survive or rescue one of your NPCs which get lost every now and then, but you never really learn anything about what is happening elsewhere. So you only learn about plans to capture Kong right at the moment where it happens. The cutscenes that the game provides aren't really cutscenes in the classical sense, they are more there to bridge the loading time between the levels and don't provide any additional story. You are also left completly in the dark about the motivation of the natives on the island, they are really just canon fooder for Kong.
Another thing that the game fails to provide diversity. The game starts out nice and interesting, but nothing really changes through the course of the game. You start out walking through the jungle and you continue to do so for the rest of the game with the jungle pretty much looking all the same throughout the game.
Linearity is also a problem, with being trapped in a jungle one would expect some exploration, but none of that happens. You are confined to a very small path that you have to walk. You never bump into invisible walls, but the more visible ones can also annoy.
But for most part the game rather well, fighting against animals using spears and fire as weapons is a nice change compared to the standard run&gun FPS stuff. More diversity would have been nice, but even so the game keeps you entertained till. The story is a downer, maybe a less annoying one when you have seen the movie, but still I would have expected a bit more in that direction. A final word about the graphics: While overall nothing special, the game does a few nice things with (faked) volumetric lighting, that you normally don't see on an old Xbox.
Update: I just unlocked everything that there is to unlock in the game. Good news: the alternate ending is fun, Bad News: Web codes suck. Certain extras in the game require that you enter a code you receive from http://www.kingkonggame.com. The game gives you a code that encodes your score and when you enter that code on the webpage you get a different code in return that you enter into the game. The tracking of highscores itself is nice, however the web code is pointless and annoying. It doesn't require any special action on the page, but simply that you get a high enough score, which is the exact same way how everything else in the game is unlocked, just that you need to make a trip to the Internet for those three extras that use web codes. Anyway, the point why this sucks is that the web is fragile. Creating a new account on the webpage is already broken, using an account from ubi.com still works, but certainly not forever. In a few years down the road such connection with the web could really turn out trouble some, leaving a part of the game in a non-functioning state. Sure, it is only a tiny part in this game, two art galleries and an interview to be exact, but I still prefer it much more if games are self contained things that don't require external dependencies. It is not really a big issue here, but in other games things have already gone really bad, namely online servers for games have been switched of (Resident Evil on PS2 I think). And we will certainly see much more of this with all the DRM around.
Tuesday, April 29, 2008
Saturday, April 26, 2008
Rerouting input events on Linux
In the last days I have turned what began as a XBox360 userspace driver into a full blown event router. This means you can not only remap a few buttons, but have virtually total freedom in how to translate your input events. You can turn your dpad into axis, change the order of axis, add auto-fire, turn a normal button into a toggle button, merge multiple axis into one, do mouse emulation, emit keyboard events or pretty much whatever you like.The basic idea behind the thing is that you simply take any input event you can find on your system and then reroute it through as many control nodes as you like to turn it into something else and then output it via the uinput kernel service. The little picture on the right gives you a view of how such a routing network might look like. At this time there is support for recieving events from /dev/input/eventX as well as from XBox360 gamepads, but future extensions are quite possible and likely. There are of course also plenty of things missing, such as changing the configuration on the fly and abs events that have different ranges aren't handled well either, but overall it already works quite nicely and if you need to change mappings for a game that doesn't support it, you know can.
One thing I haven't figured out yet is how to best swap /dev/input/jsX devices, since the event rerouter naturally comes last, it will end up as /dev/input/js1 instead of /dev/input/js0, which some games might not like. Just using 'mv' of course works, but has some ugly sideeffects, since udev doesn't seem to register it.
Anyway, the thing is floating around as inputdrv in the current xboxdrv git repository. If you want to play with it, have fun.
Thursday, April 24, 2008
How to wreak your system, temporarly...
What do you do if you have a perfectly working system? You dist-upgrade and so I did from Ubuntu Gutsy to Ubuntu Hardy. After the "Update Manager" failed on me, no idea what went wrong there, I went the manual way with 'apt-get dist-upgrade', that went fine, even so dist-upgrade still keeps asking me stupid questions in the middle of the install. Anyway, all that done the system was ready for a reboot and so I did.
Result? My hard drives have gone missing. Turned out that in Ubuntu Hardy there is no longer a /dev/hda1, but its now a /dev/sda1. Since my fstab was free of any UUIDs that caused quite a bit of confusion and issues such as the lack of swap.
The fix was to figure out where all the drives went, that required a bit of detective work with cfdisk, but wasn't all to hard, hda became sda, hdb became and sdb and hdd became sdc, since hdc is now called scd0, great. Next step was to find the UUID and adjust my fstab so that this doesn't happen again. That can be done with "sudo blkid /dev/sda1", the 'sudo' part is important, else blkid will just report nothing, not even that you have to be root.
So what else is broken? The scroll/zoom-wheel on my Microsoft Ergonomic 4000 no longer works. That was kind of expected, since it required a kernel patch even before. On the positive side all the other buttons now work without a kernel patch, which they didn't before without a patch. But looks like I still have to patch the kernel and recompile to get everything to 100%.
Other then that I also had a weird crash/halt/whatever. Linux became pretty much completly unresponsive without any obvious load. Might be due to the lack of swap or something else, we have to wait and see if it happens again.
Result? My hard drives have gone missing. Turned out that in Ubuntu Hardy there is no longer a /dev/hda1, but its now a /dev/sda1. Since my fstab was free of any UUIDs that caused quite a bit of confusion and issues such as the lack of swap.
The fix was to figure out where all the drives went, that required a bit of detective work with cfdisk, but wasn't all to hard, hda became sda, hdb became and sdb and hdd became sdc, since hdc is now called scd0, great. Next step was to find the UUID and adjust my fstab so that this doesn't happen again. That can be done with "sudo blkid /dev/sda1", the 'sudo' part is important, else blkid will just report nothing, not even that you have to be root.
So what else is broken? The scroll/zoom-wheel on my Microsoft Ergonomic 4000 no longer works. That was kind of expected, since it required a kernel patch even before. On the positive side all the other buttons now work without a kernel patch, which they didn't before without a patch. But looks like I still have to patch the kernel and recompile to get everything to 100%.
Other then that I also had a weird crash/halt/whatever. Linux became pretty much completly unresponsive without any obvious load. Might be due to the lack of swap or something else, we have to wait and see if it happens again.
Sunday, April 20, 2008
Doing some art for Vegastrike
A few days ago I started to contribute some art for Vegastrike. I never actually have played the game, but so what? When I draw something I can try to draw something useful instead of something random, so I did some stuff on request for use in the in-flight communication displays:You can find more info in this thread in the Vegastrike forums. I actually like it to draw stuff on request, since that frees me from actually doing any creative work on it and doing stuff for a project that isn't my own also make it easier to get things done, since perfection becomes far less important.
Saturday, April 19, 2008
Hitting the invisible wall... again
Since I am still pretty much stuck in the last generation of consoles I am currently buying and trying pretty much every game that I think might have some interesting element in it, this after all isn't much of a problem when a used game only cost just 5€. Going next-gen where games cost 70€ might turn into a painful experience.
Anyway, one thing that really starts (did it ever stop?) to annoy me are the invisible walls and pre-scripted events. A recent offender is Brothers in Arms on the XBox. One can see that it doesn't try to be a run-of-the-mill WW2 FPS, since it introduces a new mechanic namely the suppression fire and flanking (previously seen in a better implementation in Full Spectrum Warrior), but yet it utterly fails at being that realistic shooter that it tries to be. Why is that? The reason is the same why pretty much every other FPS fails to provide anything that remotely reassembles a realistic experience: invisible walls.
A nice example of how stupid the invisible walls are in Brothers in Arms is a level in which one should take out a machine gun. Frontal attacking is of course a big no-no, so one has to move around it. Well, easier said then done since on the left there is no "around". The whole way is blocked by a huge stupid invisible wall, great, especially when it is not obvious that this actually should be a wall. The solution of course is to take the right path which leads one through a bunch of houses and gardens to finally take out the machine gun. So why is this bad? Easy, it destroys every tiny last bit of immersion that might have been in that game. Nothing takes one more out of the moment then not having to think how to solve a situation, but to try to figure out which way the level designer intended one to go. The whole game simply turns into a path finding experience around invisible walls instead of being a simulation of a gun fight. Brothers in Arms is of course by no means the first offender, Half Life 2 was full of that stuff and worst of all was probably Call of Duty 2, but in general you can find that stuff in tons and tons of games, you probably can find more games with them then without.
To make one thing clear, the problem here isn't the invisible wall by itself, one can't expect a level to be endless. But a level should be large enough to freely walk around in it. Don't place those invisible walls two meters from the path that I am supposed to go where I basically have to run into them when I don't exactly follow the predefined path. Also make them obvious, make them a lake, a river, a building or just a good old high stone wall so that I can see that there is a impassable wall and not a magic thingy that won't allow me to go further. There is of course another kind of invisible wall, not the one that marks the borders of a level, but one that is in the level itself, this kind is especially annoying. In Brother in Arms you have plenty of 50cm high stone walls, which look like you can jump right over them, except of course you can't. You can't shoot over them, but not jump. In a game without a jump button one could overlook such a blunter, because the underlying mechanic is obvious, even so a little stupid, but in a game with a jump button it is just ridiculous to not be able to tell which walls one can jump over and which one can't.
Well, what else can I say? One has to look no further then Operation Flashpoint to see things done right. The only wall there is, is the sea and you don't bump into it, you drown in it. And of course the land area you have is gigantic, it would literally take you hours to walk from one and to the other. This comes of course at a small price, the graphics are not so hot as in other games. But in terms of immersion it simply blows most other games away, since you really can walk to each and every point you will see in the game, you are never stopped by anything, except of course enemy fire. Operation Flashpoint of course is by far not the first game, flight simulations have had no invisible walls for a long long while and games like Midwinter didn't have them either (that was back in 1989, just to put things into perspective).
The other annoying point I mentioned: scripted events. Lets just say that in one level I died because the tank I had to protect was destroyed. No biggy, I restart at the last checkpoint and try again. What happens 30sec later? A cutscene starts and the tank gets destroyed. Right, the very tank for which destruction I failed the mission previously gets destroyed seconds later in the "mission complete" cutscene. Way to go. What idiot had that idea?
To sum it up: Games that behave stupid, destroy immersion, Brother in Arms does plenty of that, but so do most other games. Almost 20 years after Midwinter developers still haven't managed to turn their games into interactive simulations. And by simulation I don't mean that a game has to be realistic, it just has to follow consistent and logical rules. Mario64 does that to a much higher degree then Brothers in Arms. This is of course a weird comparison, but both Mario64 and Operation Flashpoint have some of those very qualities I miss in so many other games and that is the reason why those games stay fun even after years of playing while most other games already bore me when I haven't even solved half of it.
Honorable mention for in-game stupidity: "Splinter Cell: Chaos Theory". When you run out of ammo you would expect that you can pick up enemy guns, well, not here, if you are out of ammo you have to pretty much restart the level from scratch, since you can't pick up anything.
Anyway, one thing that really starts (did it ever stop?) to annoy me are the invisible walls and pre-scripted events. A recent offender is Brothers in Arms on the XBox. One can see that it doesn't try to be a run-of-the-mill WW2 FPS, since it introduces a new mechanic namely the suppression fire and flanking (previously seen in a better implementation in Full Spectrum Warrior), but yet it utterly fails at being that realistic shooter that it tries to be. Why is that? The reason is the same why pretty much every other FPS fails to provide anything that remotely reassembles a realistic experience: invisible walls.
A nice example of how stupid the invisible walls are in Brothers in Arms is a level in which one should take out a machine gun. Frontal attacking is of course a big no-no, so one has to move around it. Well, easier said then done since on the left there is no "around". The whole way is blocked by a huge stupid invisible wall, great, especially when it is not obvious that this actually should be a wall. The solution of course is to take the right path which leads one through a bunch of houses and gardens to finally take out the machine gun. So why is this bad? Easy, it destroys every tiny last bit of immersion that might have been in that game. Nothing takes one more out of the moment then not having to think how to solve a situation, but to try to figure out which way the level designer intended one to go. The whole game simply turns into a path finding experience around invisible walls instead of being a simulation of a gun fight. Brothers in Arms is of course by no means the first offender, Half Life 2 was full of that stuff and worst of all was probably Call of Duty 2, but in general you can find that stuff in tons and tons of games, you probably can find more games with them then without.
To make one thing clear, the problem here isn't the invisible wall by itself, one can't expect a level to be endless. But a level should be large enough to freely walk around in it. Don't place those invisible walls two meters from the path that I am supposed to go where I basically have to run into them when I don't exactly follow the predefined path. Also make them obvious, make them a lake, a river, a building or just a good old high stone wall so that I can see that there is a impassable wall and not a magic thingy that won't allow me to go further. There is of course another kind of invisible wall, not the one that marks the borders of a level, but one that is in the level itself, this kind is especially annoying. In Brother in Arms you have plenty of 50cm high stone walls, which look like you can jump right over them, except of course you can't. You can't shoot over them, but not jump. In a game without a jump button one could overlook such a blunter, because the underlying mechanic is obvious, even so a little stupid, but in a game with a jump button it is just ridiculous to not be able to tell which walls one can jump over and which one can't.
Well, what else can I say? One has to look no further then Operation Flashpoint to see things done right. The only wall there is, is the sea and you don't bump into it, you drown in it. And of course the land area you have is gigantic, it would literally take you hours to walk from one and to the other. This comes of course at a small price, the graphics are not so hot as in other games. But in terms of immersion it simply blows most other games away, since you really can walk to each and every point you will see in the game, you are never stopped by anything, except of course enemy fire. Operation Flashpoint of course is by far not the first game, flight simulations have had no invisible walls for a long long while and games like Midwinter didn't have them either (that was back in 1989, just to put things into perspective).
The other annoying point I mentioned: scripted events. Lets just say that in one level I died because the tank I had to protect was destroyed. No biggy, I restart at the last checkpoint and try again. What happens 30sec later? A cutscene starts and the tank gets destroyed. Right, the very tank for which destruction I failed the mission previously gets destroyed seconds later in the "mission complete" cutscene. Way to go. What idiot had that idea?
To sum it up: Games that behave stupid, destroy immersion, Brother in Arms does plenty of that, but so do most other games. Almost 20 years after Midwinter developers still haven't managed to turn their games into interactive simulations. And by simulation I don't mean that a game has to be realistic, it just has to follow consistent and logical rules. Mario64 does that to a much higher degree then Brothers in Arms. This is of course a weird comparison, but both Mario64 and Operation Flashpoint have some of those very qualities I miss in so many other games and that is the reason why those games stay fun even after years of playing while most other games already bore me when I haven't even solved half of it.
Honorable mention for in-game stupidity: "Splinter Cell: Chaos Theory". When you run out of ammo you would expect that you can pick up enemy guns, well, not here, if you are out of ammo you have to pretty much restart the level from scratch, since you can't pick up anything.
Tuesday, April 15, 2008
Sending webpages to the OLPC
Ok, this little script is rather minimalistic. Every now and then I visit a longer webpage and want to read it on the OLPC instead of my good old CRT, trouble is: How to be get the URL onto the OLPC with minimal effort? With Opera at least there is an easy solution:
#!/bin/sh
ssh olpc@192.168.1.100 "DISPLAY=:0 opera -newpage \"$1\""
# EOF #
This little script will take the URL and send it to an Opera running on the OLPC. You use it like:
% olpc-send http://grumbel.blogspot.com
And the page will magically appear on your OLPC. The script works best if Opera is already running on the OLPC.
#!/bin/sh
ssh olpc@192.168.1.100 "DISPLAY=:0 opera -newpage \"$1\""
# EOF #
This little script will take the URL and send it to an Opera running on the OLPC. You use it like:
% olpc-send http://grumbel.blogspot.com
And the page will magically appear on your OLPC. The script works best if Opera is already running on the OLPC.
Sunday, April 13, 2008
Hunt the sync button...
In the adventure to try to find out how the wireless XBox360 controller gets synchronized with the wireless USB adapter for the PC I did a little search for a sync button on the controller to see if its just a button or some deeper magic that triggers the synchronization. That shouldn't be so hard you think as there are plenty of pretty product images on the official page, right? Well, turns out not to be that easy, since half the picture actually don't have a sync button.
On the other side one should of course never believe that a product image actually shows the actual product or even something that is at least functionally equivalent, nope, seems just some early prototype from fantasy land, since the real thing does look quite a bit little different and yep, thats a sync button right there.
PS: Google really should do something about their image search, these days Flickr is far more useful in the hunt for a picture of a thing then images.google.
On the other side one should of course never believe that a product image actually shows the actual product or even something that is at least functionally equivalent, nope, seems just some early prototype from fantasy land, since the real thing does look quite a bit little different and yep, thats a sync button right there.
PS: Google really should do something about their image search, these days Flickr is far more useful in the hunt for a picture of a thing then images.google.
Friday, April 11, 2008
Why git rocks...
Over the past weeks I have started to really like git, but not because all the cool branch and merge stuff or because it is a distributed SCM, nope, for a much different reason: Simplicity.
Every now and then I start a new toy project and more often then not, it is just not worth the time to setup a proper SVN repository for it, it is just a few lines in the shell, sure, but you don't want that for 'hello world' and more importantly you don't want to do it after you already have a working directory, since moving all the files is a hassle and ensuring that everything actually lands in the repository even more so.
With git it is different, it is just one line: "git init" and you are done with creating the repository and moving your working directory 'into' it. After that it is just "git add", "git commit" and so on as you would do with SVN or basically any other SCM tool.
Now is git "perfect"? Nope, some things that irritate me is the lack of directory tracking and the handling of binary files. Lack of directory tracking isn't a big deal, but the binary file handling really gets me worried about what happens when you publish a git repository. When you delete or update binary files regularly you don't want a user to download all versions of a file, you want him to download just the latest one. But with git that isn't possible, since a 'git clone' copies the whole repository with all the history. Not a big deal for text, which can be well compressed and diffed, but with binaries? That could likely cause trouble. This becomes even more problematic when your repository not only contains binaries needed to run a program, but source files that might be much larger then the file needed to run the program. A short test shows that this turns a 50KB download easily into a 20MB download (game texture drawn in multilayer 1024x1024, resized to 256x256 for in-game use). Increasing the download size by 400 fault isn't fun.
Some of this could of course be handled by using multiple repositories, instead of just a single big one, but then even with a splited one you would still have the issue with the multiple versions of the same file that a user has to download. Maybe special filters that aid the compression would help, at least for images that might be doable in theory for some cases. But overall I think the best or even only solution would be a form of lazy-cloning from a remote repository, only copy what is actually needed for a working directory tree, not everything.
But that said, for small or text-only projects git just rocks, it is so simple to use, that even "hello world" is already enough to use it. git makes version control so cheap that there really isn't much reason left to not use it.
Every now and then I start a new toy project and more often then not, it is just not worth the time to setup a proper SVN repository for it, it is just a few lines in the shell, sure, but you don't want that for 'hello world' and more importantly you don't want to do it after you already have a working directory, since moving all the files is a hassle and ensuring that everything actually lands in the repository even more so.
With git it is different, it is just one line: "git init" and you are done with creating the repository and moving your working directory 'into' it. After that it is just "git add", "git commit" and so on as you would do with SVN or basically any other SCM tool.
Now is git "perfect"? Nope, some things that irritate me is the lack of directory tracking and the handling of binary files. Lack of directory tracking isn't a big deal, but the binary file handling really gets me worried about what happens when you publish a git repository. When you delete or update binary files regularly you don't want a user to download all versions of a file, you want him to download just the latest one. But with git that isn't possible, since a 'git clone' copies the whole repository with all the history. Not a big deal for text, which can be well compressed and diffed, but with binaries? That could likely cause trouble. This becomes even more problematic when your repository not only contains binaries needed to run a program, but source files that might be much larger then the file needed to run the program. A short test shows that this turns a 50KB download easily into a 20MB download (game texture drawn in multilayer 1024x1024, resized to 256x256 for in-game use). Increasing the download size by 400 fault isn't fun.
Some of this could of course be handled by using multiple repositories, instead of just a single big one, but then even with a splited one you would still have the issue with the multiple versions of the same file that a user has to download. Maybe special filters that aid the compression would help, at least for images that might be doable in theory for some cases. But overall I think the best or even only solution would be a form of lazy-cloning from a remote repository, only copy what is actually needed for a working directory tree, not everything.
But that said, for small or text-only projects git just rocks, it is so simple to use, that even "hello world" is already enough to use it. git makes version control so cheap that there really isn't much reason left to not use it.
Thursday, April 10, 2008
Writing an XBox360 driver...
A long while ago I bought a XBox360 USB pad (the one with a cable) for use in Linux and for a while that worked good enough, however recently the standard xpad driver has caused plenty of problems for me. Main problem, it crashed and left the USB system in an inconsistent state that could only be fixed via a reboot. It also had issues with always detecting four XBox360 controllers instead of just the one that was actually plugged in. I didn't really bother much to fix it, since each time I plugged the thing in required a reboot and that wasn't fun. My knowledge of kernel internals is also happens to be rather limited, so I didn't even try to fix the xpad driver itself.
Long story short, I started a userspace driver for the XBox360 gamepad (wired USB version). And to my surprise that turned out far easier then expected. No messing around with HID, no magic init strings or whatever, you just read from the USB port with libusb, interpret the 20 bytes the controller sends and you are done. To turn the LED on or off or let it blink just three bytes are needed and that worked easy enough as well.
Now would a kernel driver be better? I am not so sure. For one thing it would of course allow easy plug&play if there would be a kernel driver that worked, but on the other side a userspace driver has the advantage of allowing much more customization. Now I haven't implemented any of that, but in theory it should be rather easy to allow free remapping of buttons and to turn axis into buttons and visa verse, which especially on the XBox360 controller with its analog-triggers should be a useful feature.
Anyway, the XBox360 driver as it is now works, it doesn't do anything special, but it gives you a joystick device as you would expect, thanks to uinput. To use it just compile it via 'scons' and then start the xbox360 binary. Make sure you unload the regular xpad driver before this. Once the binary is started a /dev/input/js0 will be created and the thing is ready to use.
You can obtain the driver from:
Long story short, I started a userspace driver for the XBox360 gamepad (wired USB version). And to my surprise that turned out far easier then expected. No messing around with HID, no magic init strings or whatever, you just read from the USB port with libusb, interpret the 20 bytes the controller sends and you are done. To turn the LED on or off or let it blink just three bytes are needed and that worked easy enough as well.
Now would a kernel driver be better? I am not so sure. For one thing it would of course allow easy plug&play if there would be a kernel driver that worked, but on the other side a userspace driver has the advantage of allowing much more customization. Now I haven't implemented any of that, but in theory it should be rather easy to allow free remapping of buttons and to turn axis into buttons and visa verse, which especially on the XBox360 controller with its analog-triggers should be a useful feature.
Anyway, the XBox360 driver as it is now works, it doesn't do anything special, but it gives you a joystick device as you would expect, thanks to uinput. To use it just compile it via 'scons' and then start the xbox360 binary. Make sure you unload the regular xpad driver before this. Once the binary is started a /dev/input/js0 will be created and the thing is ready to use.
You can obtain the driver from:
Subscribe to:
Posts (Atom)