I've been looking at the output of the thumbsticks, and it appears a value less than 24% (0.24) is ever returned. I know it's very important to implement deadzone in your programs, but why has it been done for us Someone may want to write a game that needs a smaller deadzone, but as far as I can tell it would be impossible given we don't have full access to the output right the way from 0 to 1.
Is this behaviour intentional
Many thanks,
Adam Miles
XNA has it's own GamePad DeadZone?
Hot Topic
- Big Help and FAQ Post, also contains code to render 2D and 3D lines
- Rotating a Vector3
- XNA will changes?
- DreamBuildPlay is up!!!
- Where is my fragment linker?
- Creating cusom vertex format
- How modify vertices of a vertexbuffer? (C++)
- Limits of DrawPrimitive / VertexBuffer size
- Collision - Boundingbox
- Using XNA with VS2005
Game Technologies
- Fullscreen and Alt+Tab
- Destructible terrain 2D
- Sprite Doesn't Animate
- Doesn't Direct3DDevice9Ex support ID3DXFont ?
- Help needed with Spacewar Disaster
- After exception, can't save files: "The operation could not be completed. The parameter is incorrect."
- How do you implement Fog into a scene?
- 2D sprite transparency
- Duplicate DLLs when building application (C#)
- Are Visual C# or Game Studio buggy?
XNA has it's own GamePad DeadZone?
sarathy
I made a small test application in which I have a sprite rotated in the same direction as my left thumbstick. So when you press the left thumbstick upwards my sprite on screen points upwards, when you press the thumbstick downright (South-East direction), the sprite on screen also points in that direction. You get it :)
But now, when you make a full circle with your left thumbstick (from north to east to south to west to north), the sprite will not rotate smoothly. Due to having deadzones on both axes independently of each other it will stay most of the time at one of the 4 poles (north, east, south or west).
Will it be possible (in the upcoming release) to disable the deadzone
- Glow
missa350043
The documentation doesn't give any indication that those values are any more right than ones a developer would want to use. Losing 25% of the stick's travel seems pretty bad though, especially in the center where it's most sensitive. I can see your trouble though since the only way to set the deadzone is through a C++ compiler #define, I can't think of an easy way for you to expose it to us. It's not as simple as allowing #define XINPUT_GAMEPAD_LEFT_THUMB_DEADZONE 1000 in C# is it
Learning VB
Neither do I which is why I said the bug was the fact that the deadzones are being treated as though they are per-axis... that's what the line you quoted says anyway. Hence the reason they are clipping at the extreme top, bottom, left and right of the stick.
A deadzone should be just that, a zone around 0,0 where the controller is considered dead and the value clipped. At the moment, it appears that if X is outside the deadzone and Y is inside the deadzone, X will be still be clipped.
Just noticed your deadzone code... why would you want to create a deadzone round the outside of the stick's movement Deadzones are designed to eliminate jitter and slight movement round 0 so your deadzone should be inside, not outside.
Tecnomage
This one concerns me enough to file a bug for it myself.
Please vote for it here if you think the dead zone should be optional.
Andy.
randyvol
There is a bug that we should be returning values 0.0...1.0 rather than 0.24...1.0 after we calculate the deadzone. I'm wondering why you think you need to calculate the deadzone yourself Inside the deadzone, the values you get back from the controller are not reliable. I.e. they are never 0,0 and are pretty much random. The deadzone value we use is from the XINPUT API documentation. I'd be interested in knowing what you'd like to do with the raw value and the deadzone, assuming we fix the current values returned.
Terryj1
I don't think having dead-zones per axis is a good idea, because of the circular bounds of the stick. My favorite way of implementing deadzones on this sort of controller is to treat the axis values as polar coordinates, clip the magnitude below a threshold and normalise it. I don't have any tested code handy, but it would be something like:
low = 0.24 high = 0.95
stick = ( x, y )
mag = sqrt ( | stick | )
if (mag < dead) return (0, 0)
scale = (mag - low) / (high - low)
scale = max(0, min(1, scale)) / mag
return stick * scale
That way you also get a sort of dead zone around the outside, which means you can pick any point in the unit circle, but none outside it (assuming I didn't make a mistake).
I like the idea of using the XDK recommended dead zone by default (since it's known hardware), but it still might be nice to have access to the raw data as well (pad.Raw.LeftStick or something).
Chardiot
When I click Andy's link I get a Page Not Found error. Hmm
Personally I'd like to see the deadzone percentage be a property. 0.24 can be the default, but allow games to supply their own lower bound (including letting them set it to 0.0, which effectively turns the filtering off completely).
chubbysilk
Just wanted to let y'all know I worked out a partial solution to the deadzones in software. Adding in a delay to the orientation update based on the analog stick allows you to mask the deadzones you pass through on the way. Works great for large changes in stick position, which works well for me as I'm working on a tank game and wanted to tie the turrent orientation to an analog stick position.
Consider:
The tricky bits are handling wrap-around & deciding which direction to move.
Consider:
None of that is terribly hard, just takes a bit of thought & maths.
This won't solve the issue of moving the stick within the deadzone. IE: from 1, 0 to 1, 0.1 - that's still in the deadzone and there's just no data to work with. So slowly moving in a circle around the outside of the range of motion will still have hiccups. But it works really well for large motions.
I have some sample code, but it's heavily interwoven with my stuff right now. I'll see if I can't post a stripped down version soon.
vakman
Please make sure you submit your suggestion through Microsoft Connect. http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=682921&SiteID=1
Thanks!
ved_30
Hmm my mistake. I wasn't registered for connect. The generic "Page not Found" they serve when you click one of those links and aren't already registered is pretty horrible from a user confusion perspective.
Anyway, I'm aware of what the deadzone is and its usage and how simple it is to implement one's own code for it. I still believe a property is the most flexible way to handle it. Since most games are going to want some deadzone and since Microsoft already has code within the controller classes to deal with it, why not just make it an adjustable property Yes, you're only saving about two lines of code, but putting it in the XNA controller class saves those two lines everywhere else and people who want XNA to just not do any filtering can set the deadzone property to 0.0 and handle it on their own.
rsat
The actual bug lies in the fact that the horizontal deadzone is being reported when the vertical position is outside the vertical deadzone and visa versa.
Lateral movement round the edges should not be subject to the deadzones. It sounds for example like the vertical position isn't being taken into account when deciding if the input should be deadened.
Or at least, that's the way I see it working at present... If the input was raw, i.e. subject to no deadzones, the programmer could programme a customisable zone. With all the clever routines on here, I daresay that this would be a simple task for most of the XNA users. They could even write dampening code to adjust the sensivity at lower speed to keep the controller responsive but to filter out the slop as someone kindly called it.
nglow
Try it again, it seems to be ok. I presume you have registered and all that
I'm not sure a property would be all that much use - the dead zone attempts to cut off the range of movement that is inherent in the thumbstick 'slop', i.e. the amount it moves without significant force. Microsoft evidently see that 24% allows for all of the manufacturing tolerances (I say this because I have seen this value elsewhere as well) - and I am in no position to argue with that value, let alone reduce it. The issue for me lies in the way they implement the dead zoning (see above where a circular motion of the stick does not translate into a circular motion on screen), so you might want to implement your own method. Or alternatively you might not want a dead zone at all. And what makes it worse still is that the value jumps from 0 to 0.24 all at once. Imagine you are steering a car - do you really want the steering to jump to 24% once you leave the dead-zone I doubt it. In fact I can't really see one instance where it would be just right.
To be honest the code to do dead zoning the way it has been done in XNA, for each thumbstick, is 2 lines of code, and in my opinion is best left to the programmer (perhaps with a code example in the SDK).
Andy.
Alexander Petukhov
RSHORE