Pandora Nubs Acting As A Switch?

[kuru]

I was watching one of those quake on pnd videos when I started wondering whether it would be possible to allow for influence on movement speed via the nubs, even if the engine of the game in question wouldn't originally allow for it.
Hence I know nothing about game engines it could very well be that the next sentence (or the whole topic) is moot, should quake feature variable movement speed opposed to just run/walk.

So I'm not thinking about a, say, 5-or-more speed system like mario 64, but just a trigger that sets the char to run if the nub travels further than 75% from its center or similar. If we could get this, or even "real" analogue movement (speeds) to work, I see a big improvement in how it must feel to play one of those games.

Is it possible to "grab" an input event and "chain" another to it, so the nub travelling past a certain point would trigger run/walk?

 

[lulzfish]

This should be easy to do as long as the games aren't closed-source.

For emulators and open-source ports, you would just re-write the input functions slightly to do that.

 

[calc84maniac]

I actually do wonder if something like PWM could be applied according to the nub position for games that use digital controls. That is, if the nub is moved halfway to the right, it should switch the state of the virtual digital button on and off so on average it is on during half the frames. I imagine something like this could work even in the original Super Mario Bros.

 

[bzar]

[quote post='729943' date='31 May 2009 - 09:25 AM' name='B-ZaR']
How about configuring the nub so, that the player walks if the nub isn't pushed to the edge and runs if it is? Something like <75% = arrow keys, >=75% = shift+arrow keys?

yeah that's doable although the always run option would need to be off
[/quote]

 

[kuru]

I see, has already been asked Thanks guys.

 

[x86Daddy]

Another way this would be very useful: if nub-as-mouse input is developed/enabled, moving the mouse cursor faster based on the extremity of nub tilt would be very helpful!

 

[Pleng]

I had a thought similar to this for emulators a while back. Perhaps you could set the nubs up so that they essentially simulating hammering the arrow buttons very fast, increasing the speed as you pushed further, then only registering a full hold on the button when pushed to the extreme. This could make an interesting psuedo analogue control system that could be great for driving and flying games. I'm thinking the original Mario Kart on the SNES, and Virtua Racing on the Megadrive and 32x especially.

 

[typs lik dis]

I think the nub-mouse function will be analog by design. It probably wouldn't be implemented as key presses.

 

[Phawx]

I seriously can't wait to mess around with the nubs on the Pandora.

 

[MWeston]

Using the nubs as buttons doesn't really work but might be possible in some sense as I will explain. There was a time in the past where tapping the nubs without actually deflecting them was generating values but it was a firmware bug and messed up the calibration or it was the result of not calibrating the nubs first (which has to be done on each power up; takes about 2-3 seconds). It has been fixed since then and now tapping on them without really moving them may or may not generate numbers. In theory, the act of pressing on the disc can be enough to activate the interrupt in the controller which would then generate an interrupt to the host, reporting zeros as the position from center if your finger doesn't move. This could be interpreted as a button push but I don't know if it is predictable enough to be considered a feature or a good luck thing. I'd have to dig up one of Notaz's old programs that spits out raw I2C data as I'm not sure if the event driver handles it raw enough to show this.

As for mouse pointers, the nub controller firmware was originally designed exactly for this application and then we got them to design custom nubs for us to use with gaming. The controllers output both relative and absolute data. Games probably like absolute data since it is a direct 1:1 output of deflection. A mouse likes the relative data as each time you poll the controller you can see how far the nub has moved since you last checked it which is a good indication of speed and direction.

 

[trix]

Can't you simply cat the device? I use to cat /dev/input/js0 to test out random gamepads and make sure input works without actually installing drivers for them all.

 

[mindlord]

Can't you simply cat the device? I use to cat /dev/input/js0 to test out random gamepads and make sure input works without actually installing drivers for them all.

MW says that just touching the nub will cause it to send a stream of 0's but cat can't print those. I'm pretty sure you're aware that 0's are null characters and don't print, but for the uninitiated they might not get that.

 

[rabidpoobear]

Can't you simply cat the device? I use to cat /dev/input/js0 to test out random gamepads and make sure input works without actually installing drivers for them all.

MW says that just touching the nub will cause it to send a stream of 0's but cat can't print those. I'm pretty sure you're aware that 0's are null characters and don't print, but for the uninitiated they might not get that.

are you sure it's sending its deflection values as binary, not as ascii representations of the integers? I would think it would send them as ints, because otherwise you couldn't have negative values...
I don't really know how catting most devices works though, I've only catted GPSes, but they don't send out binary, they send out ascii of the NMEA sentences.

 

[trix]

I could be wrong, but I was under the impression that zero and null were different in most cases, zero being a valid value between -1 and 1, null being no value at all.

 

[rabidpoobear]

I could be wrong, but I was under the impression that zero and null were different in most cases, zero being a valid value between -1 and 1, null being no value at all.

mind lord is saying that the values would be catted as binary, so if the nub is deflected 0 then it will be 0x00 in ascii (which is the "null" or "string terminator" character) and if the nub is deflected 0x61 then you will see an "a" on the cat output (because 0x61 is ascii 'a').
I was saying that it's probably going to cat values in ascii, so if the nub is deflected 0 it will send 0x30 (the ascii value of the character '0').

 

[mindlord]

The device is sending all kinds of wild SIGNED INT data to /dev/input/js0 cat doesn't know what that is so it treats the incoming stream as a unsigned INTs which it converts to ASCII and blurts out on the screen. 0 in ASCII is a NULL, so nothing prints there.

edit: ninja'd

 

[rabidpoobear]

In case you guys didn't pick up what MWeston was saying, he was saying that it may be possible to use 0 values from the nubs as a "click" even though we don't have an actual switch built into them. He wasn't talking about being able to read the values from the nubs, he's saying that the controller may or may not actually send the "0" values when the nubs are pressed. If they do, and it's reliable, then we can have clickable nubs even though they technically aren't made to be.

 

[trix]

mind lord is saying that the values would be catted as binary, so if the nub is deflected 0 then it will be 0x00 in ascii (which is the "null" or "string terminator" character) and if the nub is deflected 0x61 then you will see an "a" on the cat output (because 0x61 is ascii 'a').
I was saying that it's probably going to cat values in ascii, so if the nub is deflected 0 it will send 0x30 (the ascii value of the character '0').

^^^ Yes! That's what I meant, sorry, I am not so clear sometimes. I have never seen the output of catting a device return binary values, though I haven't catted all that many devices, usually gamepads and input devices. And, we are talking about a gamepad. Is the Pandora's gamepad controls handled via /dev/input/js0 like a joypad or does it have a special device that combines it with keyboard?

I suppose the only way to know for sure if catting it will return binary or not is to have someone with a Pandora try it.

@mindlord: Ahh thank you for the clarification, I've never attempted to read a zero value on a device with cat so I didn't know it would send it as null rather then zero (0x30). Well I learned something new!

@rapidpoobear: Yep, that's what we are talking about. I was attempting to suggest to MWeston to use cat on the device to discover if it sends zero value when the nub is touched but not moved, to discover whether or not we can read that value as a click.

I love the smart people on these forums!

 

[mindlord]

I wouldn't (as a dev) use this anyways.

It means that just by resting your thumb on the cap it's "clicked" so not useful unless you're also not using the nub for it's analog input as well. The natural inclination is to rest your thumb lightly on the cap at all times when using the nub for analog input so it would always be "clicked". The only place this would be useful is to replace the entire function of the nub as an analog stick with a button press, in which case any random input would do. So simply flicking the nub lightly would be more reliable than just tapping it with your thumb. Just tapping it would likely generate enough real data to interpret the action as a "click" anyways. Even just jostling the unit a bit might produce a stream of 0's without even touching the nubs. "Damnit, the bus hit a bump and I fired my last missle at thin air!"

 

[trix]

I wouldn't (as a dev) use this anyways.

It means that just by resting your thumb on the cap it's "clicked" so not useful unless you're also not using the nub for it's analog input as well. The natural inclination is to rest your thumb lightly on the cap at all times when using the nub for analog input so it would always be "clicked". The only place this would be useful is to replace the entire function of the nub as an analog stick with a button press, in which case any random input would do. So simply flicking the nub lightly would be more reliable than just tapping it with your thumb. Just tapping it would likely generate enough real data to interpret the action as a "click" anyways. Even just jostling the unit a bit might produce a stream of 0's without even touching the nubs. "Damnit, the bus hit a bump and I fired my last missle at thin air!"

Excellent point! I had not thought of it, but you are totally correct. I rest my thumbs on the joystick almost permanently when playing a console game that uses them, I don't imagine the nubs being any different. Without physical travel required for the click to work, it would be far too easy to click by mistake.