need to do bit logic in GCpad bound

**ulao** · (This post was last modified: 07-25-2013, 02:47 AM by ulao.)

in the most simplest terms
can I some how do this ? `Axis Xr+-` * 4

-----------------------------------

In the simplest term I have data spanned over two analogs. This is to be thought of as bits not 10 based integers.

a1 11111111 254 total. MSB
a2 11111111 254 total. LSB.
a2a1 11111111 11111111 total 65536

I need this in one of dolphins analogs.

-------------------------------

Another way to put it.

I need to take this equation (`Axis Xr+-` | `Slider 1-+`) from a bound controller and do this

(`Axis Xr+-` << 8 ) | `Slider 1-+`

is there any way to do that?

('Axis Xr+-`') holds 8 bits and I need to shift left and add (`Slider 1-+`) 8 more to it.

If this can be done I also need a way to assign (`Axis Xr+-` << 8 ) | `Slider 1-+` to X- and X+ if possible. Or figure out the math to chop it up. Since dolphin can't just assign one axis to the + and - stick at once.

**pauldacheez** · 07-25-2013, 06:09 AM #2

So I asked the cool guy who wrote the new input parser to look at this:
<pauldachz> Jasper: https://forums.dolphin-emu.org/Thread-need-to-do-bit-logic-in-gcpad-bound Feel like helping a guy use your shiny new input parser?
<Jasper> pauldachz, that doesn't make sense to me. Axes are floating point values, bit shifting floating point values doesn't make sense

I'd advise getting on the IRC (#dolphin-dev on Freenode) and pinging him if possible, as he doesn't (yet) have a forum account.

**ulao** · (This post was last modified: 07-25-2013, 07:09 AM by ulao.)

He is right it does not make "normal sense" though it makes mathematical sense. Thx for asking, i may try the channels. Really though the very top explains it the best. If I can just do a simple + 4 or * 3 to my ending value I can accomplish most of what I need and that makes perfect sense in terms of explaining.

Quote:that doesn't make sense to me. Axes are floating point values, bit shifting floating point values doesn't make sense

In the normal convention yes. In my case I'm taking a two byte wide value and putting it on two 1 byte analogs with the intention to reassemble it at software level. Granted this would only work on an emulator advanced enough to do it. I'm limited by usb 1.1 to 8 bytes per poll and each byte can only hold 254. If I simply combine them ( 10 base arithmetic ) I only get 512 and that is not enough. using bit logic I get 16 bits allowing me to go to 6553. by shifting one byte over 8 bits and oring the second byte.

**Jasper** · 07-25-2013, 07:42 AM #4

Hi. I wrote the new expression parser.

The official hardware and APIs don't support more than 8-bit joystick positions for GC pads or Wii (classic controller, nunchuk) devices. I don't care about supporting 16-bit range that we're going to truncate back down into an 8-bit range anyway.

Use xpadder or x360ce. Maybe they're crazy enough to support this.

**ulao** · (This post was last modified: 07-25-2013, 08:29 AM by ulao.)

Pleas tell me if I understand this correctly.

The DirrectX axis 1 for example by doc capable of supporting 65536 ( correct me if I'm wrong ) can not be used by dolphin if greater then 256? ( otherwise its truncated or modded )

also

Each readable axis in dolphin will only support one byte? So stuffing one DX axis to the negative and one to the positive will clamp at 256 total?

If so I dont see how x360ce would help if dolphin will just trunk it.

thx for the response. Its vital that I know the correct answer in how dolphin reads. If its just going to clap it to one byte that answers my question.

Quote:The official hardware and APIs don't support more than 8-bit joystick positions for GC pads or Wii (classic controller, nunchuk) devices

Just a tad bit confused on that.
http://wiibrew.org/wiki/Wiimote/Extension_Controllers/Nunchuck "AX, AY, and AZ are the 10-bit accelerometer data " and the motion plus add on is 16 bit.
Again, either way, if the emulator is not going to support it I got my answer.

**Jasper** · 07-25-2013, 08:57 AM #6

(07-25-2013, 08:16 AM)ulao Wrote: Pleas tell me if I understand this correctly.

The DirrectX axis 1 for example by doc capable of supporting 65536 ( correct me if I'm wrong ) can not be used by dolphin if greater then 256? ( otherwise its truncated or modded )

DirectX axes are 32-bit signed integers (LONGs, see DIJOYSTATE)

(07-25-2013, 08:16 AM)ulao Wrote: also

Each readable axis in dolphin will only support one byte? So stuffing one DX axis to the negative and one to the positive will clamp at 256 total?

If so I dont see how x360ce would help if dolphin will just trunk it.

We get the DIPROP_RANGE of the device, and look at lMin/lMax to read data from DirectInput. We use this information to convert all axes to floating point values from -1.0 to 1.0.

(07-25-2013, 08:16 AM)ulao Wrote: thx for the response. Its vital that I know the correct answer in how dolphin reads. If its just going to clap it to one byte that answers my question.

The only time we clamp to convert back to 8 bits is when we tell the Wii about them. I'm assuming you're manipulating analog sticks here (which are limited to 8 bits, keep in mind), but if you're not (you pointed to MotionPlus / accelerometer info), then we'll accurately read the 10-bit / 16-bit information from DInput.

I think it's better to make a DInput driver that better supports your custom HID interpretation, than to try to adapt everything else.

**ulao** · (This post was last modified: 07-25-2013, 09:37 AM by ulao.)

Quote:I think it's better to make a DInput driver that better supports your
custom HID interpretation, than to try to adapt everything else.

Right that is my limitation. My device works on ps3, xbox, and other non driver based devices thus I can not. I'm adding the wii accessory to my adapter and as I pointed out above it does send data greater them one byte. Though now that I think about it I know for a fact the GC would not use anything greater then one byte as I'm quite familiar with its GC pad interface. Would the same be true for the emulated wii? Will the emulator support data greater the one byte for any of the analogs? I understand that you can read larger data from DX but in the end when the game sees the code, will it just be clamped to a byte? If the extra data is not used, my efforts are pointless and I thank you for your time.

pauldacheez, thx for hunting down my answer!

**Jasper** · 07-25-2013, 10:08 AM #8

Wii Motion+ supports 16 bits of range, and the standard Wii accelerometers support 10 bits of range for X, and 9 bits for Y/Z. We don't support emulated Wii Motion+ yet, but yes, we do support the full range for accelerometers.

We don't truncate anything. We take the values you give us from SDL/DirectInput/XInput/whatever, normalize them into double-precision floating point values between -1.0 and 1.0, do the expression parsing based on those floating point values (A | B, for instance, is std::max(value_A, value_B)), and then spit those out to the game by converting the normalized floating point values into the values the Wiimote SDK wants them in, and the values the Wiimote normally gives them in.

**ulao** · (This post was last modified: 07-25-2013, 10:27 PM by ulao.)

Jasper, thx for your help. In the best interest of my buyers I just have one more question. Can the parser allow normal arithmetic. Really all of this talk is irrelevant if the answer is yes. All bits aside, I just need to multiple an analog by a fixed number as *4 is the same as >> 2. Is the request unreasonable? I ask because I know I will be asked.

on a side note not related to the parser. Maybe a better skid question. Is there any way to allow analog to analog mapping? Dolpinh wants this set x- to ... and set x+ to ..., why not just set x to ...

**Jasper** · 07-25-2013, 03:35 PM **#10**

(07-25-2013, 12:14 PM)ulao Wrote: Jasper, thx for your help. In the best interest of my buyers I just have one more question. Can the parser allow normal arithmetic. Really all of this talk is irrelevant if the answer is yes. All bits aside, I just need to multiple an analog by a fixed number as *4 is the same as << 2. Is the request unreasonable? I ask because I know I will be asked.

The only arithmetic operation I'm interesting in supporting is +, which has been requested by multiple users. I could add multiplicative operators and subtraction, and it wouldn't be too hard, but frankly, I don't find that interesting. I'd rather you write a proper DirectInput driver that will work out of the box in every system.

Additionally, looking at the USB HID specification, there's nothing preventing you from using more than one byte to describe an axis, or really any sort of valuator control. Everything is generic.

Making a USB HID-compliant device is probably the least path to resistance, rather than making a brand new fancy protocol based on USB that would require custom drivers and emulator-specific hacks...

(07-25-2013, 12:14 PM)ulao Wrote: on a side note not related to the parser. Maybe a better skidd question. Is there any way to allow analog to analog mapping? Dolpinh wants this set x- to ... and set x+ to ..., why not just set x to ...

I don't know. It was like that when I started working on Dolphin. I think it's for people who want to use arrow keys or WASD to control tilt or something like that. Note that we normalize on the average between lMin and lMax. Everything below that midpoint goes into the negative axis, and everything above it goes into the positive axis.