Re: [AD] New gfx api

[ 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.





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/