[0.4.0] [Duke3D] Weapon switching using mouse wheel

[Sangman]

If you want to reproduce without cheats: go into E1L1 and collect the RPG under the Innocent? sign.
Scrolling using the mouse wheel seems to be funky currently, sometimes it works but often it doesn't, no weapon switch occurs at all.

If it helps, my mouse is the Logitech MX518 but there's nothing special about it.

[Graf Zahl]

We are aware of this, it seems to be dependent on the mouse being used and the frequency with which it sends events.

[Nash]

As has been reported many times before - for Duke (and Shadow Warrior), mousewheel scrolls only registers if you spin it aggressively.

[sinisterseed]

And even that is inconsistent, this potentially depending on the mouse as well isn't too far fetched.

When I tried to replicate the behavior it was fine on my end.

[Graf Zahl]

The root cause here is that the mouse wheel gets cleared each frame but the input code does not check for key presses but key holds which creates gaps in which the wheel has no state. As long as I cannot change it to checking key presses the wheel won't work reliably. In ZDoom this wasn't an issue because all non-continuous input is handled by CCMDs, not by buttons as in Build. I'm going to have to change it so that trigger options are being done as CCMDs to circumvent the problems with the button input logic.

[markanini]

I have a very similar problem in Blood. Interestingly when I assign next/prev weapon to mouse side buttons it's completely responsive, but it occasionally skips 3-4 weapon slots when switching.

[VGA]

Good to see that this is a known problem, it happens to me in Blood and Duke. When configuring it, it is detected fine but not in gameplay

This is with 0.4.2

[Korell]

This also happens with the Megaton and World Tour versions of Duke Nukem 3D. Doesn't happen with my older EDuke32 though (version r6576).

[mjr4077au]

@Sangman, are you able to please test this again with the latest git head? A compiled copy is here: https://drive.google.com/open?id=1e3Tp2 ... N2nt6Nx0lT

I've backported some input code changes from newer EDuke32 releases and cannot replicate this anymore. The input code is very different from the older version this was reported against.

EDIT: Please note that the input changes are only for Duke3D and RR frontends. If this is an issue with Blood, SW etc then it will still be an issue.

[Manuel-K]

Still not working in RR and Duke on Linux.

[mjr4077au]

Still not working in RR and Duke on Linux.

What version are you using? The commits that change the input code are post 0.5.1 so you'd have to compile again from the latest git head to test.

[Graf Zahl]

This should indeed fix it - but this somehow needs to be transplanted to the other games as well, which won't be an easy task...

[mjr4077au]

Just to confirm, you don't think there could be generic input code for all the games to use/share? When I look at how each game processes input, they're all same same, but different. It looks like ultimately they all do the same thing from my eyes.

Easiest to hardest IMO would be Exhumed, Blood, Shadow Warrior.

[sinisterseed]

Just to confirm, you don't think there could be generic input code for all the games to use/share?

Good question. This always bugged me honestly, it would be so much better if input was handled the same way across all supported games versus each game doing its own thing - which requires manually adjusting to each game every time you switch them... so much pointless fiddling...

SW feels the best to me honestly, followed by Duke, but Blood kinda gives me grief sometimes.

[mjr4077au]

All the games feel good to play. I think Duke is now a cut above the rest with those latest cherry picks from upstream. Blood's vertical look axis scaling is off to me, looking up and down is ~50% faster than looking side to side.