[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Chris wrote:
Peter Wang wrote:
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.
I don't know how else to say it. You don't have to handle any queues if
you don't want to. There is a key[]-like mechanism already -- you just
can't access it without going through some synchronisation. Similarly
for the mouse and joystick APIs.
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".
Ok, so you don't like the one extra step.
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.
I know key[] is convenient for many programs, but passing information
between threads through global variables without any synchronisation is
just a bad idea. I just couldn't think of a mechanism which is both
thread-safe _and_ as convenient.
Peter
PS. I'd really like to know how Allegro's global state variables work on
a multiprocessor system.