Re: Interactive Effects

[Rodrigo D. <cu...@uo...>]

Johann Deneux wrote:

> 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=20
>>>> to assign independent parameters to the X and Y axes...it should=20
>>>> though, since the PID spec says there are two condition blocks for=20
>>>> it - one for each axis...is it okay to modify it to include=20
>>>> separate parameters??
>>>>
>>> Definitely yes. I-Force also allows that.
>>>
>>   Okay, will do so...also, is itme who has an outdated version of=20
>> 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=20
> driver to
> decide how to implement this effect.
>
       I'm in favor of implmenting it, to comply with the specs...

>
> About interactive effects: See these effects as functions from somethin=
g
> to a force.
> Position -> Force : That's a spring
> Velocity -> Force : That's friction (or damping, why does pid define bo=
th
> 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 knew this...if you look in Immersion Studio, you'll see you can=20
actually see a graph force vs. {position | velocity | acceleration }...

>
>
> I agree that we should add FF_INERTIA and FF_RAMP, but FF_DAMPER looks
> pretty useless to me. Unless I missed the point ?
>
       Well, I've tried creating some Damper effects - it does make a=20
difference...besides, it's in the specs...

>> 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 IFee=
l
> 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=20
> rumble
> effects.
>
       Oh, okay...doesn't it have any parameters?? Not even magnitude??

>> 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=20
> parameter
> blocks. Is it a safe bet to assume future specs won't change ?
>
       Well, if this model is working well, there'd be no reason for=20
them to change it... _if_ they ever do, we'll think about it...even=20
because if they change it, it'll have to be backwards-compatible...

> 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.
>
       Would even be nice, but I think we should leave this decision to=20
the programmer...

> 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.
>
       I prefer the first one...it's how I'm creating prototypes for=20
libff at least...

>> since(in PID specs at least) custom effect data is sent on one(or=20
>> more) report by itself, saved in a memory position(just like an=20
>> effect), etc., we could just make an IOCTL to upload the custom data,=20
>> then we can normally upload an effect which points to that custom=20
>> 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=20
>> things it could do...I'm using re-usable parameter blocks(something=20
>> like FF_create_constant(float direction, float magnitude, FF_envelope=20
>> *envelope, FF_trigger *trigger, FF_time *time, FF_flags flags)  )
>>
>
> So you are going towards a user-visible 1-parameter-n-effects approach =
?
>
       Yes(actually it's n-parameters-m-effects)...even if that happens=20
only at a library level, and the kernel works differently...obviously,=20
there will be some convenient functions like to delete an effect and all=20
its related parameter blocks, so if a programmer wants 1-to-1, he can=20
just do something like:

eff =3D FF_create_constant(0, 1, FF_create_envelope(bla bla),=20
FF_create_trigger(bla bla), FF_create_time(bla bla), 0);

and then later a:

FF_delete_effect_related(eff);

   Would free all parameters blocks allocated...obviously it needs some=20
checks like if the user did something like

eff2.envelope =3D eff.envelope;

   Then we'd need to set eff2.envelope to NULL, just so it can't get=20
sent and cause a memory bug...

Rodrigo

--=20
*******************************
* Rodrigo Damazio             *
* *************************** *
* cu...@uo...           *
* rod...@po... *
* ICQ: #3560450               *
* http://www.vros.com/cuddly/ *
* *************************** *
* Engenharia da Computa=E7=E3o    *
* Escola Polit=E9cnica          *
* USP - S=E3o Paulo             *
*******************************