Re: Interactive Effects

[Johann D. <jo...@Do...>]

On Sat, 26 Jan 2002, Rodrigo Damazio wrote:

> Johann Deneux wrote:
> 
> > On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
> >
> >>    I just realized - the interactive effect struct doesn't allow us 
> >> to assign independent parameters to the X and Y axes...it should 
> >> though, since the PID spec says there are two condition blocks for it 
> >> - one for each axis...is it okay to modify it to include separate 
> >> parameters??
> >>
> >
> > Definitely yes. I-Force also allows that.
> >
>    Okay, will do so...also, is itme who has an outdated version of 
> input.h, or does it really not have ET Ramp, Damper, and Inertia?? And 

Ramps did not seem to useful to me. Indeed, they can be realised using
other effects, for example, using a shaped constant effect.
However, I think they should be added in the API. It's up to the driver to
decide how to implement this effect.

About interactive effects: See these effects as functions from something
to a force.
Position -> Force : That's a spring
Velocity -> Force : That's friction (or damping, why does pid define both
as different effects ???)
Acceleration -> Force : That should be inertia. It's not implemented in
I-Force. Actually, Immersion seems to consider this to be the same as
friction.

I agree that we should add FF_INERTIA and FF_RAMP, but FF_DAMPER looks
pretty useless to me. Unless I missed the point ?

> what would FF_RUMBLE be?? Is it I-force specific?? If it's okay, I'll 

No, this effect is the "force feedback for the poor". It's used in IFeel
mice for example. It's just a simple vibration. You can find it in
some console joypads, too. For example, the AVB Pegasus joystick has
(should have, mine has none) a connector to add a joypad supporting rumble
effects.

> add FF_RAMP, FF_DAMPER, and FF_INERTIA since they're defined in the
> spec(5.1.1)...
> 
> >
> 
> > Anyway, we will have to change the API to take custom effects into
> > account.
> >
>    Yes, I know...have you decided how we'll do that?? I guess that 

No. The "1 parameter block - n effects" is appealing, but we must make it
hardware independant. Right now, there is no obstacle to doing it, as
I-Force and PID seems to share the same view of what to put into parameter
blocks. Is it a safe bet to assume future specs won't change ?

The other solution would be to hide these parameter blocks and let the
driver optimize its memory usage. This looks pretty ambitious to me,
though.

The last solution is to go for "1 parameter block - 1
effect" solution. It's safe, easy to implement, but it kills the
possibility to share parameters between several effects.

> since(in PID specs at least) custom effect data is sent on one(or more) 
> report by itself, saved in a memory position(just like an effect), etc., 
> we could just make an IOCTL to upload the custom data, then we can 
> normally upload an effect which points to that custom data...that would 
> require only minor changes to the existing code...
> 
> Rodrigo
> 
> P.S.: I've started libff too...send me all ideas you have for nice 
> things it could do...I'm using re-usable parameter blocks(something like 
> FF_create_constant(float direction, float magnitude, FF_envelope 
> *envelope, FF_trigger *trigger, FF_time *time, FF_flags flags)  )
> 

So you are going towards a user-visible 1-parameter-n-effects approach ?

-- 
Johann Deneux