add vigem-iidxio implementation - [closed]

[icex2]

In GitLab by @GRIM.657 on Dec 18, 2020, 01:55

Merges master -> master

It would appear icex2 and I worked on vigem support for iidxio at the same time.

Advantages of icex2's impl: has a spotlight sequencer, might be cleaner

Advantages of mine: compatibility with LR2, more options for TT input handling

Thanks to zyp, this turntable button input implementation draws from their Arcin firmware adjustments for LR2. Also thanks to Xyen, for vigem-sdvxio on which this was based.

[icex2]

In GitLab by @xyen on Dec 18, 2020, 07:56

I had originally held off on including vigem-iidxio since in testing it didn't work with infinitas. Have you tested this with it?

[icex2]

In GitLab by @GRIM.657 on Dec 18, 2020, 10:41

I did, unfortunately I do not believe it's possible with the ViGEmBus driver alone. I tried emulating both X360 and DS4 controllers, and could not get either to register. I also tried using a utility to map the vigem pads to a virtual keyboard, which Infinitas also did not pick up.

Side note, I should probably be more specific about LR2 compatibility. LR2 can not use the D-Pad buttons of the Xinput controller, at all. The turntables and all other functions must be mapped to the face and shoulder buttons. This is why I am using three separate vigem controllers, and not mapping anything to the D-Pad. Making the TT buttons behave in a way that's actually usable for scratch sections in-game is finicky but Zyp did a great job on the Arcin and I'm borrowing from them, I also exposed some of the constants used in the logic as config options so players can fine-tune their own setups.

[icex2]

In GitLab by @xyen on Dec 18, 2020, 12:29

In that case, I suggest closing this out, and implementing vJoy instead. Which would allow us to emulate dinput instead, which should work.

[icex2]

@xyen does it make sense having two solutions, vigem and vjoy for iidxio then?

@GRIM.657 Great to see that you also looked into this but sorry for the unfortunate clash here. I would propose moving the vigem stuff from my current MR !66 to a dedicated one and merge it with whatever makes sense from yours, e.g. compatibility with LR2, more options for TT input handling. Then take reviewing changes for this together from there. I would take care of driving that.

[icex2]

Dedicated ViGEm iidxio client MR for my changes: https://dev.s-ul.eu/djhackers/bemanitools/-/merge_requests/68

[icex2]

Comparing this implementation to mine from !68, this is one of the features mine is lacking. Do you mind explaining why people need that? What's the problem that is solved with the debouncing and the threshold below?

[icex2]

You mentioned something about LR2 not liking the d-pad in another comment. Does that mean that this button mapping is tested with LR2 and confirmed working?

[icex2]

In GitLab by @GRIM.657 on Dec 18, 2020, 19:34

Commented on src/main/vigem-iidxio/main.c line 180

Yes, I'm using the "L/R thumb stick pressed", which show up as buttons 9 and 10 in Windows. For each player, keys 1-7 should show up as buttons 1-7, start is button 8, TT is 9 and 10. Because only 10 buttons are available per player, I'm using a third vigem controller for shared inputs like VEFX, Effect Test, Service, Coin.

I intended to use the D-Pad when I originally wrote the code, but had to pivot after testing with LR2. Thus the "dpad" variable names. I'm happy to clean this up if you'd like.

[icex2]

All good, no need to change this here as I am already porting the few missing bits from your MR to mine.

[icex2]

In GitLab by @GRIM.657 on Dec 18, 2020, 20:09

Commented on src/main/vigem-iidxio/main.c line 121

For the user it is ideal if:

A. There is some minimum amount of movement necessary to activate the turntable (more than just 1 tick)

B. The turntable input will remain solid for some time, instead of flickering.

Debounce is the amount of time the TT button will remain held after no ticks are registered, which is between (debounce * threshold * 2ms) and 2 * (debounce * threshold * 2ms), which is the "tt_dpad_maximum".

This is necessary because at 500hz or 1000hz, with only 8bits of accuracy for TT position, many cycles pass where the turntable delta is 0 even if the user is turning it constantly. We want the input to be solid and not flickering while the user is spinning the TT, so this takes care of that. This logic is mostly lifted from Arcin firmware (https://cgit.jvnv.net/arcin/tree/arcin/main.cpp?h=conf line 433)

Threshold is the number of ticks the TT must move in an amount of time (debounce * 2ms) to register an input. IIDX has similar threshold code as this, i.e., that TT must move X ticks within Y frames to count as an input. This is why turning the table very slowly in IIDX has no effect. This code is to emulate that behavior.

Notes

The debounce variable thus affects both how wide the window is to register TT movement, and how long the button will remain pressed after TT input has stopped.

The 2ms values I'm using above are from Sleep(2) in the main loop.

[icex2]

In GitLab by @GRIM.657 on Dec 23, 2020, 03:58

Commented on src/main/vigem-iidxio/main.c line 121

changed this line in version 2 of the diff

[icex2]

In GitLab by @GRIM.657 on Dec 23, 2020, 03:58

added 1 commit

• b3279865 - vigem-iidxio: cleanpup

Compare with previous version

[icex2]

In GitLab by @GRIM.657 on Dec 23, 2020, 04:06

added 1 commit

• 5f5e517c - vigem-iidxio: fix missed find/replace

Compare with previous version