Re: interactive effects

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

Johann Deneux wrote:

>On Sat, 26 Jan 2002, Rodrigo Damazio wrote:
>
>>Bj|rn Augustsson wrote:
>>
>>>Quoting Johann Deneux <jo...@Do...>:
>>>
>>>>About interactive effects: See these effects as functions from someth=
ing
>>>>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 thr=
u
>>>section 5.3, on page 12.
>>>
>>       It's just like he said...take a look at Immersion Studio...
>>
>
>The point was: what's the difference between friction and damping ? PID
>define both effect types, but on page 12 they use both terms to refer to
>the same function (force =3D f(Velocity)).
>
        Actually, I think that's not really up to us to discuss...if it=20
has two different IDs which can be sent to the device, then we should=20
implement it, and it's up to the device to make it different(or not)...

>>>>>what would FF_RUMBLE be?? Is it I-force specific?? If it's okay, I'l=
l
>>>>>
>>>>No, this effect is the "force feedback for the poor". It's used in IF=
eel
>>>>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...
>>
>
>It does not "work" right now, as it's not implemented (none of my device=
s
>support it). But people working on the IFeel mouse will probably use it.
>
>>>>The other solution would be to hide these parameter blocks and let th=
e
>>>>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
>>
>
>I also had a look, and found no reference to sharing parameter
>blocks. What they have is basically the following:
>- a struct DIEFFECT describing the basic attributes (direction,
>timing...). This struct has pointers to the two other structures
>- a struct DIPERIODIC, to set the period, phase...
>- a struct DIENVELOPE, for the envelope.
>
>None of these structures has ids. This makes me think parameter blocks
>cannot be shared, or at least the user has no control over it.
>
        There's struct DIPERIODIC, DIENVELOPE, then there's=20
LPDIPERIODIC, LPDIENVELOPE, etc. which are pointers to such=20
structs...that's when it happens...and in DIEFFECT struct, you can see th=
is:

    LPDIENVELOPE lpEnvelope;=20

        (I hate how obscure they make it, but it's a pointer)

>Updating effects is done the same way we do it (by sending the
>changed effect and specifying the id of the effect to change). I see no
>way change a parameter block alone.
>
        No, there isn't one at API level, but inside a program you can=20
use 1-to-n....but you're right, for the driver it seems like it's 1-to-1.=
..

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