Re: [AD] Proposal for first step towards new api

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Fri, Dec 21, 2001 at 11:27:54AM -0500, Bob wrote:
> Grzegorz Godlewski wrote:
> 
> > VPh> These two could even get merged:
> > VPh> int al_get_device_state(ALDEVICE dev,int which);
> > 
> > I agree. There also should be a function for controling device
> > parameters:
> > al_set_device_state(ALDEVICE dev,int which,int value);
> > 
> > Device specific function (for instance al_get_device_bitmap) should
> > check some flag in AL_DEVICE for it's capability to perform this
> > function as well.
> 
> 
> This makes Allegro look more and more like Win32. I'm not sure that's a very 
> good idea.
> 
> Also, about the statically linked version: will hte compiler be smart enough 
> to not include the code for setting/getting attributes of objects which 
> aren't in use in the user program?

If unifying input devices is a good thing, then it's beacuse the
user can use one API to query all the devices.  I'm not totally
sure how useful this is, but if it is desirable then we can use
a vtable system for the querying, but still have device-specific
initialisation.  That means if the user doesn't initialise any
joysticks, the joystick code doesn't get linked -- because the
only references to it are the user's init call and the functions
in the vtable, which is itself only references directly from the
init call.

As for what to put in the vtable, that's another matter.  At
work we use a generic input class with processed input from
whatever the device is (keyboard, joypad, Xbox controller, AI
logic, saved replay data), and this can be really useful, but it
tends to be app-specific.  I don't think it would be valuable
for Allegro to support this structure in a customisable way
(except as an add-on).

There are also two main ways to read the mouse, and only one way
customarily used for joysticks.  (Mice can give absolute
coordinates or mickeys; joysticks only give mickeys.)  The
driver could emulate the absolute coordinates of a joystick by
adding up the mickeys.  Or the input data returned could only
give mickeys, and the mouse would have two modes for returning
data.  In the end it makes me wonder if it really is worth
unifying, since the devices do behave differently -- in the
context of our input class here at work, it only makes sense
because it's already processed into steering, accelerating,
braking, leaning the rider, etc.  Without this processing, it
would be impossible to abstract the keyboard input because it
has a ridiculous number of keys, far more than any joystick or
mouse.

So at the end of the day, I don't think it's very useful to use
the same function for all devices, and it has potential to get
in the way.  I think I'd just make an interface more like:

    joy1 = al_install_joystick();
    al_update_joystick (joy1);

where joy1 is a pointer to a struct containing driver-specific
data identifying which stick it is (maybe install_joystick needs
a parameter for this), some capability bits telling the user
what the stick can do, and some data for each axis and button
the joystick has.  Similarly, installing a mouse would return
pointer to a mouse data struct, etc.  Maybe the keyboard should
do the same?

George



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