Re: Fw: Re: [AD] messy allegro 5.0 stuff

[Sven Sandberg <svsa1977@xxxxxxxxxx>]

Shawn Hargreaves wrote:
> As far as Allegro goes, assuming Unicode only ever ranges 0-65535
> is probably reasonable (lots of programs do the same), but not
> exactly correct. It would be nice to get this totally right if
> possible, allowing the entire 32 bit range for Unicode characters,
> and putting the flags and scancode somewhere else...

Yes, and this seems much cleaner than having to mask out the value, but
how should it be done? Probably it would have to be something like

   void al_read_key(int *unicode, int *scancode);
or
   int al_read_key(int *scancode);

returning 0 in one of the arguments and unicode/scancode in the other.
This seems a bit complicated but it's probaby worth it. It also seems
more evident what format the return value is in.


Oh, and I just noticed that keypressed() is not included in Laurence's
proposal. Does this mean that al_read_key() does not wait for a keypress
and instead returns 0 if nothing was pressed (i.e., a non-blocking API
like for al_read_scancode())? It may be good to state explicitly in the
proposal.

Should we make a clearer distinction between the scancode API and the
unicode API in the function names? I think we could use the word `key'
for the scancode API (because it reflects the actual keys on the
keyboard) and the word `unicode' for the unicode API (because it
reflects the unicode character represented by a key, defined by the
locale's mapping). Maybe:

  al_read_scancode()         --> al_read_key()
  al_read_key()              --> al_read_unicode()
  al_clear_keyboard_buffer() split into al_clear_key_buffer() and
al_clear_unicode_buffer()
  al_convert_scancode()      --> al_key_to_unicode()
  al_key_down()              unchanged
  al_simulate_scancode()     --> al_simulate_key()
  al_simulate_key()          --> al_simulate_unicode()

-- 
Sven Sandberg    svsa1977@xxxxxxxxxx    home.student.uu.se/svsa1977