The problem most people have with gamepads in XNA is the fact that you can’t use any joystick type input apart from the XBox 360 controller. This tutorial shows you the most simple way to get joystick input in your XNA game.

The reason I’m writing this is because it took so long to get it to work myself and thought there should be a more useful tutorial on the net about it.

For this tutorial, I’m going to assume you already have an XNA game with keyboard input and just want to be able to use joysticks.

Step 1. Don’t use Soopah.

Although it was a really good little plugin, it’s no longer supported (last updated in 2007) and it only works with XNA 1.0.

Step 2. Grab SlimDX

SlimDX is a DirectX interface for use with C# projects.

You will need to download the correct version for your project, which will most likely be the x86, .NET 4.0 version. It can be found here: http://slimdx.org/download.php

Once downloaded, install it.

Step 3. Reference it in your project

Right-click on your project in the solution browser and select “Add Reference…”. Click “Browse” and browse to C:WindowsMicrosoft.NETassemblyGAC_32SlimDXv4.0_4.0.13.43__############# and select SlimXD.dll.

Or, you probably should copy that DLL file and paste it in your project (it depends where you want it) and then link it from there.

Step 4. Programming

Put this at the top of the files that you need to use methods from the DLL:

using SlimDX.DirectInput;

In your class, you want to declare some variables that DirectInput is going to use:

private DirectInput directInput;
private Joystick joystick;

For the setting up phase (initialize) parts, you want to add:

directInput = new DirectInput();

// Search for device
foreach (DeviceInstance device in directInput.GetDevices(DeviceClass.GameController, DeviceEnumerationFlags.AttachedOnly))
{
    // Create device                 
    try
    {
        joystick = new Joystick(directInput, device.InstanceGuid);
        break;
    }
    catch (DirectInputException)
    {
    }
}

if (joystick == null)
{
    // do error for no joystick here
}

// get joystick device objects
foreach (DeviceObjectInstance deviceObject in joystick.GetObjects())
{
    if ((deviceObject.ObjectType & ObjectDeviceType.Axis) != 0)
    {
        joystick.GetObjectPropertiesById((int)deviceObject.ObjectType).SetRange(-100, 100);
    }
}

// Acquire sdevice             
joystick.Acquire();

Then, when in your update loop, you need to get a key or direction from the joystick, just use code like the following:

// button press
if(joystick.GetCurrentState().IsPressed(0))
{
    // do some action like jump
}

// direction press
if(joystick.GetCurrentState().X < 0)
{
    // do some action for pressing "left" on the stick
}

If you need to disable the joystick, use the following:

if (joystick != null)
{
    joystick.Unacquire();
    joystick.Dispose();
}
joystick = null;

Of course, you may want to incorporate better error handling and probably implement this into your game’s input handler that controls the key presses. But as I said in the intro, this is a very simple implementation, and will be enough as a starting point.

If you have any questions or if you found this tutorial useful, please leave a comment.

Camera bug

I found a bug in my camera programming. The issue was that when the ray flying towards the camera HITS the transparent-able wall, it doesn’t go any further, which means if the camera is behind a solid wall, it never hits that, therefore the camera can go through walls if its behind a transparent wall.

To fix this, I put the transparent wall objects on the transparent effects layer and used that for things that are “not solid”. These include also the mother and children.

I then changed the programming to fire 2 rays instead: 1 to check with transparent things, and another to check with solid walls. This worked, however, I realized that it wouldn’t if there there was perhaps 2 transparent effects. This means I will need to do a loop of rays, each time ignoring the previous object, until the ray hits the camera. This will be quite difficult, and I may have to use some other method than a ray, or tweak the ray more so it can ignore certain objects or something. I did some research but couldn’t find much help.

Research

Other than trying to fix the camera, I also did more research for cameras. Looking into it at the beginning of the project, the camera seemed pretty straightforward, but as the project comes along it’s starting to seem more complex.

I had a look at some videos of games that used cameras such as Mario 64, Banjo Kazooee, Journey, and various other Mario games. One thing I notices, especially with Mario 64, was that the camera had an AI. It seemed that at certain times in the game, the camera would position its self and aim in certain directions depending on what was happening. For example, when Mario has to fight Bowser, the camera zooms into Bowser’s face from behind Mario, and when game-play starts, the camera “LERP”s back to its normal position (orbiting Mario from a set distance). The camera controls and type of view are signified by an icon at the bottom-right of the screen. There’s also wall avoidance that was included.

As well as this, I did some reading for the camera in Unitie’s 3d person tutorial. The only thing I found to do with the camera in particular was that the camera has a “near” and “far” camera, that are both combined to make the finished image. This seemed like a good idea, but for the time being we will just render everything to the current camera until any tests reveal slow-downs of the game.

After all this I can see that the camera is going to be a quite large task. It is also a main element of the game. I think for a good camera, it will need a lot of sections in every level that tell the camera to navigate to a certain angle if the player is standing in certain area, mixed with any key things in the level that need to be in view. I can combine these to try and get a nicer camera.

I might be just picky, or maybe I spend too much time screwing around in games trying to figure out how they made stuff.

I do notice that every time I see a bug in a game, it reveales some secrets on how it was made.

So one of my last posts was sort of about billboarding, and I found bad billboarding in Borderlands 2.

 

Herpaderrrrrrrrrr.