Datapipeline

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Datapipeline

      There is one important point i found not to be covered by mr.mike in gamecoding complete (or other books/articles i've read so far) which is the passing around of data or the datapipeline between subsystems. what i mean is for example an explanation how the orientationmatrix gets manipulated by the animation subsystem then how it is transferred to the (async) physics which chews on it and finally how the renderer pulls the calculated orientationmatrix from somewhere to render an object and the audiosystem gets the active position to update the soundsourceposition.
      i've been struggling with this problem a while mainly because i don't have any real experience how this is accomplished in games. so my question is: how is this done in real gameengines?

      i just can imagine three ways:
      - hardcoded instructions like in your game of teapot wars (e.g. a direct call to physics from ai for rotation/movement). if yes, what is then the normal flow? which subsystem does what e.g. ai controls the movement plainly through direct/indirect calls to physics?
      - totally through events (send an event when ANYTHING from an object changes: e.g. orientationmatrix)
      - pull data from subsystem e.g. each subsystem holds an instance to the object and this object acts as a "hub" between all subsystems. the physics and the animation continuously updates the orientationmatrix (most probably async) and as often the audio and renderer work they pull the information they need from it.

      most probably in real games there are lots of hardcoded instructions to keep it tight (prevent butterfly effect) but this is inflexible, events would make it easy to be run async but too much events could bring the system down and pulling data becomes difficult to be synced.

      Could you give me some advice or hints?
    • RE: Datapipeline

      Take another look at the event chapter! I think that's what you are looking for.

      For the example you mention - the matrix doesn't get shunted around, rather the rotation or position deltas do, and the matricies are likely either shared in a central spot OR they sometimes just get duplicated.

      Duplicates are useful if you can't count on having the authoritative copy, such as when the renderer stores the matrix for an object which is also stored authoritatively on a game server somewhere else.
      Mr.Mike
      Author, Programmer, Brewer, Patriot