i was trying to add some framedelaying into some plugs and i was trying this , see patch to see better .
Native and plug seem to behave the same apart from that the native can be connected to itself and plug one can not . what am i missing ?
also how can i make it delay more than one frame ?
public void Evaluate(int SpreadMax)
{
FOutput.SliceCount = SpreadMax;
Array.Resize(ref FMyLastState, SpreadMax);
for (int i = 0; i < SpreadMax; i++)
{
FOutput[i](i) = FMyLastState[i](i);
FMyLastState[i](i) = FInput[i](i);
//Thread.Sleep(1); I tried with Threading also
//but i presume this only make a 1 millisecond pause in the app not too sure .
}
}
you cannot do a framedelay as s plugin right now. if you need a custom functionality you have to use a combination of your code and the native node.
for delaying things more than one frame you would need a Queue-like buffer data structure, where you put in a value at the end and put out the first value and delete it.
Is it still impossible to write a custom FrameDelay node? Stuck at usual feedback task in DX11, programmed custom FrameDelay with vux help, but it doesn’t allow me to push data upstream. Can it be solved somehow?
yeah, its exactly like woei said- it can be done with two nodes: the Framer and the Delayer. The Delayer is connected upstream from the Framer, the Framer gets the data and pushes it into an unconnected input pin of the Delayer.
that way we can even use this combination for patched feedback loops, because it _safely_circumvents the sdk’s restrictions.
I coded my plugins generically (much like the Cons or the Buffer nodes in the sdk), so you can implement them for your own datatype with 3 lines of code.
Yeah, i’m currently using it, but in some cases texture is buggy or not all tFX is working. Maybe this hack broke something in flow pipeline.
Update:
Solved this by S and R nodes. Framedelay by message node is a little bit buggy for dx11 textures, because of the Update cycle and device context.
i considered a lot of cases to make sure it would not break vvvv node graph. however, if the dx11 graph has some underlying magic to it, i would be interested in your patch to see what’s breaking it.
would you be so kind and send me the patch? marko ät intolight dot de
Thanks for the peek. I see what you tried to do. I really like the possibilities.
Unfortunately this will not work with my basic generic nodes, nor with embedding DX11-Textures to Messages. There is simply too much difference in the handling of standard vvvv types and graphic resources.
But I’m sure you could adapt your S and R code to your own Frame and Delayer to make a FrameDelay module and hence the data flow safer.
Yep, i agree. But i planned to clone texture in another node and just send the link via Message - all is worked fine, except some bugs with tFX. Currently i still expecting some bugs with tFX, even with direct texture processing, so maybe this was a generic bug.
at the moment tfx behaves strangely after recompiling re-initializing re-whatevering during normal scenario.
btw i’m not that good in coding DX11 resources yet but i desperately need some framedelaying story can you send me that S+R workaround too ( _@mcro.de )? or upload it here?
