Re: interactive effects

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

Bj|rn Augustsson wrote:

> Quoting Johann Deneux <jo...@Do...>:
>
>> 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 agree that they should be added to the API. I don't think a driver
> should decide to emulate one effect with another, except in extreme
> cases. This sort of thing is much better done in userspace. (A library
> for example.)

       libff...btw, does the API have a way to get the capabilities of a=20
PID device?? Like what effects it can produce??

>> About interactive effects: See these effects as functions from somethi=
ng
>> to a force.
>> Position -> Force : That's a spring
>> Velocity -> Force : That's friction (or damping, why does pid define=20
>> both
>> as different effects ???)
>>
>
> No idea. Note how the spec avoids talking about that about halfway thru
> section 5.3, on page 12.
>
       It's just like he said...take a look at Immersion Studio...

>>> 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 IFe=
el
>> 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.
>>
>
> Right.  This is not even defined in the PID spec, which is kind of
> weird.

       That's why I thought it might be I-force specific...well, if it=20
works, just leave it there...

>>>> 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=20
>> 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 ?
>>
>
> Actually, having thought about this some more, this is NOT how PID
> works, unless you're in driver-managed mode (which the MS FF2 isn't -
> it uses the "device managed"  memory model. (Maybe it can switch, I
> haven't checked that carefully, but I don't think so.)
>
> Here you get a number (in the FF2 case, 40) "slots" to put effects in,
> and they each have room for whatever extra parameter blocks are needed.
> (Ie, they're often oversized.) You can _not_ share parameter blocks=20
> between effects in this model.

       You're right - I hadn't thought about this...so we have two=20
choices - wec

>> 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.
>>
>
> Absolutely. Again, it could be done in a library.
>
> Hmm, Rodrigo, did you have a look at what the MS DirectInput looks=20
> like? How
> do they do this?
>
       Yes, I have - it seems they use 1-to-many...look at this:

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dx8_c/=
directx_cpp/Input/CPP_Tuts/Tut4/Step4CreatingEffect.asp

       It's a tutorial on how to create effects... and has links to the=20
structs definitions...

>> 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.
>>
>
> Right.
> Now for custom effects, I think we should have a separate call to uploa=
d
> those. Having the variable length array thing you suggested is nice, bu=
t
> then we can't add more fields to the strut after that if we choose to
> later. (Or can we? I seem to remember that the variable length array ha=
s
> to be the last member of a struct, but I'm not sure...)
>
       We can add members before the variable-length array...

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             *
*******************************