Problems with AmigaInputAnyware

I remember quite some time ago that I had installed AmigaInputAnyware to let me play some games with a USB controller that were otherwise keyboard-only. It worked well enough at the time from what I remember. However, I tried to use it today and I just can't get it to work for me. I'm not sure whether I'm doing something wrong, or if it's perhaps a change in OS 4.1FE that's caused problems, but anyway...

I can't seem to be able to modify the settings in any meaningful way. My controller is recognised and works fine within AmigaInput prefs, and it's found by AmigaInputAnyware when it starts up, as are the various profiles in the config drawer. But, the resulting keyboard events don't appear to match any of the profiles - even the Default profile in NotePad doesn't do what it should. For example, buttons 2 and 4 produce left and right cursor movements, even though none of the profiles have the cursor key codes in any of the button positions.

It doesn't help that the documentation for AmigaInputAnyware basically doesn't exist, so I can't be sure that I even understand how it's supposed to work. Have I got this right? My understanding is that you run AmigaInputAnyware, highlight the desired profile, and the inputs are translated as specified in that profile. So, I can change profiles by simply clicking the name of another one, is that correct?

If I've got that wrong, does anyone have any proper documentation on it so I can figure it out properly? Or are there any other programs that do a similar job?

@Daedalus

That spelling error is following me everywhere; actually, I do not know the answer to this question.

vkeyboard was implemented not unlike this program bad crashed a lot, actually I was surprised I did have the same problems with AmigaInputAnyWhere.

It might have been that Hyperion has removing forbids / permits, if this is the case and now are using shempore or Mutex, my program don't know about this Mutex or Sahmpore, it think it safe as long as it the only running program. But it might take over in middle of something.

Anyway that’s speculation, I'm not beta tester, and not part of Hyperion don't what they changed and how that effects my programs.

And I can't fix the problem with out knowing accurately how to modify my code to stay compatible, whit this changes.

@LiveForIt

Thanks for the reply So, do I have the concept correct? Do you have OS4.1FE update 1 to test it on?

@Daedalus

I use AmigaOS4.1 now, I have not tried this program in years.
also I edit my last comment.

Hmmm, that's a shame, because it would be very useful. The thing is, I don't think the problem is to do with the interfacing with the OS itself, but more with the configuration. The inputs generated by your code still work, there just doesn't seem to be any way to change them. For example, buttons 2 and 4 give left and right keyboard arrows in games, buttons 1 and 3 give A and S inputs. So, it just seems like the configurations are being ignored and some random defaults are being applied.

@Daedalus

ok, I see, maybe I have look at it then, I'm currently working Amos Kittens a Amos interpreter, I will be implementing joystick support there, so will be looking at code in the not too dissent future.

I'm working on string commands.
Next will io file and so on.
memory commands.

maybe few months time.

Cool, well if you need a hand, either with the code or with testing an update, please let me know. It should be a very useful program with a little bit of tweaking and perhaps some updated documentation.

@Daedalus

"documentation" well I'm dyslectic I double hate writing docs. so if you like write some docs that be great.

No problem I'll write the documents for you (AmigaGuide and readme) if you get it working for me. Deal? :-p

@LiveForIt

You can add functionality so that the one-off use of the pad button results in the automatic repeated use of the keyboard key (the aim is to obtain an autofire effect).

Little bump to see if this ever got looked at?

Another little bump for this. Any update?

@Daedalus

Amos Kittens is progressing well, it looks like there are only few issues to work out with AMAL and collision detection. I have the same problem in AMOS kittens as I have in AmigaInputAnywhere, sadly not bugs I can fix, as bug are in AmigaInput not in my code.

So what's the exact nature of the bug then? I don't understand how AmigaInput can prevent AmigaInputAnyware from remapping keys, when it works fine with default keys...

@Daedalus

If the gamepad lose / unplug connection while you’re playing you get crash in Amiga Input, sub task, its like it does not know its being used, is purged without any concern that something might actually be using the gamepad. There is no attempt from "AmigaInput" side, to inform "AmosKittens", A game or "AmigaInputAnywhere" that something is unplugged.

Yes, I'm aware of that issue, but if you read my posts, you'll see that that's not the issue I'm talking about. The issue I'm talking about here is specifically to do with AmigaInputAnyware not mapping inputs properly.

Or, if you don't have the time or means to fix AmigaInputAnyware, how about sharing the source for it so that I or someone else might be able to fix it for you? I don't have a lot of time for Amiga-related projects, so it would save me having to write my own alternative from scratch...

Okay, this evening I've done a little feasibility work for writing my own version of an AmigaInputAnyware-type-program. From what I've done so far, I can tell you that:

- It looks like AmigaInputAnyware is reading the button offsets incorrectly for some controllers, meaning button 4 corresponds to button 1, buttons 1-3 correspond to various hat/axis offsets, and everything else seems to be shifted by the same amount. Possibly some sort of alignment bug in the struct, or assumptions made about the number of hats/axes? Anyway, I can read the controller inputs without issues so it's not the controller or AmigaInput itself. This explains why my mappings would never work in AmigaInputAnyware with that controller but did with a previous one.

- AmigaInput will tell you if a controller is disconnected, but will crash if you try to read a disconnected controller after reconnecting it, since the context is no longer valid. Therefore, you can avoid the crashes if you immediately dump the context as soon as the controller is disconnected and re-initialise it from scratch when the controller is reconnected. Once you do that, you can disconnect and reconnect the controller as much as you like and still read it without issues. The additional problem is that if you're polling the device instead of using signals, you need to check the device is connected before any attempted read of it.

@Daedalus

I have only gamepads, one ps1 controller and one Dual action game controller, they are wary similar, button mapping is the same.

on Dual Sock controller the button 1 and button 2, is bit strange organized, so this makes it hard to use, the digital stick is useless.

Amos kittens swaps this two buttons, pretty simple code, maybe too simple.

Looked at the code, I do not query offsets, for buttons etc.

I was always going rewrite it from scratch if where do more on AmigaInputAnywhere.


There is no disconnected event type or device event type or anything like that in my SDK.

/* Event types */

#define AINET_AXIS 1
#define AINET_BUTTON 2
#define AINET_HAT 3
#define AINET_KEY 4



I can query the device by intervals, using AIN_Query() this command takes the context, so if the context is deleted, it will crash...

#define AINQ_CONNECTED 18


>since the context is no longer valid.

Well i obtained the device, my program owns the device, until my program release the device.

I created the context, its my job delete the context.
the context might not be valid,
but it should safe to use it.

@Daedalus

>The additional problem is that if you're polling the device instead of using signals.

I'm not checking the signal before AIN_GetEvent(...)
this might be the major mistake in the code.

I guess this is becouse its not using GetMsg( MsgPort )..