[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Peter Wang wrote:
Chris wrote:
I mean the programs they're used in. A event queue must be iterated
through, whether it's done a specific way for a program, or a general
way by the lib. A program can do special things when it empties the
queue itself (like say, do a special action if it detects a certain
event), though I think the losses of not having Allegro handle it for
you (ease of use) is a bigger concern.
I don't know what you're talking about. What is the `it' part of "not
having Allegro handle it for you"?
The queue'd data (ala updated a key[] array, or having the mouse_* vars
updated or whatever). Allegro should handle them automatically and
supply them, not rely on you to handle the queue.
Note that al_key_down() could be an inline function, and that it
operates on AL_KBDSTATEs. AL_KBDSTATEs are only updated when
al_get_keyboard_state() is called (an 8-byte copy, with thread
synchronisation around it).
So.. polling. :)
And how is the key[] array any different? It's still "polling" in that
sense.
But with a key[] array, it's updated away from the main program/thread.
So if I dereference the key array, wait a second, then dereference again
it'll show the current keyboard state along with whatever changes
happened within that second, not the last time you "took the snap shot".
If I have to continually refresh the keyboard state, it'll just bring
more work into the main program. I'd prefer the main program not have to
worry about refreshing the keyboard (or mouse or other device) state..
it should be done automatically.
- Kitty Cat