Re: [Libff-devel] Re: libff API

[Johann D. <jo...@do...>]

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 
> >> again, etc..
> >>
> >
> > Ok. That's what's being done now. 
> 
>         Do you think we should keep it this way?? I think it's good 
> 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).

> 
> >
> >>>>> 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... 
> >>>
>     How about this part?? How important is it??

I think it is. I agree we need to be able to query the device.

> 
> >>>>
> >>>>        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. 
> >>
> >>
> >>
> >>        Incredible enough, I looked, and there's NO basic joystick 
> >> library in freshmeat or sourceforge...just stuff like "run programs 
> >> with your joystick"...should we really include that in libff, or 
> >> 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, 
> 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 open
one joystick several times. This means that input and force feedback
libraries do not need to be aware of eachother.

> 
> >
> >>> >>>>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 ? 
> >>
> >>
> >>
> >>
> >>        You can't..specially if the kernel uses 1-to-1 parameter 
> >> models...you can update the copy that is in user memory, and that may 
> >> make managing effects easier, for example you can have all your 
> >> effects with the same envelope, and can change only one envelope, but 
> >> you still have to call an update for all the effects...perhaps we 
> >> could even write a little function that would update all effects that 
> >> use a certain block automagically...
> >
> >
> > By the way, I wondered what happened to those two messages I sent 
> > yesterday. I can see them in the archives, but I have not yet received 
> > them. I posted two messages entitled "API: handling effects" and "API 
> > suggestion: feature queries". Did you receive them ? 
> 
>         No, I didn't...maybe you should repost them...I'll look in the 
> archive anyway...
>         I'm attaching a rough draft of the API - it's just my initial 
> suggestion...please do criticize...
>         One point I forgot to mention is the whole thing about angle 
> units - in my suggestion I made it so the programmer can specify angles 
> in degrees(0-360), radians(0-2PI), grads(0-400), or raw(0-FFFF)...what 
> do you think about that??

Why not. I do not think it's necessary, as programmers can probably do 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.


-- 
Johann Deneux