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

[Laurence Withers <lwithers@xxxxxxxxxx>]

In reply to Shawn Hargreaves <shargreaves@xxxxxxxxxx>:
>Unicode actually defines a full 32 bit character space. Or should I say,
>currently doesn't, but might some day :-)

Yes, but UTF-8 only defines encodings for 0 to 0x7FFFFFFF, so I presumed
it was safe to use bit 32 for my own ends (and it's going to take a hell
of a long time to fill up that many characters anyway :-) ). And they
have currently assigned 95 156 code points, so a 16-bit solution
wouldn't work thoroughly.

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

The scancode / unicode value are never mixed within the same integer,
but as you noticed, I used a single bit as a flag for non-Unicode
control keys. This is never going to cause a problem if Allegro limits
itself to UTF-8, anyway.

One other solution is to return such keypresses as one of the
proprietary code points, of which there are 132 672, but I think this is
a very messy solution compared to just testing the top bit.

>> Also, maybe it could be useful to have two separate functions to clear
>> the scancode buffer and the unicode buffer?
>
>Absolutely: doing both at the same time has caused no end of trouble in
>the current API.

OK, I'll update the proposal again. I didn't think it was a necessary
feature, but I trust you more :-)

Bye for now,
-- 
Laurence Withers, lwithers@xxxxxxxxxx
                http://www.lwithers.demon.co.uk/

Attachment: signature.asc
Description: PGP signature