I've just ran into the problem of not being able to read two specific joystick axes (Rotation X and Y) which are used for the right analog stick on the Xbox 360 wired controller/gamepad. They're simply not enumerated by the Allegro 4.2 library.

It seems like it's a known bug approached in this thread:
http://www.allegro.cc/forums/thread/507375

Peter Wang's assessment seems correct: "I think the problem is in object_enum_callback() in src/win/wjoydx.c. I suspect the missing axis falls under GUID_RxAxis or GUID_RyAxis which is not being tested for there."

Is this going to be fixed? Can someone please follow up on this issue? I don't want to have to switch to SDL input handling...

Thanks so much in advance!

(Wait, could I make the bugfix myself to the allegro code? Should I start looking for the sourceforce repository?!)

- Dan T, working on Cortex Command
http://www.datarealms.com

Yes, fix it and send us the patch, either to the [AD] mailing list, here, or on the SF.net bug tracker (as you have found). It's unlikely anyone else will fix it for you as we basically have no Windows developers any more.

Oh! How come?

The problem is that just adding checks for RxAxis and RyAxis doesn't help - the problem still persists. I tried that the last time around.

[EDIT]
Hmm. Actually, adding that check does make the missing Rotary show up - it just doesn't update. I think the problem might reside in joystick_dinput_poll() (or rather, that there might be an additional problem in joystick_dinput_poll()).

I think I'll try to wrap my head around Allegro's joystick code and see if I can produce a fix for this tonight.

[EDIT 2]
Way too many edits.

[EDIT 10⁴]
Hah. I was right. It was a combination of all three guesses to what the problem was: not enough MAX_STICKS + no RxAxis/RyAxis checking in object_enum_callback() + a similar problem joystick_dinput_poll().
I've tested a "proof of concept" fix that works for my joystick at least. I'll try to convert it into a clean fix and make a diff of it later tonight.

Good job gnolam

Though it sounds like the current joystick code is a crock of shite

UPDATE: a proper fix will take a while, since trying to extract relevant information from MSDN is like repeatedly smashing a claw hammer into your groin.

Well, it's certainly showing its age anyway... it makes me wonder if there's any chance of introducing an _ex family of joystick functions and structures (with, for example, > 8-bit detail on axis positions, configurable deadzone/range properties, etc).

I think we should make Allegro hacking a spectator sport.

Well, I have some good news and some bad news...
The bad news is that there's just no clean way to do this without a major rewrite.
The good news is that I've found out why I never managed to get axis/button name mapping right.

In more detail:
Allegro's name assignment is completely broken. When a device is initialized, its elements are counted and their names are read and copied into Allegro's JOYSTICK_INFO structure. However, when the device's state is actually polled, the order in which the axes are assigned data has nothing to do with their order in that structure.
This is also why I can't fix the polling routine cleanly - without it knowing which axes correspond to which on the physical device, it can't actually know if lRx and lRy exist or not (an axis which doesn't exist always has a value of 0, but that is also a valid state of an existing axis). Therefore, the best thing I can do is to tack them onto two additional axes after all the others have been read. It's a hack, and an ugly one at that, but I don't think it should break anything (num_axis should make sure they're never visible unless they're actually there).

The solution to both problems would be to actually associate each Allegro axis with a corresponding DirectX axis, but I'm not sure if I'm allowed to touch the internal structures...

IMO of course. There might actually be a clean way to do all this, but I'll leave finding it to someone who's not as tired.

I will attach patches for testing in a minute or two.

[EDIT]
Attached.

[EDIT2]
I just realized I didn't make those patches against the SVN tree. I will rebuild them in a couple of minutes.

[EDIT3]
Reattached.

Good job, gnolam. It's always good to see progress being made on the Windows port.

Good work Gnolam!

Unfortunately we can't bump MAX_JOYSTICK_AXIS and MAX_JOYSTICK_STICKS in the 4.2 branch as it would break ABI compatibility. Is it really necessary?

Yes. STICKS, anyway.

Well, that's a load of work for nothing then.

Not nothing, it'll be able to be included in 4.3 at least

Wow you guys rock! Here I thought I wouldn't get much response for a while... gnolam you rock.

Props were due and given:
http://www.datarealms.com/devlog/cortex-command/open-sores-in-action/

A 4.3 update would be hot.

4.3 will be a little different than 4.2. some/alot of the api will change, as 4.3 is designated as part of the incremental update to "allegro 5". So you may have to "port" over stuff to 4.3, and aditional updates to 4.3 or 4.4+ will also have significant changes.

Don't install your modified Allegro binary to the system library directory, please!

Seems like i'll have to use SDL for the joystick input after all.. oh well! ;p

Thanks for the quick help and effort though! Looking forward to a rewritten input module sometime!

How did you arrive at this conclusion? Just apply gnolam's patch on your local SVN copy of Allegro and staticlink your game. Problem solved.

Right. I'll just come back and resubmit it in 5 years then...

Or you could apply it to 4.3 now.

AFAIK, 4.3 is still a jumble of broken code with no actual API plan, so no.

(We've only been waiting for Allegro 4.2.1 for what, a year?)

AFAIK 4.3 compiles just fine.

its the old allegro_new branch or whatever that was totally broken.

Maybe it does. But even if the patch should prove relevant, there's still the utter lack of documentation and planning. So no, I'm not planning on contributing anything to 4.3.

And thats why theres a lack to begin with. "I'm not going to do anything if noone else does!".

Actually, I'm nearly done the new file/path handling stuff for allegro 4.3. Including the unix and windows specific code.

No, that's not it. Try
"I'm not going to do anything since nobody has any idea what should be done."
or
"I'm not going to do anything unless the people who have done something tells other people what it is they have done."
or
"I'm not going to do anything since what I do might prove completely irrelevant because someone else has a different idea."

You don't start building a house without first drawing up detailed plans. Likewise, you don't contribute to a project with no apparent direction unless you get paid for it.

Can someone check if the same problem exists in 4.3? I think I'd already taken gnolam's change to wjoydx.c into account in the 4.3 branch, and the approach I took was to group Rx,Ry,Rz into a single stick. It might not be right, but we could do the same for 4.2.

I'm pretty hazy on what exactly affects ABI compatbility - would a "shadow array" of element-to-name mapping (to solve the name problem at least) be doable or would it break anything?

That would be fine. The problem with bumping the MAX_* constants (except for MAX_JOYSTICKS) is that it changes the size of the elements of the joy[] array, so a program compiled with 4.2.0 would have different ideas of the offset of &joy[N] compared to a DLL compiled with your patch.

I'm kind of out of the loop since I've stayed out of the Allegro 5 discussion. But I was under the impression that a whole freakin wiki existed about what's been done/planning for allegro 5...

If there arn't "planning docs", then maybe someone should make them. Has the actual planning not been done? If so, I'd say gnolam's right, and that's not a minor issue. (The absence of planning, not gnolam being right.)

Alright, I didn't defect to SDL quite yet. Instead, did as Miram suggested: patched my local SVN copy of allegro with gnolam's fix, built the static libs and finally rebuilt my game with them.

And... it works! I can now use the rotation axes. You guys rock!

Please don't be disheartened and give up development on allegro, folks. It's worth it!

Thanks again,
- D