Re: [Libff-devel] libff API

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

Johann Deneux wrote:

> On Sun, 17 Feb 2002, Rodrigo Damazio wrote:
>
>> Johann Deneux wrote:
>>
>>>>       My idea was not using a queue - it was just aborting and
>>>> returning an error and let the application decide whether it'll try=20
>>>> again, etc..
>>>>
>>> Ok. That's what's being done now.
>>
>>        Do you think we should keep it this way?? I think it's good=20
>> enough...
>>
>
> Yes. We can also add a FF_play_as_soon_as_possible function that takes
> care of the retries (the actual name of the function should be shorter,
> of course).
>
       That would need a thread just for handling the retries, wouldn't=20
it??

>>>>>>       I suppose there is another lib which can be used for=20
>>>>>> reading the device data?? Like axes position, buttons, etc...so=20
>>>>>> we don't need to worry about that, right?
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> No, we do need to take care of that.
>>>>
>>>>
>>>>
>>>>       Incredible enough, I looked, and there's NO basic joystick=20
>>>> library in freshmeat or sourceforge...just stuff like "run programs=20
>>>> with your joystick"...should we really include that in libff, or=20
>>>> would it be better to make a generic event library(like directinput)=
??
>>>>
>>> Well, there are PLib, SDL, libjsw, certainly ClanLib and maybe others.
>>
>>        I know...but should we implement input functions in libff too,=20
>> or should we just leave that up to other libs??
>>
>
> My philosophy is "If other people can do some work, let them do it".
> The nice thing about the drivers in Linux is that it is possible to ope=
n
> one joystick several times. This means that input and force feedback
> libraries do not need to be aware of eachother.
>
       Yes, I have realized that...it's really nice...

>>>>>>>>> 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=20
>>>>>>>>> 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=20
>>>>>>>> with that idea...but probably(and specially if the kernel=20
>>>>>>>> chooses 1-to-1 scheme), updating a block will only change the=20
>>>>>>>> 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=20
>>>>>>> looks
>>>>>>> like we should apply the change as soon as the parameter block=20
>>>>>>> is changed.
>>>>>>>
>>>>>>       An effect is a group of properties that will generate a=20
>>>>>> force...
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Then when you update a parameter you update the effect itself too.=20
>>>>> How can you update a parameter without updating the effect ?
>>>>
>>>>
>>>>
>>>>
>>>>       You can't..specially if the kernel uses 1-to-1 parameter=20
>>>> models...you can update the copy that is in user memory, and that=20
>>>> may make managing effects easier, for example you can have all your=20
>>>> effects with the same envelope, and can change only one envelope,=20
>>>> but you still have to call an update for all the effects...perhaps=20
>>>> we could even write a little function that would update all effects=20
>>>> that use a certain block automagically...
>>>>
>>>
>>> By the way, I wondered what happened to those two messages I sent=20
>>> yesterday. I can see them in the archives, but I have not yet=20
>>> received them. I posted two messages entitled "API: handling=20
>>> effects" and "API suggestion: feature queries". Did you receive them =
?
>>
>>        No, I didn't...maybe you should repost them...I'll look in the=20
>> archive anyway...
>>        I'm attaching a rough draft of the API - it's just my initial=20
>> suggestion...please do criticize...
>>        One point I forgot to mention is the whole thing about angle=20
>> units - in my suggestion I made it so the programmer can specify=20
>> angles in degrees(0-360), radians(0-2PI), grads(0-400), or=20
>> raw(0-FFFF)...what do you think about that??
>>
>
> Why not. I do not think it's necessary, as programmers can probably do=20
> the
> conversion themselves. I never heard anybody complaining that the math
> lib (cos, sin and friends) only handled radians. But people certainly
> won't complain if we give them macros to handle the conversions.
>
       I guess I'll just make it raw angles and leave all the conversion=20
to macros then...

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