GrIP Support in Allegro:

(August 09, 1999)
This seems to work, as of Allegro 3.9.25 (WIP).


1. The files 

  grip.c
  grip.h
  gripjoy.c
  gripfnc.s

need to be added to src\dos .

2. src\dos\djoydrv.c must be updated with a 
"JOYSTICK_DRIVER_GRIP" line.

3. In Makefile.lst, the lines

	src/dos/grip.c \
	src/dos/gripjoy.c \
	src/dos/gripfnc.s \

must be added to the ALLEGRO_SRC_DOS_FILES section
to include the new files.

4. include\allegro\aldos.h needs a grip section:

  #define JOY_TYPE_GRIP            AL_ID('G','R','I','P')
  AL_VAR(JOYSTICK_DRIVER, joystick_grip);
  #define JOY_TYPE_GRIP4            AL_ID('G','R','I','4')
  AL_VAR(JOYSTICK_DRIVER, joystick_grip4);
  #define JOYSTICK_DRIVER_GRIP                               \
        { JOY_TYPE_GRIP,    &joystick_grip,      TRUE  },    \
        { JOY_TYPE_GRIP4,   &joystick_grip4,     TRUE  },

which, of course, can be distributed instead.

The latter adds support for only allowing the digital
pads to move in only four directions. The GamepadPros and 
Xterminators are notorious for being messy in 4-way games.

5. Something needs to be done about the MAX_JOYSTICKS
parameter. It can be defined in allegro.h... Or uncommented 
in gripjoy.c. The gripjoy code actually does its best to 
determine such size parameters, but it can't get at the 
number of joysticks. Another solution is to replace 

  AL_ARRAY(JOYSTICK_INFO, joy);

with

  extern JOYSTICK_INFO joy[4];

in allegro.h. I can't say what's best here. (Except that I
am in favor of explicitly defining all the MAX_foo 
parameters and having the allegro headers and code use these
defines. That would make it simple to change them, as well,
and discourage people from hard-coding in such parameters to
individual code sections).

6. Doesn't need to be done, and like the parenthesised 
solution above it doesn't seem desired, but the Xterminator
(at least) will work better with the stick limit changed to
6 (digital, analog, POV, throttle, right flipper, left flipper).

In allegro.h

  typedef struct JOYSTICK_INFO
  {
     int flags;
     int num_sticks;
     int num_buttons;
     JOYSTICK_STICK_INFO stick[4];
     JOYSTICK_BUTTON_INFO button[16];
  } JOYSTICK_INFO;

changes to

  typedef struct JOYSTICK_INFO
  {
     int flags;
     int num_sticks;
     int num_buttons;
     JOYSTICK_STICK_INFO stick[6];
     JOYSTICK_BUTTON_INFO button[16];
  } JOYSTICK_INFO;

If this is impossible, there is a compile-time option
to 'pack' the throttle axes as tight as possible into
pseudo-sticks.



That's about it. Seems to work fine. It could be more efficient,
but I thought that should wait for wider testing. It is fairly
flexible and should work on all GrIP hardware. It does depend
on GRIP.GLL being in the executable directory, path, or 
c:\grip. However, that's included in the standard Gravis 
software, and is redistributable. I may do away with this, since
I think I have gathered the necessary info on the protocol and
interface to code it up by direct assembly code. I still am
thinking that it is smoother and more flexible this way, though.

gripfnc.s, grip.c, and grip.h are the basic gravis API code. I 
ripped it from the Gravis SDK and modified it somewhat (the 
most significant change being moving the assembly routines to
the gas format). I had to guess at some values, because the 
SDK has not been updated for a long time, and does not support
all the current features (like analog sticks).

gripjoy.c is the true Allegro-specific driver. It contains a
number of parameters that change the behavior at compile-time.
They are mainly:

 - TEST_CODE: The driver will silently output a GRIP.OUT file
into the current directory when it is initialized. This file
contains the configuration and detected GrIP and Allegro data.
Useful for reports from testers, and as a system diagnostic.

 - UNLOAD_GRIP: Skips unloading the GRIP.GLL library. Shouldn't
normally cause any problems, and may prevent memory bugs outside
my code.

 - THROTTLE_AS_BUTTON: Treats throttles as buttons. Normally, 
they are considered one-axis sticks that can only register
digitally in one direction. This may make for easier support
with older applications.

 - ENABLE_AXIS, ENABLE_ANALOG, ENABLE_POV, ENABLE_THROTTLE:
These enable support for each of the given control types. 
Perhaps useful for testing.

 - PACK_THROTTLES: Yes, I caved in and added the packing option
I mentioned above just now. With distaste. :) This lets you
make, for example, 3 throttles into one 3-axis stick instead of
three 1-axis sticks. 



That's pretty much it... Please let me know if there are any 
problems with this. Hope it works for you...

 - Rob

Robert J. Ragno <rjr@mit.edu>
