I am toying with Allegro 5.0.x with which I am using several gamepads (joysticks, according to the API). I have all that working great (got my game loop checking events, ect).

For debug builds, which I work on while, say, on the bus, I do not have a gamepad with me. In the past to alleviate this issue I have created a thin "conversation layer" that maps keyboard inputs to gamepad buttons. The solution has worked wonders for my convenience but I can not seem to figure out how to implement it with Allegro.

Is there a way to inject custom events into the joystick queue? Going through the documentation I have tried playing with al_set_event_source_data() (line looks like al_set_event_source_data(al_get_joystick_event_source(), 1)) but can not figure it out. On top of that looking through the source I see intptr_t is just an int pointer of a specific size but with no indication as to what that should be pointing to?

This would only be for debugs builds. A handful of #define's remove it from release builds.

I searched both Google and the forums but can not seem to find an answer. Any help-- or alternative suggestions-- would be welcomed.

"The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying."- John Carmack on software patents

Well, you can use al_init_user_event_source and al_emit_user_event to emit an event with a type value of 1024 or greater. But you can't actually emit a standard allegro event and I'm not quite sure what the reasoning for this is. It would be nice to be able to simulate events.

Then when you get a joystick event you emit a user event to match it. Then only take action on the user joystick events. That way you can emit one yourself, or forward one from the joystick event.

"The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying."- John Carmack on software patents

If it's for testing purposes, you could use a virtual joystick. The operating system reports to applications about a controller that only exists digitally. The virtual joystick is fed whatever input necessary through library functions.

For Windows, vJoy looks like a good option to create the virtual joystick. ppJoy can work but is a little bit of a pain to set up for Vista onward. If you don't want to feed the input from your program with library functions, you can feed with a control script program like AutoHotkey, FreePIE, or GlovePIE.

I know there's a nice program for Macs. And don't know about other OSes.

"The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying."- John Carmack on software patents

Is there a way to inject custom events into the joystick queue? Going through the documentation I have tried playing with al_set_event_source_data() (line looks like al_set_event_source_data(al_get_joystick_event_source(), 1)) but can not figure it out. On top of that looking through the source I see intptr_t is just an int pointer of a specific size but with no indication as to what that should be pointing to?

If you're doing custom mapping, inject your conversion layer inbetween your game and the allegro routines, not the allegro routines and the OS.

Instead of using some form of "is_allegro_joystick_pressed()" in your logic routines you do "is_control_pressed()" and let your code do the linking between whether Allegro has a joystick, mouse, or keyboard present. Your game shouldn't know whats behind is_control_pressed() at all.

-----sig:“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

The other highlighted line should probably be changed to event->any.timestamp =al_get_time(); to make it more suitable for any event in general.

The actual nitty gritty function that allegro uses behind the scenes is _al_event_source_emit_event, which needs to have the event source locked first, and which uses _al_event_queue_push_event internally.

I'm not 100% clear on the implications, but I think being able to emit core events would be great. Another related thing is that it would be great to create event constructor functions (like al_emit_key_event or whatnot). It'd make the internals somewhat cleaner (pretty much every backend has a version of these constructor functions).