[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Peter Wang wrote:
Their designs are documented at http://alleg.sourceforge.net/future/
in particular events.txt, evtqueue.txt, evtsrc.txt
I'll look them over, thanks. :)
The difference between polling (in my understanding) and events is that
polling requires the user to *guess* when something has happened. On
the other hand, events *tell* the user when something has happened, so
is far more efficient.
To me, it just seems polling is generalized event handling in a wrapper
function.
You'll be glad to know the input device designs support both models.
See keyboard.txt, joystick.txt & pointer.txt (although the keyboard and
pointer APIs require changes as they are a bit ugly in parts).
But according to keyboard.txt: "You cannot read the state of keys
directly. Use the function al_key_down()."
This is exactly what I would like to avoid. Being able to hold an
external pointer to a keystate is a very useful feature. Like this:
volatile char *gamekey_move_forward = &(key[KEY_W]);
Then all you have to do is check (*gamekey_move_formward) to get the
state of the forward key, whatever it's mapped to. Granted you could
have it hold a scancode and just call al_key_down with it, but I think
it's preferable to reduce the function call (and associated code)
overhead. Dereferencing a variable is easier on the CPU than calling a
function.
- Kitty Cat