Re: [AD] New gfx api

[ 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




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