   Building a dependency graph for paralleization / buffering
small problem with diagram, should be a line between F1--->F4pseudo code of node behaviourProcess(){   for each input, get input node's buffered state do some snazoo stuff with it   store to new_state }AdvanceFrame(){   buffered_state = new_state}G's on the diagram are "generators" and are not dependent on any inputs for determining the following state. Fs are processors which can be fed-back into each other - with a 1 state-length delay.if we simply foreach(node) process and then follow up with foreach(node) advanceframe, what we get is when we have a chain like this:[G]->[f1]->[f2]->Endby the time G's state makes it all the way to "End" we have introduced a state delay of three, so we need to changeG1.ProcessF1.ProcessF2.ProcessG1.AdvanceFrameF1.AdvanceFrameF2.AdvanceFrametoG1.ProcessG1.AdvanceFrameF1.ProcessF1.AdvanceFrameF2.ProcessF2.AdvanceFramebut if we had the following layout[G]-[F1]-[F3]  \ /   -[F2]-we would want the following "work order" created****queue 1****G1.ProcessG1.AdvanceFrame****queue 2****F1.ProcessF2.ProcessF1.AdvanceFrameF2.AdvanceFrame****queue 3****F3.ProcessF3.AdvanceFrameSo that I no longer have the state-delay between elements, and also can parallelize each queue.In the big diagram I have colour coded to show the order I want this to run in, Red being Queue 1, Orange being Queue 2. With this "method" feedback will still have a 1-state delay, but that is okay for my purposes.Each of my nodes is aware of all nodes connected both ways (in and out) but I am having a difficult time figuring out exactly how to build the algorithm that takes the basic graph, and seperates it out into "work queues" ...if that makes sense!Sorry if it's a TL;DR; just been stumped on this one for a while and figured I'd dump my brain-storming to the knowledgable folks of General Programming!thx!!!   
Quote:Original post by djzEach of my nodes is aware of all nodes connected both ways (in and out) but I am having a difficult time figuring out exactly how to build the algorithm that takes the basic graph, and seperates it out into "work queues" ...if that makes sense!Topological sorting only works on graphs without cycles.If there is a cycle, break it, and put all the output for processing on next step.Example:+--> ReadInput|   v|Update|   v|Render+--------+Cycle here needs to be broken after render. Usually, there would be some state. Due to concurrency, the simplest solution is to use multiple buffers. In above case, Input/Update/Render would all read old state, and produce new state. Then, old state gets discarded, and new state becomes old state.Same approach applies to your problem. F4 would not be writing to F1, but future F1.   ;Quote:Original post by AntheusQuote:Original post by djzEach of my nodes is aware of all nodes connected both ways (in and out) but I am having a difficult time figuring out exactly how to build the algorithm that takes the basic graph, and seperates it out into "work queues" ...if that makes sense!Topological sorting only works on graphs without cycles.If there is a cycle, break it, and put all the output for processing on next step.Example:+--> ReadInput|   v|Update|   v|Render+--------+Cycle here needs to be broken after render. Usually, there would be some state. Due to concurrency, the simplest solution is to use multiple buffers. In above case, Input/Update/Render would all read old state, and produce new state. Then, old state gets discarded, and new state becomes old state.Same approach applies to your problem. F4 would not be writing to F1, but future F1.radical! thanks man! always glad to read about a new algo; and yup - using double buffered states already