Re: [AD] New gfx api

[Peter Wang <tjaden@xxxxxxxxxx>]

Chris wrote:

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


I don't understand what you mean.  Surely event queues are more general?

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


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).  I think this might actually be _more_ 
efficient than a volatile array, due to caching (subject to many 
factors, of course).

But encapsulation and thread-safety are the main concerns, not efficiency. 

Further, the synchronous nature of AL_KBDSTATEs make them easier to 
understand.  I also think it makes them more suited to a multi-window 
environment.

Peter