   Hi! Problem with 'circuitry' program...
  Hi, this is my first post... I'm not posting in the beginners section because i've been making games for a while, so I know the basics, if nothing else :DOk, here's my problem.I'm making a game like Widget Workshop (If you haven't seen that, here's a pic: http://www.apple.com/education/LTReview/spring99/simulation/images/figure14.jpg - it's a real oldie, It's probably over 5 years old). Basically you have 'gadgets' which are connected up by wires via input + output ports.A gadget is loaded from a DLL, which contains functions that are called in certain situations (oninit(), onloop(), oninput(), etc).My objects are all instances of OBJ. When an object is clicked (let's say it was a button), it would run through its list of "child objects" (other OBJ's that are connected through the ports). These objects are all added to a temporary stack. On each game loop, the stack is traversed and all the objects on it are calculated (EG, the objects that recieved an input on the previous loop). So, this goes on as long as there is data travelling between objects.It seemed like the perfect system, but I have a problem!!Let's say you have this sort of situation:http://kris.acsv.net/widget_problem.gifBecause the bottom wire has an extra component, it takes an extra game loop for the signal from obj 2 to reach. Consequently the XOR gate is out of sync and won't produce the right output. After running a few other circuit simulations I've discovered that they have some way of making both signals reach the gate at the same time, regardless of how much stuff is in between the source and the destination. The problem is, I have no idea what it is!Anybody have any ideas about a workaround for this? Any help would be a godsend.Thanks,Kris   Moo![edited by - Kris A on February 1, 2004 3:03:34 PM][edited by - Kris A on February 1, 2004 3:04:15 PM]
  Ignore this if I have understood your problem incorrectly...Perhaps you shouldn''t work with a simple list of child objects. Just have a whole n-tree of objects representing all your gadgets. When one of them is clicked, you have a simple way of traversing through all input connectors at once on each update cycle. Go the whole tree up until you reach a gadget without an input connector.   - Christoph---Teamwork Software - Stuff That Does Something ;  well, I don''t know if  this would be realistic or not, but maybe you could introduce a "delay" component that you could tune to however long the other input would take to get there.Either that, or you could make the xor component simply wait for the second input.   Joel Martinezhttp://www.codecube.net/ ;  Cap''n Nuss: Not sure what you mean, sorry. I think either you have the wrong end of the stick, or I do :DJoel: Both of these ideas sprung to mind. I was going to do a delay system, but I''m trying to make this as user friendly as possible, so the user wouldn''t have to figure out how long a signal is to take to reach something.Also, if I made the XOR component wait for a signal from port 2 after recieving one through port 1, it might not get one (at least for a long time). If the idea of that particular gate was to only recieve one signal, it would be waiting for something that''s never to arrive. This would delay the whole circuit even more!(Good ideas though) ;  You say the objects are all traversed on each game loop, so I do not understand how any one element can be out of synch.Each game loop your stack would probably look like this:obj1 -> obj2 -> 2-way -> XOR -> the rest of itSo obj1 is updated, it sends a signal to XOR. obj2 is updated, it sends a signal to 2-way. 2-way is updates it sends the second input to XOR. XOR is updated and it computes its output from the two signals it received. And the loop continues.Maybe you could post some code or elaborate some more.   - lmov ;  OK, I''ll try again.  In the following text I''ll just take your visual illustration of the problem as the starting point.You''ll have some kind of data structure to represent your gadgets and how they''re connected. This will probably be some kind of linked list in a tree-like structure, like that: Obj2  |  |  |  |   Obj1  Splitter\  /  \ \/    \  \   / \   \ /  ...   XOR  Say, now, that the XOR gadget is clicked. If I understood you correctly, your program is to display the input signal received by the XOR gadget after that gadget has processed it according to some rules. To do so, take the XOR leaf of the tree-like thing and traverse up all the gadgets that are connected to the input ports of the XOR gadget. On each game loop, you query Obj1 for its output signal. Then, you query the Splitter for its output signal, which, in turn, has to query Obj2 to get its (the Splitter''s) input signal. This way, you don''t get any timing problems and everything works out fine.   - Christoph---Teamwork Software - Stuff That Does Something ;  Sorry, I haven't explained too well.Only objects that are actually 'being used' are traversed. This includes objects that have been interacted with by the user and objects that have just recieved an input.[obj 1]------>[obj 2]||__________[obj 3]In this example, obj 1 is a button. When it gets clicked, its target objects (obj 2 and obj 3) are given their new input valueobj2->input[port 0].value = obj1->output[port 0].value;obj3->input[port 0].value = obj1->output[port 0].value;Obj 2 and Obj 3 are then added to the 'queue'. On the next game loop, the queue is traversed, and obj 2 & obj 3 will both be considered (if they have any ports linked to other objects, they will send their data, etc).Because of this system, only a finite number of objects are traversed per loop, thus signals take a finite time to reach their destination, based on the number of objects they need to pass through.[obj 1]-------->[obj 2]-------->[XOR][obj 3]---------------------------|in this example, even if obj 1 and obj 2 both sent their outputs at the same time, the topmost signal would take one extra game loop to reach the XOR gate.Just to make sure.. here's a list of the items on the queue after each game loop:LOOP 1------obj 1 (triggered by user)obj 3 (triggered by user)LOOP 2------obj 2 (triggered by obj 1)XOR port 2 (triggered by obj 3)LOOP 3------XOR port 1 (triggered by obj 2)as you can see, it takes 3 loops for port 1 to recieve an input, but it only takes 2 for port 2 to recieve one.Edit: whoops, that took longer than I thought to write out [edited by - Kris A on February 1, 2004 3:43:02 PM];  HI. it looks pretty much like LabView if i''m not mistaken. well i think that a splitter like that just ''splits'' the signal, distributing it to another modules, and not doing any other operation with input can just pass to the next module in one clock time. let me explain myself:i think that any module that has some input data, once instanced in game, should check(or be given at start) the location where to get data. if that location is a splitter(memorized like a pointer to an object output or something) then it should change the ''pointer'' to the object that sends data through the splitter. it''s something like a late binding (OOP terminology), meaning that at launch time the objects link their inputs and outputs making abstraction of splitter and other conectors. So the splitter and other connectors are drawn in the simulation view(because they must be there), but the simulation bypass them in the background. I don''t know what I write is of some use, but that is my opinion.   Mihai ;  it's possible that I could do that, but as all of my objects exist as stand-alone (loaded and controlled via an external module), there'd be no way of it knowing how to do that, Especially since the problem occurs with any object 'en route', not just a splitter.Cpn. Nuss: I'm just reading your example now, I'm not too sure how feasable this would be with my system (yet)   [edited by - Kris A on February 1, 2004 3:47:38 PM];  Couldn't you just evaluate each branch independently in one go until you come to a gate? How often and in what situations does it calculate the result of the circuit? From your problem, all I can think of is that you just need to make sure that the "pulse" down the wire last longer than the time step that you are evaluating at. Wouldn't you get this problem with normal electronics if you have a wire twice as long as another, and the pulse lasted for only the time it took to travel down the shorter wire, hence meaning the pulse from the longer wire arrives just after the short one stopped.It looks like an interesting program, good luck  [edited by - ch1pz on February 1, 2004 4:06:48 PM]