 | | |
| | |
|
Spaces home  OBsIVProfileFriendsBlogMore |  Tools   |
OBsIVIt's obsessive.
September 28 Building your own Xbox 360 Input Machine (XIM)The XIM community is growing fast! Take advantage of the community’s experience in building XIMs by getting support from our new forum.
Last month, I published a write up with a demonstration video documenting a side project I’ve been working on: Xbox 360 Gaming with a Wiimote. What was intended as something friends could look at to see what I’ve been working on turned into something much larger than I anticipated. The reaction from the community was phenomenal. I never expected the kind of attention that it received (Engadget , Joystiq, Gizmodo, etc). Not to mention the level of traffic on my blog and views of the video. I’d like to personally thank all those that took time to check out my work – especially those who left comments of encouragement and praise.
With the level of interest XIM generated, of course, I expected people to be interested in trying it out for themselves. I’ve gotten many requests to share the technology. So I spent a lot of time thinking about the best way to do just that (given the limited amount of time I had to invest). Even though some soldering skills are required, I didn't want to require people to know how to program to use it. Yet, for those programmers out there, I wanted to make sure they had access to the low-level XIM services so they could adapt other input devices to the Xbox 360 themselves: flight sticks, musical instruments, VR gloves, SplitFish, trackballs, controllers from other consoles, etc. Since my introduction of XIM, I’ve continued to evolve the Wiimote profile (such as adding support for melee in Halo by swinging the Wiimote like a club – very satisfying :). I also recently added mouse and keyboard (MK) support too. What’s great about MK is it’s really easy to configure. Unfortunately, with the Wiimote profile, expressing anything more than the most simple gesture in a high-level manner (i.e. a simple configure file) is difficult without knowing how to program. For these reasons, I decided to stick with only exposing MK support at this time which includes my configuration application to make customization easy:
Screen shot of the XIM Mouse and Keyboard Profile application showing current button and stick translation status
What I’m providing: 1) Major parts list
2) Assembly instructions 3) Microcontroller firmware (binary form only) 4) XIM Profile and Configuration application (MK support only) 5) XIM SDK Cost: Free!
Special Thanks
The information I’m providing wouldn’t be of much use unless I had validation that XIM could be reproduced by someone else. I’d like to thank Egyokeo (a fellow modder) for not only verifying my steps and software work on a variety of system configurations, but, also providing valuable feedback in the form of bugs and suggestions of every part of XIM. You can check out his skills and his excellent use for XIM: Play Guitar Hero 2 on the Drums. (Yes, you read the right – it’s called MidiHero :)
Egyokeo’s XIM Implementation
Building Prerequisites
As you may have gathered thus far, XIM is a very powerful and flexible system that can really change the way you game on your Xbox 360. If you haven’t done so already, please look over my previous blog entry to get an idea of what it took to build XIM. I took care of the hardest parts (such as the microcontroller firmware and the PC software), and, as I mentioned before, I'll will provide this to you for free. But, there is still a cost. Besides having a PC close to your Xbox, you will need an XCM XFPS (see Parts List). You will also need to know how to do some moderately-precise soldering and know how to use a multi-meter.
If cost isn't a factor and you feel you have the technical skills to assemble the parts, then, it’s time to get into the details of what you’ll need. But, before I start, there are a few things concerning XIM's usage I want to cover. Terms of Use and Disclaimer XIM is being provided to you free of charge. You may use these instructions and software/firmware to build your own XIM for your own personal Xbox 360 gaming use. You may absolutely not sell XIM as part of any commercial product. XIM must remain free. You may not redistribute any part of XIM. All distribution of XIM (official assembly instructions, parts list, software, and firmware) can only come from me. In addition, I make no guarantee about the performance of the XIM hardware/software/firmware or the accuracy of the assembly instructions. I am also not responsible for any injury (or worse) that you may incur when building your XIM. Please don’t expect a considerable amount of support from me. You taking action in building XIM means you understand and agree with the terms of use and disclaimer I just covered.
Downloading the XIM Software/Firmware Package You can acquire the XIM software and firmware from the XIM Community Forum. The XIM package is found in the Download section and it contains all the software and firmware that you will need. It also contains the SDK which consists of a DLL, C header file, and C import library so that you can create your own systems for adapting just about type of input device to your Xbox 360. Assembly Diagram The XIM system is assembled with the following major components (details in the following Parts List section). PC – Silicon Labs ToolStick – PS2 Cable – XFPS 360 PRO – Xbox 360
Parts List
1) A PC running Windows Vista or XP
To date, verification has been made on PCs running Vista and XP Home and Professional (SP1 and SP2). You will need one free USB port. 2) Silicon Labs ToolStick Starter Kit
http://www.silabs.com/tgwWebApp/public/web_content/products/Microcontrollers/en/USBToolStick.htm (information) http://www.mouser.com/3plcart/cart.cfm?sid=63410000&pn=TOOLSTICKSK&pd=ToolStick%20Starter%20Kit (purchase) The XIM firmware runs on top of a Silicon Labs 8051 microcontroller. I was new to Silicon Labs when I began XIM, but, quickly became a fan thanks to the quality of their hardware and development environment. They are excellent.
The ToolStick Starter Kit (model number is TOOLSTICKSK) includes the ToolStick Base Adapter, a ToolStick C8051F330 Daughter Card and a nice retractable USB cable.
3) PS2 Extension Cable
You will be cutting this cable and soldering the wires on to the F360 daughter card. This is then plugged into the XFPS 360.
4) XCM XFPS 360 Pro
http://www.xcm.cc/XFPS_360_PRO.htm If you read my last blog post about XIM, I covered the importance of the XFPS and its ability to circumvent the 360’s peripheral security. Where the XFPS is a terrible mouse and keyboard adapter, it is a very good PS2 controller adapter. This is why XIM uses the PS2 connection. Unfortunately, this product is way overpriced for what you get. I wish I didn’t have to be giving people a reason to buy this device, but, it has a very necessary feature that you can’t get from anywhere else.
NOTE: XIM works on both the standard (Black) and “Pro” (White) version of the XFPS.
5) Wired Xbox 360 Controller
The XFPS requires this.
6) Project Enclosure Box (optional)
http://www.mouser.com/search/ProductDetail.aspx?R=CU-743virtualkey56310000virtualkey563-CU743 Although optional, a nice project box will protect your XIM hardware from dust or other unfortunate circumstances as the ToolStick boards are pretty fragile. It is best to mount the ToolStick in the box using double-sided foam tape (a piece under the USB connector, and one under the base/daughter-card connector).
Assembly Step 1: Soldering PS Connector to the Hardware The first step to building your own XIM is to connect your PS2 cable to the ToolStick F360 board. The F360 board has a series of connection points in the form of a grid. There are three columns (0, 1, and 2). Every column has 8 connectors (pins). Ground (GND) is separate. The PS2 cable must be cut and 6 of its wires connected to the board. The following picture shows which PS2 cable wire/pin goes to what point on the F360 board. Make sure to double check that your cable’s pin-wire color matches up NOTE: You can see I color coded the diagram to correspond to the actual color of the wires. For example, the yellow wire would connect to pin 1.4 on the F360 board. I also mention this is pin 6 on the PS2 connector. This is important since there is no guarantee that the extension cable you bought (likely from a 3rd party manufacturer) will match the wire color to PS2 connector pin listed: 1 = Brown, 2 = Orange, 4 = Black, 6 = Yellow, 7 = Blue, and 9 = Green. To be absolutely sure that, for example, pin 6 is the yellow wire, you need to use a multi-meter to measure the resistance between these two points. If you read ~0 ohms, then, you know it matches up. Once you have the connector soldered on, it’ll look something like this: PS2 connector soldered on to the ToolStick (compliments of Egyokeo) Assembly Step 2: Flashing the Hardware The second (and last) step to the XIM hardware is flashing (downloading) the XIM firmware onto the ToolStick. In order to do this, you will need to download Silicon Lab’s flash utility: Link to the Flash Utility page: http://www.silabs.com/tgwWebApp/public/web_content/products/Microcontrollers/en/mcu_winflashutilitiy.htm Click on: Flash Programming Utility under Download Now After you install the tool (assuming you installed to the default location), follow these steps: 1) Plug your ToolStick into your PC’s USB port 2) Go to: C:\SiLabs\MCU\Utilities\FLASH Programming\Static Programmers\Windows Console 3) Run: FlashUtil.exe 4) Under the Connect/Disconnect tab: a) Make sure the Debug Interface is set to C2 b) Make sure the Debug Adapter says it is USB Debug Adapter and the Adapter Selection has a serial number in it c) Click the Connect button (you should see a yellow and red LED light up on your ToolStick base adapter) 5) Go to the Download Hex File/Go/Stop tab: a) Under Download filename, click Browse and select XIMfirmware330.hex from where you extracted your XIM package b) Click the Download button 6) Go back to the Connect/Disconnect tab: a) Click the Disconnect button (you should the yellow and red LED lights turn off) 7) Close the Flash Utility 8) Unplug the ToolStick and plug it back in XIM Hardware is Ready At this point, your XIM hardware is ready. You should be able to plug one end of the hardware into your XFPS (via the PS2 connector, of course), and the other end into your PC. Run XIM.exe and try to navigating around the Xbox 360’s dash board by using your PC keyboard’s arrow keys. If you see the blades fly around as you’d expect, you are ready to go! One other thing to note is that the tool should constantly display around 29 updates-per-second. This is important to ensure best gaming experience. If it’s running below that, make sure there isn’t something else going on with your PC (such as background processes taking over the CPU). Now that the hardware is ready, it’s time to learn more about how you can configure XIM’s mouse and keyboard profile to best suit your gaming style. Introducing the XIM Mouse and Keyboard Profile The goal of the XIM MK profile is to provide Xbox 360 with the closest experience to mouse and keyboard gaming on a PC. Turns out that interfacing a mouse to an Xbox 360 game (especially shooters) is difficult to do well. Simple translations really show how bad it can be (such as what you get when using the XFPS's mouse and keyboard feature -- ouch). A shooter (like Halo 3) requires precision that you normally don’t get from playing with a low-precision device (i.e. the standard 360 controller’s thumbstick). That is why a generous amount of aim-assist features (in the form of auto-aim and acceleration curves) are included in the game to compensate for this deficiency. But, when it comes to a high-precision device like a mouse, these aim-assist features severely degrade the experience. This is why a simple mouse-to-stick translation isn’t enough. Something more complex needs to be in place to counteract these aides.
The MK profile supports many points of customizability (“knobs”) via a configuration file. Pressing CTRL-ENTER brings up the current configuration so that you can adjust the knobs. The default configuration file that ships with XIM is designed for FPS games (specifically, Halo 3) that use a 1600dpi mouse (such as the Logitech MX518). It’s easy to quickly try different adjustments – and you likely will). The default is based on how I play. For example, I have the “smoothness” knob turned off for Halo 3 so my reticule is very reactive. You may choose you want to have it feel “heavier”. Simply modify file and close it. XIM will reload your new values. Check out the log display to make sure you didn’t make any mistakes while editing the configuration file.
As mentioned, the MK profile supports many knobs of adjustment. In addition to standard buttons assignments (i.e. A = KeySpace), the controller stick mapping has many options to best map mouse moves to stick movement. For example:
DeadZone: All games have a threshold where stick movement isn’t registered until it reaches a certain point. This value makes it so that the smallest mouse change will result in on-screen movement. (More on this later.)
DeadZone Type: The shape of the dead zone (Circular or Square). (More on this later.) YXRatio: The ratio between Y and X movement for games that don’t have independent adjustable X/Y sensitivity. For example, 2.0 means Y movement should be twice as much as the equivalent X movement. TranslationExponent: When converting mouse movement to stick, this value allows you to do more than just a simple linear conversion. An exponential translation helps alleviate some of the acceleration that is there for controllers. SensitivityPrimary: Movement sensitivity multiplier. This combined with the YXRatio provides any combination of X/Y sensitivity. SensitivitySecondary: A second sensitivity value (typically higher than the primary). When activated, can be used for less-sensitive, non-aiming actions (such as driving vehicles). SensitivityToggle: The button to use to activate the secondary sensitivity. Smoothness: Smoothes out sudden movement by moving to the next translation position over time. The more smoothness results in a less jerky, but “heavier” moving reticule. SmoothnessCutoff: Smoothness adjusts positioning over time. The cutoff value stops smoothing when it reaches this threshold. Please make sure to configure your game for highest movement sensitivity. For example, in Halo 3, you’d change your look sensitivity setting to Insane. A Word About Dead Zone Dead zone is something that most gamers don't realize exists, but, is a very important part gaming when using a controller. A dead zone is the area of stick positioning that doesn't register as actual movement within the game. Without it, the reticule would constantly drift as thumbsticks generally never settle to a rest position (and where they do stop is typically different every time). Resting your thumb on the stick also constantly moves it slightly off center.
Where dead zone is necessary for thumbsticks, it is terrible for mice. Mice don't have the same rest-position problems as thumbsticks and the slightest movement is tracked by a mouse. At a minimum, a constant value needs to be added to any mouse movement that occurs to compensate for the dead zone. Otherwise, small movements wouldn't register and your movement will constantly "stall" if you aren't moving the mouse fast enough. Mouse and keyboard adapter devices like the SmartJoy FRAG (SJF) have this dead zone setting, whereas, the XFPS's mouse and keyboard feature does not. The XIM MK profile, of course, has this dead zone setting as well. But, it goes beyond this with allowing you to customize the shape of the dead zone too.
Most people that talk about dead zone never talk about its shape, but, it turns out that this is something that has a big impact on mouse translation quality. The XIM MK Profile has a dead zone "discovery" mode that you can use to not only determine the size of the dead zone, but, also learn more about its shape. It does this by moving the stick by the current dead zone value horizontally, then vertically, then finally diagonally. If do this on Halo 3, you'll see that, at a dead zone of 35, the reticule moves in all 3 directions. Then, if you reduce to 34, movement stops in all directions. This means that Halo 3 has a square dead zone of 34. (If it were circular, then, movement wouldn't occur in the horizontal and vertical directions, but, would still occur in the diagonal direction.) This actually surprised me since that means you need to move the stick further to get your reticule to move diagonally. Again, most people don't realize this since thumbsticks are so imprecise. In Halo 3, it appears that diagonal movement is actually more sensitive than the other directions. This may have to do with the fact that you have to move the stick further diagonally to cause the reticule to move. When you are talking about a mouse (where you want the smallest of mouse movement to cause your reticule to move), it feels less controllable when dragging diagonally because of this. The XIM MK profile allows you to specify whether you want your dead zone to be circular or square. I've found, in general, that mouse translation is better when you are working against a circular dead zone. But, how will this work with a game like Halo 3 where the dead zone is square? Turns out that a circular dead zone works nicely when it's grafted on top of the game’s square dead zone. Horizontal and vertical movements wind up being slightly beyond the dead zone area, whereas diagonal movement is slightly within. So, for Halo 3, a circular dead zone with a radius of 42 feels just right. XIM MK Profile Performance
I’ve been playing Halo 2 and now Halo 3 for awhile now with XIM’s mouse and keyboard support and have been thrilled with its performance. I love being able to game on Xbox Live playing Halo 3 on my big HDTV, on my couch with the mouse and keyboard of my choice. Any mouse and keyboard will work. I use a Logitech MX518 1600dpi mouse and a Thermaltake Flare gaming keyboard:
Picture of my living-room mouse and keyboard gaming lap-board “rig” that connects to my XIM The question you are probably asking is how well it actually works. I’m happy to report that it works incredibly well. Is it as good as gaming on a PC? I’d have to say its close. It’s subtle, but, you can still slightly feel that built-in controller auto-aim and acceleration I’ve talked about. The XIM MK profile does a lot to minimize these effects thanks to all the advanced settings you can tweak. As a result, the reticule still feels really solid. But, I can guarantee that it is, by far, better than any other Xbox 360 mouse and keyboard adaptor available. Unlike Halo 2, I’ve found Halo 3 doesn’t need any smoothness compensation at all. The look mechanics of Halo 3 have definitely changed (for the better). I feel that I’ve found the sweet spot of the XIM MK Halo 3 configuration with the combination of dead zone (with shape), exponential translation factor, and sensitivity I’ve chosen (plus all the other knobs). I can’t believe how responsive it is. It may be possible to perfect it even more, but, I’m ready to start putting in some serious quality Halo 3-time. :) So, after all the time and energy I put into XIM, was it all worth it? Absolutely! August 06 Xbox 360 Gaming with a WiimoteXbox 360 Input Machine (XIM) enables any PC input device to be used on the Xbox 360.
Since this blog entry was posted, an additional post has been made describing how to build your own Xbox 360 Input Machine (XIM). Click here for details.
I (like many others) am a proud owner of a Wii60. Us Wii60 owners feel that we've got gaming all covered. Our Xbox 360 gives us top-class hard core online gaming in high definition. Our Wii gives us really unique gaming experiences because the Wiimote is like nothing else. But, what if we could get the best of the Xbox 360 and the best of the Wii, together, in a single game? I was curious, and the end result is my creation that I call Xbox 360 Input Machine (or, "XIM" for short).
(Even though I chose to adapt a Wiimote to my Xbox 360, this system will work with any input device that a PC can recognize. This, of course, includes any gaming mouse and keyboard (wired or wireless) available.)
Why a project like this?
XIM is, by far, the most ambitious side project I have ever worked on. It took most of my spare time over many months to complete and there were a lot of failures along the way. People may wonder why I'd spend so much time on a project like this. I have no agenda behind it. The answer is simple: I enjoy it. I like working on hardware, software, and firmware. Given that I also like gaming, I felt this sort of project was a natural fit with my interests.
No matter what, I wasn't interested in creating vaporware. The end result had to work. I wanted something that I could play on daily that performed well.
Where to start?
The initial hurdle was to figure out where to start. We've seen devices come and go that let you use alternate input devices on the Xbox. Of course, there was the SmartJoy FRAG (SJF) for the Xbox, and now the XFPS 360 for the Xbox 360. Both these devices enable gaming using a mouse and keyboard with various levels of success. I own both of these devices and I can tell you that the SJF worked well on the Xbox (all my time with the device was spent on Halo 2). It was far from perfect, but, it was workable. As for the XFPS, that's a different story. It's performance is horrific (not to mention its hefty price tag). A lot of "SJF people" like me bought this device only to be very disappointed.
One redeeming trait of the XFPS is that it can also accept Playstation 2 controllers. It turns out that it does the translation to Xbox 360 very well. The XFPS also has another important feature: it circumvents the Xbox 360s security which prohibits 3rd parties from creating alternate input devices. Because of this, I decided to take my XFPS (which, at this point was collecting dust) and use it in my project.
Generating the right signals
As I mentioned, the XFPS can convert PS2 controller input to Xbox 360 input. This meant that I needed to emulate a PS2 controller. Turns out that the protocol is fairly well documented. The best source of information I found is here. The document describes the protocol in detail (using ASCII-art for the waveforms!). It turns out that the PS2 protocol is very similar to the standard Serial Peripheral Interface (SPI) (4-wire Master/Slave) that many microcontrollers support in hardware. It's not exact though. The PS2 protocol includes an controller-side acknowledgement (ACK) signal and it delivers bits in reverse relative to SPI. There was another issue too: the XFPS itself is emulating a PS2 console so, there may be slight differences in how it implements the protocol. Despite all these differences, I decided to go down the SPI route, and, I was glad it did.
The microcontroller and firmware
It's been many years since I used and wrote firmware for a microcontroller. Back then I was using a Motorola HC11 and the firmware was in assembly language. Compared to the types of desktop software development tools and debuggers we have today, it was a pretty primitive environment. As I was searching for a microcontroller platform to develop on, I was thinking (hoping) that times have changed. I'm happy to report they have.
It hasn't reached the level of sophistication of desktop software development environments, but, microcontroller development has come a long way. They now have integrated development environments (IDEs), in-circuit real-time debugging, and mature C-based compilers. There are quite a few offerings out there, but, the company that stood out amongst the rest is Silicon Labs. They offer a great end-to-end solution that includes affordable (cheap) development kits called their ToolStick line. For $25 I got a nice 8051-based kit that includes a prototyping area and also interfaces with the PC via USB. These processors are incredibly fast (25 MHz) and are only a couple of millimeters in size. And, most importantly, they include the SPI interface in hardware.
The "black box" in my design contains the development kit along with a PS2 controller extension cord cut and soldered on to the prototype area. The firmware I wrote configures the microcontroller to interface to the PS2 bus via the SPI interface. The ACK signal I mentioned before is also generated after an entire data transfer cycle is complete to inform the XFPS to start on the next cycle. The firmware also handles communication with PC via the onboard USB connection. The PC sends a PS2 controller state "packet" down to the microcontroller, then, in turn, the microcontroller places this data on the PS2 bus. Of course, timing is everything. Care was taken to ensure that the microcontroller is always responding to the XFPS quickly, otherwise, data would be corrupted or lost. At the same time, packets received from the PC must be buffered until the latest PS2 bus transfer is fully committed. As I was unfamiliar with development on this microcontroller, it took some time, trial and error to get this all working. The result turned out to be really solid and I'm happy with the overall design.
The PC connection
The requirement of a PC could be considered pretty "heavy-weight". Even though an underpowered PC is good enough, we are still talking about gaming on a console after all. But, the PC in the overall XIM-equation is a vital piece of the puzzle for a few reasons:
1) The ability to interface with just about any input device
As I mentioned before, the system can interface with any input device that the PC supports. Given that the Wiimote is a standard Bluetooth HID (Human Interface Device), existing OS interfaces could be used access the device.
2) The ability to model complex input translation "profiles"
Input translation is how input from the Wiimote is ultimately converted to input to the Xbox 360. The more I worked on this project, the more I realized that a "one-size-fits-all" solution just isn't enough.
Games for the Xbox 360 are simply not designed for anything other than a dual-analog game pad configuration and it differs per-game. First Person Shooter games are especially difficult due to extensive "aim assist" features (in the form of look acceleration and auto-aim) to make aiming with your thumb possible. These assist features make simplistic translations result in a mediocre play experience (i.e. "jumpy reticule") when using a Wiimote or mouse.
Every combination of game and input device truly requires a different (potentially complex) translation method (i.e. "profile") for best experience. My first profile is Halo 2 played with the Wiimote.
3) Shareable input translation profiles
It wasn't easy building a good translation profile between the Wiimote and Halo 2 on the Xbox 360. Since I'm using a PC, I could share the profile with someone else by publishing it online.
Talking to the Wiimote
The Wiimote and Nunchuk are great input devices. They are relatively straight forward to program against since they are standard HID devices. There is actually a decent sized community out there using the Wiimote in different ways. The main alternate use is gaming on the PC.
Accessing the Wiimote via HID APIs is one thing, but, knowing how to send commands to it and decipher data coming from it is another. I was happy to find that there is a decent amount of code available online that I could reference. The best I found is a .NET library. This code base gave me the vital information I needed to communicate with the Wiimote using my unmanaged C++ code base.
The Wiimote Halo 2 input translation profile
I was set. The hardware interface and firmware was done. I could send single controller state (button presses and analog stick positions) commands from my PC to the Xbox 360. It worked really well. I could also read input commands from my Wiimote and Nunchuk. But, the next hurdle was to take this live data from the Wiimote and convert it to Xbox 360 controller input that actually felt right in-game. Button presses are easy to map. What was going to be most difficult is mapping look (reticule) movement in Halo 2. (Why Halo 2? Because I love Halo and Halo 3 is right around the corner!)
I had two problems left now:
1) How to use a Wiimote in a fixed-reticule game like Halo
2) How to compensate for the aim-assist that made for jumpy reticules with Xbox mouse and keyboard adapters
Wiimote and fixed reticules
Anyone that has played a FPS game on the Wii knows that they use a "bounding-box" technique for aiming. The reticule moves with the Wiimote and look movement occurs when the reticule goes beyond an imaginary box on the screen. Once you get used to it, it controls very well and makes for really fun game play. I had the problem now of figuring out how to make Halo's fixed-point reticule move with the Wiimote.
Various PC demos I've seen used the tilt of the Wiimote to cause reticule movement. This struck me as awkward as it seemed like it would be difficult to control (especially restoring the Wiimote back to the "zero" position to stop movement). I went ahead and tried this sort of look translation, and, I was right, although movement was smooth, it was uncontrollable.
I decided to take the same approach as a mouse in FPS gaming. Reticule movement on screen would correspond to where the Wiimote is pointing (via its IR sensors). When you run out of "mouse pad" the mouse is picked up and repositioned on the pad. Similarly for the Wiimote, when the Wiimote exceeds the IR field, you use the A button to disengage movement and reposition the Wiimote. This feels the most natural and responsive to play. The negative to this was that, since the Wiimote IR is so sensitive, every little movement (including your hand shaking slightly) would translate to movement on the screen. This problem along with the game's existing "auto-aim" needed to be addressed.
Smoothing out the reticule
Making look (reticule) movement feel smooth turned out to be a recurring process of trial and error. Wiimote IR movement deltas couldn't be translated directly (linearly) to Xbox look thumb stick deltas without a jumpy reticule. I settled on an exponential translation curve to best help counter the affects of in-game acceleration. I then added smoothing algorithms to help keep the reticule stable. I still had a problem between precise aiming and fast turning.
I felt like given the constraints of the look mechanics of the game, I couldn't make both precise aiming and fast turning work with the same translation curve. That's when I decided to program in two curves which are switched based on the state of the Nunchuk C button. By default, turning is fast. But, when you need to be more precise on aiming, pressing the C button drops the sensitivity.
All this combined with independent X-Y sensitively and, of course, dead zone compensation, made for a good experience. It's not perfect, but, I feel with more tweaking, it has the potential of being great.
Where we go from here
As far as hardware, where I think where it should go is beyond the free time I have to invest. I'd love to see something like this packaged (i.e. all the parts) into a single device. The device would have to be sophisticated enough to accept new, relatively complex input transformation profiles. This means it would need to be able to interface with a PC in some way (ideally wirelessly) and be programmable via the PC. Of course, accepting more than a mouse and keyboard is a must (such as a Wiimote or other bluetooth devices).
But, for now, I'm looking forward to spending quality time gaming with this new setup, applying incremental improvements to the software and firmware, and coming up with new profiles for different games. February 25 Wii: Potentially the best First Person Shooter platformI’m a FPS fan. In fact, it’s my game type of choice. I just finished Call of Duty 3 on my Wii. That’s no real accomplishment, really. But, for me, it is because this was the first shooter that I’ve completed the entire campaign. The reason for this wasn’t because COD3 is a particularly phenomenal game. For starters, the whole World War franchise doesn’t excite me. COD3’s presentation had a washed out and muddy look to it. It had framerate problems a lot. Really, overall, it felt rushed out the door. Despite all this, it was the most fun campaign I’ve played. And, this wouldn’t have been true if I had played this game on any other platform. For me, the Wii made all the difference.
I’d say the Wii is my FPS platform of choice… almost. I’ve listed out what makes a platform great for shooters. The Wii almost has it all:
1) Control, not photo-realistic graphics, makes a game more fun to play
There has been a lot of talk over the Wii’s graphics power (or lack thereof) compared to the Xbox 360 and PS3. I just roll my eyes when I hear it. What makes a game more fun? What about a game makes it more immersive and compelling? It’s how you interface with the game. The Wii’s motion sensitive controller makes you feel so much closer to the action than standard dual analog thumb sticks. Don’t get me wrong, there is a learning curve (just like there is when learning to aim with your thumb). But, after you figure this out, aiming feels so nice and natural. I’d honestly have to say that the thought now of aiming with my thumb seems downright ridiculous.
As a first glimpse into how FPS control can be on the Wii, COD3 is a good start. It’s not perfect and I feel the game tries too hard to include too many different gestures into the game (some of them awkward and hard to execute correctly). But, overall, the core part of a shooter, the aiming, is impressive. What even better is that the nunchuck still gives you the fluid movement ability of an analog stick. Previews of future Wii FPS titles, such as Metroid Prime: Corruption, talk of even tighter aiming systems that are sure to make hard core gamers happy. I believe this since I’m experiencing smoother aim control even as latest titles come out. For instance, Wii Play’s target shooting game has a reticule that feels more stable, but yet remains really responsive.
(As a side, if you aren’t familiar with how FPS aiming works on the Wii, IGN has a great article about it.)
2) Fragging is best when kicked back on a couch
The fact that I’ve been talking solely about consoles, and not PCs, is deliberate. As far as control, when comparing a mouse and keyboard configuration to analog sticks, the mouse wins out for aiming and the analog stick wins for movement. But, where the PC loses out big time is whole comfort factor. Working a mouse while sitting at a desk is not most peoples’ idea of a great gaming experience. This is why consoles will always be the gaming platform of choice when compared to a PC.
Can you kick back on a couch and play a shooter with the Wiimote? Absolutely! Contrary to what you read on the web, you don’t have to play your Wii with your arms flailing with the risk of destroying your TV. The beauty of the Wiimote is that you can choose to play like you want to dislocate your shoulder, or, you can play like you would with a normal dual analog stick controller. For COD3, I played sitting with both wrists resting on my legs. My sensitivity settings were such that I barely needed to move at all to play yet I still could easily fire those headshots.
3) A solid online multiplayer experience is required
A good single player campaign is nice, but, what keeps a FPS title from being totally forgetful is online multiplayer. Easily, a shooter’s replay value is in its online multiplayer support. I’m not talking about minimum bar support here. A shooter’s online features need to include: solid matchmaking and ranking, easy game staging with good voice support, custom games with a good friends system, and solid network instability management to new a few.
This is where the Wii is potentially the best FPS platform. To date, we’ve gotten essentially nothing from Nintendo as far as online support for the Wii. At this point the ball is in Nintendo’s court. We’ve been hearing about the Wii’s online capabilities well before the console shipped. WiiConnect24 was going to solidify Nintendo’s position as a serious contender. The only problem is: where are the online games?
Nintendo, give us the FPS title we’ve been waiting for
Up to this point, Nintendo’s Wii has been a force of nature. Enormous sales figures and non-stop interest and hype continue to surprise naysayers. Wii is a console marketed as having something for everyone, which it is on the path to achieving. But, to win the console war, Nintendo needs to better target the hard core gaming crowd. Hard core gamers are intrigued by the Wii because of its radically different type of approach to gaming. But, the lack solid online multiplayer will inevitably cause this crowd to label the Wii as just a novelty.
I want Nintendo to succeed. This is why they need to make sure key franchises like Metroid Prime: Corruption will include online multiplayer support and they can’t wait until next Christmas to do it. I’m amazed how tight lipped Nintendo has been on the whole online multiplayer subject (especially with regard to Metroid). So far, Nintendo and the Wii have done well at not disappointing. I hope they don’t start now.
January 07 Custom Wii Sensor Bar for Large TVsI've never had so much interest in a console than I have with the Nintendo Wii. I must say, Nintendo shocked me back when they announced details of their new "Revolution". At the time, I was an Xbox addict (especially with Halo 2 online) and couldn't see what Nintendo could possibly offer me. I had written off Nintendo as a kid-centric company, not something for serious gamers. Then I saw the Revolution video showcasing what looked like a white TV remote control. At first glance, I thought Nintendo had lost their minds (how could someone play anything worth while with that thing?). It wasn't until they showed how people could use the remote (along with the optional nunchuck) when it really clicked. Whoa! Motion and direction-sensitive controlled gaming? I could easily see everyone wanting a console like this. Talk about innovation. But, how well will it really work? I was willing to wait 7 hours in line on launch day to find out. First impressions Upon opening the box, the Wii hardware stuck me as being elegant. Simply plug in the console and place the sensor bar and you have everything you need for a radical new way of gaming. So, I fired up my big HDTV and the console, sat back, and started moving my virtual hand across the Wii Menu. The result? The cursor was incredibly jittery. None of the demo videos I saw looked like that, so, I figured it must either be a bad setting or something with my environment. The sensitivity setting didn't help, but, what I did notice that getting up closer to the TV did help. In fact, it worked best when I was about 4' away from the sensor bar. My couch is 11' away from the TV, so, this was obviously going to be a problem (for me and every person that plays a Wii on a large TV). My next step was to move the sensor bar closer to me. My only option was the coffee table. But, it stands pretty low. The cursor was smoother this way, but, I was aiming below my TV for results (not to mention I was straining my arm to do so). The sensor bar really needs to right below (or above) the TV. To gain the correct line of sight between the remote and the bar so that aiming felt right, I had to put the bar on top of a big stack of books. This was ridiculous and not something I wanted to do every time I play my Wii. Not really a sensor bar It wasn't long before information about the sensor bar started showing up online. The fact is, the sensor bar isn't really a sensor at all -- it's an emitter. All the smarts are in the Wii remote. People had success with creating their own sensor bars. Many infrared (IR) sources would work (including candles!). Various wireless sensor bar configurations started popping up as well (you can even buy them now). This was great news as it opened possibilities for solving my dilemma. Wireless versions of the sensor bar isn't a good solution I wasn't interested in either creating or buying one of the wireless sensor bar solutions coming online. As I mention before, the bar needs to be positioned in such a way that the remote targets the screen correctly. What I really wanted was IR emitters that were on my TV's frame. With that, I came up with some goals. Project goals
Complete success Below is a picture of my 40" HDTV with my custom "sensor" bar affixed to the top of the TV's frame. I'm thrilled with the results! The on-screen cursor is incredibly stable. The cursor never jitters. It's even more stable than with the standard Wii sensor bar at close range (which was still jumpy for me when pointing at the far corners of the screen). Notice the distance between the emitters. The standard Wii sensor bar has emitters positioned 7.5" apart. As I mentioned before, I was getting best results at 4'. Given that I sit 11' from my screen, using simple trigonometry, I computed that the emitters must be spaced a litter more than 20" apart at my distance.
Each emitter uses 9 IR LEDs and is housed in a small 1" square project box. They are slightly tilted downwards to best hit my couch.
Each emitter uses 9 IR LEDs and each strand of 3 uses a special LED driver to guarantee constant and optimal brightness (i.e. an always constant current of 20mA through every LED). The emitters are driven using a standard 9V power adapter. The hardware was ordered online from Mouser and some was bought locally from Radio Shack. Total cost was around $25.
Hey Nintendo -- people want to play the Wii on large HDTVs I can understand Nintendo providing an out-of-box configuration that works for the lowest common denominator (i.e. people running on smaller standard definition TVs). It's good that Nintendo does appear to care about HDTV by selling component cables (by the way, a must if you are gaming on an HDTV) and supporting 480p widescreen modes. But, they absolutely need to offer an alternative sensor bar for owners of large TVs. A simple variation of the existing sensor bar would do. My advice to Nintendo is: make a sensor bar that is brighter and its width adjustable to enable gaming at greater distances. They'd make a lot of gamers happy. Parts List I'm including the parts list of the critical components that make up the emitters. The wire, 9V DC power source, on-off toggle, and power indicator light are common parts that can be found at places like Radio Shack.
The 20mA LED drivers used must have at least a 5V drop. Given that each LED drops 1.2V at 20mA. Three LEDs in series makes 3.6V which leaves 5.4V when a 9V power source is used. There are 6 LED "strands" total (3 per emitter) each drawing 20mA for a total of 120mA draw from the power source. Make sure your power source can handle that load (for example, the one I'm using from Radio Shack is rated for up to 300mA and I chose to use an M type connector). I wanted to keep the emitters as small as possible. As you can see from the pictures, there isn't a lot of room to house all these components. Be aware that precision soldering and drilling is required if a project box this small is used. |
|
||||||||||||||||||||||||||||||||||||||
|
|
