|
From: Johann D. <jo...@do...> - 2002-03-19 16:41:44
|
Alexander Rawass wrote: > Hi, > > I had the idea that we should implement 'effect groups' in libff. I believed that's planned. I don't know if it's in the headers, though. > > Because I want to have many effects - most of them consisting of 2 or 3 > simple effects, and they won't fit in the memory of all devices, I believe. > > So libff should care take of that, allow the user to design effect groups, > and then libff should find out automatically which effects to stop and which > to play. > > For VS, I would have the following effects groups: > > * afterburner on > - jerk 0 > - wiggle x 1 > - wiggle y 1 > *afterburner off > - wiggle x 2 > - wiggle y 2 > * bolt fired > - jerk 0 > - vibrate x 2 > * shield hit > - jerk 0 > - vibrate 1 > > etc etc > > The numbers are meant to be effect priorities, with 0 being the highest one. Good idea. >[...] > > Some more questions: > > If I get the number of effects with EVIOCGEFFECTS - what does this tell me? > > a) the (maximum) number of effect that can be played at the same time > b) the (maximum) number of effects that can be hold in memory It does not tell much really. I should remove this ioctl from the API. For I-Force devices, it's the maximal number of effects that can be stored, which might as well be the maxmimum number of effects playable at the same time. Since several applications may use the device at the same time, nothing tells you will actually reach this number. > > Do different effect types use a different amount of memory - like, you can > upload 20 constant effects or 10 periodic effects, because periodic effects > need more mem etc? They do take a different amount of memory, indeed. However, on the devices I know, the amount of RAM is largely enough to contain all the heaviest effects. > > > If I am getting an error when I am updating an already existing effect (when > I am updating too fast, I mean) - does this mean > a) that this special effect cannot be updated at the moment or > b) that the device cannot be updated at the moment > > If a), I could try and find another slot that is currently capable of > updating. It's a). This does not exclude the possibility of b), however. -- Johann Deneux |