[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
* For those of you who don't subscribe to the commits list, here are
some recentish changes on the new_api_branch:
Renamed al_(un)install_joystick_driver to
al_(un)install_joystick. Renamed al_request_joystick to
al_get_joystick. Added new function al_joystick_name (stub only
right now).
Added condition variables
to the internal threads API. With this, the implementations of
event queues on Unix and Windows are identical.
Changed the semantics of al_wait_for_event() so
that the RET_EVENT argument may be NULL. In that case, the
function WON'T remove the first event from the queue and store it
into RET_EVENT. Similarly for al_wait_for_specific_event().
Also fixed a bug in al_wait_for_specific_event().
* I have a patch here which makes joystick axis ranges into floating
point values from 0.0 to 1.0. I will probably apply it soon.
* I'm not sure what to do about analogue joystick buttons. Once you
start allowing a whole range of values for button states, the
AL_EVENT_JOYSTICK_BUTTON_DOWN and AL_EVENT_JOYSTICK_BUTTON_UP events
don't make much sense. I guess the right thing to do would be to
replace them with an AL_EVENT_JOYSTICK_BUTTON event and have a field in
the event structure tell the user the new value, just like joystick
axes. No drivers support analogue buttons yet though (I couldn't see
how to do it in either DirectX or Linux).
* AL_JOYSTATEs will probably stay as they are. I had a chat with Bob on
#allegro about this a couple of weeks ago. The problem Bob had with it
was that it was not an opaque type. To fix that you would access the
fields of AL_JOYSTATEs via accessor functions (uncomfortable). But to
be really future proof you'd need constructor/destructor functions for
joystates too, so the user could no longer allocate them on the stack.
I think that's too uncomfortable to justify.
* A work-in-progress patch implementing the last keyboard API proposal
from alleg-bigfive is available. It works on Linux console, X, and
Windows. Compatibility for the older keyboard API is present. It's
pretty much done, just needs some more cleanup.
http://members.ozadsl.com.au/~tjaden/a5/nu/nu-keyboard-api-20040924.zip
The X keyboard driver no longer emulates keyboard scancodes to pass off
to the pckeys.c module. The other two drivers work the same as they
used to.
* How important is it to keep set_keyboard_rate() working? In the new
API I haven't introduced an analogous function. You just get whatever
repeat setting the OS gives you, which I think is the right thing to
do. To maintain the same behaviour in the compatibility module I set up
an AL_TIMER which emulates the timing of whatever repeat rates the user
passes to set_keyboard_rate(). This is what Allegro 4 does, too, but it
uses install_int() instead. It works fine, but I just wonder if it's
that important. Otherwise the compatibility module could just use the
AL_EVENT_KEY_REPEAT events which are generated by the new keyboard API
anyway. Right now it just ignores them.
BTW, the Windows keyboard driver has to do extra work to generate
AL_EVENT_KEY_REPEAT events anyway, so the autorepeat emulation is done
_twice_ there if you use the compatibility module. Once for the new
API, emulating the setting from the Control Panel, then a second time to
emulate the setting from set_keyboard_rate() :-P
Peter