Re: [Libff-devel] Re: libff API

[Johann D. <de...@if...>]

Rodrigo Damazio wrote:
> Johann Deneux wrote:
> 
>> On Fri, 15 Feb 2002 20:41:27 -0200
>> "Rodrigo Damazio" <cu...@uo...> wrote:

>>
>> My first idea was that we should be able to ask the device if it's 
>> ready to
>> accept an update. For example, with iforce devices, we must wait that 
>> the device
>> acknowledges the update before performing a new update. However, it is 
>> ok to
>> update effect 2 even if we haven't yet received the ack for effect 1. 
>> That's why
>> my second thought was to do it on a per-effect basis.
>>
>        I see...that's possible...if the device is not ready, what should 
> we do?? Make it async and return an error, or should we just sit and 
> wait 'til it's possible??

The iforce module just refuses the update and return an error. The 
reason for doing that is that generally applications that flood the 
device use a "ongoing update" algorithm (for example to render a force 
computed by the physics engine). In that case, missing an update is not 
too serious.
The async solution is not too good. Whatever size we may choose for the 
queue, it will be filled.

> 
>>
>> Maybe there are properties of the device itself that could be queried, 
>> too.
>> Do you see any such dynamic property (ie beside the name, type, 
>> effects supported
>> by the device) ?
>>
>        That'd be stuff like gain, which actuactors are enabled, etc...
>        I suppose there is another lib which can be used for reading the 
> device data?? Like axes position, buttons, etc...so we don't need to 
> worry about that, right?

No, we do need to take care of that.

> 
>> If there is no effect, the status of the device is obvious: it's doing
>> nothing (what could it do ???)
>>
>        It could be playing effects from another application =c))

Right.

>>>
>>>> Other question: what's your opinion about the shared parameter block 
>>>> issue ? It's seems we are
>>>> forced to go for the restrictive 1-parameter 1-effect scheme on the 
>>>> driver side, but that does
>>>> not mean we cannot try to emulate it on the API side.
>>>>
>>>        I'm in favor of it - in fact the API has already started with 
>>> that idea...but probably(and specially if the kernel chooses 1-to-1 
>>> scheme), updating a block will only change the effects where it is 
>>> used, if the effect itself is updated...
>>>
>>
>> We will need to define clearly what we mean by effect. To me, it looks
>> like we should apply the change as soon as the parameter block is 
>> changed.
>>
>        An effect is a group of properties that will generate a force...

Then when you update a parameter you update the effect itself too. How 
can you update a parameter without updating the effect ?

> 
>        Btw, should we implement effect groups, like in Immersion Studio? 
> It could be useful...

I too thought about that. See my other posts to this list...

-- 
Johann Deneux

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif